1 2015-08-21 02:10:11 <jtimon> cfields: wumpus: Luke-Jr ping https://github.com/bitcoin/bitcoin/pull/6068
  2 2015-08-21 04:38:19 <delboy1978uk> any particular reason all my tests would run fine on my dev machine, but when the tests run on travis it freaks out calling getblocktemplate? calling the jsonrpc
  3 2015-08-21 04:38:50 <delboy1978uk> on my dev box i get a ton of json, on travis a 500, and its not clear why
  4 2015-08-21 05:48:20 <Luke-Jr> dcousens: you deleted your comment?
  5 2015-08-21 06:15:33 <phantomcircuit> <delboy1978uk> any particular reason all my tests would run fine on my dev machine, but when the tests run on travis it freaks out calling getblocktemplate? calling the jsonrpc
  6 2015-08-21 06:15:38 <phantomcircuit> getblocktemplate is super slow potentially
  7 2015-08-21 06:15:50 <phantomcircuit> iirc travis limits total cpu time per run to something reasonable
  8 2015-08-21 06:16:01 <phantomcircuit> so potentially he simply exceeded the total cpu time alloted
  9 2015-08-21 06:17:09 <kang_> Bitcoin can be scaled by changing the behavior of wallets towards deferred transactions using DKG threshold crypto
 10 2015-08-21 06:18:02 <phantomcircuit> kang_, you're going to need to expand on that somewhere other than here, might i suggestion #bitcoin-wizards ?
 11 2015-08-21 06:18:22 <kang_> If we have an unbroadcasted transaction paying A to B, and A's private key becomes unusable thereafter, then without relaying the transaction, B has the power to show it can claim the coins at address A by relaying this transaction.
 12 2015-08-21 06:22:25 <kang_> Thanks phantomcircuit
 13 2015-08-21 06:37:45 <dcousens> Luke-Jr: accidentally submitted is a better way to put it
 14 2015-08-21 06:37:55 <dcousens> dman email notifications are instant heh
 15 2015-08-21 06:38:00 <dcousens> damn*
 16 2015-08-21 06:38:18 <dcousens> What was the contents,  I can re-add it if you feel its worth while
 17 2015-08-21 09:28:46 <dcousens> should a 33 byte R value with a value greater than 2^256 just be rejected outright?
 18 2015-08-21 09:29:03 <dcousens> Seems odd to let it be acceptable input in BIP66
 19 2015-08-21 09:31:56 <wumpus> BIP66 doesn't really deal with the values, just with restricting their allowed representation
 20 2015-08-21 09:32:40 <wumpus> but yes, a R that is too large should certainly be rejected outright
 21 2015-08-21 09:32:55 <dcousens> wumpus: well it does restrict negative values
 22 2015-08-21 09:33:27 <dcousens> it checks that r[0] === 0x00 && !(r[0] & 0x80),  aka,   r is not signed if its padded
 23 2015-08-21 09:33:46 <wumpus> IIRC it needs to, otherwise some redundancy would be possible
 24 2015-08-21 09:33:52 <dcousens> but we should also check,  if (rLen > 32 && r[0] !== x000) return bad
 25 2015-08-21 09:34:14 <dcousens> no I know,  I'm saying we could do both, and value checking isn't exactly out of place there
 26 2015-08-21 09:34:20 <dcousens> at least, at this level
 27 2015-08-21 09:34:22 <wumpus> anyhow it's too late to change BIP66 now, should have commented befoer it was implemented
 28 2015-08-21 09:34:32 <dcousens> wasn't paying attention at the time
 29 2015-08-21 09:34:49 <wumpus> and if it doesn't result in bugs it's not a cause for urgent action (or action at all)
 30 2015-08-21 09:34:58 <dcousens> so,  how can it be resolved?  are bips really that strict?
 31 2015-08-21 09:35:15 <dcousens> no doubt, but it could be an early exit for sure?
 32 2015-08-21 09:35:26 <wumpus> you could create a new BIP, but I doubt a softfork would be adopted for a non-issue like this
 33 2015-08-21 09:36:09 <dcousens> why would this be a soft-fork?
 34 2015-08-21 09:36:20 <dcousens> no transaction could have validated with this before
 35 2015-08-21 09:36:23 <dcousens> its an optimization solely?
 36 2015-08-21 09:36:32 <wumpus> throughout the BIP it is assumed that what will actually handle the signature does proper error checking with regard to allowed ECDSA values
 37 2015-08-21 09:37:07 <wumpus> nah, an optimization for a very rare edge case
 38 2015-08-21 09:38:40 <dcousens> wumpus: sure,  thats fine.  Just wanted to clarify that :)
 39 2015-08-21 09:40:56 <wumpus> right :)
 40 2015-08-21 09:41:11 <dcousens> infact,  its only R that could be >32,  because the S value is checked to be <n/2
 41 2015-08-21 09:41:27 <dcousens> interesting that we run the sig check twice though
 42 2015-08-21 09:43:11 <wumpus> when? you mean when the transaction comes in first, and when it ends up in a block? there's a cache for that
 43 2015-08-21 09:43:32 <dcousens> not verified, IsValidSignatureEncoding is called twice
 44 2015-08-21 09:43:47 <wumpus> ok
 45 2015-08-21 09:44:41 <dcousens> in CheckSignatureEncoding,  its called specifically, then again in IsLowDERSignature (which is called in IsValidSignatureEncoding)
 46 2015-08-21 09:46:20 <dcousens> (sorry,  which is called in CheckSignatureEncoding*)
 47 2015-08-21 09:54:27 <dcousens> wumpus: so in what cases is a BIP necessary?
 48 2015-08-21 09:55:55 <wumpus> in case of softforking or hardforking changes to the block chain, or P2P protocol changes, anything that affects bitcoin-at-large and not just bitcoin core
 49 2015-08-21 09:56:45 <dcousens> so, in this case, how would it be considered a soft-forking change?
 50 2015-08-21 09:58:10 <wumpus> it wouldn't. But keeping the function in the code exactly the same as in the BIP is useful
 51 2015-08-21 10:03:44 <dcousens> true,  I guess its just a matter of it being more useful than restricting the R value earlier on.  In this case, it probably is.
 52 2015-08-21 10:04:06 <dcousens> (more useful to keep it as the BIP that is)
 53 2015-08-21 10:20:53 <wumpus> yes
 54 2015-08-21 16:47:10 <Bootvis_> /names
 55 2015-08-21 17:29:45 <BlueMatt> anyone have the best reference for the first public comments on bloom filtering dos issues?
 56 2015-08-21 17:39:06 <gmaxwell> BlueMatt: FWIW, I pointed to that PR in #btcd and sounds like support from there.
 57 2015-08-21 17:39:44 <BlueMatt> yea, I'm not sure anyone doesnt support such a proposal at this point
 58 2015-08-21 17:46:01 <warren> BlueMatt: the mid-2013 security audit of Litecoin by petertodd had many comments on that topic, the biggest of which were not released to the public until after a time delay.
 59 2015-08-21 17:46:28 <warren> The audit led to Litecoin adding NODE_BLOOM and an option to disable bloom filtering if the network were to be attacked.
 60 2015-08-21 17:46:50 <warren> let me find the URL
 61 2015-08-21 17:46:57 <warren> hmm
 62 2015-08-21 17:47:18 <warren> petertodd: was the time delay portion of the audit released?
 63 2015-08-21 17:47:40 <warren> BlueMatt: found it, http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html
 64 2015-08-21 17:48:50 <warren> oh wait, wrong URL
 65 2015-08-21 17:52:02 <BlueMatt> hmm?
 66 2015-08-21 17:57:52 <BlueMatt> is there a reasonable proposal anyone has made for making dnsseed requests for nodes with specific nServices bits set?
 67 2015-08-21 17:58:26 <BlueMatt> and/or does anyone have any objections to proposing the naiive MINIMUM_BITS_YOU_WANT_IN_HEX.seedname as a BIP?
 68 2015-08-21 18:19:49 <jonasschnelli> BlueMatt: MINIMUM_BITS_YOU_WANT_IN_HEX.seedname.tld: ACK.
 69 2015-08-21 18:21:36 <BlueMatt> just had a conversation with sipa, and he pointed out that dns seeds are maybe better used as a "connect to this as a hostname, you will get some connection to some node, then do a getaddr, then disconnect"
 70 2015-08-21 18:22:02 <BlueMatt> this is what bitcoin core already does over tor, but is maybe a better way to do it in all cases
 71 2015-08-21 18:22:22 <BlueMatt> and I rather agree with him - it would be nice to not break caching for less-commonly-used-lookups
 72 2015-08-21 18:24:06 <jonasschnelli> okay... i see.
 73 2015-08-21 18:28:25 <jonasschnelli> BlueMatt: what about supporting service bits in getaddr?
 74 2015-08-21 18:32:09 <warren> jonasschnelli: addresses are passed on and not verified in any way, the bits passed along with that aren't very useful
 75 2015-08-21 18:32:17 <warren> as the node who gave it to you could lie
 76 2015-08-21 18:34:16 <jonasschnelli> Hmm... warren: Right... but a node could also indicate BF support but than just ignore the filterX commands...
 77 2015-08-21 18:50:05 <btcdrak> I posted a blocksize proposal to -wizards if anyone is interested.
 78 2015-08-21 18:50:43 <gmaxwell> jonasschnelli: that does kind of undermine the privacy improvement that comes from caching, if there is much diversity in the requests.
 79 2015-08-21 19:29:37 <BlueMatt> gmaxwell: hmm?
 80 2015-08-21 19:30:55 <BlueMatt> jonasschnelli/warren: meh, you get an address with bits from getaddr, no? You should not trust the dnsseeds much/any more than the response you get from a random node
 81 2015-08-21 19:30:59 <BlueMatt> so its not too different
 82 2015-08-21 19:41:30 <evoskuil> BlueMatt: agree. adding service bits to getaddr responses just saves a wasted connection on both ends.
 83 2015-08-21 19:42:30 <BlueMatt> I think they alread do
 84 2015-08-21 19:42:58 <warren> but is it actually useful?  I don't think so
 85 2015-08-21 19:43:44 <BlueMatt> if you're trusting the dnsseeds more than a random peer, you're doing it wrong
 86 2015-08-21 19:44:08 <evoskuil> warren: it will be useful when we have a bit for BF
 87 2015-08-21 19:45:54 <BlueMatt> oh, yes, context, this is all related to NODE_BLOOM
 88 2015-08-21 19:48:45 <evoskuil> BlueMatt: agree, we make no distinction whatsoever between seed nodes and peers. it would be nice to not get connections from wallets just for us to reject them.
 89 2015-08-21 19:58:33 <rodarmor> Does a PR that just fixes a trivial identifier typo belong in bitcoin/bitcoin or theuni's trivial-next fork?
 90 2015-08-21 20:02:49 <evoskuil> BlueMatt: I just saw your original query on this. I don't see it as beneficial to specialize the request from a seed node. Certainly one could specialize seed nodes, achiving the optimization with no protocol changes.
 91 2015-08-21 20:07:24 <dhill> are the devs still against not accepting unsolicited transactions (requiring inv/getdata/tx vs current behavior of accepting unsolicited tx's).  it would break the current behavior of bitcoinj, which breaks specification.
 92 2015-08-21 21:41:29 <andytoshi> i have a wallet backup which bitcoind refuses to recover, says 'Failed to rename wallet.dat to wallet.xxx.dat'
 93 2015-08-21 21:41:36 <andytoshi> this is a result of https://web.stanford.edu/class/cs276a/projects/docs/berkeleydb/api_cxx/env_dbrename.html failing
 94 2015-08-21 21:42:10 <andytoshi> it seems from that link that if DB_AUTO_COMMIT is passed (it is), txnid must be non-NULL (it's not)
 95 2015-08-21 21:42:15 <andytoshi> alternately the wallet is 83Mb
 96 2015-08-21 21:43:11 <andytoshi> alternately it might actually be corrupted, or i have filesystem problems...not sure yet
 97 2015-08-21 21:44:05 <andytoshi> oh, hmm, even using cstdio::rename() fails
 98 2015-08-21 21:44:14 <gmaxwell> are you out of inodes?
 99 2015-08-21 21:44:30 <andytoshi> gmaxwell: i don't think so, i can use `mv` successfully
100 2015-08-21 21:44:34 <andytoshi> and i've only got like 200000 files
101 2015-08-21 21:46:13 <CodeShark> right now libconsensus doesn't deal with state, right? It mostly evaluates scripts.
102 2015-08-21 21:46:39 <andytoshi> gmaxwell: "errno 2: No such file or directory" i think it's filesystem problems, or selinux, or something
103 2015-08-21 21:47:19 <andytoshi> ah, it works if i run bitcoind from ~/.bitcoin
104 2015-08-21 21:47:47 <andytoshi> then `Salvage(aggressive) found no records in wallet.1440193621.bak` ... fuck
105 2015-08-21 21:48:09 <CodeShark> is this everything that the libconsensus exposes in this header? https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.h
106 2015-08-21 21:51:38 <CodeShark> did you lose some keys, andytoshi?
107 2015-08-21 21:51:58 <andytoshi> CodeShark: not sure ... i think about 200000 of them
108 2015-08-21 21:53:19 <CodeShark> does the file look really messed up>
109 2015-08-21 21:53:20 <CodeShark> ?
110 2015-08-21 21:53:36 <andytoshi> CodeShark: i dunno, i can send it to you if you wanna poke at it
111 2015-08-21 21:54:10 <CodeShark> Dunno if I'll be able to right now...but perhaps later
112 2015-08-21 21:54:33 <CodeShark> I don't really have tools handy for that ATM
113 2015-08-21 21:54:38 <andytoshi> no worries
114 2015-08-21 21:54:45 <andytoshi> i've got another backup, and i can maybe undelete the original
115 2015-08-21 21:55:46 <andytoshi> oh thank god, the other backup is uncorrupted
116 2015-08-21 21:56:20 <CodeShark> so problem solved?
117 2015-08-21 21:56:29 <andytoshi> i think the "have to run bitcoind from .bitcoin to get the automatic salvage to work" is a bug, i'll bug it when i get a chance
118 2015-08-21 21:56:34 <andytoshi> CodeShark: not sure yet, i think so
119 2015-08-21 21:56:38 <andytoshi> still rescanning
120 2015-08-21 21:56:46 <andytoshi> probably will be a while, i have a ton of keys
121 2015-08-21 21:57:23 <CodeShark> heh...we really need to optimize that shit at the datastructure level...but bah :p
122 2015-08-21 21:58:22 <CodeShark> I can't wait until we finally have better commit structures :p
123 2015-08-21 21:59:14 <CodeShark> so no takers to my earlier question?
124 2015-08-21 21:59:31 <CodeShark> is this everything that the libconsensus exposes in this header? https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.h
125 2015-08-21 22:00:01 <andytoshi> hehe, i got my money back plus 0.03 that i didn't know i had :D
126 2015-08-21 22:00:15 <andytoshi> like, somehow the balance on the backup was higher than the balance in my savings sheet..
127 2015-08-21 22:59:18 <cagatay_> Hı everyone
128 2015-08-21 22:59:41 <cagatay_> not really related to development but i'm unable to subscribe to bitcoin-dev mailing list
129 2015-08-21 22:59:48 <cagatay_> i get this error when i submit the form:
130 2015-08-21 22:59:49 <cagatay_> Bug in Mailman version 2.1.9
131 2015-08-21 22:59:49 <cagatay_> We're sorry, we hit a bug!
132 2015-08-21 22:59:50 <cagatay_> Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs.
133 2015-08-21 23:18:21 <jtimon> cfields: wumpus: Luke-Jr ping https://github.com/bitcoin/bitcoin/pull/6068