1 2015-05-23 02:22:56 <Luke-Jr> why are we using unsigned int for sizes in libconsensus, rather than size_t?
 2 2015-05-23 02:24:53 <gmaxwell> there is plenty of reason to use "int" -- because use of unsigned often is a trap due to C promotion rules, but I dunno why it would use unsigned int over size_t.
 3 2015-05-23 02:31:37 <Luke-Jr> feels like a portability bug waiting to happen
 4 2015-05-23 03:39:27 <andytoshi> in libsecp256k1 how can i build the tests binary with no optimization?
 5 2015-05-23 05:07:22 <cfields> andytoshi: ./configure CFLAGS="-O0 -g"
 6 2015-05-23 05:07:28 <cfields> assuming you want debug symbols too
 7 2015-05-23 05:08:04 <cfields> Luke-Jr: size_t is implementation defined too
 8 2015-05-23 05:08:27 <Luke-Jr> cfields: yes, but it must be large enough for the biggest possible object
 9 2015-05-23 05:08:50 <Luke-Jr> unsigned int could theoreticalyl be 16-bit on a system with 640 GB of memory ;)
10 2015-05-23 05:09:57 <Luke-Jr> not a practical problem since Scripts can't go that big, but still ugly to assume IMO
11 2015-05-23 05:10:30 <phantomcircuit> Luke-Jr, er... is there anything that actually limits the size of a script besides blocksize + overhead?
12 2015-05-23 05:11:36 <cfields> Luke-Jr: i don't think that's a practical concern, though i do think that anything descriptive should be in absolute terms
13 2015-05-23 05:11:50 <cfields> for ex, there's that get_int() in CScriptNum that's always felt very nasty
14 2015-05-23 05:12:24 <Luke-Jr> phantomcircuit: yes
15 2015-05-23 05:13:19 <Luke-Jr> phantomcircuit: shouldn't you know this⁈
16 2015-05-23 05:14:15 <Luke-Jr> 10k on script itself, 520 bytes on constant data, 1000 elements shared between both stacks
17 2015-05-23 05:16:42 <phantomcircuit> Luke-Jr, the stack size limits and push size limits are enforced only when the op is executed
18 2015-05-23 05:16:48 <phantomcircuit> unless there's some check that im missing
19 2015-05-23 05:17:09 <phantomcircuit> oh yeah i see the 10k script size limit
20 2015-05-23 05:18:10 <phantomcircuit> that makes something i was working on mildly easier
21 2015-05-23 05:21:44 <Luke-Jr> phantomcircuit: no, the push size limit is effective even when not executed
22 2015-05-23 05:23:46 <Luke-Jr> lesson of the night: remember that when you have configured with --disable-tests, src/test/test_bitcoin will pass even when you break things
23 2015-05-23 05:27:51 <phantomcircuit> Luke-Jr, the script parser?
24 2015-05-23 05:28:34 <Luke-Jr> phantomcircuit: the interpreter checks the size of all pushes even when not executing them
25 2015-05-23 05:29:24 <phantomcircuit> ah right
26 2015-05-23 05:29:34 <phantomcircuit> GetOp is called even after a negative OP_IF
27 2015-05-23 05:29:42 <phantomcircuit> which makes sense otherwise you'd end up with gibberish
28 2015-05-23 08:55:55 <ronkrt> What is the SCRIPT_ADDRESS
29 2015-05-23 12:43:01 <lclc> Where does the LogPrint() go?  Can't find anything in debug.log
30 2015-05-23 13:44:19 <akstunt600> akit should be debug.log might have to check log levels
31 2015-05-23 16:33:00 <Luke-Jr> cfields: FYI, user building 0.10 with -j6 got: /usr/bin/ld: ./leveldb/libleveldb.a(log_writer.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
32 2015-05-23 16:33:12 <Luke-Jr> cfields: make clean and rebuild worked, so I'm guessing a race
33 2015-05-23 16:58:30 <www> hey
34 2015-05-23 16:58:39 <www> what is the minimum length of a bitcoin signature?
35 2015-05-23 20:06:26 <jonasschnelli> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/6103#issuecomment-104940082 the PR currently allows you to select between hashes and complete data for blocks and transactions.
36 2015-05-23 20:07:11 <Luke-Jr> jonasschnelli: as a command line option, which is dumb
37 2015-05-23 20:08:21 <jonasschnelli> Luke-Jr: Ah. I see what you mean. But wouldn't publish both formats generate a overhead even if you only listen to one of the possible formats?
38 2015-05-23 20:15:08 <Luke-Jr> jonasschnelli: ZeroMQ should take care of it
39 2015-05-23 21:11:58 <cfields> Luke-Jr: eh? Sounds like they had object left over from a previous build
40 2015-05-23 21:13:41 <Luke-Jr> cfields: supposedly it was a new clone
41 2015-05-23 21:13:51 <Luke-Jr> and even if they had, the build system should rebuild it :p
42 2015-05-23 21:14:55 <cfields> not if configure options had changed... is this in gentoo where the system leveldb is an option?
43 2015-05-23 21:15:27 <Luke-Jr> not to my knowledge
44 2015-05-23 21:15:40 <Luke-Jr> although it is my ljrP branch, which has the configure changes for that
45 2015-05-23 21:15:50 <Luke-Jr> but afaik he was never using it
46 2015-05-23 21:16:40 <cfields> Luke-Jr: as far as i know, there's no way for 'make clean' + 'make' to fix a PIC build problem, unless the config had changed in between
47 2015-05-23 21:17:07 <Luke-Jr> cfields: my guess was that the .o file was only partly written or something, when the .a got made
48 2015-05-23 21:17:13 <Luke-Jr> but it's just a guess
49 2015-05-23 21:18:27 <cfields> that'd be pretty freakish, but i don't think it could happen since we just tell leveldb "make -C leveldb libleveldb.a" or so
50 2015-05-23 21:18:34 <cfields> 10:1 it's a stale object somewhere :)
51 2015-05-23 21:19:11 <Luke-Jr> unfortunately, it's not reproducable, so :/
52 2015-05-23 21:19:39 <cfields> ok. I'm happy to take a look, just not much to go on there.
53 2015-05-23 21:20:19 <Luke-Jr> I don't expect there to be anything to go on, just thought you might want to know.
54 2015-05-23 21:20:53 <cfields> in that case, thanks :). I'll watch out for that
55 2015-05-23 21:21:38 <Luke-Jr> np