1 2015-08-18 00:01:59 <nwilcox> Look for GHOST protocol.
  2 2015-08-18 00:02:18 <nwilcox> If I had to guess, I'd guess off topic for this channel. ;-)
  3 2015-08-18 00:29:36 <dcousens> nwilcox: possibly,  though if its applying the idea to bitcoin,  maybe,  just depends on what points you wanted to bring up.  dessugrue ?
  4 2015-08-18 01:07:17 <dcousens> Heh,  bitcoin/bitcoin has its own JSON parser? :/
  5 2015-08-18 01:07:24 <dcousens> I mean,  sure, its not hard.  But,  really? haha
  6 2015-08-18 01:11:53 <dcousens> Anyone know if there is a specific reason a JSON reader/writer was rolled into core?
  7 2015-08-18 01:15:46 <midnightmagic> dcousens: Right, so those sorts of comments are not constructive. Please take that sort of pointless criticism somewhere else, like say #bitcoin-pricetalk or ##bitcoin.
  8 2015-08-18 01:16:12 <dcousens> midnightmagic: Sorry,  whats wrong?
  9 2015-08-18 01:16:29 <gmaxwell> the library one we we were using before is not good in a number of respects (most importantly including updates making it randomly corrupt values-- great for money handling applications). Just switching to another would likely have left the same problems, and also broken compatibility.
 10 2015-08-18 01:16:57 <Luke-Jr> actually, there's no real reason UniValue couldn't be used as a proper library AFAIK?
 11 2015-08-18 01:17:04 <alpalp> apparently it is hard.
 12 2015-08-18 01:17:16 <gmaxwell> Unfortunately JSON has a lot of freedom in its behavior and then applications come to depend on specific arbritry choices and then break when they change.
 13 2015-08-18 01:17:32 <Luke-Jr> so I think I agree with dcousens that this is unnecessary poor anti-modular design
 14 2015-08-18 01:17:41 <dcousens> gmaxwell: that sounds unfortunate,  but surely that could be managed by increasing the amount of testing in the target library?
 15 2015-08-18 01:18:16 <midnightmagic> Luke-Jr: The mocking tone was absurd and counter-productive.
 16 2015-08-18 01:18:50 <dcousens> midnightmagic: I had no mocking tone,  I was only surprised... apologies for the misconception.
 17 2015-08-18 01:19:49 <Luke-Jr> dcousens: if you want to put the effort into making it a proper external shared library, feel free to PR it IMO; although perhaps the time is better spent on other things
 18 2015-08-18 01:20:14 <midnightmagic> "< dcousens> I mean,  sure, its not hard.  But,  really? haha" <-- seriously? You're going to tell me that's not mocking?
 19 2015-08-18 01:21:34 <dcousens> midnightmagic: I'm sorry you misinterpreted that,  but no,  that was not mocking.  That was surprise.  It reflects how I would react in real life.
 20 2015-08-18 01:21:49 <dcousens> Luke-Jr: I mentioned https://github.com/nlohmann/json as an alternative in a recent issue mentioning a weird formatting problem in UniValue
 21 2015-08-18 01:22:12 <dcousens> It appears to be well tested,  but I've no doubt the tests would need to be vetted.
 22 2015-08-18 01:23:26 <midnightmagic> dcousens: http://www.thefreedictionary.com/mocking
 23 2015-08-18 01:24:43 <dcousens> midnightmagic: I'm aware of the definition(s),  again,  none of them match my intention.  This is getting off topic now,  PM me if you want to clarify further.  And again,  sorry.
 24 2015-08-18 01:46:47 <dcousens> gmaxwell: what was the previously used library btw?
 25 2015-08-18 01:48:05 <Luke-Jr> JSON Spirit: A C++ JSON Parser/Generator Implemented with Boost Spirit
 26 2015-08-18 01:48:27 <Luke-Jr> it was ugly C++ template magic that made compiles use a ton of memory, and bloated binaries
 27 2015-08-18 02:17:46 <dcousens> Luke-Jr: the one I linked above is semi template heavy,  however only to define the default `json` export and the allocator etc (https://github.com/nlohmann/json/blob/master/src/json.hpp#L172-L180).
 28 2015-08-18 03:32:30 <drazisil> could you explain the score in getnetworkinfo? is that total cumulative connection count?
 29 2015-08-18 04:13:06 <drazisil> What is getaddr used for in the protocol? does a node ask peers for their peers and then attempt to them?
 30 2015-08-18 06:55:20 <btcdrak> gmaxwell: when is it acceptable to bug you again for a BIP number for op_csv? :)
 31 2015-08-18 06:56:12 <gmaxwell> btcdrak: one week after the post. has it been a week? :)
 32 2015-08-18 06:57:36 <btcdrak> gmaxwell: hrm. it's been a working week :-P else I have to wait until Thursday.
 33 2015-08-18 07:01:25 <poutine> what is op_csv
 34 2015-08-18 07:08:49 <btcdrak> poutine: OP_CHECKSEQUENCEVERIFY for a relative checklocktimeverify. There is a PR open for it now 6564
 35 2015-08-18 07:19:40 <jonasschnelli> Luke-Jr
 36 2015-08-18 07:21:31 <Luke-Jr> jonasschnelli: … then why did it need a bunch of post-merge fixes?
 37 2015-08-18 07:23:27 <jonasschnelli> two bug fixes: handling of \u0000 chars and scientific notation parsing. one minor improvement: solidus escaping.
 38 2015-08-18 07:25:36 <gmaxwell> it's just full of bugs we haven't found yet.
 39 2015-08-18 07:25:40 <gmaxwell> All software is full of bugs. :)
 40 2015-08-18 07:26:00 <gmaxwell> especially when you don't think its full of bugs. :)
 41 2015-08-18 07:26:38 <Luke-Jr> those two bugs fixed, are probably more bugs than any other implementation we could have chosen ;)
 42 2015-08-18 07:26:46 <btcdrak> gmaxwell: most bugs are in a quantum superposition
 43 2015-08-18 08:11:46 <dcousens> If I have Q = dG,  P = cG and R = bG,  and I then sign two different messages using `dP` and `dR` respectively, and I accidentally get duplicate r-values for both signatures, and an attacker knows Q... do I face the same risk as if I had signed with d both times?   My question is based around whether stealth address re-use faces the same (or, similar)
 44 2015-08-18 08:11:46 <dcousens> problems to typical address re-use?
 45 2015-08-18 08:16:16 <sipa> and b and c are public?
 46 2015-08-18 08:17:27 <dcousens> sipa: yes,  in the sense they are ephemerally created by the sender (could be the attacker even)
 47 2015-08-18 08:17:43 <sipa> i believe so
 48 2015-08-18 08:18:34 <dcousens> because they are all signed by d right,  P/R are basically pointless that point except in determining the address for script purposes?
 49 2015-08-18 08:19:17 <sipa> your private keys are dc and db, right?
 50 2015-08-18 08:19:30 <sipa> oh, wait
 51 2015-08-18 08:19:34 <sipa> yes
 52 2015-08-18 08:19:42 <dcousens> yes,  sorry, they should be*
 53 2015-08-18 08:20:13 <sipa> but the r valyes should not be predictable
 54 2015-08-18 08:20:27 <dcousens> right,  just realised that as you pointed out db dc
 55 2015-08-18 08:20:32 <sipa> if you compute them using rfc6979, there is no problem
 56 2015-08-18 08:20:44 <sipa> or any other cryptographic prng
 57 2015-08-18 08:21:01 <dcousens> even if the k value was the same,  the r-values would be different
 58 2015-08-18 08:21:08 <sipa> yes
 59 2015-08-18 08:21:13 <dcousens> is that still a risk though?
 60 2015-08-18 08:22:43 <sipa> what is?
 61 2015-08-18 08:23:55 <sipa> two messages with the same r and totally unrelates private key, are safe afaict
 62 2015-08-18 08:24:00 <dcousens> I'll re-write the question with the right terms,  AFAIK its not an issue,  I forgot the addition
 63 2015-08-18 08:24:37 <sipa> but because a relation is known between the private keys, i think you can solve for the keys
 64 2015-08-18 08:24:44 <dcousens> If I have Q = dG,  P = cG and R = bG,  and I then sign two different messages using (d + c)P and (d + b)R respectively, and I accidentally get duplicate r-values for both signatures, and an attacker knows c,b,Q... do I face the same risk as if I had signed with d both times?
 65 2015-08-18 08:24:47 <sipa> given two signatures
 66 2015-08-18 08:26:20 <sipa> so private keys (d + c)*c and (d + b)*b ?
 67 2015-08-18 08:26:25 <sipa> yes
 68 2015-08-18 08:26:47 <sipa> i think that doesn't change anything, except the equation becomes a bit more complex
 69 2015-08-18 08:27:53 <sipa> knowing Q is not even necessary
 70 2015-08-18 08:47:57 <gmaxwell> dcousens: all you have to do is count up the variables and unknowns, if the linear system is exactly or over determined then it can all be solved.
 71 2015-08-18 09:14:17 <jonasschnelli> signing multiple inputs simultaneous: does the signature of the 2nd input includes the signature of the 1st input? Or can i sign all inputs simultaneous without knowing other inputs signatures?
 72 2015-08-18 09:14:52 <jonasschnelli> I can't fully follow the CTransactionSignatureSerializer() code
 73 2015-08-18 09:16:03 <jonasschnelli> hmm... https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1034
 74 2015-08-18 10:01:30 <gmaxwell> I created a privacy label in the bitcoin repository. I'm surprised we didn't have one before. Help welcome in identifying issues to tag with it.
 75 2015-08-18 10:36:54 <dcousens> gmaxwell: have you seen https://github.com/kristovatlas/bips/blob/master/bip-0069.mediawiki ?
 76 2015-08-18 10:37:10 <dcousens> Might be relevant given #6568
 77 2015-08-18 10:38:00 <dcousens> gmaxwell: and cheers regarding the tip above RE solvability, is there any where I can read up on that method? I think I understand it,  but if you have a reference that'd be great for solidifying the process :)
 78 2015-08-18 10:41:20 <dcousens> PR for the BIP: https://github.com/bitcoin/bips/pull/157
 79 2015-08-18 17:22:48 <NCSK> Hello, is it normal that bitcoind announces each block twice?
 80 2015-08-18 17:22:50 <NCSK> blocknotify:00000000023df130fc27e19c0461acc1fc70453d32083f901e97edca67703d2f
 81 2015-08-18 17:22:51 <NCSK> blocknotify:0000000000000642d36b38444b3236cc2b811ab20ac0f6259f6d0d1118b1038e
 82 2015-08-18 17:22:51 <NCSK> blocknotify:00000000023df130fc27e19c0461acc1fc70453d32083f901e97edca67703d2f
 83 2015-08-18 17:23:44 <BitcoinBIGFAN> HEllo!
 84 2015-08-18 17:24:00 <BitcoinBIGFAN> I wanna know if Bitcoin and Bitcoin XT will be the same network
 85 2015-08-18 17:24:19 <BitcoinBIGFAN> Will common Bitcoin and Bitcoin XT use the same network?
 86 2015-08-18 17:24:46 <jeremias_> no, the bitcoin value will go to zero
 87 2015-08-18 17:24:58 <jeremias_> Bitcoin XT  value will go to $-1
 88 2015-08-18 17:25:09 <BitcoinBIGFAN> Why?
 89 2015-08-18 17:27:20 <BitcoinBIGFAN> I heard that Bitcoin XT will use the same network as Bitcoin. Is it true if we spend Bitcoin XT it will spend the original Bitcoin?
 90 2015-08-18 17:28:56 <jeremias_> yep
 91 2015-08-18 17:29:09 <jeremias_> it will be spent in both chains if the inputs are right
 92 2015-08-18 17:40:32 <Luke-Jr> BitcoinBIGFAN: #bitcoin
 93 2015-08-18 18:07:04 <SkillfulHacking> what will happen if a large block gets mined on an XT client today, or is the mechanism to improve larger blocks not implemented until the network hits 75 %?
 94 2015-08-18 18:10:06 <helo> nothing
 95 2015-08-18 18:10:14 <helo> SkillfulHacking: good topic for #bitcoin, though
 96 2015-08-18 18:10:34 <BitcoinBIGFAN> Why helo?
 97 2015-08-18 18:10:52 <helo> #bitcoin
 98 2015-08-18 18:10:57 <BitcoinBIGFAN> This is bitcoin-dev, dev is for development, right?
 99 2015-08-18 18:11:06 <helo> this is for discussion between developers
