12017-01-04T00:31:51  *** Giszmo1 has joined #bitcoin-core-dev
  22017-01-04T00:32:16  *** Giszmo has quit IRC
  32017-01-04T00:34:29  *** Giszmo has joined #bitcoin-core-dev
  42017-01-04T00:34:30  *** Giszmo1 has quit IRC
  52017-01-04T00:52:32  *** Chris_Stewart_5 has quit IRC
  62017-01-04T00:54:18  *** fanquake has quit IRC
  72017-01-04T00:56:43  *** fanquake has joined #bitcoin-core-dev
  82017-01-04T01:08:11  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  92017-01-04T01:47:26  *** Ylbam has quit IRC
 102017-01-04T01:54:00  *** Chris_Stewart_5 has quit IRC
 112017-01-04T01:59:18  *** abpa has quit IRC
 122017-01-04T02:23:30  *** Giszmo has quit IRC
 132017-01-04T02:52:55  <morcos> BlueMatt: The remaining sdaftuar comment is in regards to the fact that you could announce two compact blocks via NewPoWValidBlock in quick succession even after the change to only announce potential new tips
 142017-01-04T02:55:33  <morcos> If those are tied at the same height, then one of them will not have ever become our tip and sp wpm
 152017-01-04T02:56:33  <morcos> oops..  and so won't be BLOCK_VALID_SCRIPTS or in our best chain and we'll stall any node asking for it
 162017-01-04T03:00:02  <morcos> but yes the change to BLOCK_VALID_TRANSACTIONS is in the later line where we set "send".  and the recently added code in getdata to fix my bug from 9447 can go away.
 172017-01-04T03:03:43  <gmaxwell> I've kinda wonered if we shouldn't just remember the NewPoWblock announcements that we've done e.g. {peer, hash} in a limitedmap, and then if we get in a request that is in that map, just blindly reply with the data on disk.
 182017-01-04T03:03:50  <gmaxwell> Similar to how the relay pool works.
 192017-01-04T03:05:10  <gmaxwell> (in that the relay pool means we'll give you a transaction we offered to you, even if we've since discarded it)
 202017-01-04T03:07:33  <morcos> gmaxwell: that's what i was thinking at first too, but i think sdaftuar's solution might just be more elegant
 212017-01-04T03:09:00  <morcos> as long as you lock cs_main if the requested hash doesn't match the cached block, that'll mean any announced block will be written to disk, and be available to be read..
 222017-01-04T03:10:05  <morcos> since these will be rare, i don' tthink there is a performance issue with reading them back from disk, the only existing problem is we weren't serving them b/c we weren't seeing them as BLOCK_VALID_SCRIPTS b/c they'd never been connected
 232017-01-04T03:10:24  <morcos> oh shoot... i keep forgetting... you can't serve them in that case
 242017-01-04T03:10:36  *** MarcoFalke has quit IRC
 252017-01-04T03:10:40  <morcos> well if we're going to be pedantic about following the protocol we've got a problem
 262017-01-04T03:11:00  <morcos> b/c we're announcing blocks before we even now if we're going to test them for validity, so what do we do if we never test them
 272017-01-04T03:11:35  <morcos> also perhaps we never though through the case of what to do if we announce a block that turns out to be invalid... surely stalling the requester isn't the right course of action
 282017-01-04T03:17:33  <gmaxwell> (actually the deseralizzation is pretty slow, as an aside)
 292017-01-04T03:18:07  <gmaxwell> your concern is because we didn't really properly consider relaying unvalidated blocks, but we just glommed it on because it would have unfortunate to specify BIP152 another way.
 302017-01-04T03:18:33  <morcos> i hope thats a statement and not a question
 312017-01-04T03:18:50  <gmaxwell> We should specify a network message that says "I think block XYZ is invalid, if I told you about it before, forget about it, I'm not going to respond to requests about it."
 322017-01-04T03:19:03  <gmaxwell> statement.
 332017-01-04T03:19:15  <gmaxwell> A negative-inv if you will.
 342017-01-04T03:19:48  <morcos> yeah..   but we need to do something for now..
 352017-01-04T03:20:06  <gmaxwell> though perhaps like the relay pool we ought to be willing to serve up data for any block we've pre-relayed, even if we never verified it and don't intend to.
 362017-01-04T03:20:39  <gmaxwell> which we could do with a relay pool like strategy. even avoid putting them on disk... (who cares about a few megabytes of blocks in ram?)
 372017-01-04T03:21:51  <morcos> yes but avoiding disk is an unnecessary optimization... we're talking about a rare race condition here (and we've already writtent them to disk before we've even decided whether to validate or not)
 382017-01-04T03:23:57  <gmaxwell> okay, from your comments above I was thinking there was some path where we didn't save to disk.
 392017-01-04T03:24:42  <gmaxwell> We don't generally want to allow arbritary peers to fetch blocks on disk that aren't in our best chain. (leads to fingerprinting attacks). Which was why I made the peer,hash suggestion above.
 402017-01-04T03:26:17  <morcos> gmaxwell: we already have other various protections that aren't always that it's in our best chain, in this case, we require non-best-chain blocks to be less than 30 days old
 412017-01-04T03:26:40  <morcos> but we also require BLOCK_VALID_SCRIPTS, if we just loosen that we're ok  (for the case of untested blocks)
 422017-01-04T03:27:28  <morcos> i still think we potentially have a problem about what to do with blocks that turn out to be invalid
 432017-01-04T03:27:51  <morcos> back in a bit
 442017-01-04T03:36:29  <gmaxwell> I think for now we should serve them if we've advertised them... but should make a protocol extension so we can refuse to.
 452017-01-04T03:37:05  <gmaxwell> (we do ourselves no favors to help the network converge on things we think are invalid)
 462017-01-04T03:43:51  *** brg444 has joined #bitcoin-core-dev
 472017-01-04T03:53:47  *** fanquake has quit IRC
 482017-01-04T03:58:09  *** justanotheruser has quit IRC
 492017-01-04T03:59:58  *** justanotheruser has joined #bitcoin-core-dev
 502017-01-04T04:05:42  *** chris200_ has joined #bitcoin-core-dev
 512017-01-04T04:08:53  *** chris2000 has quit IRC
 522017-01-04T04:21:01  *** Alina-malina has quit IRC
 532017-01-04T04:24:33  *** Alina-malina has joined #bitcoin-core-dev
 542017-01-04T05:08:01  *** justanotheruser has quit IRC
 552017-01-04T05:09:33  *** justanotheruser has joined #bitcoin-core-dev
 562017-01-04T05:36:25  *** grbs has quit IRC
 572017-01-04T05:49:46  *** grbs has joined #bitcoin-core-dev
 582017-01-04T06:01:58  *** grbs has quit IRC
 592017-01-04T06:14:30  *** grbs has joined #bitcoin-core-dev
 602017-01-04T06:25:10  *** brg444 has quit IRC
 612017-01-04T06:33:08  <gmaxwell> why do we know have a birthday/rescan height for importaddress?
 622017-01-04T06:33:39  <gmaxwell> I had thought this was going to get fixed with a range setting for the rescan rpc, but I see we closed that with 'you should import with birthdays' but there is no way to do that for a watching address import.
 632017-01-04T06:36:22  <gmaxwell> oh I see importmulti has a timestamp. cool.
 642017-01-04T06:38:00  <gmaxwell> midnightmagic: wrt the question someone was asking in #bitcoin about how do you handle an import backlog for a node that was offline: You use importmulti with the approrpiate birthdates, and it will handle any required rescan.
 652017-01-04T06:39:11  *** grbs has quit IRC
 662017-01-04T06:39:40  <gmaxwell> perhaps the importaddress RPC help text should recommend you use importmulti instead.
 672017-01-04T06:52:44  *** grbs has joined #bitcoin-core-dev
 682017-01-04T07:00:04  *** dermoth has quit IRC
 692017-01-04T07:00:50  *** dermoth has joined #bitcoin-core-dev
 702017-01-04T07:21:32  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2a524b8e8fe6...649cf5fe894b
 712017-01-04T07:21:32  <bitcoin-git> bitcoin/master fab6c5f MarcoFalke: [qt] Do not translate `~`
 722017-01-04T07:21:33  <bitcoin-git> bitcoin/master 649cf5f Wladimir J. van der Laan: Merge #9462: [qt] Do not translate tilde character...
 732017-01-04T07:21:52  <bitcoin-git> [bitcoin] laanwj closed pull request #9462: [qt] Do not translate tilde character (master...Mf1701-qtTransTilde) https://github.com/bitcoin/bitcoin/pull/9462
 742017-01-04T07:48:33  *** kadoban has quit IRC
 752017-01-04T08:05:56  *** BashCo has quit IRC
 762017-01-04T08:06:34  *** BashCo has joined #bitcoin-core-dev
 772017-01-04T08:11:00  *** BashCo has quit IRC
 782017-01-04T08:11:54  <gmaxwell> gah we still sign inside the transaction creation inner loop?! I thought we fixed that a long time ago. :-/
 792017-01-04T08:12:03  <gmaxwell> insanity.
 802017-01-04T08:13:59  *** Guyver2 has joined #bitcoin-core-dev
 812017-01-04T08:26:19  *** BashCo has joined #bitcoin-core-dev
 822017-01-04T08:26:59  *** Alina-malina has quit IRC
 832017-01-04T08:26:59  *** Alina-malina has joined #bitcoin-core-dev
 842017-01-04T08:29:29  *** arowser has quit IRC
 852017-01-04T08:29:45  *** arowser has joined #bitcoin-core-dev
 862017-01-04T08:29:48  *** xiangfu has quit IRC
 872017-01-04T08:31:33  *** fengling has quit IRC
 882017-01-04T08:37:07  *** fengling has joined #bitcoin-core-dev
 892017-01-04T08:37:13  *** Squidicc has quit IRC
 902017-01-04T08:38:18  <jonasschnelli> gmaxwell: you don't if you are using fundrawtx
 912017-01-04T08:38:32  *** xiangfu has joined #bitcoin-core-dev
 922017-01-04T08:38:46  <jonasschnelli> well, you use the dummy signer
 932017-01-04T08:41:49  <Jouke> pruning node do forward blocks nowadays right?
 942017-01-04T08:41:56  <gmaxwell> yes.
 952017-01-04T08:42:52  <Jouke> A rescan on my problem node didn't work, so I removed the block and chainstate dir and let it sync from fresh.
 962017-01-04T08:43:34  <gmaxwell> rescan? why were you rescanning?
 972017-01-04T08:44:18  <Jouke> I had that problem before which you helped me with a couple of days ago.
 982017-01-04T08:44:47  <Jouke> It couldn't read a block from disk when I issued a getblock rpc call
 992017-01-04T08:44:52  <gmaxwell> did you rescan or reindex?
