1 2014-11-04 00:15:17 <gmaxwell> belcher: first known CJs on the network were paid... there is nothing special about doing that but it complicates making the values indistingushable.
 2 2014-11-04 00:16:52 <belcher> interesting, didnt know they were paid
 3 2014-11-04 00:16:58 <belcher> the payment is added to the change address, which under darkwallet's scheme is already not private
 4 2014-11-04 00:21:37 <belcher> but is there any attacks you can see against the scheme? someone suggested it might make it easier for sybils because now they get paid
 5 2014-11-04 00:23:46 <gmaxwell> maybe, but sybils help your privacy against anyone who isn't getting data from the sybil.
 6 2014-11-04 00:25:25 <belcher> also there's the idea that sybils who get your data will undercut everyone else, since honest market makers will always charge more as privacy data isnt valuable to them
 7 2014-11-04 00:25:42 <belcher> so always going for the cheapest offer might be playing into the hands of sybils
 8 2014-11-04 05:11:31 <aburan28> "An attack on the timestamp semantics of Bitcoin" http://bramcohen.com/2014/11/03/an-attack-on-the-timestamp-semantics-of-bitcoin
 9 2014-11-04 05:12:36 <gmaxwell> aburan28:  Too bad he moderated my response. I also replied on reddit: http://www.reddit.com/r/Bitcoin/comments/2l83y5/an_attack_on_the_timestamp_semantics_of_bitcoin/