100 2015-08-18 18:11:50 <SkillfulHacking> why nothing? wouldnt XT accept it and core reject it?
101 2015-08-18 18:20:05 <jgarzik> SkillfulHacking, large blocks not considered valid by XT until network hashpower hits a threshold
102 2015-08-18 18:20:30 <jgarzik> Bitfury not a fan of XT: https://twitter.com/BitfuryGeorge/status/633566230314618880
103 2015-08-18 19:10:01 <adlai> roaming|has yet there been made a list of the ways that people [ab]use OP_RETURN ?
104 2015-08-18 19:29:45 <adlai> roaming|any link summarizing the "current status" of OP_RETURN would be welcome. I've found some discussion saying that the size may be increased, but am I correct in concluding that it's not safe to assume more than 40 bytes are supported?
105 2015-08-18 19:33:07 <pigeons> adlai|roaming: probably we shoud take it to #bitcoin. larger outputs won't be relayed or mined by most anyone but are still valid but not standard
106 2015-08-18 22:25:40 <ebfull> is the reference client designed so that the block size limit can be function of the block number?
107 2015-08-18 22:26:14 <ebfull> i guess that would be a stupid question since the proposal in XT doubles every so often... nvm
108 2015-08-18 22:27:25 <dgenr8> ebfull: it also interpolates, so every block has a slightly higher limit and there is no step function at future doublings
109 2015-08-18 22:28:04 <ebfull> would a temporary raise to 8MB block size limit, which decreases very slowly back to 1MB, perhaps over the course of a few years, not be a good compromise?
110 2015-08-18 22:28:58 <ebfull> obviously it invites the same problem (we're pulling 8MB out of our ___) but it does give us plenty of capacity to work with while building alternative plans, but not committing us indefinitely to such a high block size if we discover in retrospect it's a bad idea
111 2015-08-18 22:29:59 <ebfull> it also sounds a lot better than the "dynamic" block size proposal i read somewhere, which has no cap and doesn't force us to address scalability
112 2015-08-18 22:30:25 <ebfull> though it does force us to hardfork _again_ years later if this approach is not suitable
113 2015-08-18 22:31:26 <kanzure> SIGHASH_NOINPUT things https://github.com/Roasbeef/btcd/commit/67830e506fa135d5239177340918cea39909e6a4 https://github.com/Roasbeef/bitcoin/commit/4b3c3f1baf7985208ceb6887261ee150ab6e3328
114 2015-08-18 23:02:15 <btcdrak> Seems hearn gavinandresen paid no heed to this comment https://github.com/bitcoinxt/bitcoinxt/commit/a3f4f0b868fa93e4a4383d60f532659661300924#commitcomment-12617452 which interferes with CLTV deployment.
115 2015-08-18 23:04:33 <dcousens> btcdrak: has the soft-fork strategy for CLTV been decided yet?
116 2015-08-18 23:05:51 <btcdrak> well it was looking like consensus was for same method as previous softforks, but now we need to rethink, (unless we ignore XT entirely).
117 2015-08-18 23:07:02 <btcdrak> Maybe we can mask off the bits from 0x20000007 so we can compare as a normal integer again. We'd need a higher nVersion I guess, 8 instead of 4 now.
118 2015-08-18 23:11:13 <Luke-Jr> btcdrak: I think using the old method may be a mistake we regret.
119 2015-08-18 23:11:50 <Luke-Jr> it would effectively prevent usage of yet another bit for the future softfork system
120 2015-08-18 23:11:56 <btcdrak> Luke-Jr: but there is no new method yet, at least nothing written I was aware of.
121 2015-08-18 23:12:07 <Luke-Jr> btcdrak: I thought I saw a draft BIP for it
122 2015-08-18 23:12:18 <btcdrak> nVersionbits, there's no code
123 2015-08-18 23:12:28 <Luke-Jr> there doesn't need to be code for there to be a BIP
124 2015-08-18 23:12:40 <Luke-Jr> and beside the point
125 2015-08-18 23:13:09 <Luke-Jr> a rule that nVersion must be >=4 means you can't clear all the bits anymore - now three bits have to be ignored, rather than two
126 2015-08-18 23:13:15 <dcousens> Luke-Jr: the nVersion is basically being [ab]used right now as voting mechanism, rather than its intended purpose of actual versioning for pre-defined changes,  no?
127 2015-08-18 23:13:57 <dcousens> (including how it was used for BIP66 soft fork*)
128 2015-08-18 23:14:43 <Luke-Jr> dcousens: what? softforks /are/ such changes
129 2015-08-18 23:14:51 <btcdrak> Here's the BIP - https://gist.github.com/sipa/bf69659f43e763540550 - last discussion on the list in June sipa said he would be incorporating feedback.
130 2015-08-18 23:15:56 <dcousens> Luke-Jr: re-word, was nVersion intended to be essentially a bit vector for feature flagging?
131 2015-08-18 23:16:55 <Luke-Jr> dcousens: not that I am aware of
132 2015-08-18 23:18:43 <roasbeef> kanzure: doesn't include OP_CHECKSIG2 since I'm planning on making a testnet sidechain with the new sighash flag to prototype some LN stuff (like a catch-bob-trying-to-cheat-you-by-broadcasting-an-invalidated-commitment-tx-while-you-are-offline-as-a-service outsourcability daemon)
133 2015-08-18 23:18:58 <roasbeef> (assuming the original dual funder, single anchor model)