1 2015-05-15 00:26:10 <cfields> BlueMatt: i think i might've tracked down the comparison tool's sporadic NPE. Please shoot me a ping when you're around
 2 2015-05-15 01:23:51 <Diablo-D3> http://www.rfc-editor.org/rfc/rfc7540.txt
 3 2015-05-15 01:23:53 <Diablo-D3> ITS NOW A THING!
 4 2015-05-15 02:17:49 <hulkhogan_> cfields: if you have a chance do you mind updating 6119 with that? if not np as well
 5 2015-05-15 10:05:19 <wumpus> michagogo: it's not a "default" just an example, but feel free to change it in depends/README.usage
 6 2015-05-15 10:08:21 <wumpus> I'd like to reorder the depends documentation, one thing is that README.usage should be the default README; #6045 is a good start
 7 2015-05-15 10:14:24 <wumpus> going to change the default too, and maybe add a list of example targets
 8 2015-05-15 15:34:15 <mjerr> Is there any active discussion currently on adding SIGHASH_NOINPUT? I looked, but couldn't find anything in the mail archive, just something from this irc# from one month ago between gmaxwell and tdryja..
 9 2015-05-15 16:30:27 <Eliel> I think I heard of a simple wallet daemon made with bitcoinj with support for generating addresses, calculating balance (individual and address balances) and sending transactions. I forget the name though. Any pointers?