10 2014-11-04 05:35:25 <chaord> hi guys, any dev's know off the top of their head what would happen if a miner solves a block, submits it to the network, but voluntarily sets the generating transaction to have maturity of, say, 2000 blocks (instead of the current 100 blocks i think it is)
11 2014-11-04 05:35:39 <chaord> would the network still accept the block, or is the 100 block maturity hardcoded?
12 2014-11-04 05:37:07 <gmaxwell> There is no signaled value at all, so nothing to set... it's just a block validity rule that coinbase tx cannot be spent for 100 blocks.
13 2014-11-04 05:38:24 <chaord> gmaxwell: thanks for the quick response....yah, that was my understanding as well
14 2014-11-04 05:38:38 <chaord> was mostly just curious ;)
15 2014-11-04 06:17:36 <Luke-Jr> rebased https://github.com/bitcoin/bitcoin/pull/5103 , last PR dependency for block proposals
16 2014-11-04 06:22:48 <gmaxwell> Luke-Jr: any chance you could give https://github.com/bitcoin/bitcoin/pull/5161 some testing?  I'd like to get some third party testing on it.
17 2014-11-04 06:33:50 <Luke-Jr> gmaxwell: sure, gimme a bit
18 2014-11-04 06:46:07 <sipa> cfields: yes
19 2014-11-04 06:48:36 <cfields> sipa: ok, I've got it worked up that way. With those changes, it pretty much completely defeats the purpose of the original PR by just flat-out deleting the logging and replacing it with a single error-code. But I believe that's what you wanted intially anyway
20 2014-11-04 06:50:22 <cfields> I'll go ahead and PR that anyway, since the error codes need to be done either way for the lib. If anyone objects too loudly I can put back the more fine-grained ones I suppose.
21 2014-11-04 06:50:52 <sipa> right, that sounds fine
22 2014-11-04 06:53:08 <cfields> great, thanks
23 2014-11-04 07:10:54 <chaord> in the dev docs regarding a coinbase transaction, it says that there is a special coinbase field that replaces the field that would normally hold a signature script secp256k1 signature. However, is there a particularly good protocol reason why a coinbase transaction shouldn't support a, for example, p2sh type transaction?
24 2014-11-04 07:11:21 <chaord> also, if this question is something that i should be asking elsewhere, please let me know...it just seemed like something that only a dev would know ;)
25 2014-11-04 07:13:26 <sipa> chaord: you're confusing inputs and outputs
26 2014-11-04 07:13:57 <sipa> the part that is special in a coinbase transaction is the input (it has to have exactly one, and it doesn't contain an actual script with a signature, but just arbitrary data)
27 2014-11-04 07:14:11 <sipa> the outputs of a coinbase transaction are completely normal, and can indeed be p2sh or anything
28 2014-11-04 07:14:56 <chaord> sipa: got it...and yes, you're right, i was confusing inputs and outputs (i'm rusty on the protocol side), thank you for your prompt response and setting me straight ;)
29 2014-11-04 07:16:08 <chaord> sipa: while I have you, so then the network simply ignores an attempt to spend outputs for a coinbase transaction until after 100 blocks then, correct?
30 2014-11-04 07:16:36 <sipa> not just ignores; they're strictly invalid
31 2014-11-04 07:16:45 <chaord> understood
32 2014-11-04 07:17:02 <chaord> thanks so much for taking the time to clarify that for me...i greatly appreciate it!
33 2014-11-04 07:17:04 <sipa> a block which tries to spend coinbase outputs before 100 blocks have passed, is invalid as well
34 2014-11-04 07:17:33 <chaord> makes sense
35 2014-11-04 07:18:45 <sipa> cfields: btw, how do you make make (ha!) spit out those nice 'CXX' etc lines, rather than full commands?
36 2014-11-04 07:20:08 <cfields> sipa: uhm, i have a branch around for libsecp256k1 that fixes all that
37 2014-11-04 07:20:19 <cfields> forgot all about it. want me to PR it, i suppose?
38 2014-11-04 07:20:26 <sipa> why does this not surprise me? :p
39 2014-11-04 07:20:27 <sipa> yes :)
40 2014-11-04 07:20:41 <cfields> sec, i can give you a quick one-liner
41 2014-11-04 07:20:54 <cfields> there are a few other little fixups wrt the assembler, though
42 2014-11-04 07:21:59 <Luke-Jr> sipa: they're not *strictly* invalid - you won't get DoS-banned for them (I hope)
43 2014-11-04 07:22:24 <Luke-Jr> they're treated identical to if the output doesn't exist yet
44 2014-11-04 07:22:25 <sipa> Luke-Jr: i mean it's a consensus rule that such transaction are invalid
45 2014-11-04 07:22:31 <cfields> sipa: ah, i think it was buried in a PR i actually pushed. sec.
46 2014-11-04 07:22:41 <sipa> but consensus rules only apply to things inside blocks, of course
47 2014-11-04 07:22:49 <Luke-Jr> k
48 2014-11-04 07:22:59 <Luke-Jr> hm, we really have like 3 sets of rules now, don't we? :x
49 2014-11-04 07:23:17 <Luke-Jr> consensus rules, anti-DoS ban rules, and policies :p
50 2014-11-04 07:25:03 <cfields> sipa: https://github.com/theuni/secp256k1/commit/f180ef783a273f68c5688c2cb03218866d2fed21
51 2014-11-04 07:25:12 <cfields> i'll dig up the other changes and PR em tomorrow
52 2014-11-04 14:23:58 <Luke-Jr> gmaxwell: how exactly do you need it tested? looks like it could take hours to properly test it, especially not being able to easily follow the logic (why is CAddress a subclass to the Nth degree? :/)
53 2014-11-04 14:56:04 <pastly> ed
54 2014-11-04 17:12:06 <andytoshi> seems like everywhere that CCoinsViewMemPool is used, it is passed a mempool reference that is LOCK'd in the previous line, and remains locked for the duration of theCCoinsViewMemPool's lifetime
55 2014-11-04 17:12:17 <andytoshi> should i move the lock into CCoinsViewMemPool's constructor/destructor then?
56 2014-11-04 17:12:43 <andytoshi> this would be a minor cleanup and would let me move forward with #4226
57 2014-11-04 17:13:14 <sipa> sgtm
58 2014-11-04 17:14:11 <andytoshi> kk. istm there is no LOCK macro which gives me a lock that i can hold onto, is this right? sync.h:160 is where the existing LOCK macros are
59 2014-11-04 17:14:56 <andytoshi> they just create CCriticalBlock's, so if i add a CCriticalBlock as a member of CCoinsViewMemPool, and copy the LOCK code into its constructor, is that a good way to do this?
60 2014-11-04 17:16:23 <sipa> seems reasonable
61 2014-11-04 17:16:37 <andytoshi> cool, thx, i'll submit a PR for discussion
62 2014-11-04 17:16:42 <sipa> having the CCriticalBlock as member of CCoinsViewMemPool is certainly cleaner than calling lock/unlock directly
63 2014-11-04 17:17:01 <sipa> as it will correctly interact with the lock contention/inversion detection too
64 2014-11-04 17:19:43 <andytoshi> ok, last q: CCriticalBlock wants a filename/lineno, which in the LOCK macro is given by __LINE__ and __FILE__ ... should i macro the CCoinsViewMemPool constructor or just accept that these will be the same for every CCoinsViewMemPool ?
65 2014-11-04 17:21:10 <andytoshi> i'm leaning toward having it always be the same, imho the macro-obfuscation is not worth it
66 2014-11-04 17:22:32 <sipa> andytoshi: agree
67 2014-11-04 17:23:48 <andytoshi> cool, running `make check` now
68 2014-11-04 17:24:01 <andytoshi> thx for all your help (esp your overview of classes yesterday), you totally unblocked me
69 2014-11-04 17:27:30 <sipa> you're welcome!
70 2014-11-04 17:34:51 <andytoshi> https://github.com/bitcoin/bitcoin/pull/5206
71 2014-11-04 19:00:19 <gmaxwell> Luke-Jr: Thanks for the review; wrt testing, the only thing I think really needs testing is to setup a host that needs the discovery and verify it still learns and advertises its IP. ... I did this, but AFAIK it was only me that did it, and I'd be happier if a second person also tested it.
72 2014-11-04 19:02:00 <Luke-Jr> hm
73 2014-11-04 19:02:26 <Luke-Jr> gmaxwell: is it supposed to work in the scenario where the public IP is IPv4, but it's connection out is over IPv6? ;)