1002017-01-04T08:45:06  <gmaxwell> rescan will do nothing, so if that didn't work it's unsurprising.
1012017-01-04T08:45:14  <Jouke> Euh, reindex indeed
1022017-01-04T08:45:36  <Jouke> I did a reindex
1032017-01-04T08:45:45  <gmaxwell> whew. Interesting!
1042017-01-04T08:46:38  <Jouke> But since it was connected only to a pruning node, I had it temporarily connect to an other node of mine through an ssh tunnel.
1052017-01-04T08:46:55  <gmaxwell> yes, can't fetch the history through the pruned node.
1062017-01-04T08:47:54  <Jouke> That connection went down this evening (I'm in europe), and it synced to block 445248
1072017-01-04T08:48:33  <Jouke> But the pruning node it connects to should have the rest of the blocks as prune=80000
1082017-01-04T08:48:46  <gmaxwell> if you were expecting it to fetch blocks that weren't at the tip but were within the pruning window, that also won't work: the pruned node has no way to tell the peer what blocks it has.
1092017-01-04T08:49:55  <gmaxwell> your fetching node will not try to sync off it. But when the pruned node has a new block it will relay it along (and if there is a reorg required, the client node will still fetch whatever blocks are required to accomplish the reorg).
1102017-01-04T08:50:28  <Jouke> Hmm, ok.
1112017-01-04T08:50:55  <Jouke> So my expectations were wrong. Thanks again for explaining!
1122017-01-04T08:51:26  *** gielbier has joined #bitcoin-core-dev
1132017-01-04T08:57:16  <bitcoin-git> [bitcoin] gmaxwell opened pull request #9465: [Wallet] Do not perform ECDSA in the fee calculation inner loop. (master...no_signing_in_inner_loop) https://github.com/bitcoin/bitcoin/pull/9465
1142017-01-04T09:04:11  *** Squidicuz has joined #bitcoin-core-dev
1152017-01-04T09:04:34  *** fanquake has joined #bitcoin-core-dev
1162017-01-04T09:08:40  *** Guyver2 has quit IRC
1172017-01-04T09:10:06  <gmaxwell> wumpus: I'm glad I wasn't the only person who thought it was already the case.
1182017-01-04T09:10:30  <bitcoin-git> [bitcoin] fanquake opened pull request #9467: [Trivial] [Doc] Install Protobuf v3 on OS X (master...osx-protobuf-doc) https://github.com/bitcoin/bitcoin/pull/9467
1192017-01-04T09:10:43  *** jannes has joined #bitcoin-core-dev
1202017-01-04T09:10:46  <gmaxwell> only noticed it wasn't when I went to decrement the fee when we found we needed less than we expected and found I couldn't because the transaction was already signed.
1212017-01-04T09:10:47  <wumpus> gmaxwell: I thought that was exactly why the dummy signer was introduced, but apparently not
1222017-01-04T09:11:23  <gmaxwell> I ... think there was a miscommunication when it was proposed that a dummy signer be used there. :P
1232017-01-04T09:12:11  <gmaxwell> As in someone thought that it was only needed for the fundrawtransaction case. :P
1242017-01-04T09:12:12  <wumpus> probably
1252017-01-04T09:12:25  <wumpus> ohh, so that's why it was introduced. Yes I remember now
1262017-01-04T09:12:30  *** Giszmo has joined #bitcoin-core-dev
1272017-01-04T09:12:52  <wumpus> anyhow using it for normal transaction generation makes a lot of sense
1282017-01-04T09:13:16  <gmaxwell> should be a lot faster in some cases.
1292017-01-04T09:13:30  <gmaxwell> but also lets us do more sensible things with fees.
1302017-01-04T09:14:00  *** JackH has joined #bitcoin-core-dev
1312017-01-04T09:23:23  <jonasschnelli> We could remove the "real" signing from CreateTransaction and factor out SignTransaction (from signrawtx) and use everywhere Create/Fund/Sign.
1322017-01-04T09:23:40  <jonasschnelli> (everywhere internally)
1332017-01-04T09:23:49  <jonasschnelli> Qt / sendtoaddr / sendmany
1342017-01-04T09:24:56  <jonasschnelli> Ah. Just saw. #9465
1352017-01-04T09:24:57  *** Ylbam has joined #bitcoin-core-dev
1362017-01-04T09:24:58  <gribble> https://github.com/bitcoin/bitcoin/issues/9465 | [Wallet] Do not perform ECDSA signing in the fee calculation inner loop. by gmaxwell · Pull Request #9465 · bitcoin/bitcoin · GitHub
1372017-01-04T09:31:49  *** Squidicuz has quit IRC
1382017-01-04T09:32:31  *** Squidicuz has joined #bitcoin-core-dev
1392017-01-04T09:40:01  <fanquake> Is libevent 2.1.7 actually a release candidate, or just new beta version? Maybe a chance for a new release in the next few months.
1402017-01-04T09:40:47  <fanquake> wumpus would you be opposed to moving depends to the latest libevent beta (which it is pre 0.14) for the 0.14 release?
1412017-01-04T09:41:51  <fanquake> Just looking through dependancies now. Qt is another one to consider. 5.7 has had a point release, so should be more stable.
1422017-01-04T09:42:29  <cfields> fanquake: speaking of, I know I owe you a bunch of review/acks on depends PRs. Been rushing to get net stuff finished up. I'll find some time this week to go through those.
1432017-01-04T09:43:51  <fanquake> cfields no worries. I've just fixed-up the Zero-MQ one. Was going to open a more general depends related one tonight/tomorrow. Are you working on anything there that might conflict?
1442017-01-04T09:45:12  <cfields> fanquake: no, only qt would conflict. I have a halfway-rewritten .mk to take advantage of some of the new build features for 5.7. But iirc we can bump without that and save it for 5.8 if needed.
1452017-01-04T09:46:11  <cfields> er, that should say halfway-done rewrite
1462017-01-04T09:47:36  <fanquake> cfields cool. I'll get these changes finished up and PR. Are we at all confident of dropping Boost for 0.14.0? Otherwise is a 1.61.0 -> 1.63.0 bump worth it in the interim?
1472017-01-04T09:48:37  <cfields> fanquake: yea, not going to make it for 0.14. The changes are no fun to review, so it tends to go slowly
1482017-01-04T09:51:45  <fanquake> cfields fair enough, it's a long slog. You're doing great work though. :)
1492017-01-04T09:52:46  *** windsok has quit IRC
1502017-01-04T09:53:08  <cfields> heh, thanks
1512017-01-04T10:06:29  *** berndj has quit IRC
1522017-01-04T10:19:19  *** windsok has joined #bitcoin-core-dev
1532017-01-04T10:21:51  <wumpus> fanquake: no, I'd propose the same
1542017-01-04T10:22:09  <wumpus> fanquake: the libevent beta is *lots* better than the last stable, lots of fixes and new features
1552017-01-04T10:23:04  <fanquake> wumpus: Great, i'll work on some changes for that as well.
1562017-01-04T10:25:48  <wumpus> IIRC also means a windows-specific patch is no longer necesary
1572017-01-04T10:26:25  <fanquake> Yes, I think there is the possibility to drop some workarounds as well.
1582017-01-04T10:26:35  <fanquake> Yea #8867
1592017-01-04T10:26:37  <gribble> https://github.com/bitcoin/bitcoin/issues/8867 | Move to Libevent 2.1.x · Issue #8867 · bitcoin/bitcoin · GitHub
1602017-01-04T10:53:23  *** AaronvanW has quit IRC
1612017-01-04T11:03:43  *** MarcoFalke has joined #bitcoin-core-dev
1622017-01-04T11:09:47  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/649cf5fe894b...c0ddd32bf629
1632017-01-04T11:09:47  <bitcoin-git> bitcoin/master 27765b6 isle2983: Increment MIT Licence copyright header year on files modified in 2016...
1642017-01-04T11:09:48  <bitcoin-git> bitcoin/master c0ddd32 Wladimir J. van der Laan: Merge #9450: Increment MIT licence copyright header year on files modified in 2016...
1652017-01-04T11:10:04  <bitcoin-git> [bitcoin] laanwj closed pull request #9450: Increment MIT licence copyright header year on files modified in 2016 (master...PR-increment-year) https://github.com/bitcoin/bitcoin/pull/9450
1662017-01-04T11:12:58  *** AaronvanW has joined #bitcoin-core-dev
1672017-01-04T11:12:59  *** AaronvanW has quit IRC
1682017-01-04T11:12:59  *** AaronvanW has joined #bitcoin-core-dev
1692017-01-04T11:21:34  *** jtimon has joined #bitcoin-core-dev
1702017-01-04T11:22:05  *** jannes has quit IRC
1712017-01-04T11:22:17  <bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/c0ddd32bf629...d9ae1cefa081
1722017-01-04T11:22:18  <bitcoin-git> bitcoin/master 7325b15 Cory Fields: net: a few small cleanups before replacing boost threads...
1732017-01-04T11:22:18  <bitcoin-git> bitcoin/master 799df91 Cory Fields: net: add CThreadInterrupt and InterruptibleSleep
1742017-01-04T11:22:19  <bitcoin-git> bitcoin/master 0985052 Cory Fields: net: make net interruptible...
1752017-01-04T11:22:28  <bitcoin-git> [bitcoin] laanwj closed pull request #9289: net: drop boost::thread_group (master...connman-threads) https://github.com/bitcoin/bitcoin/pull/9289
1762017-01-04T11:23:31  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/d9ae1cefa081...869781c51cc1
1772017-01-04T11:23:32  <bitcoin-git> bitcoin/master c44e4c4 Pieter Wuille: Make AcceptToMemoryPool take CTransactionRef
1782017-01-04T11:23:32  <bitcoin-git> bitcoin/master 62607d7 Pieter Wuille: Convert COrphanTx to keep a CTransactionRef
1792017-01-04T11:23:33  <bitcoin-git> bitcoin/master 6713f0f Pieter Wuille: Make FillBlock consume txn_available to avoid shared_ptr copies
1802017-01-04T11:23:42  <bitcoin-git> [bitcoin] laanwj closed pull request #9283: A few more CTransactionRef optimizations (master...sharedblock2) https://github.com/bitcoin/bitcoin/pull/9283
1812017-01-04T11:34:21  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/869781c51cc1...1ce7ede2a9df
1822017-01-04T11:34:22  <bitcoin-git> bitcoin/master eab8e1b Alex Morcos: fix a bug if the min fee is 0 for FeeFilterRounder
1832017-01-04T11:34:22  <bitcoin-git> bitcoin/master f8d43b8 Alex Morcos: Avoid rollingMinimumFeeRate never being able to decay below half
1842017-01-04T11:34:23  <bitcoin-git> bitcoin/master 1ce7ede Wladimir J. van der Laan: Merge #9288: Fix a bug if the min fee is 0 for FeeFilterRounder...
1852017-01-04T11:34:29  <bitcoin-git> [bitcoin] laanwj closed pull request #9288: Fix a bug if the min fee is 0 for FeeFilterRounder (master...fixFFRbug) https://github.com/bitcoin/bitcoin/pull/9288
1862017-01-04T11:45:46  *** JackH has quit IRC
1872017-01-04T11:48:18  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1ce7ede2a9df...d65a13b773f8
1882017-01-04T11:48:18  <bitcoin-git> bitcoin/master 3f67972 accraze: updated listsinceblock rpc docs...
1892017-01-04T11:48:19  <bitcoin-git> bitcoin/master d65a13b Wladimir J. van der Laan: Merge #9396: Updated listsinceblock rpc documentation...
1902017-01-04T11:48:35  <bitcoin-git> [bitcoin] laanwj closed pull request #9396: Updated listsinceblock rpc documentation (master...docs-listsinceblock-rpc) https://github.com/bitcoin/bitcoin/pull/9396
1912017-01-04T12:01:33  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d65a13b773f8...c2ea1e6561ca
1922017-01-04T12:01:33  <bitcoin-git> bitcoin/master 0513c70 Gregory Sanders: Make rpcauth help message clearer, add example in example .conf
1932017-01-04T12:01:34  <bitcoin-git> bitcoin/master c2ea1e6 MarcoFalke: Merge #9401: Make rpcauth help message clearer, add example in example .conf...
1942017-01-04T12:01:46  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9401: Make rpcauth help message clearer, add example in example .conf (master...rpcauthnotes) https://github.com/bitcoin/bitcoin/pull/9401
1952017-01-04T12:14:52  *** harrymm has quit IRC
1962017-01-04T12:46:49  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c2ea1e6561ca...5bc3b6cede8d
1972017-01-04T12:46:49  <bitcoin-git> bitcoin/master 35ee63c fanquake: [Doc] Install Protobuf v3 on OS X
1982017-01-04T12:46:50  <bitcoin-git> bitcoin/master 5bc3b6c MarcoFalke: Merge #9467: [Trivial] [Doc] Install Protobuf v3 on OS X...
1992017-01-04T12:47:05  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9467: [Trivial] [Doc] Install Protobuf v3 on OS X (master...osx-protobuf-doc) https://github.com/bitcoin/bitcoin/pull/9467
2002017-01-04T13:00:06  *** windsok has quit IRC
2012017-01-04T13:15:15  <bitcoin-git> [bitcoin] fanquake opened pull request #9468: [WIP][Depends] Dependancy updates for 0.14.0 (master...depends-update-014) https://github.com/bitcoin/bitcoin/pull/9468
2022017-01-04T13:24:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2032017-01-04T13:28:30  <bitcoin-git> [bitcoin] fanquake opened pull request #9469: [WIP][depends] Qt 5.7.1 (master...depends-0-14-0-qt) https://github.com/bitcoin/bitcoin/pull/9469
2042017-01-04T13:32:17  *** windsok has joined #bitcoin-core-dev
2052017-01-04T13:37:28  <bitcoin-git> [bitcoin] laanwj opened pull request #9470: qt: Set (count) placeholder in sendcoinsdialog to notranslate (master...2017_01_more_translate_fixes) https://github.com/bitcoin/bitcoin/pull/9470
2062017-01-04T13:42:27  * jonasschnelli is downloading github issue/PR-html 0-10000 to process html and calculate how many comments where made in 2016
2072017-01-04T13:43:04  <fanquake> jonasschnelli What's your guess?
2082017-01-04T13:43:11  <jonasschnelli> No idea. :)
2092017-01-04T13:43:20  <jonasschnelli> I guess around 30 per day
2102017-01-04T13:44:39  <jonasschnelli> I though about counting words per comment,... but due to code/log copy and paste, etc., this is not really representative
2112017-01-04T13:45:40  <fanquake> I was going to say far less than that, maybe between 3000-5000 comments total. However now I think about it, some days I'd easily see > 30 emails from bitcoin/bitcoin heh
2122017-01-04T13:46:01  <fanquake> Depends how many people you have blocked :p
2132017-01-04T13:47:13  <MarcoFalke> Huh, you can block comments from specific people?
2142017-01-04T13:48:01  <fanquake> I don't think so, just block the entire user. So you won't see any PRs/comments etc
2152017-01-04T13:48:42  <MarcoFalke> hmm, interesting. Luckily we don't have returning spammers.
2162017-01-04T13:50:14  <fanquake> One thing I had been considering was going back through some ancient issues/PRs, and "locking" the conversation. That would at least stop the random comments/replies on some.
2172017-01-04T14:00:57  <fanquake> wumpus looks like we can drop both libevent patches
2182017-01-04T14:08:37  <sipa> jonasschnelli: isn't easier through the json interface?
2192017-01-04T14:09:12  <bitcoin-git> [bitcoin] fanquake opened pull request #9471: [WIP][depends] libevent 2.1.7rc (master...depends-0-14-0-libevent) https://github.com/bitcoin/bitcoin/pull/9471
2202017-01-04T14:09:19  <jonasschnelli> sipa: last time I checked there where some limits and not all data was available
2212017-01-04T14:09:51  *** fanquake has left #bitcoin-core-dev
2222017-01-04T14:13:28  <jonasschnelli> sipa: I guess the main problem is: curl https://api.github.com/rate_limit
2232017-01-04T14:13:51  <jonasschnelli> Maybe I need to a sleep(100) and run it over night
2242017-01-04T14:14:08  <jonasschnelli> I mean, not I need a sleep(100), the script.
2252017-01-04T14:19:01  <jonasschnelli> Ah. Found the reason why I didn't used the API: "Requests that return multiple items will be paginated to 30 items by default."
2262017-01-04T14:20:17  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5bc3b6cede8d...df1ab5b4d67b
2272017-01-04T14:20:17  <bitcoin-git> bitcoin/master 388ea19 Wladimir J. van der Laan: qt: Set (count) placeholder in sendcoinsdialog to notranslate
2282017-01-04T14:20:18  <bitcoin-git> bitcoin/master df1ab5b MarcoFalke: Merge #9470: qt: Set (count) placeholder in sendcoinsdialog to notranslate...
2292017-01-04T14:20:32  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9470: qt: Set (count) placeholder in sendcoinsdialog to notranslate (master...2017_01_more_translate_fixes) https://github.com/bitcoin/bitcoin/pull/9470
2302017-01-04T14:33:07  *** laurentmt has joined #bitcoin-core-dev
2312017-01-04T14:34:23  *** laurentmt has quit IRC
2322017-01-04T14:50:37  <luke-jr> https://www.reddit.com/r/Bitcoin/comments/5ltw5n/bitcoin_core_v0131_sends_enormously_high_fee/ seems to not be an isolated case
2332017-01-04T14:54:23  <MarcoFalke> jonasschnelli: I think there is already a repo with all the github comments to Bitcoin Core. (Including history for each comment)
2342017-01-04T14:54:44  <MarcoFalke> But I can't find the link. I think someone mentioned it last year in Zürich
2352017-01-04T14:54:48  <jonasschnelli> Yes. I remember that. Is it up to date? I can't recall the URL though
2362017-01-04T14:56:37  <jonasschnelli> A html dump is always a good thing. Also, parsing auto-generated-html is simple and a good regex exercise. :)
2372017-01-04T14:56:57  <luke-jr> a markdown dump would be better *hides*
2382017-01-04T14:59:17  <jonasschnelli> luke-jr: Yeah. But does Github offers a md dump? I don't think so.
2392017-01-04T14:59:29  <rabidus_> http://bitcoinfees.21.co shows that there are plenty of more those 421-450 satoshi/byte transactions. Maybe related to that bug?
2402017-01-04T15:01:37  <MarcoFalke> kanzure: ^ Might know the url to the repo. :)
2412017-01-04T15:02:01  <kanzure> actually no, i'd like to know that repo as well
2422017-01-04T15:02:15  <MarcoFalke> How come no one ever reported that wallet fee bug?
2432017-01-04T15:03:29  <kanzure> (i've also never heard of it.)
2442017-01-04T15:05:19  <luke-jr> jonasschnelli: there must be some way, since the AJAX gets it for comment editing
2452017-01-04T15:07:04  <kanzure> or email inbox receiving all comments
2462017-01-04T15:07:30  <kanzure> which is better because you have even deleted comments (which, ahem, has happened to btcdrak and others)
2472017-01-04T15:13:36  <jtimon> jonasschnelli: I just realized I never understood your proposal for the spv mode in bitcoin core (or maybe I'm missing something about bloom filter based implementations of SPV)
2482017-01-04T15:13:59  <jonasschnelli> jtimon: It's simple.
2492017-01-04T15:14:07  <jtimon> you said that this is better for privacy because it will download full blocks, which makes sense to me
2502017-01-04T15:14:24  <jtimon> but how do you know which blocks you want to download?
2512017-01-04T15:14:24  <jonasschnelli> Just download blocks, scan transactions, if relevant to the wallet, mark them a fSPV=true
2522017-01-04T15:14:31  <jonasschnelli> Just all of them!
2532017-01-04T15:14:43  <jonasschnelli> But not deeper then your wallet birthday.
2542017-01-04T15:15:08  <jonasschnelli> If you start a fresh bitcoin-qt/d, you download only a couple of blocks and can start using Core with SPV
2552017-01-04T15:15:08  <jtimon> mhmm, you download all blocks without validating them?
2562017-01-04T15:15:28  <jonasschnelli> jtimon: You have to do that anyways
2572017-01-04T15:15:32  <jonasschnelli> (if you want a full node)
2582017-01-04T15:15:36  <jtimon> ok, I get now, thanks
2592017-01-04T15:15:48  <jonasschnelli> Just download the relevant blocks first, don't validate and use them for SPV
2602017-01-04T15:16:21  <jonasschnelli> As soon as we have block-bloom-filters, we can find out which of the blocks are relevant to the wallet (2nd step)
2612017-01-04T15:18:11  <MarcoFalke> kanzure: jonasschnelli: If it is on the web, you can find it: https://github.com/zw/bitcoin-gh-meta
2622017-01-04T15:18:19  <jonasschnelli> MarcoFalke: thanks.
2632017-01-04T15:18:41  *** jannes has joined #bitcoin-core-dev
2642017-01-04T15:18:56  <jonasschnelli> jtimon: If your node is out-of-sync for a week, you need to catch up 144*7 blocks = ~1GB data, ... .maybe 30min.
2652017-01-04T15:19:35  <jonasschnelli> and the download blocks are kept for the later full-validation
2662017-01-04T15:20:26  <jtimon> thanks again, it was the "download all blocks from wallet creation" part that I was missing
2672017-01-04T15:22:44  *** windsok has quit IRC
2682017-01-04T15:25:55  <kanzure> MarcoFalke: thank you. i've now timestamped that repository as of 38ff87cb68592ca19b10803908cf3d1bf0320bf7 :D.
2692017-01-04T15:29:17  <kanzure> we should probably ask whoever maintains that to do some automatic timestamping (petertodd made a git compatibility tool)
2702017-01-04T15:33:16  *** NielsvG has joined #bitcoin-core-dev
2712017-01-04T15:33:19  *** arubi has quit IRC
2722017-01-04T15:33:19  *** wasi has quit IRC
2732017-01-04T15:42:08  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/df1ab5b4d67b...123ea7362478
2742017-01-04T15:42:09  <bitcoin-git> bitcoin/master fae26e8 MarcoFalke: [qt] Add more sources to translate
2752017-01-04T15:42:09  <bitcoin-git> bitcoin/master facf3e7 MarcoFalke: [qt] `make translate`
2762017-01-04T15:42:10  <bitcoin-git> bitcoin/master 123ea73 Wladimir J. van der Laan: Merge #9457: [qt] Select more files for translation...
2772017-01-04T15:42:28  <bitcoin-git> [bitcoin] laanwj closed pull request #9457: [qt] Select more files for translation (master...Mf1701-qtTrans) https://github.com/bitcoin/bitcoin/pull/9457
2782017-01-04T15:42:49  *** arubi has joined #bitcoin-core-dev
2792017-01-04T15:42:49  *** wasi has joined #bitcoin-core-dev
2802017-01-04T15:56:37  <gmaxwell> morcos: RE #9167  I asked a question there and I think you may have answered me on IRC but I don't remember the reply.
2812017-01-04T15:56:39  <gribble> https://github.com/bitcoin/bitcoin/issues/9167 | IsAllFromMe by morcos · Pull Request #9167 · bitcoin/bitcoin · GitHub
2822017-01-04T15:59:59  <morcos> gmaxwell: yep, will copy conversation into PR
2832017-01-04T16:01:33  <luke-jr> gmaxwell: sigh, #9326 apparently breaks with LibreSSL
2842017-01-04T16:01:35  <gribble> https://github.com/bitcoin/bitcoin/issues/9326 | Update for OpenSSL 1.1 API. by gmaxwell · Pull Request #9326 · bitcoin/bitcoin · GitHub
2852017-01-04T16:03:11  *** windsok has joined #bitcoin-core-dev
2862017-01-04T16:04:47  *** abpa has joined #bitcoin-core-dev
2872017-01-04T16:05:54  <gmaxwell> luke-jr: okay, well we don't support that.... And dark, I did test it with older OpenSSL.
2882017-01-04T16:06:27  <luke-jr> apparently LibreSSL claims to be OpenSSL >=1.1 for some stupid reason :/
2892017-01-04T16:06:40  <luke-jr> without supporting 1.1 APIs..
2902017-01-04T16:07:18  <gmaxwell> morcos: oh right, that was where I commented that we should track input values so fees could be computed accurately.
2912017-01-04T16:07:49  <morcos> ha, yes, i left out the rest of the conversation, because i figured that was a bigger change. sorry.
2922017-01-04T16:08:03  <gmaxwell> it was, I agree.
2932017-01-04T16:08:18  <luke-jr> libressl-2.5.0/include/openssl/opensslv.h:#define OPENSSL_VERSION_NUMBER  0x20000000L
2942017-01-04T16:08:19  <luke-jr> >_<
2952017-01-04T16:09:33  *** abpa has quit IRC
2962017-01-04T16:10:56  <timothy> luke-jr: cool
2972017-01-04T16:11:14  <gmaxwell> luke-jr: so it needs to be changed to a #if NEW_OPENSSL_API  and a #define NEW_OPENSSL_API that has a different version test for libressl and openssl?
2982017-01-04T16:12:11  <luke-jr> I guess so. I was just going to change it to http://bpaste.net/show/ac2c68d93576
2992017-01-04T16:12:30  <luke-jr> (getting some libressl user to test this before I open a PR)
3002017-01-04T16:12:44  <timothy> luke-jr: I think you should use something like have_func("CRYPTO_lock") || $defs.push("-DHAVE_OPENSSL_110_THREADING_API")
3012017-01-04T16:12:58  *** JackH has joined #bitcoin-core-dev
3022017-01-04T16:13:07  <timothy> check if CRYPTO_lock function exists instead of rely on OPENSSL_VERSION_NUMBER
3032017-01-04T16:13:18  <luke-jr> EVP_MD_CTX_new in this case
3042017-01-04T16:13:41  <luke-jr> I suppose that'd probably be more future-proof if LibreSSL then adds it
3052017-01-04T16:18:46  <luke-jr> someone here has an OpenSSL 1.1 system? Can you test http://bpaste.net/show/7565deaf5c48 ?
3062017-01-04T16:20:17  <luke-jr> (note re-running autogen.sh is needed)
3072017-01-04T16:22:00  <timothy> luke-jr: give me 2 minutes
3082017-01-04T16:24:37  <bitcoin-git> [bitcoin] sipa opened pull request #9472: Disentangle progress estimationc from heckpoints and update it (master...update_tx_estimation) https://github.com/bitcoin/bitcoin/pull/9472
3092017-01-04T16:25:00  *** NielsvG has left #bitcoin-core-dev
3102017-01-04T16:25:21  *** Giszmo has quit IRC
3112017-01-04T16:40:02  *** BashCo has quit IRC
3122017-01-04T16:40:18  <bitcoin-git> [bitcoin] sipa opened pull request #9474: Mark the minconf parameter to move as ignored (master...stale_minconf_parameter) https://github.com/bitcoin/bitcoin/pull/9474
3132017-01-04T16:41:13  <timothy> luke-jr: you have to use AC_CHECK_FUNCS instead
3142017-01-04T16:47:11  <luke-jr> timothy: does this work any better? http://bpaste.net/show/b0c01efeceb6
3152017-01-04T16:47:27  *** abpa has joined #bitcoin-core-dev
3162017-01-04T16:49:04  <timothy> AC_CHECK_DECLS is wrong
3172017-01-04T16:49:28  <timothy> wait
3182017-01-04T16:49:55  <gmaxwell> luke-jr: patch does not work on openssl 1.1
3192017-01-04T16:51:21  <gmaxwell> HAVE_DECL_EVP_MD_CTX_NEW isn't getting set.
3202017-01-04T16:54:31  <timothy> setting CFLAGS is useless since it's using g++
3212017-01-04T16:54:39  *** laurentmt has joined #bitcoin-core-dev
3222017-01-04T16:54:44  *** laurentmt has quit IRC
3232017-01-04T16:55:23  <luke-jr> hmm
3242017-01-04T16:55:41  <timothy> configure:29569: g++ -c -g -O2 -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS conftest.cpp >&5
3252017-01-04T16:57:10  <timothy> gmaxwell: do you have the same behaviour?
3262017-01-04T17:00:20  *** BashCo has joined #bitcoin-core-dev
3272017-01-04T17:02:11  <luke-jr> ok, tested http://bpaste.net/show/5acc82591b69 with a non-installed OpenSSL 1.1 build, should work finally
3282017-01-04T17:03:47  <timothy> +CXXFLAGS="${CFLAGS} ${SSL_CFLAGS}"
3292017-01-04T17:03:49  <timothy> typo
3302017-01-04T17:04:02  <timothy> CXXFLAGS+"${CXXFLAGS} ${SSL_CFLAGS}" imho
3312017-01-04T17:04:08  <timothy> CXXFLAGS=
3322017-01-04T17:05:15  <luke-jr> oops good catch
3332017-01-04T17:05:29  * luke-jr wonders why autoconf doesn't have a macro to push-and-append stuff like this
3342017-01-04T17:06:12  <timothy> since SSL_CXXFLAGS doesn't exists, SSL_CFLAGS is ok
3352017-01-04T17:06:48  <gmaxwell> that (fixed version of luke's patch) compiles for me.
3362017-01-04T17:07:08  <timothy> for me too
3372017-01-04T17:08:41  <luke-jr> thanks
3382017-01-04T17:08:48  <bitcoin-git> [bitcoin] luke-jr opened pull request #9475: Let autoconf detect presence of EVP_MD_CTX_new (master...EVP_MD_CTX_new) https://github.com/bitcoin/bitcoin/pull/9475
3392017-01-04T17:16:21  *** abpa has quit IRC
3402017-01-04T17:16:45  <timothy> luke-jr: why don't you use  #include <openssl/evp.h> (https://www.openssl.org/docs/manmaster/man3/EVP_MD_CTX_new.html) ?
3412017-01-04T17:17:57  *** abpa has joined #bitcoin-core-dev
3422017-01-04T17:18:00  <luke-jr> timothy: the actual code doesn't.
3432017-01-04T17:18:23  <luke-jr> figure less hiccups if the check and code are closer aligned
3442017-01-04T17:21:18  <timothy> luke-jr: on openssl 1.1  you have openssl/evp.h
3452017-01-04T17:21:58  <luke-jr> x509_vfy.h includes evp.h, and Core's code only includes x509_vfy.h
3462017-01-04T17:26:18  <jtimon> how realistic it is to hope to get https://github.com/bitcoin/bitcoin/pull/8994 merged for 0.14 ?
3472017-01-04T17:27:21  <jtimon> what is it missing? as said in a comment, segwit.py and p2p-compactblocks.py still need to run with self.chain = "regtest" instead of self.chain = "custom". But perhaps that's ok?
3482017-01-04T17:27:53  *** wvr has quit IRC
3492017-01-04T17:30:28  *** kadoban has joined #bitcoin-core-dev
3502017-01-04T17:37:21  <jtimon> maybe a new rpc test changing some chainparams values?
3512017-01-04T17:50:18  <MarcoFalke> cfields: Any guess why #9416 causes a undefined reference to `qInitResources_bitcoin()'?
3522017-01-04T17:50:19  <gribble> https://github.com/bitcoin/bitcoin/issues/9416 | travis: make distdir before make by MarcoFalke · Pull Request #9416 · bitcoin/bitcoin · GitHub
3532017-01-04T18:08:51  *** AaronvanW has quit IRC
3542017-01-04T18:14:38  *** protomar has joined #bitcoin-core-dev
3552017-01-04T18:20:37  <paveljanik> MarcoFalke, https://travis-ci.org/bitcoin/bitcoin/jobs/187303535#L1939
3562017-01-04T18:20:46  <paveljanik> Cannot find file 'res/movies/spinner-000.png'
3572017-01-04T18:21:27  <paveljanik> strange 8)
3582017-01-04T18:24:28  <Chris_Stewart_5> Just to be clear, there are public keys in the blockchain that do not pass the `IsCompressedOrUncompressedPubKey` check right? This is enforced as policy right?
3592017-01-04T18:28:42  <sipa> there may be
3602017-01-04T18:28:44  <sipa> i'm not sure
3612017-01-04T18:28:45  <bitcoin-git> [bitcoin] instagibbs closed pull request #8992: Enable pubkey lookup for p2sh-p2wpkh in validateaddress (master...validatep2pkh) https://github.com/bitcoin/bitcoin/pull/8992
3622017-01-04T18:28:57  <sipa> there certainly are in testnet
3632017-01-04T18:29:16  <Chris_Stewart_5> sipa: Is there a BIP that was proposed that check?
3642017-01-04T18:31:01  <sipa> not afaik
3652017-01-04T18:38:45  <cfields> MarcoFalke: hmm, sounds like something's legitimately not getting included
3662017-01-04T18:39:12  <MarcoFalke> paveljanik had a hint. Let me try to solve the wildcard
3672017-01-04T18:40:04  <cfields> MarcoFalke: ah, missed that
3682017-01-04T18:45:47  <cfields> MarcoFalke: hmm, it's been a while, but i'm assuming that I somehow missed the other qrc in fc4ad0c7fcf2e5841756c9d1003f95c879ee5cd2
3692017-01-04T18:48:02  <Chris_Stewart_5> sipa: We don't have a more general public key check do we? For instance, a valid public key encoding that encompasses all encodings that are valid in openssl?
3702017-01-04T18:48:12  <cfields> MarcoFalke: so.. http://pastebin.com/raw/xYXmu8Jk
3712017-01-04T18:48:21  <MarcoFalke> cfields: Could be but when this is the cause, I don't understand why travis didn't fail back then: https://github.com/bitcoin/bitcoin/blob/fc4ad0c7fcf2e5841756c9d1003f95c879ee5cd2/.travis.yml#L76
3722017-01-04T18:48:58  <sipa> Chris_Stewart_5: CPubKey::IsFullyValid()
3732017-01-04T18:49:09  <sipa> (which is implemented in libsecp256k1)
3742017-01-04T18:49:17  <Chris_Stewart_5> Thank you!
3752017-01-04T18:50:07  <cfields> MarcoFalke: unsure. The above is just a guess. I need to catch a flight, I'll catch up on irc logs later
3762017-01-04T18:50:25  <MarcoFalke> sure, will try your patch
3772017-01-04T18:50:28  <gmaxwell> sipa: I'm doubtful that SIGCHECK_VERIFICATION_FACTOR is correct anymore except on really slow computers, fwiw.
3782017-01-04T18:50:42  <cfields> MarcoFalke: heh, that came off as very rude. Wasn't intentional :)
3792017-01-04T18:50:50  <sipa> gmaxwell: willing to change it based on HARD DATA
3802017-01-04T18:51:02  <MarcoFalke> cfields: I didn't read any rudeness. :P
3812017-01-04T18:51:13  <gmaxwell> 'HARD DATA, Soft forks.'
3822017-01-04T18:51:26  <sipa> gmaxwell: though, it's probably better to overshoot than undershoot
3832017-01-04T18:51:36  <sipa> (seeing a progress bar speed up over time is nice)
3842017-01-04T18:51:52  <Chris_Stewart_5> /r/oddlysatisfying
3852017-01-04T18:52:14  <gmaxwell> jeremyrubin: did you ever explore having a simple bypass of the signature cache when validating blocks far from the best header, to reduce lock contention during IBD?
3862017-01-04T18:52:22  <sipa> gmaxwell: oops
3872017-01-04T18:52:29  <sipa> my code is wrong
3882017-01-04T18:52:46  <sipa> it assumes no signature checks up to the timestamp given
3892017-01-04T18:53:48  *** droark has quit IRC
3902017-01-04T18:57:38  <Chris_Stewart_5> sipa: I did not realize libsecp256k1 had java bindings in the repo, nice!
3912017-01-04T18:58:08  <gmaxwell> they might even work!
3922017-01-04T18:58:30  <sipa> gmaxwell: they have unit tests!
3932017-01-04T18:58:56  <Chris_Stewart_5> assert(true == true, "true")
3942017-01-04T19:00:11  <sipa> gmaxwell: jeremyrubin: did you ever explore having a simple bypass of the signature cache   ->   you can't do that at the sigcache level, as there may be CHECKSIG NOTs in the chain
3952017-01-04T19:01:20  <gmaxwell> sipa: hm? just treat it as there being nothing in the cache for the whole block.
3962017-01-04T19:01:35  <sipa> Ah
3972017-01-04T19:01:36  <sipa> nvm
3982017-01-04T19:01:42  <gmaxwell> which there won't be, in ibd.
3992017-01-04T19:02:21  <jtimon> btw gmaxwell did you stop working on your patch to get rid of Checkpoints::GetLastCheckpoint() ? it looked quite advanced a while ago
4002017-01-04T19:05:08  <gmaxwell> We're really review starved right now.
4012017-01-04T19:09:09  <jtimon> I see
4022017-01-04T19:09:30  <jtimon> but you didn't open a PR, did you?
4032017-01-04T19:10:05  <jtimon> no, just looked
4042017-01-04T19:10:17  <jtimon> anyway, leaving now...
4052017-01-04T19:10:49  *** Guyver2 has joined #bitcoin-core-dev
4062017-01-04T19:15:10  *** jtimon has quit IRC
4072017-01-04T19:18:32  <MarcoFalke> cfields: Your patch works! Mind to create a pull for that some time after your flight?
4082017-01-04T19:23:50  <morcos> gmaxwell: re: 9465, it concerns me a little that DummySignatureCreator creates 72-byte signatures and not 73-byte signatures.  I realize most of the time its neglible, but it seems like it could just lead to bad edge cases.  It seems like we should always overpay instead.
4092017-01-04T19:28:31  <sipa> morcos: since low-S, the maximum is 72, i think
4102017-01-04T19:28:35  <sipa> and on average 71.5
4112017-01-04T19:28:50  <gmaxwell> darn sipa with the answer while I was off trying to confirm it. :)
4122017-01-04T19:28:50  <morcos> ah, missed that.. yeah i was caring about the maximum
4132017-01-04T19:30:17  <sipa> gmaxwell: of course, i also tried to confirm first :)
4142017-01-04T19:30:35  <morcos> out of curiousity, how were you confirming that
4152017-01-04T19:30:42  <sipa> 32 bytes S, 33 bytes R, 6 bytes DER stupidity, 1 byte sighash
4162017-01-04T19:31:03  <sipa> is the maximum
4172017-01-04T19:31:18  <sipa> where R is 32 bytes 50% of the tie
4182017-01-04T19:31:51  <morcos> ok i thought you meant confirming S couldn't be more than 32 bytes, which seemed pretty obvious if i understood what low-S meant
4192017-01-04T19:32:45  *** grbs has quit IRC
4202017-01-04T19:35:07  *** waxwing has quit IRC
4212017-01-04T19:35:48  <sipa> maybe we should grind by default to produce a 32-byte R as well
4222017-01-04T19:35:48  *** waxwing has joined #bitcoin-core-dev
4232017-01-04T19:35:50  <sipa> :)
4242017-01-04T19:36:03  *** norotartagen has quit IRC
4252017-01-04T19:36:03  *** gribble has quit IRC
4262017-01-04T19:36:03  *** zxzzt has quit IRC
4272017-01-04T19:36:03  *** ratoder has quit IRC
4282017-01-04T19:36:05  <sipa> would need 2 iterations on average
4292017-01-04T19:36:17  *** zxzzt has joined #bitcoin-core-dev
4302017-01-04T19:36:21  *** ratoder has joined #bitcoin-core-dev
4312017-01-04T19:36:27  *** norotartagen has joined #bitcoin-core-dev
4322017-01-04T19:38:04  <gmaxwell> sipa: it could be done in constant time using the endomorphism, no?
4332017-01-04T19:40:03  <sipa> gmaxwell: oh, sure!
4342017-01-04T19:40:14  <sipa> the negation endomorphism, you mean?
4352017-01-04T19:41:15  *** gribble has joined #bitcoin-core-dev
4362017-01-04T19:41:37  <gmaxwell> negation doesn't change X, and it's used by low-S.  I mean multiply by lambda, potentially twice.
4372017-01-04T19:43:02  <sipa> is there a guarantee that that will always result in a R.x value in the lower range?
4382017-01-04T19:49:47  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/123ea7362478...0fc1c31a878e
4392017-01-04T19:49:47  <bitcoin-git> bitcoin/master ffeb195 Alex Morcos: add test for -walletrejectlongchains
4402017-01-04T19:49:47  <bitcoin-git> bitcoin/master 0fc1c31 MarcoFalke: Merge #9395: Add test for -walletrejectlongchains...
4412017-01-04T19:49:57  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9395: Add test for -walletrejectlongchains (master...fixmovedtx) https://github.com/bitcoin/bitcoin/pull/9395
4422017-01-04T19:51:43  <gmaxwell> sipa: thats why I asked, expirementally it's true bit it's not obvious to me how to prove it.
4432017-01-04T19:53:05  <gmaxwell> sipa: I tested for F(-1) to F(-100000) and in all case either *beta or *beta^2 results in a number less than 2**255
4442017-01-04T19:53:32  <gmaxwell> okay -1 to -1000000 now.
4452017-01-04T19:55:28  <gmaxwell> okay, theory disproved.
4462017-01-04T19:56:41  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0fc1c31a878e...7dac1e5e9e88
4472017-01-04T19:56:41  <bitcoin-git> bitcoin/master b50cd7a Alex Morcos: Fix dangerous condition in ModifyNewCoins....
4482017-01-04T19:56:41  <bitcoin-git> bitcoin/master 7dac1e5 Pieter Wuille: Merge #9107: Safer modify new coins...
4492017-01-04T19:56:52  <bitcoin-git> [bitcoin] sipa closed pull request #9107: Safer modify new coins (master...saferModifyNewCoins) https://github.com/bitcoin/bitcoin/pull/9107
4502017-01-04T19:58:46  <gmaxwell> (it's only true 87% of the time, but happens to hold for all very large and very small field elements)
4512017-01-04T20:32:24  *** dcousens has joined #bitcoin-core-dev
4522017-01-04T20:32:53  <dcousens> gmaxwell: RE https://github.com/bitcoin/bitcoin/issues/9463#issuecomment-270303374,  my point was for naming of the RPC calls
4532017-01-04T20:33:37  <dcousens> Wait, I've just realised I've mis-read what belcher meant, I read it as:   " bitcoin nodes known to your node via RPC."
4542017-01-04T20:34:17  <dcousens> as in,  RPC connections
4552017-01-04T20:35:41  <gmaxwell> dcousens: I thought you might have been misreading it that way, thus the question.
4562017-01-04T20:36:04  <dcousens> gmaxwell: cheers :)
4572017-01-04T20:47:59  *** brg444 has joined #bitcoin-core-dev
4582017-01-04T21:03:58  *** dcousens has quit IRC
4592017-01-04T21:04:15  *** dcousens has joined #bitcoin-core-dev
4602017-01-04T21:15:19  *** roidster has joined #bitcoin-core-dev
4612017-01-04T21:42:16  *** roidster has quit IRC
4622017-01-04T21:42:43  *** droark has joined #bitcoin-core-dev
4632017-01-04T21:54:43  *** droark has quit IRC
4642017-01-04T22:19:54  *** arubi has quit IRC
4652017-01-04T22:19:54  *** wasi has quit IRC
4662017-01-04T22:23:46  *** jannes has quit IRC
4672017-01-04T22:30:47  *** brg444 has quit IRC
4682017-01-04T22:31:20  *** brg444 has joined #bitcoin-core-dev
4692017-01-04T22:31:20  *** protomar has quit IRC
4702017-01-04T22:44:02  *** MarcoFalke has left #bitcoin-core-dev
4712017-01-04T22:46:21  *** brg444 has quit IRC
4722017-01-04T22:46:53  *** brg444 has joined #bitcoin-core-dev
4732017-01-04T22:48:53  *** roidster has joined #bitcoin-core-dev
4742017-01-04T23:09:29  *** davec has quit IRC
4752017-01-04T23:10:43  *** davec has joined #bitcoin-core-dev
4762017-01-04T23:13:24  *** brg444 has quit IRC