10 2015-05-15 17:26:40 <BlueMatt> cfields: ping
11 2015-05-15 17:26:50 <cfields> BlueMatt: pong
12 2015-05-15 17:27:27 <BlueMatt> yea, there may be shit because of https://github.com/bitcoin/bitcoin/pull/5422
13 2015-05-15 17:27:32 <BlueMatt> ie branches may be updated to that
14 2015-05-15 17:28:55 <cfields> looking
15 2015-05-15 17:32:53 <intx> does bitcointools work if I only have the wallet.dat file?
16 2015-05-15 17:33:01 <intx> or do I need to download the whole blockchain?
17 2015-05-15 17:33:16 <cfields> BlueMatt: atm, i don't think we want to be adding more tests to the java comparison tool, given the movement on the python framework
18 2015-05-15 17:34:34 <cfields> mm, though i suppose they serve different purposes here
19 2015-05-15 17:34:44 <cfields> sdaftuar: thoughts?
20 2015-05-15 17:36:17 <BlueMatt> cfields: they serve very different purposes, and testing consensus via the rpc is kinda shitty
21 2015-05-15 17:36:33 <BlueMatt> (ie we should have a tester that tests spv consensus, too)
22 2015-05-15 17:36:47 <BlueMatt> for other clients
23 2015-05-15 17:42:18 <cfields> BlueMatt: ok, it looks like this is just a snapshot of master with 5 commits on top?
24 2015-05-15 17:42:44 <BlueMatt> probably something like that
25 2015-05-15 17:44:09 <Luke-Jr> petertodd: should 5496 be closed? where do I review/comment?
26 2015-05-15 17:45:38 <Luke-Jr> nm, I think I see the difference
27 2015-05-15 17:45:49 <petertodd> Luke-Jr: seems like we have rough consensus that a separate opcode for RCLTV is appropriate
28 2015-05-15 17:46:05 <petertodd> Luke-Jr: in whcih case it could be closed
29 2015-05-15 17:46:36 <Luke-Jr> petertodd: or negative CLTV for relative; why are you preventing that at the moment?
30 2015-05-15 17:47:07 <petertodd> Luke-Jr: because I don't want to get caught up in some bug related to it - not to mention script themselves can easily make that mistake
31 2015-05-15 17:47:13 <BlueMatt> cfields: gotta run...feel free to leave messages with the bouncer :)
32 2015-05-15 17:47:22 <cfields> BlueMatt: how about updating the block-tester without adding the new reorg test?
33 2015-05-15 17:47:36 <cfields> ok
34 2015-05-15 17:47:53 <petertodd> Luke-Jr: my preference is to have a separate GET_TXOUT_HEIGHT opcode that requires the txout to have >MATURITY confirmations
35 2015-05-15 17:48:25 <Luke-Jr> I guess it makes sense, considering CLTV is simpler
36 2015-05-15 17:48:55 <Luke-Jr> petertodd: 5-byte bignums only go to 2⁑32-1?
37 2015-05-15 17:49:15 <petertodd> yes, which is fine becaue nLockTime itself is 32bits
38 2015-05-15 17:49:24 <petertodd> (unsigned 32 bits)
39 2015-05-15 17:50:10 <Luke-Jr> I would have expected 2**39-1
40 2015-05-15 17:50:42 <petertodd> oh, yeah, the 5-byte-bignums go up to 2**39-1, but it's irrelevant as nLockTime itself doesn't
41 2015-05-15 17:51:20 <Luke-Jr> ok, I suggest clarifying that in the comment :p
42 2015-05-15 17:51:23 <petertodd> you'll note I have tx_(in)valid testcases for the entire range of nLockTime
43 2015-05-15 18:02:45 <andytoshi> what is the best way to do time sidechannel measurements for libsecp256k1?
44 2015-05-15 18:04:15 <gmaxwell> you can use the TSC but on a normal host its very noisy. TD-Linux is working on a power sidechannel analysis rig (that will also make precise time sidechannel measurements as a side effect).
45 2015-05-15 18:04:23 <gmaxwell> andytoshi: for now what sipa and I have done is read the assembly.
46 2015-05-15 18:05:59 <joshc> maybe perf would give you some useful metrics (cycle counts/instruction counts, etc)
47 2015-05-15 18:09:33 <gmaxwell> rusty was suggesting we create a valgrind tool that records instruction and memory access traces; which seems reasonable. (I'd previously used valgrind to find branches on secret data).
48 2015-05-15 18:17:44 <ajweiss> what kind of sampling rates do you need to actually carry out a power sidechannel attack?
49 2015-05-15 18:18:01 <gwillen> missed him by 3 seconds :-P
50 2015-05-15 18:25:25 <gmaxwell> ajweiss: depends on the amount of leakage!
51 2015-05-15 18:29:13 <gmaxwell> ajweiss: there have been implementations leaky enough that you could measure the nonce hamming weight based on signature response times across the network.
52 2015-05-15 18:47:03 <morcos> BlueMatt: Did you see the new python p2p code, I think eventually it could be made to recreate all the tests in the java tool, although there may still be a fair amount of work to do before we get there.
53 2015-05-15 18:59:10 <mjerr> Is there any active discussion currently on adding SIGHASH_NOINPUT? I looked, but couldn't find anything in the mail archive, just something from this irc# from one month ago between gmaxwell and tdryja..
54 2015-05-15 19:16:04 <jgarzik> morcos, +1 that would be fantastic
55 2015-05-15 19:16:41 <jgarzik> morcos, none of the core devs save BlueMatt ever touch Java, which is a problem
56 2015-05-15 19:16:55 <jgarzik> (problem in depending on a Java tool, that is)
57 2015-05-15 20:03:19 <BlueMatt> cfields: I want the new reorg test for pruning testing :)
58 2015-05-15 20:04:47 <BlueMatt> morcos: yes, I was aware it was being done....personally I find the python tests even more unreadable than the java stuff (or at least harder to work with), but thats just because our python tests are a shitshow
59 2015-05-15 20:05:09 <BlueMatt> jgarzik: yes, and they should generally be rewritten in something non-java
60 2015-05-15 20:07:56 <jtimon> mhmm, not sure what is wrong with https://travis-ci.org/bitcoin/bitcoin/jobs/62742395 timeout?
61 2015-05-15 20:08:44 <jtimon> cfields can you take a look?
62 2015-05-15 20:08:52 <cfields> wumpus: around?
63 2015-05-15 20:09:08 <cfields> jtimon: that's a symptom of the stale caches. If wumpus is around, he can clear it for you
64 2015-05-15 20:09:30 <jtimon> oh, great, thanks
65 2015-05-15 20:09:46 <cfields> those should all be fixed now, just need to nuke all of the caches
66 2015-05-15 20:09:59 <cfields> BlueMatt: ^^ is why we can't add any extra time to our tests at the moment :(
67 2015-05-15 20:10:56 <cfields> hmm, might be worth re-arranging some, though. there's really no need to run the comparison-tool for the same test where we build bitcoin-qt
68 2015-05-15 21:03:53 <BlueMatt> cfields: ideally someone would rewrite all the comptool tests and remove the damn thing
69 2015-05-15 21:04:04 <BlueMatt> I dont care too much in what language, but something that doesnt depend on bitcoin-rpc
70 2015-05-15 21:14:08 <andytoshi> can somebody explain https://travis-ci.org/bitcoin/secp256k1/jobs/62756337 to me? this it the only build that fails here, "file not found" does not make sense to me
71 2015-05-15 21:18:09 <andytoshi> oh, i got it, i had to update Makefile.am for `make distcheck` to work
72 2015-05-15 23:11:29 <phantomcircuit> cfields, was there a particular reason for not passing the scripterror value back from bitcoinconsensus_verify_script ?
73 2015-05-15 23:12:01 <cfields> phantomcircuit: yes, we didn't want them to be considered part of the api
74 2015-05-15 23:12:16 <cfields> also, didn't want people relying on the values rather than the bool return value
75 2015-05-15 23:14:12 <phantomcircuit> that makes sense but is unfortunate for my application
76 2015-05-15 23:14:13 <phantomcircuit> heh
77 2015-05-15 23:14:29 <cfields> phantomcircuit: sounds like it was the right call then :p
78 2015-05-15 23:14:45 <phantomcircuit> psh i know what im doing!
79 2015-05-15 23:15:14 <cfields> heh
80 2015-05-15 23:39:29 <andytoshi> travis passed libsecp256k1 #252 :D