12017-05-11T00:00:56  *** Giszmo has joined #bitcoin-core-dev
  22017-05-11T00:05:51  *** jcliff42 has quit IRC
  32017-05-11T00:06:02  *** d9b4bef9 has quit IRC
  42017-05-11T00:07:08  *** d9b4bef9 has joined #bitcoin-core-dev
  52017-05-11T00:12:46  *** AaronvanW has quit IRC
  62017-05-11T00:14:40  *** jcliff42 has joined #bitcoin-core-dev
  72017-05-11T00:15:00  *** jcliff42 has joined #bitcoin-core-dev
  82017-05-11T00:16:00  *** justanotheruser has joined #bitcoin-core-dev
  92017-05-11T00:32:41  *** dermoth has quit IRC
 102017-05-11T00:46:00  *** goksinen has joined #bitcoin-core-dev
 112017-05-11T00:50:23  *** goksinen has quit IRC
 122017-05-11T01:09:55  *** jcliff42 has quit IRC
 132017-05-11T01:14:11  *** Ylbam has quit IRC
 142017-05-11T01:26:04  *** gm2052 has quit IRC
 152017-05-11T01:27:21  *** gm2052 has joined #bitcoin-core-dev
 162017-05-11T01:28:41  *** justanotheruser has quit IRC
 172017-05-11T02:04:55  *** justanotheruser has joined #bitcoin-core-dev
 182017-05-11T02:08:29  *** jcliff42 has joined #bitcoin-core-dev
 192017-05-11T02:08:49  *** jcliff42 has joined #bitcoin-core-dev
 202017-05-11T02:10:19  *** jcliff42_ has joined #bitcoin-core-dev
 212017-05-11T02:12:10  *** goksinen has joined #bitcoin-core-dev
 222017-05-11T02:13:46  <bitcoin-git> [bitcoin] kallewoof opened pull request #10386: [wallet] Optional '-avoidreuse' flag which defaults to not reusing addresses in sends (master...feature-white-black-address) https://github.com/bitcoin/bitcoin/pull/10386
 232017-05-11T02:14:17  *** jcliff42_ has quit IRC
 242017-05-11T02:14:23  *** jcliff42 has quit IRC
 252017-05-11T02:17:01  *** goksinen has quit IRC
 262017-05-11T02:27:57  *** goksinen has joined #bitcoin-core-dev
 272017-05-11T02:30:02  *** gm2051 has joined #bitcoin-core-dev
 282017-05-11T02:32:17  *** goksinen has quit IRC
 292017-05-11T02:32:33  *** gm2052 has quit IRC
 302017-05-11T03:15:26  *** goksinen has joined #bitcoin-core-dev
 312017-05-11T03:20:27  *** goksinen has quit IRC
 322017-05-11T03:29:36  *** zooko has joined #bitcoin-core-dev
 332017-05-11T03:50:01  *** zooko has quit IRC
 342017-05-11T03:54:59  *** dermoth has joined #bitcoin-core-dev
 352017-05-11T04:04:43  *** zooko has joined #bitcoin-core-dev
 362017-05-11T04:06:02  *** d9b4bef9 has quit IRC
 372017-05-11T04:07:09  *** d9b4bef9 has joined #bitcoin-core-dev
 382017-05-11T04:12:37  *** Dyaheon has quit IRC
 392017-05-11T04:13:37  *** Dyaheon has joined #bitcoin-core-dev
 402017-05-11T04:14:55  *** tripleslash has quit IRC
 412017-05-11T04:18:07  *** tripleslash has joined #bitcoin-core-dev
 422017-05-11T04:29:33  *** paveljanik has quit IRC
 432017-05-11T04:30:21  *** zooko has quit IRC
 442017-05-11T04:32:16  *** niska has quit IRC
 452017-05-11T04:32:43  *** niska has joined #bitcoin-core-dev
 462017-05-11T04:35:10  *** tripleslash has quit IRC
 472017-05-11T04:38:46  *** tripleslash has joined #bitcoin-core-dev
 482017-05-11T04:47:48  *** tripleslash has quit IRC
 492017-05-11T04:49:26  *** annanay25 has quit IRC
 502017-05-11T04:49:36  *** annanay25 has joined #bitcoin-core-dev
 512017-05-11T04:50:11  *** tripleslash has joined #bitcoin-core-dev
 522017-05-11T05:02:39  *** tripleslash has quit IRC
 532017-05-11T05:04:07  *** tripleslash has joined #bitcoin-core-dev
 542017-05-11T05:16:56  *** goksinen has joined #bitcoin-core-dev
 552017-05-11T05:18:45  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a26280bc1415...7f2b9e0868f5
 562017-05-11T05:18:46  <bitcoin-git> bitcoin/master f203ecc Pavel Janík: Shadowing is not enabled by default, update doc accordingly.
 572017-05-11T05:18:46  <bitcoin-git> bitcoin/master 7f2b9e0 Wladimir J. van der Laan: Merge #10381: Shadowing warnings are not enabled by default, update doc accordingly...
 582017-05-11T05:19:16  <bitcoin-git> [bitcoin] laanwj closed pull request #10381: Shadowing warnings are not enabled by default, update doc accordingly (master...20170510_Wshadow_not_enabled_by_default) https://github.com/bitcoin/bitcoin/pull/10381
 592017-05-11T05:21:27  *** goksinen has quit IRC
 602017-05-11T05:29:40  *** ckm has joined #bitcoin-core-dev
 612017-05-11T05:32:45  *** goksinen has joined #bitcoin-core-dev
 622017-05-11T05:37:23  *** goksinen has quit IRC
 632017-05-11T05:58:55  *** Victorsueca has quit IRC
 642017-05-11T06:06:27  *** Ylbam has joined #bitcoin-core-dev
 652017-05-11T06:17:03  *** Dyaheon has quit IRC
 662017-05-11T06:20:50  *** Dyaheon has joined #bitcoin-core-dev
 672017-05-11T06:38:38  *** marcoagner has quit IRC
 682017-05-11T06:38:47  *** marcoagn1 has joined #bitcoin-core-dev
 692017-05-11T07:04:42  <ckm> anybody know why bitcoin started on microsoft/windows?
 702017-05-11T07:05:01  <ckm> seems odd for an open-source project
 712017-05-11T07:08:34  <kallewoof> Probably because Satoshi was using Windows when he wrote it
 722017-05-11T07:09:47  *** EagleTM has joined #bitcoin-core-dev
 732017-05-11T07:14:18  *** CubicEarth has joined #bitcoin-core-dev
 742017-05-11T07:15:44  <ckm> okay, yeah, that's a pastability. not sure though. maybe it was that the alternatives were less prevalent then, so it could have been strategic to get more miners. i kinda want a logical explanation. like it could have been a statement like hacking microsoft/windows in a phoenix type of way. hmm. your thoughts?
 752017-05-11T07:22:55  <sipa> my assumption is that satoshi or whoever wrote the first code was a windows programmer
 762017-05-11T07:23:10  <sipa> the naming style of variables etc is consistent with that
 772017-05-11T07:27:33  *** waxwing has quit IRC
 782017-05-11T07:29:09  <ckm> okay going with that then is there any indication that this was a microsoft job? they do seem to be the most supportive big tech company, including support in visual basic, openly wanting a cashless money system, and with statements of public approval
 792017-05-11T07:33:27  *** goksinen has joined #bitcoin-core-dev
 802017-05-11T07:37:57  *** goksinen has quit IRC
 812017-05-11T07:59:08  <sipa> offtopic
 822017-05-11T08:05:30  <wumpus> there are likely more windows programmers than unix programmers in the world, so the chance of a software project starting as windows software is fairly high. Seems kind of a big leap to say it's a microsoft job then. If it had started as linux project, would you have personally implicated Linus?
 832017-05-11T08:05:35  <wumpus> but yes, offtopic, #bitcoin please
 842017-05-11T08:06:55  *** shockoo has joined #bitcoin-core-dev
 852017-05-11T08:14:00  *** jannes has joined #bitcoin-core-dev
 862017-05-11T08:16:40  <ckm> i just looked through all the original code and it doesn't seem like a "microsoft job" from the comments et cettera. i wasn't very into computers, i thought linux was hard to use back then, so i was using windows/mac but a programmer would i think have been able to use it. although it would be fairest to the public to make a windows version so everybody could in theory mine the genisis block.
 872017-05-11T08:16:52  <ckm> and sorry for offtopic i will switch over to there, thanks!
 882017-05-11T08:20:42  *** i3-c3 has joined #bitcoin-core-dev
 892017-05-11T08:28:51  *** waxwing has joined #bitcoin-core-dev
 902017-05-11T08:31:23  *** timothy has joined #bitcoin-core-dev
 912017-05-11T08:35:24  *** CubicEarth has quit IRC
 922017-05-11T08:36:03  *** CubicEarth has joined #bitcoin-core-dev
 932017-05-11T08:37:42  *** CubicEarth has quit IRC
 942017-05-11T08:45:12  *** ckm has quit IRC
 952017-05-11T08:57:49  *** AaronvanW has joined #bitcoin-core-dev
 962017-05-11T08:57:49  *** AaronvanW has joined #bitcoin-core-dev
 972017-05-11T09:03:36  <jonasschnelli> Can anyone explain when a peer does relay its own CAddress to a connected peer? When I connect with mininode and inject a getaddr, I get now addr message
 982017-05-11T09:04:19  <wumpus> on incoming connections, yes
 992017-05-11T09:04:45  <jonasschnelli> wumpus: hmm... maybe I got fooled by the AddNewAddresses time penalty?
1002017-05-11T09:05:12  <wumpus> sure, or maybe there's a bug, I don't know
1012017-05-11T09:05:30  <jonasschnelli> Okay... i'll check.. maybe my local changes broke thinsg...
1022017-05-11T09:05:40  <wumpus> it seems advertizing works, but the issues about IP changes not propagating are kind of strange
1032017-05-11T09:06:27  <wumpus> sorry I meant on outgoing connections, incoming wouldn't make sense as the peer already found you :)
1042017-05-11T09:06:58  <jonasschnelli> wumpus: Ah... right..
1052017-05-11T09:07:48  <wumpus> so when your peer connects to someone else, it learns its own address (through the peer's version message), it starts advertizing that
1062017-05-11T09:08:31  <jonasschnelli> Though, if I start two peers (A,B) and connect_nodes_bi(A.B), then connect with a mininode (C) to B, I guess B should relay addr(A) when I send a getaddr
1072017-05-11T09:09:55  <wumpus> yes I think so, it should gossip about addresses it knows, though it's heavily randomized
1082017-05-11T09:15:58  <sipa> eventually, yes
1092017-05-11T09:16:03  <sipa> but that may take hours
1102017-05-11T09:16:51  <jonasschnelli> sipa: do you see a better/simpler way how to test if a peer has relayed a addr (through our test/functional/ framework)?
1112017-05-11T09:17:02  *** d9b4bef9 has quit IRC
1122017-05-11T09:17:06  *** laurentmt has joined #bitcoin-core-dev
1132017-05-11T09:17:42  <jonasschnelli> (examine peers.dat is probably a very bad idea)
1142017-05-11T09:17:55  *** laurentmt has quit IRC
1152017-05-11T09:18:19  *** d9b4bef9 has joined #bitcoin-core-dev
1162017-05-11T09:18:27  <wumpus> parsing peers.dat from the test framework seems painful
1172017-05-11T09:19:05  <jonasschnelli> If there would be a way to retrieve addrmans content from the outside..
1182017-05-11T09:19:08  <wumpus> also it's not really an interface to be tested, the peers.dat format should be flexible
1192017-05-11T09:19:16  <jonasschnelli> yeah.. indeed
1202017-05-11T09:19:22  <wumpus> agreed
1212017-05-11T09:19:41  <wumpus> some testing-only RPC?
1222017-05-11T09:20:11  <warren> why testing only?
1232017-05-11T09:20:15  <wumpus> that part of the code needs to be more testable
1242017-05-11T09:20:26  <wumpus> so we can assure that it works and track regressions
1252017-05-11T09:20:49  <wumpus> I don't see much point in having it as documented outside interface, but if you have use cases, sure...
1262017-05-11T09:21:04  <jonasschnelli> wumpus: Yes. Thought the same... I try to add an debug RPC to outputs addrmans content
1272017-05-11T09:21:08  <warren> I mean, it would be useful to be able to dump what it thinks it knows about peers during runtime of an ordinary node.
1282017-05-11T09:31:16  <sipa> we could add an rpc to report all of addrman's db through json?
1292017-05-11T09:32:54  *** dcousens has quit IRC
1302017-05-11T09:34:13  *** goksinen has joined #bitcoin-core-dev
1312017-05-11T09:36:32  *** paveljanik has joined #bitcoin-core-dev
1322017-05-11T09:36:33  *** paveljanik has joined #bitcoin-core-dev
1332017-05-11T09:39:02  *** goksinen has quit IRC
1342017-05-11T09:56:01  *** i3-c3 has quit IRC
1352017-05-11T10:03:52  *** EagleTM has quit IRC
1362017-05-11T10:26:32  *** shockoo has quit IRC
1372017-05-11T10:47:42  <wumpus> yes, exactly
1382017-05-11T11:03:20  <kallewoof> Heh. I always thought getpeerinfo did just that.
1392017-05-11T11:03:44  <kallewoof> But I guess addrman can have entries for nodes you aren't currently connected to..
1402017-05-11T11:04:07  *** rubensayshi has quit IRC
1412017-05-11T11:04:22  *** rubensayshi has joined #bitcoin-core-dev
1422017-05-11T11:04:41  <wumpus> right, getpeerinfo shows the peers that the node is currently connected to, not the ones it knows about
1432017-05-11T11:06:26  *** Giszmo has quit IRC
1442017-05-11T11:07:16  *** Giszmo has joined #bitcoin-core-dev
1452017-05-11T11:28:35  *** SopaXorzTaker has joined #bitcoin-core-dev
1462017-05-11T11:29:26  <jonasschnelli> A simpler approach would be to ensure we directly answer a getaddr request when the debug GetArg("-getaddr_direct") is set
1472017-05-11T11:30:31  *** laurentmt has joined #bitcoin-core-dev
1482017-05-11T11:33:43  *** laurentmt has quit IRC
1492017-05-11T11:34:15  *** laurentmt has joined #bitcoin-core-dev
1502017-05-11T11:34:57  *** goksinen has joined #bitcoin-core-dev
1512017-05-11T11:37:10  *** Sosumi has joined #bitcoin-core-dev
1522017-05-11T11:39:22  *** goksinen has quit IRC
1532017-05-11T11:46:42  *** Giszmo has quit IRC
1542017-05-11T11:48:05  *** harrymm has quit IRC
1552017-05-11T11:58:19  *** Dyaheon has quit IRC
1562017-05-11T11:59:42  *** Dyaheon has joined #bitcoin-core-dev
1572017-05-11T12:02:36  *** waxwing has quit IRC
1582017-05-11T12:02:42  <jonasschnelli> The whole address relay is pretty hard to test on localhost. If 127.0.0.1 then IsRoutable() == false, GetLocalAddress() does not allow 127.0.0.1,..
1592017-05-11T12:07:56  *** harrymm has joined #bitcoin-core-dev
1602017-05-11T12:29:11  *** Victorsueca has joined #bitcoin-core-dev
1612017-05-11T12:37:14  *** waxwing has joined #bitcoin-core-dev
1622017-05-11T12:45:50  <paveljanik> jonasschnelli, can you please rebase #9697 to make it easier for testing? Thank you.
1632017-05-11T12:45:52  <gribble> https://github.com/bitcoin/bitcoin/issues/9697 | [Qt] simple fee bumper with user verification by jonasschnelli · Pull Request #9697 · bitcoin/bitcoin · GitHub
1642017-05-11T12:46:42  <jonasschnelli> paveljanik: I did fresh compile it on Ubuntu 14.10 and didn't had any problems... There is already an ACK on the PR... but I can rebase if it's unavoidable.
1652017-05-11T12:47:37  <paveljanik> jonasschnelli, ok, np.
1662017-05-11T12:48:02  <paveljanik> there are three new commits anyway...
1672017-05-11T12:48:13  <jonasschnelli> Yeah.. right. Let me rebase then.
1682017-05-11T12:48:33  <jonasschnelli> Give me some minutes (working branch is different right now)
1692017-05-11T12:49:14  <paveljanik> It is an issue with my workflow... rebase will make it much easier for me (I'll be able to use the default/automated workflow).
1702017-05-11T12:49:21  *** JackH has quit IRC
1712017-05-11T12:49:23  <jonasschnelli> sure... will do
1722017-05-11T12:55:31  *** riemann has joined #bitcoin-core-dev
1732017-05-11T12:57:49  *** spinza has quit IRC
1742017-05-11T13:02:08  *** kcud_dab has quit IRC
1752017-05-11T13:03:52  *** bad_duck has joined #bitcoin-core-dev
1762017-05-11T13:06:21  *** goksinen has joined #bitcoin-core-dev
1772017-05-11T13:10:55  *** Giszmo has joined #bitcoin-core-dev
1782017-05-11T13:11:11  *** goksinen has quit IRC
1792017-05-11T13:19:59  *** laurentmt has quit IRC
1802017-05-11T13:27:38  <jonasschnelli> paveljanik: #9697 is now rebased
1812017-05-11T13:27:40  <gribble> https://github.com/bitcoin/bitcoin/issues/9697 | [Qt] simple fee bumper with user verification by jonasschnelli · Pull Request #9697 · bitcoin/bitcoin · GitHub
1822017-05-11T13:28:18  *** spinza has joined #bitcoin-core-dev
1832017-05-11T13:38:22  *** Guyver2 has joined #bitcoin-core-dev
1842017-05-11T13:40:14  *** goksinen has joined #bitcoin-core-dev
1852017-05-11T13:44:54  *** goksinen has quit IRC
1862017-05-11T13:47:27  *** goksinen has joined #bitcoin-core-dev
1872017-05-11T13:49:38  *** drizztbsd has joined #bitcoin-core-dev
1882017-05-11T13:50:26  *** d_t has joined #bitcoin-core-dev
1892017-05-11T13:51:58  *** timothy has quit IRC
1902017-05-11T13:52:05  *** goksinen has quit IRC
1912017-05-11T13:54:29  *** goksinen has joined #bitcoin-core-dev
1922017-05-11T13:55:17  *** d_t has quit IRC
1932017-05-11T13:58:41  *** drizztbsd is now known as timothy
1942017-05-11T14:00:40  *** waxwing has quit IRC
1952017-05-11T14:00:48  *** goksinen has quit IRC
1962017-05-11T14:20:11  *** goksinen has joined #bitcoin-core-dev
1972017-05-11T14:20:40  *** zooko has joined #bitcoin-core-dev
1982017-05-11T14:22:51  *** zooko has left #bitcoin-core-dev
1992017-05-11T14:23:31  *** zooko has joined #bitcoin-core-dev
2002017-05-11T14:23:53  *** zooko_ has joined #bitcoin-core-dev
2012017-05-11T14:24:04  *** zooko has quit IRC
2022017-05-11T14:24:08  *** zooko_ has quit IRC
2032017-05-11T14:24:21  *** SopaXorzTaker has quit IRC
2042017-05-11T14:24:36  *** zooko has joined #bitcoin-core-dev
2052017-05-11T14:24:56  *** goksinen has quit IRC
2062017-05-11T14:24:58  *** SopaXorzTaker has joined #bitcoin-core-dev
2072017-05-11T14:26:50  *** goksinen has joined #bitcoin-core-dev
2082017-05-11T14:32:48  *** d_t has joined #bitcoin-core-dev
2092017-05-11T14:32:56  *** wallet42 has quit IRC
2102017-05-11T14:33:19  *** wallet42 has joined #bitcoin-core-dev
2112017-05-11T14:38:13  *** d_t has quit IRC
2122017-05-11T14:44:31  *** waxwing has joined #bitcoin-core-dev
2132017-05-11T14:47:04  *** Cheeseo has joined #bitcoin-core-dev
2142017-05-11T14:52:31  *** JackH has joined #bitcoin-core-dev
2152017-05-11T14:59:26  *** zooko has quit IRC
2162017-05-11T15:00:18  *** Cheeseo has quit IRC
2172017-05-11T15:03:02  *** riemann has quit IRC
2182017-05-11T15:04:16  *** Dyaheon has quit IRC
2192017-05-11T15:04:57  *** Dyaheon has joined #bitcoin-core-dev
2202017-05-11T15:09:02  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10387: [WIP] Define and signal NODE_NETWORK_LIMITED (pruned peers) (master...2017/05/node_network_limited) https://github.com/bitcoin/bitcoin/pull/10387
2212017-05-11T15:45:57  *** abpa has joined #bitcoin-core-dev
2222017-05-11T15:50:20  *** waxwing has quit IRC
2232017-05-11T15:55:13  *** SopaXorzTaker has quit IRC
2242017-05-11T16:03:48  *** waxwing has joined #bitcoin-core-dev
2252017-05-11T16:10:19  *** timothy has quit IRC
2262017-05-11T16:12:07  *** goksinen has quit IRC
2272017-05-11T16:23:00  *** gm2051 has quit IRC
2282017-05-11T16:26:47  *** gm2051 has joined #bitcoin-core-dev
2292017-05-11T16:29:58  *** harrymm has quit IRC
2302017-05-11T16:32:18  *** harrymm has joined #bitcoin-core-dev
2312017-05-11T16:52:33  *** talmai has joined #bitcoin-core-dev
2322017-05-11T16:56:02  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/7f2b9e0868f5...79aeff6e08f3
2332017-05-11T16:56:03  <bitcoin-git> bitcoin/master 9970219 Matt Corallo: Update contrib/debian to latest Ubuntu PPA upload....
2342017-05-11T16:56:03  <bitcoin-git> bitcoin/master a8e9286 Matt Corallo: Bump minimum boost version in contrib/debian
2352017-05-11T16:56:04  <bitcoin-git> bitcoin/master c5071e1 Matt Corallo: Build with QT5 on Debian-based systems using contrib/debian
2362017-05-11T16:56:36  <bitcoin-git> [bitcoin] laanwj closed pull request #10328: Update contrib/debian to latest Ubuntu PPA upload. (master...2017-05-update-debian) https://github.com/bitcoin/bitcoin/pull/10328
2372017-05-11T17:07:28  *** talmai has quit IRC
2382017-05-11T17:08:51  *** talmai has joined #bitcoin-core-dev
2392017-05-11T17:14:35  *** goksinen has joined #bitcoin-core-dev
2402017-05-11T17:20:03  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/79aeff6e08f3...18c9debe602d
2412017-05-11T17:20:04  <bitcoin-git> bitcoin/master a637734 Luke Dashjr: rpc/wallet: Workaround older UniValue which returns a std::string temporary for get_str
2422017-05-11T17:20:04  <bitcoin-git> bitcoin/master 18c9deb Wladimir J. van der Laan: Merge #10341: rpc/wallet: Workaround older UniValue which returns a std::string temporary for get_str...
2432017-05-11T17:20:36  <bitcoin-git> [bitcoin] laanwj closed pull request #10341: rpc/wallet: Workaround older UniValue which returns a std::string temporary for get_str (master...rpcwallet_uv_workaround) https://github.com/bitcoin/bitcoin/pull/10341
2442017-05-11T17:27:37  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/18c9debe602d...eb8263bdc9d3
2452017-05-11T17:27:37  <bitcoin-git> bitcoin/master 0c60c63 practicalswift: Remove unused Python imports
2462017-05-11T17:27:38  <bitcoin-git> bitcoin/master eb8263b Wladimir J. van der Laan: Merge #10317: Remove unused Python imports...
2472017-05-11T17:28:06  <bitcoin-git> [bitcoin] laanwj closed pull request #10317: Remove unused Python imports (master...remove-unused-python-imports-ii) https://github.com/bitcoin/bitcoin/pull/10317
2482017-05-11T17:57:19  *** dermoth has quit IRC
2492017-05-11T17:58:06  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/eb8263bdc9d3...94e52273f30f
2502017-05-11T17:58:06  <bitcoin-git> bitcoin/master 6c914ac Thomas Snider: [wallet] Securely erase potentially sensitive keys/values
2512017-05-11T17:58:07  <bitcoin-git> bitcoin/master 94e5227 Wladimir J. van der Laan: Merge #10308: [wallet] Securely erase potentially sensitive keys/values...
2522017-05-11T17:58:36  <bitcoin-git> [bitcoin] laanwj closed pull request #10308: [wallet] Securely erase potentially sensitive keys/values (master...tjps_secure_erase) https://github.com/bitcoin/bitcoin/pull/10308
2532017-05-11T18:03:48  *** dermoth has joined #bitcoin-core-dev
2542017-05-11T18:05:08  *** molz_ has joined #bitcoin-core-dev
2552017-05-11T18:07:57  *** mol has quit IRC
2562017-05-11T18:18:03  *** jcliff42 has joined #bitcoin-core-dev
2572017-05-11T18:20:25  <bitcoin-git> [bitcoin] morcos opened pull request #10388: Output line to debug.log when IsInitialBlockDownload latches to false (master...printIBD) https://github.com/bitcoin/bitcoin/pull/10388
2582017-05-11T18:29:35  <jonasschnelli> gmaxwell: The idea behind the signaling 7056 blocks in NODE_NETWORK_LIMITED was, that SPV peers and other very irregular network participants can catch up filtered (or non filtered) blocks of about a month.
2592017-05-11T18:30:40  <jonasschnelli> Though the value itself is questionable (I though NODE_NETWORK_LIMITED_HIGH^2 may be resonable).
2602017-05-11T18:32:01  *** jcliff42 has quit IRC
2612017-05-11T18:32:53  *** jcliff42 has joined #bitcoin-core-dev
2622017-05-11T18:33:22  <gmaxwell> I'm pretty doubtful people are going to set pruning to anything but not at all or all the way right now.
2632017-05-11T18:38:01  <jonasschnelli> gmaxwell: I don't know. I personally would consider pruning to 10GB or something that doesn't hurt. But yeah.... I see the point with UTXO syncs and maybe reserve it then for future use cases (though we could also add another bit)
2642017-05-11T18:38:47  *** jcliff42 has quit IRC
2652017-05-11T18:39:36  <morcos> gmaxwell: given the size requirements for other aspects of the data directory (such as chainstate), it seems to me its not unreasonable to keep several gigs of blocks...  I think if there was a 10GB option, it might be heavily used, especially if it was either recommended or somehow the default
2662017-05-11T18:40:37  *** molz_ has quit IRC
2672017-05-11T18:41:20  *** moli_ has joined #bitcoin-core-dev
2682017-05-11T18:42:57  *** dermoth has quit IRC
2692017-05-11T18:43:03  <instagibbs> Defaults are obviously quite sticky. In my experience almost no one even knows about pruning.
2702017-05-11T18:43:33  <instagibbs> (so people just shut if off)
2712017-05-11T18:44:25  <jonasschnelli> Also consider the use case (thats getting more and more popular) where people link their SPV wallets with their full node. There a "month of blocks" could make sense...
2722017-05-11T18:44:38  <jonasschnelli> And I'm not saying this is a good use case... :)
2732017-05-11T18:47:59  <jonasschnelli> instagibbs: Some people told me that the prices per GB storage falls after moors law, but I personally feel that it was much simpler to run a full node back in 2013,... and not at least because of the disk requirement.
2742017-05-11T18:49:28  *** protomar has joined #bitcoin-core-dev
2752017-05-11T18:49:38  <instagibbs> Most people buying computers aren't optimizing for 100GB+ chain sizes.
2762017-05-11T18:50:56  <wumpus> "Some people told me that the prices per GB storage falls after moors law", indeed, that hasn't been true for quite a while
2772017-05-11T18:51:26  <gmaxwell> The setting based on size thing really doesn't work that well, the two logical settings are unpruned and the minimum.
2782017-05-11T18:52:06  <gmaxwell> so I'm not saying that keeping X or Y is useless, but we need a different interface to make them ever used.
2792017-05-11T18:52:41  <gmaxwell> And the big difference is "can people sync from you" -- p2p spv nodes are almost non-existant these days.
2802017-05-11T18:52:43  <wumpus> there is currently no reason to select anything but the minimum if you set up pruning
2812017-05-11T18:53:11  <wumpus> if it did serve the latter blocks I'd gladly set the pruning to larger, and I've heard similar things from other people, but there's just no reason now
2822017-05-11T18:53:31  *** jcliff42 has joined #bitcoin-core-dev
2832017-05-11T18:54:19  <gmaxwell> The context here though is having yet another level.
2842017-05-11T18:54:21  *** jcliff42 has joined #bitcoin-core-dev
2852017-05-11T18:54:55  <murchandamus> Howdy
2862017-05-11T18:55:14  <gmaxwell> I don't think having three levels of just pruning makes a lot of sense (nor do I think it's supported by the fetching data we have), when also there will be proposals for start-from-utxo-assumevalid which will have its own levels of storage.
2872017-05-11T18:55:33  <jonasschnelli> Right, the question is if both NODE_NETWORK_LIMITED_(LOW|HIGH) is enabled, should we then use a third, larger value (bit 1: 144, bit 2: 1008, both bits: ?)
2882017-05-11T18:55:54  <sipa> we could leave it undefined for now
2892017-05-11T18:56:04  <wumpus> on the other hand if there are three possibiilties with those bits, it makes sense to give the combination meaning too
2902017-05-11T18:56:13  <wumpus> or leave it explicitly undefined for future expansion,s ure
2912017-05-11T18:56:28  <sipa> merely the presence of having server-but-not-full-archival nodes will likely change things already
2922017-05-11T18:56:31  <gmaxwell> What I suggested was that it's undefined for setting, but for recieving you know it means at least X blocks, but it may also require other things, so you can't set it yet.
2932017-05-11T18:56:32  <sipa> and we'll learn from that
2942017-05-11T18:56:35  *** dermoth has joined #bitcoin-core-dev
2952017-05-11T18:56:38  <jonasschnelli> Yes. It felt after a waste if we don't define it. Well, undefined (for future usecases) is also a definition.
2962017-05-11T18:56:56  <wumpus> agree
2972017-05-11T18:57:00  <instagibbs> gmaxwell, s/setting/sending/?
2982017-05-11T18:57:13  <gmaxwell> instagibbs: both.
2992017-05-11T18:57:24  <wumpus> gmaxwell: yes "it means at least..." makes a lot of sense for backwards compatibility
3002017-05-11T18:58:05  <gmaxwell> If you see both bits set, then it means they have at least 2016*2 blocks (which is what I suggested). But you don't set it yet, because it may (will) later be defined to say "And I offer a UTXO syncpoint" or whatnot.
3012017-05-11T18:58:19  <wumpus> yes
3022017-05-11T18:58:27  *** jcliff42 has quit IRC
3032017-05-11T18:58:31  <gmaxwell> to be extra conservative it could just be defined to mean at least _HIGH  now. I don't have a strong opinion.
3042017-05-11T18:58:38  <gmaxwell> you can always increase the requirement later.
3052017-05-11T18:59:17  *** SopaXorzTaker has joined #bitcoin-core-dev
3062017-05-11T19:00:16  <wumpus> #startmeeting
3072017-05-11T19:00:16  <lightningbot> Meeting started Thu May 11 19:00:16 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3082017-05-11T19:00:16  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3092017-05-11T19:00:26  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
3102017-05-11T19:00:31  <sipa> present
3112017-05-11T19:00:40  <murchandamus> present
3122017-05-11T19:00:44  <wumpus> topics?
3132017-05-11T19:00:49  <sipa> murchandamus == murch?
3142017-05-11T19:00:51  <cfields> hi, here
3152017-05-11T19:00:54  <instagibbs> yes sipa
3162017-05-11T19:00:54  <murchandamus> aye!
3172017-05-11T19:00:56  <morcos> gmaxwell: oh ok, i agree with not defining now..  maybe we should make just _HIGH more then though
3182017-05-11T19:00:59  <kanzure> hi.
3192017-05-11T19:01:36  <gmaxwell> morcos: yes, I was thinking HIGH would be targeted at hosts syncing 2016 blocks, but I forget where the breakpoints were exactly in sipas' data.
3202017-05-11T19:01:39  <wumpus> any proposed topics? (we can continue the pruning service bits topic if people want that)
3212017-05-11T19:01:40  <BlueMatt> damnit, can enver remember topics i wanted to bring up come meeting time :(
3222017-05-11T19:01:57  <luke-jr> O.o?
3232017-05-11T19:02:18  <gmaxwell> wumpus: well we should talk about per-txo. I think it's ready for merge except for more testing/review.
3242017-05-11T19:02:26  <instagibbs> suggested topic: fee targeting/coin selection overhaul
3252017-05-11T19:02:35  <wumpus> #topic per-txo utxo database
3262017-05-11T19:02:52  <sipa> #10148
3272017-05-11T19:02:54  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
3282017-05-11T19:02:56  <gmaxwell> if people haven't seen the graphs: https://cloud.githubusercontent.com/assets/548488/25769030/c84fe65e-31c4-11e7-8819-264c44e50ddf.png
3292017-05-11T19:03:02  <sipa> oops, no, #10195
3302017-05-11T19:03:04  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
3312017-05-11T19:03:12  <morcos> sorry sipa, that has been on my list, but my list has been gathering dust for the last couple weeks
3322017-05-11T19:03:13  <BlueMatt> I'm still halfway through review
3332017-05-11T19:03:16  <gmaxwell> The graphs should be making all your mouths water.
3342017-05-11T19:03:30  <instagibbs> why is y-axis in block time :P
3352017-05-11T19:03:34  <wumpus> ah yes I was still testing #10148, should probably switch to #10195
3362017-05-11T19:03:37  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
3372017-05-11T19:03:39  <instagibbs> clock*
3382017-05-11T19:03:39  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
3392017-05-11T19:03:41  <gmaxwell> instagibbs: so that the flushing graph works out.
3402017-05-11T19:03:52  <sipa> instagibbs: so that the x axis of both graphs lines up
3412017-05-11T19:04:00  <cfields> i've made it through review, but I lack enough confidence to ACK the thing :\
3422017-05-11T19:04:04  <BlueMatt> gm2051: #10192
3432017-05-11T19:04:05  <gmaxwell> The most impressive thing about that chart isn't the ~33% speedup, it's the reduction in flushing frequency.
3442017-05-11T19:04:08  <gribble> https://github.com/bitcoin/bitcoin/issues/10192 | Cache full script execution results in addition to signatures by TheBlueMatt · Pull Request #10192 · bitcoin/bitcoin · GitHub
3452017-05-11T19:04:17  <BlueMatt> gmaxwell: ^
3462017-05-11T19:04:20  <cfields> gmaxwell: yes, that's great.
3472017-05-11T19:04:33  <sipa> i was very surprised by how much it reduces flushing
3482017-05-11T19:04:41  *** jcliff42 has joined #bitcoin-core-dev
3492017-05-11T19:04:49  <wumpus> nice chart
3502017-05-11T19:04:54  <sipa> my guess is that the resulting speedup isn't that dramatic because it's running on a system with pretty fast I/O
3512017-05-11T19:05:12  <wumpus> heh, but most users have systems with slow i/o
3522017-05-11T19:05:27  <sipa> oh, one downside: chainstate db goes from 2.2G to 2.7G
3532017-05-11T19:05:30  <gmaxwell> right, testing it on a system with slow i/o would be interesting. But will take forever.
3542017-05-11T19:05:45  <BlueMatt> 2.7 seems fine
3552017-05-11T19:06:09  <luke-jr> hmm
3562017-05-11T19:06:31  <sipa> the TODOs that i know of are a few code cleanups (marked as TODO in the code), and better UI wrt the upgrade process
3572017-05-11T19:06:45  <sipa> there is a one-time upgrade of the old db to the new db at startup, which can be interrupted
3582017-05-11T19:06:55  <gmaxwell> The upgrade doesn't take long on a system with fast IO at least.
3592017-05-11T19:06:57  <BlueMatt> sipa: it needs way more review
3602017-05-11T19:07:02  <sipa> BlueMatt: of course
3612017-05-11T19:07:03  <BlueMatt> there are lots of things in that queue, sadly
3622017-05-11T19:07:10  <wumpus> upgrade should be fast if it just iterates through the db in sorted order
3632017-05-11T19:07:18  <wumpus> even on systems with fairly slow (seek) i/o
3642017-05-11T19:07:28  <sipa> wumpus: it does, it takes a couple of minutes on a system with fast I/O
3652017-05-11T19:08:02  <wumpus> I'll try it out this week
3662017-05-11T19:08:36  <gmaxwell> One thing to keep in mind is that keeping it unmerged reduces testing. Absolutely it needs more review before being merged, but we also should try to get it merged sooner rather than later.
3672017-05-11T19:08:46  <gmaxwell> So that we get more time baking on it in master.
3682017-05-11T19:08:56  *** jcliff42 has quit IRC
3692017-05-11T19:09:00  <BlueMatt> gmaxwell: we're not even close to that point
3702017-05-11T19:09:12  <BlueMatt> but, yes, we should be agressive about merge, as long as its a ways before release
3712017-05-11T19:09:14  <morcos> agreed gmaxwell, same thing with #10199
3722017-05-11T19:09:16  <gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
3732017-05-11T19:09:28  <sipa> morcos: i'll do another review pass on that today
3742017-05-11T19:09:40  <wumpus> yes, this shouldn't be something to merge last minute for 0.15
3752017-05-11T19:09:44  <morcos> good thing about that one, is its a lot less likely to casue a disaster
3762017-05-11T19:09:45  * BlueMatt finds 10199 to be wayyyy more important than per-utxo
3772017-05-11T19:09:50  *** kexkey has joined #bitcoin-core-dev
3782017-05-11T19:09:55  * morcos disagrees
3792017-05-11T19:10:13  <gmaxwell> I strongly disagree.
3802017-05-11T19:10:44  <wumpus> they're both important for different reasons
3812017-05-11T19:10:55  <wumpus> it's comparing apples and oranges
3822017-05-11T19:11:05  *** mol has joined #bitcoin-core-dev
3832017-05-11T19:11:09  <BlueMatt> anyway, do we have any real topics?
3842017-05-11T19:11:29  <sipa> i have one low-priority idea i'd like to talk about (running utxo commitments)
3852017-05-11T19:11:31  * BlueMatt wishes the ny weather were better...
3862017-05-11T19:11:36  <BlueMatt> sipa: shoot
3872017-05-11T19:11:46  <wumpus> #topic fee targeting/coin selection overhaul (instagibbs)
3882017-05-11T19:11:47  <gmaxwell> BlueMatt: it's beautiful here in mountain view today.
3892017-05-11T19:12:06  <sipa> instagibbs: topic
3902017-05-11T19:12:17  <murchandamus> gmaxwell: A bit cloudy here in Palo Alto though. ;)
3912017-05-11T19:12:24  <instagibbs> So I tried my hand at doing redoing fee targeting #10360 without directly changing coin selection
3922017-05-11T19:12:25  <gribble> https://github.com/bitcoin/bitcoin/issues/10360 | [WIP] [Wallet] Target effective value during transaction creation by instagibbs · Pull Request #10360 · bitcoin/bitcoin · GitHub
3932017-05-11T19:12:36  <instagibbs> Was wondering if people were wary of that, versus a complete overhaul
3942017-05-11T19:12:43  <instagibbs> morcos has concerns
3952017-05-11T19:12:49  <morcos> wary is a good word for it
3962017-05-11T19:12:55  <morcos> not opposed
3972017-05-11T19:13:02  <gmaxwell> I feel a little uneasy about the changes to augment selection while we don't have a strategy to sweep dust. It worries me that we're potentially going to again untintentionally create another UTXO count blowup event.
3982017-05-11T19:13:11  <sipa> instagibbs: i haven't looked into the details... is it just treating the net value of its output as amount - feerate*size_of_spend ?
3992017-05-11T19:13:15  <murchandamus> I've talked a bit with instagibbs about it and it seems to me that when that approach finds a direct match it may have a huge number of inputs
4002017-05-11T19:13:20  <instagibbs> sipa yes
4012017-05-11T19:13:36  <gmaxwell> murchandamus: that sounds great to me. :P
4022017-05-11T19:13:43  <murchandamus> I've combined a similar approach but trying to combine inputs by size large to small
4032017-05-11T19:14:01  *** moli_ has quit IRC
4042017-05-11T19:14:05  <instagibbs> sipa, so you may get more smaller inputs that directly match, for example
4052017-05-11T19:14:13  <murchandamus> gmaxwell: I think that slightly bigger average transaction with lower variance in transaction size are better than huge variance in transaction size
4062017-05-11T19:14:39  <morcos> i like the idea of being at least somewhat fee smart, and including more inputs when fees are lower
4072017-05-11T19:14:41  <sipa> but even if it spends many inputs, it always does so in a way that is economical
4082017-05-11T19:14:57  <instagibbs> sipa, it will always use "positive effective value" inputs
4092017-05-11T19:14:59  <sipa> so unless you assume that the feerate is going down in the future, there is little reason to postpone spending them
4102017-05-11T19:15:05  <murchandamus> morcos: Exactly. We have huge variance in fees over the week
4112017-05-11T19:15:10  <gmaxwell> murchandamus: high to low sounds like it would destroy privacy.
4122017-05-11T19:15:10  <morcos> the idea of wanting to do a quick transaction and paying 200 sat/byte to do it, and you include tons of little inputs that have little to none net value seems bad to me
4132017-05-11T19:15:46  <murchandamus> sipa: But adding a single input costs as much as four outputs, so you'd probably rather add a change output when fees are high than add another input, and later in the week do a few consolidation transactions
4142017-05-11T19:15:55  * luke-jr wonders how contentious it would be to move to a system where dust requires a larger proof so it can be pruned from the UTXO set
4152017-05-11T19:16:05  <murchandamus> I've been hearing that some people do this to save money
4162017-05-11T19:16:07  <gmaxwell> morcos: I though about that and I think a nice estimate would be the ratio between the current feerate set and the BIG_NUM target (e.g. 1008 block target).  If this ratio is low, then you should be agressive in spending.
4172017-05-11T19:16:11  <morcos> admittedly its a difficult problem...  how do you distinguish a user that only does 200 sat/byte txs vs one that has a range
4182017-05-11T19:16:32  <murchandamus> gmaxwell: I don't think it does, because it's only the selection for making exact matches
4192017-05-11T19:16:43  <morcos> gmaxwell: yes, i agree... something like that
4202017-05-11T19:16:46  <murchandamus> and you don't know if the first combination that matched was actually among the largest in your wallet
4212017-05-11T19:16:58  *** Cheeseo has joined #bitcoin-core-dev
4222017-05-11T19:16:58  *** Cheeseo has joined #bitcoin-core-dev
4232017-05-11T19:17:22  <morcos> anyway, clearly there are a lot of ideas here, and i kidn of think that the amount of consideration that has to go into most changes is almost the same, and it might not be worthing doing all of that sanity checking if we're only making a small change
4242017-05-11T19:17:23  <instagibbs> yes, so there are plenty of interesting strategies, the question is should we not be making semi-obvious fixing until we can agree on those :)
4252017-05-11T19:17:34  <murchandamus> gmaxwell: interesting approach
4262017-05-11T19:18:22  <instagibbs> related: can we kill minimum total fee?
4272017-05-11T19:18:22  <morcos> at the very least, i'd think this should be lower priority for 0.15 than the prevously mentioned things right now... so we have to think about resources
4282017-05-11T19:18:33  <morcos> instagibbs: +1 on that for a first step
4292017-05-11T19:18:37  <sipa> instagibbs: ack
4302017-05-11T19:18:38  <instagibbs> morcos, yes that was the feeling I get
4312017-05-11T19:18:41  <murchandamus> instagibbs: Accounting for UTXO in selection by effective value does take a load of pain out of selection strategies
4322017-05-11T19:19:21  <gmaxwell> instagibbs: but if a 'semi obvious fix' blows up other considerations thats bad.  Do you have a reason to believe your change won't cause a massive increase in utxo accumulation?
4332017-05-11T19:19:33  <morcos> also i have a PR #9343 that also removes edge case logic.  cleaning these things up now will make future improvements easier to do and reason about
4342017-05-11T19:19:35  <gribble> https://github.com/bitcoin/bitcoin/issues/9343 | Dont create change at dust limit by morcos · Pull Request #9343 · bitcoin/bitcoin · GitHub
4352017-05-11T19:19:38  <murchandamus> instagibbs: I'm not sure that just this change with the current selection strategy of Core does much better in the selection, because of the selecting/deselecting pass
4362017-05-11T19:19:43  <instagibbs> gmaxwell, no, I wasn't assuming as much, sorry if that seemed implied
4372017-05-11T19:20:09  <murchandamus> gmaxwell: Pretty sure it would rather decrease UTXO footprints
4382017-05-11T19:20:36  <murchandamus> right now Core will often fail in the first few passes when it selects more inputs because it hadn't accounted for the fees in advance
4392017-05-11T19:20:37  <sipa> instagibbs: which feerate are you using?
4402017-05-11T19:20:57  <instagibbs> sipa, whatever the user has selected via settings
4412017-05-11T19:21:01  <gmaxwell> instagibbs: well, thats why I ask. basically, in any mature system you can have 'bugs' which you depend on. at first glance it semeed to me that your PR might fix a bug where we're overly agressively spending TXO that are negative value. But we may depend on that bug to help manage the UTXO size.  At least that was my impression.
4422017-05-11T19:21:05  <murchandamus> with this change it would always succeed as soon as it finds an exact match
4432017-05-11T19:21:08  <sipa> instagibbs: oh, duh
4442017-05-11T19:21:09  <instagibbs> well, aside from total minimum fee, because that's stupid
4452017-05-11T19:21:55  <instagibbs> gmaxwell, could be. Maybe next step, aside from general refactor and cleaning, is to get better data
4462017-05-11T19:22:08  <gmaxwell> murchandamus: I'm not following your logic. Yes, the first few passes will fail, then it will target a higher amount, and be successful.
4472017-05-11T19:22:18  <murchandamus> gmaxwell: Yes, it shoudl never select UTXO that are negative effective value
4482017-05-11T19:22:22  <instagibbs> and stop throwing away money as fees egregiously: #10333
4492017-05-11T19:22:23  <gribble> https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p… by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub
4502017-05-11T19:22:35  <gmaxwell> murchandamus: By "should" do you mean the current behavior?
4512017-05-11T19:22:43  <instagibbs> current behavior almost certainly does
4522017-05-11T19:22:49  <gmaxwell> The current behavior absolutely will select txos with negative value.
4532017-05-11T19:23:02  <sipa> So how about we fix that first?
4542017-05-11T19:23:06  <gmaxwell> And "fixing" that may have severely deletarious effects on the network.
4552017-05-11T19:23:08  <murchandamus> gmaxwell: It only fails if it doesn't find a transaction input set within the number of estimated inputs from the previous tries
4562017-05-11T19:23:11  <morcos> sipa: yeah i was thinking that
4572017-05-11T19:23:12  <instagibbs> I could always just make it ignore negative effective value
4582017-05-11T19:23:13  <morcos> gmaxwell: disagree
4592017-05-11T19:23:13  <instagibbs> ...
4602017-05-11T19:23:14  <instagibbs> lol
4612017-05-11T19:23:38  <instagibbs> I mean either it's a feature, and we shouldnt fix it, or a bug and we should
4622017-05-11T19:23:46  <morcos> instagibbs: yeah exactly
4632017-05-11T19:24:09  <gmaxwell> It can be both! :)
4642017-05-11T19:24:18  <murchandamus> gmaxwell: I meant "should" as in when you calculate the effective value of a UTXO, if it is a negative effective value it shouldn't be selected
4652017-05-11T19:24:28  <instagibbs> aspirational should?
4662017-05-11T19:24:29  <sdaftuar> so there's a difference here between generally factoring in feerates in the coin selection, and throwing out inputs that have negative value.  i assume that's what we're getting at?
4672017-05-11T19:24:33  <murchandamus> gmaxwell: actually yes
4682017-05-11T19:24:37  <gmaxwell> It's a feature when its mild and happening during times of low feerate. And a bug when its severe when it is insane and happening during high feerate.
4692017-05-11T19:24:42  <murchandamus> current behavior would select them
4702017-05-11T19:24:48  <instagibbs> gmaxwell, fair enough...
4712017-05-11T19:25:00  <wumpus> yes, eating utxos with negative value cleans up the utxo set
4722017-05-11T19:25:06  <morcos> gmaxwell: right now when feerates vary from 10 to 200 sat/byte.   something that is 0 at 200 sat/byte should be cleaned up at a lower fee rate, not thrown away
4732017-05-11T19:25:26  <gmaxwell> Fixing it unconditionally without doing something about dust cleanup may be quite harmful to the network.
4742017-05-11T19:25:30  <wumpus> of course it's better to not create them in the first place
4752017-05-11T19:25:43  <morcos> wumpus: yes!  see #9343
4762017-05-11T19:25:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9343 | Dont create change at dust limit by morcos · Pull Request #9343 · bitcoin/bitcoin · GitHub
4772017-05-11T19:25:57  <murchandamus> morcos: That's what I meant
4782017-05-11T19:25:58  <instagibbs> ^I should review that one
4792017-05-11T19:25:59  <morcos> i'm not sure thats the only way they are created, perhaps we could do more to avoid creating them also
4802017-05-11T19:26:12  <gmaxwell> morcos: well they're created by people being buttheads.
4812017-05-11T19:26:15  <morcos> i should say, i'm sure thats not the only way
4822017-05-11T19:26:21  <instagibbs> I noticed in current logic we create near-dust, but when we're modifying change, we have much higher bar to clear
4832017-05-11T19:26:23  <gmaxwell> and no amount of fixing the wallet will prevent their creation.
4842017-05-11T19:26:24  <instagibbs> we should sync this
4852017-05-11T19:26:36  <wumpus> yes, we should get that one in
4862017-05-11T19:26:49  <wumpus> gmaxwell: well not creating them ourselves is not a total solution, but it helps
4872017-05-11T19:27:01  <gmaxwell> wumpus: absolutely, sorry if it sounded like I said otherwise.
4882017-05-11T19:27:06  <morcos> gmaxwell: yeah its a good question how many are created unintentionally vs intentionally
4892017-05-11T19:27:47  <morcos> it wouldn't be unreasonable to raise the limit for intentionally creating them in Core, in adddition to imporving unintentional behavior
4902017-05-11T19:27:51  *** Firescar96 has joined #bitcoin-core-dev
4912017-05-11T19:27:53  <gmaxwell> and at least as far as the "some anonymous third party sends you a few bitcents"  I think it's fine to spend those at a slight loss, esp if its in a privacy preserving way, and double especially if it's at as low a fee rate as you expect to see.
4922017-05-11T19:27:59  <murchandamus> morcos: Core never creates change outputs smaller than 0.01 BTC unless the wallet is being almost depleted with the transaction, right?
4932017-05-11T19:28:22  <morcos> murchandamus: well.. thats the design goal, i don't think its achieved
4942017-05-11T19:28:29  <instagibbs> it's not achieved at all
4952017-05-11T19:28:30  <instagibbs> sad!
4962017-05-11T19:28:30  <gmaxwell> what morcos said
4972017-05-11T19:28:44  <gmaxwell> well it's better since 0.13.whatever when we fixed some things.
4982017-05-11T19:28:53  <gmaxwell> with the target/2 checks.
4992017-05-11T19:29:04  <murchandamus> I'll have to check out the linked issue
5002017-05-11T19:29:11  <morcos> in particular, if you have nTotalLower < target + CENT, you aim for target, and almost definitely create some stupidly small change
5012017-05-11T19:29:26  <morcos> among other posibilities
5022017-05-11T19:29:37  <murchandamus> morcos: Ah right, I forgot about the pre-selection before knapsack
5032017-05-11T19:29:39  <morcos> the linked issue is even more edge case
5042017-05-11T19:29:41  <murchandamus> thanks for the reminder
5052017-05-11T19:30:07  <morcos> but like nTotalFee needs to go away before its easy to clean up the general case
5062017-05-11T19:30:22  <morcos> easIER
5072017-05-11T19:30:40  <murchandamus> morcos: I think the way to go would be to dissect and modularize the coin selection out of wallet.cpp, if that's possible
5082017-05-11T19:30:44  <murchandamus> right now it is such a moloch
5092017-05-11T19:31:06  <instagibbs> I mean you can basically just throw away anything at or below SelectCoins, imo
5102017-05-11T19:31:10  <wumpus> murchandamus: yes please
5112017-05-11T19:31:27  <gmaxwell> Moloch whose mind is pure machinery!
5122017-05-11T19:32:16  <murchandamus> I think instagibbs and I might coordinate something there, and jnewberry was also interested AFAIK
5132017-05-11T19:32:21  <gmaxwell> can we new-subject?  good discussion on this, lots of PRs for people to look at and discuss more. :)
5142017-05-11T19:32:28  <instagibbs> morcos is also interested
5152017-05-11T19:32:34  <instagibbs> yes I'm satisfied, we can continue offline
5162017-05-11T19:32:46  <murchandamus> thanks, me too
5172017-05-11T19:32:48  <wumpus> #topic running utxo commitments (sipa)
5182017-05-11T19:32:56  <sipa> ok
5192017-05-11T19:32:58  <gmaxwell> instagibbs: in any case, that one concern: that we might 'fix' what is dedusting the UTXO is the only reason I didn't ACK your patch. So we should try to get confidence there or add some other fix for that.
5202017-05-11T19:33:13  <instagibbs> gmaxwell, my firster iteration didnt even "fix" it :P
5212017-05-11T19:33:17  * jonasschnelli think we should have a graphical 3D "real coins" (in the size of the BTC value) manual drag'n'drop coin selection
5222017-05-11T19:33:20  <sipa> so, gmaxwell and i have been thinking about the possibility of maintaining a UTXO commitment hash all the time
5232017-05-11T19:34:03  <sipa> this would be useful for making gettxoutsetinfo instantaneous, or for syncing from someone else's UTXO set, or as the basis for a softfork later
5242017-05-11T19:34:11  *** Cheeseo has quit IRC
5252017-05-11T19:34:16  *** Dyaheon has quit IRC
5262017-05-11T19:34:18  *** Rob has joined #bitcoin-core-dev
5272017-05-11T19:34:24  <wumpus> yes, that would be useful
5282017-05-11T19:34:36  <sipa> and it seems it would be possible to have an implementation that does this at a cost of a few microseconds per input and per output
5292017-05-11T19:34:40  *** Rob is now known as Guest50211
5302017-05-11T19:34:42  <gmaxwell> A first requirement for any kind of UTXO assumevalid is having a continuous commitment value to simplify review.
5312017-05-11T19:34:44  <sipa> in a cryptographically secure way
5322017-05-11T19:35:05  *** Sosumi has quit IRC
5332017-05-11T19:35:33  <wumpus> jonasschnelli: that's pretty much just "a better GUI for coin control" right?
5342017-05-11T19:35:39  <gmaxwell> Effectively, we construct an incremental unordered hash for sets-- so you can add and remove entries one at a time... Because just one scheme isn't enough, we actually constructed several, and now have a fun tradeoffs challenge to decide between them.
5352017-05-11T19:35:41  <sipa> there are a few different possible implementations (one is based on multiplying big numbers mod a big prime, one is based on EC math, one is based on adding large hashes toether)... with different performance and security tradeoffs, i'll send a mail about it to the ML soon
5362017-05-11T19:36:00  <BlueMatt> ah, ok, was gonna ask what the design was, cool
5372017-05-11T19:36:07  <instagibbs> i love the alternative explanations...
5382017-05-11T19:36:19  *** cbits has joined #bitcoin-core-dev
5392017-05-11T19:36:19  <BlueMatt> i mean we can also not use complicated solutions and be willing to do it in the background at a cost of however many milliseconds later
5402017-05-11T19:36:29  <BlueMatt> dunno how complicated your proposal is, of course
5412017-05-11T19:36:59  <sipa> BlueMatt: map every UTXO to either a 3072-bit integer and multiply those for all outputs, or to an EC point and all those for all outputs
5422017-05-11T19:37:14  <sipa> the multiplication approach is faster, but harder to cache
5432017-05-11T19:37:18  <gmaxwell> The strength of our proposals is strictly better than the discrete log assumption.  Neighter are especially complex, though the multiplying one is probably simpler for joe-fool to implement as long as they don't care about performance.
5442017-05-11T19:37:33  <sipa> the EC approach could allow us to cache the effect of a single transaction, and then instantly apply it to the running commitment
5452017-05-11T19:38:11  *** jonasschnelli is now known as joe-fool
5462017-05-11T19:38:20  <sipa> hahaha
5472017-05-11T19:38:28  <wumpus> interesting proposal
5482017-05-11T19:38:56  <sipa> so, even though 5us per input/output may not seem much, it's several hours of CPU time for a node syncing from scratch
5492017-05-11T19:39:04  <BlueMatt> sipa: hmm, i assume you have a pointer to a crypto accumulator somewhere?
5502017-05-11T19:39:13  <BlueMatt> paper*
5512017-05-11T19:39:22  <BlueMatt> ehh, I'll just wait for your ml post
5522017-05-11T19:39:26  *** goksinen has quit IRC
5532017-05-11T19:39:28  <sipa> BlueMatt: it's a really uninteresting accumulator, as it can't be used to prove anything
5542017-05-11T19:39:46  <sipa> i'll include some references
5552017-05-11T19:39:47  *** Dyaheon has joined #bitcoin-core-dev
5562017-05-11T19:39:58  <gmaxwell> BlueMatt: there have been several papers on related schemes-- however.  Of course, the papers ignore the performance considerations.  And especially in our case we have tradeoffs around block validation latency.
5572017-05-11T19:40:28  *** dclxvi has quit IRC
5582017-05-11T19:40:38  <instagibbs> I still want compact proofs, get back to work.
5592017-05-11T19:40:48  <sipa> also, the DL approach would mean we need an implementation of a fast multiplication mod a (fixed) prime , or a GMP dependency
5602017-05-11T19:40:48  <instagibbs> (ducks)
5612017-05-11T19:41:14  <sipa> instagibbs: so one advantage that these things have is that they're not incompatible with other UTXO/TXO commitment approaches
5622017-05-11T19:41:16  <gmaxwell> in any case, ML post will talk about the tradeoffs and schemes.
5632017-05-11T19:41:17  <cfields> is ordering relevant? any effects on parallel validation/caching?
5642017-05-11T19:41:25  <sipa> cfields: it's 100% parallellizable
5652017-05-11T19:41:30  <gmaxwell> cfields: they're totally independant of ordering.
5662017-05-11T19:41:32  <wumpus> if at least it can be done in parallel with some of the i/o  (e.g. database lookups) it wouldn't have to add that much to the total validation time
5672017-05-11T19:41:34  <cfields> whew
5682017-05-11T19:41:38  <instagibbs> sipa, ack
5692017-05-11T19:41:54  <gmaxwell> And as sipa is pointing out, unlike other utxo commitments they do not break STXO like schemes where you have nodes that don't store the whole utxo set.
5702017-05-11T19:41:54  <sipa> ordering is irrelevant... it's effectively a set commitment that is homomorphic wrt to set union and subtraction
5712017-05-11T19:43:17  <sipa> but if we have this, we could for example log the UTXO commitment hash in the UpdateTip debug.log lines
5722017-05-11T19:43:17  <BlueMatt> gmaxwell: well the validation latency tradeoffs are mostly removed by commiting to the previous block's utxo commitment, no?
5732017-05-11T19:43:25  <BlueMatt> is there some reason we should avoid doing so?
5742017-05-11T19:43:36  *** goksinen has joined #bitcoin-core-dev
5752017-05-11T19:43:53  <gmaxwell> So the applications I see for this are: an instant gettxouset info,  being able to have updatetip log the UTXO state (making checking nodes much easier), a start on an ability to do an ASSUMEVALID UTXO sync. ('start on' because there is a security/philosophy debate if the value must also be commited to the chain if we're to do an assumevalid like sync)
5762017-05-11T19:43:55  <sipa> BlueMatt: well we're not even talking about commiting to it in blocks (though that is an interesting possibility later)
5772017-05-11T19:44:21  <BlueMatt> sipa: great! so lets not do it inline and do it in the background later
5782017-05-11T19:44:33  <sipa> BlueMatt: and delayed commitments are more complicated if you actually want the latency reduction... you need a backlog and background processing
5792017-05-11T19:44:33  <BlueMatt> as long as its under 100ms rpc is still instant
5802017-05-11T19:44:34  <BlueMatt> ish
5812017-05-11T19:44:46  *** chjj has quit IRC
5822017-05-11T19:44:54  <gmaxwell> oh well none of this is anywhere near that slow in any case.
5832017-05-11T19:44:55  <sipa> which would interfere with CPU demand for signature validation
5842017-05-11T19:45:24  <sipa> gmaxwell: if we need an mod inverse in the RPC, it could be 10ms or so with a naive implementation
5852017-05-11T19:45:30  <gmaxwell> I think with sutiable caching we're talking about worst case impact, if done inline, on the order of 10ms.
5862017-05-11T19:45:52  <sipa> anyway, not that much more to say about it
5872017-05-11T19:45:55  <BlueMatt> i think we can live with 10ms :p
5882017-05-11T19:46:02  <BlueMatt> anyway, looking forward to the ml post :)
5892017-05-11T19:46:08  <wumpus> #topic PRs high priority for review
5902017-05-11T19:46:10  <sipa> i just wanted to give a heads up
5912017-05-11T19:46:14  <BlueMatt> (in an rpc that would otherwise block cs_main...)
5922017-05-11T19:46:26  *** joe-fool is now known as jonasschnelli
5932017-05-11T19:46:41  <sipa> BlueMatt: that 10ms can even run without cs_main
5942017-05-11T19:46:43  <instagibbs> a less-extreme wallet PR for consideration to 0.15: #10333
5952017-05-11T19:46:43  <gribble> https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p… by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub
5962017-05-11T19:47:02  <instagibbs> there are still n > 1 reports of extremely high feerates with large num inputs
5972017-05-11T19:47:02  <BlueMatt> sipa: thats my point :p
5982017-05-11T19:47:18  <instagibbs> they seem to match up with this case
5992017-05-11T19:48:16  <wumpus> instagibbs: added 0.15 tag
6002017-05-11T19:48:26  <instagibbs> thanks
6012017-05-11T19:48:35  <gmaxwell> Where are we with multiwallet?
6022017-05-11T19:49:05  <wumpus> there were plenty of review comments on luke-jr's pull, but he hasn't addressed them yet AFAIK
6032017-05-11T19:49:08  <gmaxwell> I haven't been following it closely because I've been more focused on per-txo/the above commitment stuff/etc.
6042017-05-11T19:49:17  <gmaxwell> luke-jr: ^ plz.
6052017-05-11T19:49:19  <jonasschnelli> #8694 needs still rebase
6062017-05-11T19:49:21  <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
6072017-05-11T19:49:55  <luke-jr> wumpus: it's pending on jtimon's PR
6082017-05-11T19:50:05  <wumpus> luke-jr: which one?
6092017-05-11T19:50:15  <wumpus> I merged a few jtimon PRs this week
6102017-05-11T19:50:20  <luke-jr> #9494
6112017-05-11T19:50:22  <gribble> https://github.com/bitcoin/bitcoin/issues/9494 | Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs by jtimon · Pull Request #9494 · bitcoin/bitcoin · GitHub
6122017-05-11T19:50:43  <luke-jr> which actually looks mergable?
6132017-05-11T19:50:49  <wumpus> ok, seems that one is already in high priority for review
6142017-05-11T19:50:56  <sipa> wumpus: yeah, i marked it so last week
6152017-05-11T19:51:16  <luke-jr> reason being 8694 touches mapMultiArgs
6162017-05-11T19:51:25  <wumpus> luke-jr: good to know, will take a look at it soon and merge it
6172017-05-11T19:51:28  <luke-jr> rather than avoid that, it seems better to just fix the locking for ti
6182017-05-11T19:51:53  <wumpus> yes
6192017-05-11T19:52:01  <wumpus> sipa: thanks
6202017-05-11T19:52:35  *** kexkey has quit IRC
6212017-05-11T19:52:46  <jonasschnelli> Also, consider reviewing HD-Auto-Restore #10240 (it's currently not in high prio), we should have this in 0.15, otherwise users need to do loop10000(getnewaddress), rescan(genesis) to restore funds.
6222017-05-11T19:52:48  <gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
6232017-05-11T19:53:51  <wumpus> jonasschnelli: added 0.15 milestone
6242017-05-11T19:53:56  <gmaxwell> jonasschnelli: I'd missed that you got that going. good to hear.
6252017-05-11T19:54:10  <jonasschnelli> I'll rebase and fix the points soon.
6262017-05-11T19:54:45  <gmaxwell> I'll take a look at it after I finish my code review on some other PRs that I'm currently working on.
6272017-05-11T19:55:18  <jonasschnelli> thanks gmaxwell
6282017-05-11T19:57:05  <instagibbs> 3 minutes
6292017-05-11T19:57:37  *** chjj has joined #bitcoin-core-dev
6302017-05-11T19:57:39  <sipa> my #1 is still #10195 :)
6312017-05-11T19:57:41  <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
6322017-05-11T19:57:42  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
6332017-05-11T19:57:43  <sipa> eh
6342017-05-11T19:57:46  <sipa> ah!
6352017-05-11T19:57:55  <wumpus> yep
6362017-05-11T19:58:15  <wumpus> #endmeeting
6372017-05-11T19:58:15  <lightningbot> Meeting ended Thu May 11 19:58:15 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6382017-05-11T19:58:15  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-11-19.00.html
6392017-05-11T19:58:15  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-11-19.00.txt
6402017-05-11T19:58:15  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-11-19.00.log.html
6412017-05-11T19:58:23  <jonasschnelli> wumpus: The 3D graphical coin selection was a joke.. though, for educational use, it would be great
6422017-05-11T19:58:43  <wumpus> jonasschnelli: yes I like the idea, I'd probably use it, I currently always use manual coin selection already
6432017-05-11T19:58:46  <jonasschnelli> You have a wallet, then you 3d-pick some coins... and you get back a change into your wallet
6442017-05-11T19:59:02  <jonasschnelli> Yes. I personally always do manual coin selection.
6452017-05-11T19:59:14  <jonasschnelli> But not sure about the majority of users. :)
6462017-05-11T19:59:28  <wumpus> jonasschnelli: I think it was in Milan that someone showed some wallet app that had 2d physics effects with coins
6472017-05-11T19:59:31  <instagibbs> I've never done coin selection personally
6482017-05-11T19:59:31  <luke-jr> 2D would be enough
6492017-05-11T19:59:57  <wumpus> don't remember which one, but it looked quite funny
6502017-05-11T19:59:57  <jonasschnelli> luke-jr: Today everything needs to be 3D,... even 2D. :)
6512017-05-11T20:00:10  *** waxwing has quit IRC
6522017-05-11T20:00:15  <gmaxwell> 2d is probably better, 3d illustrations often confuse people about volumes.  But if you show more valuable coins as bigger that will create a false impression that bigger coins cost more to spend, no?
6532017-05-11T20:00:18  <instagibbs> simply tossing current coin selection and adding random selection would probably be a huge plus sadly.
6542017-05-11T20:00:21  <luke-jr> jonasschnelli: ☹
6552017-05-11T20:00:29  <wumpus> I don't think it's *useful* for most people but those things can be fun to play with and people learn how it works
6562017-05-11T20:00:47  <jonasschnelli> 3D would be in a form you woudnl't recognize. The depth and shadows only slighly change when you drag the coins.
6572017-05-11T20:01:06  <wumpus> jonasschnelli: oh, so no tetris blocks? :-)
6582017-05-11T20:01:18  <jonasschnelli> heh
6592017-05-11T20:02:11  <jonasschnelli> Someone I feel if – from the beginning – coin selection would have been a "manual process", people would understand Bitcoin transactions better.
6602017-05-11T20:02:18  <wumpus> plane tiling puzzle but with the goal to get as close as possible to the spend value :p
6612017-05-11T20:02:25  <jonasschnelli> Also the "feerate" problem.. that it's not absolute.
6622017-05-11T20:02:28  *** Firescar96 has quit IRC
6632017-05-11T20:02:36  <wumpus> jonasschnelli: I tend to agree
6642017-05-11T20:03:10  <gmaxwell> A better visualization might be be the coins being sized based on how much weight they add to the txn, and different metals based on value. :P
6652017-05-11T20:03:16  <jonasschnelli> Automatic coin selection may be something large wallets / exchanges are using.
6662017-05-11T20:03:31  <jonasschnelli> gmaxwell: Oh. Different metals... I like this.
6672017-05-11T20:03:59  <instagibbs> "Silver, since when did I have Litecoin?"
6682017-05-11T20:04:11  <jonasschnelli> With a SW badge? :-)
6692017-05-11T20:04:41  <luke-jr> gmaxwell: yeah, I was thinking numbers rather than colours
6702017-05-11T20:04:44  <luke-jr> maybe both?
6712017-05-11T20:05:08  *** SopaXorzTaker has quit IRC
6722017-05-11T20:05:27  <wumpus> niec idea
6732017-05-11T20:05:31  <gmaxwell> luke-jr: well yea, both of course.
6742017-05-11T20:05:38  *** Guest50211 has quit IRC
6752017-05-11T20:06:01  <luke-jr> gold for > 1 ᵐTBC, silver for > ᵗTBC, bronze for > 1 TBC, and "plastic" for smaller
6762017-05-11T20:06:15  * luke-jr hides
6772017-05-11T20:06:17  <gmaxwell> hah
6782017-05-11T20:10:38  *** jcliff42 has joined #bitcoin-core-dev
6792017-05-11T20:12:58  *** waxwing has joined #bitcoin-core-dev
6802017-05-11T20:16:38  *** jcliff42 has joined #bitcoin-core-dev
6812017-05-11T20:17:02  *** jcliff42 has joined #bitcoin-core-dev
6822017-05-11T20:19:50  *** jcliff42 has quit IRC
6832017-05-11T20:26:49  *** cbits has quit IRC
6842017-05-11T20:28:16  *** goksinen has quit IRC
6852017-05-11T20:36:30  *** rgod has joined #bitcoin-core-dev
6862017-05-11T20:37:40  *** d_t has joined #bitcoin-core-dev
6872017-05-11T20:38:53  <instagibbs> my p2p-fullblocks test is timing out on a couple of my machines... is this known issue
6882017-05-11T20:39:34  *** goksinen has joined #bitcoin-core-dev
6892017-05-11T20:40:17  *** moli_ has joined #bitcoin-core-dev
6902017-05-11T20:41:17  <instagibbs> oh scratch that, this seems to be an assertion error
6912017-05-11T20:42:08  *** d_t has quit IRC
6922017-05-11T20:42:58  *** mol has quit IRC
6932017-05-11T20:45:29  *** cbits has joined #bitcoin-core-dev
6942017-05-11T20:49:29  *** Guyver2 has quit IRC
6952017-05-11T20:53:36  *** Sprh has joined #bitcoin-core-dev
6962017-05-11T21:04:02  *** gm2052 has joined #bitcoin-core-dev
6972017-05-11T21:06:16  *** gm2051 has quit IRC
6982017-05-11T21:13:42  *** Firescar96 has joined #bitcoin-core-dev
6992017-05-11T21:18:25  *** JackH has quit IRC
7002017-05-11T21:23:40  *** [Author] has quit IRC
7012017-05-11T21:27:58  *** BashCo has joined #bitcoin-core-dev
7022017-05-11T21:28:16  *** gm2053 has joined #bitcoin-core-dev
7032017-05-11T21:28:47  *** [Author] has joined #bitcoin-core-dev
7042017-05-11T21:31:55  *** gm2052 has quit IRC
7052017-05-11T21:33:02  *** cbits has quit IRC
7062017-05-11T21:34:21  *** talmai has quit IRC
7072017-05-11T21:35:01  *** gm2052 has joined #bitcoin-core-dev
7082017-05-11T21:38:14  *** gm2053 has quit IRC
7092017-05-11T21:39:10  *** shesek has quit IRC
7102017-05-11T21:44:32  *** kadoban has quit IRC
7112017-05-11T21:50:11  *** kadoban has joined #bitcoin-core-dev
7122017-05-11T21:58:40  *** Sprh has quit IRC
7132017-05-11T22:00:36  <gmaxwell> jonasschnelli: sipa: petertodd: luke-jr:   Bitcoin-dev is as useful as we make it.  There are certian reliable parties that will crap-post reply to every useful idea posted to the list.  When we respond directly point by point arguing their foolish positions, the list becomes useless for technical discussions.
7142017-05-11T22:00:46  *** protomar has quit IRC
7152017-05-11T22:01:26  <gmaxwell> I would strongly recommend that whenever you get a message from someone who has reliably made useless progress blocking responses that you do not respond to them point by point, but instead make sure their concerns are addressed in a message responding to a productive point raised by someone else.
7162017-05-11T22:02:22  <gmaxwell> Otherwise, the thread just becomes an endless argument over stupidity and people who are likely to make reasonable responses will ignore the thread.
7172017-05-11T22:04:32  *** kadoban_ has joined #bitcoin-core-dev
7182017-05-11T22:04:51  *** kadoban has quit IRC
7192017-05-11T22:07:12  *** rgod has quit IRC
7202017-05-11T22:22:10  *** mol has joined #bitcoin-core-dev
7212017-05-11T22:24:57  *** moli_ has quit IRC
7222017-05-11T22:26:35  *** Firescar96 has quit IRC
7232017-05-11T22:26:57  *** mol has quit IRC
7242017-05-11T22:29:14  <sipa> frequency of depths of blocks downloaded from my node over the past 3 months: http://bitcoin.sipa.be/depths.png
7252017-05-11T22:30:29  *** moli_ has joined #bitcoin-core-dev
7262017-05-11T22:30:51  *** moli_ has quit IRC
7272017-05-11T22:31:20  *** moli_ has joined #bitcoin-core-dev
7282017-05-11T22:35:25  *** gm2053 has joined #bitcoin-core-dev
7292017-05-11T22:38:20  *** d_t has joined #bitcoin-core-dev
7302017-05-11T22:39:41  *** gm2052 has quit IRC
7312017-05-11T22:42:30  *** gm2052 has joined #bitcoin-core-dev
7322017-05-11T22:42:36  *** d_t has quit IRC
7332017-05-11T22:43:27  *** goksinen has quit IRC
7342017-05-11T22:44:40  *** gm2051 has joined #bitcoin-core-dev
7352017-05-11T22:45:36  *** gm2053 has quit IRC
7362017-05-11T22:47:32  *** gm2052 has quit IRC
7372017-05-11T22:53:05  *** NewLiberty has quit IRC
7382017-05-11T23:05:16  *** Dyaheon has quit IRC
7392017-05-11T23:06:27  *** Dyaheon has joined #bitcoin-core-dev
7402017-05-11T23:14:48  *** gm2052 has joined #bitcoin-core-dev
7412017-05-11T23:18:39  *** gm2051 has quit IRC
7422017-05-11T23:20:04  *** gm2053 has joined #bitcoin-core-dev
7432017-05-11T23:23:56  *** gm2052 has quit IRC
7442017-05-11T23:30:58  *** NewLiberty has joined #bitcoin-core-dev
7452017-05-11T23:34:55  *** gm2052 has joined #bitcoin-core-dev
7462017-05-11T23:38:52  *** gm2053 has quit IRC
7472017-05-11T23:39:57  *** jannes has quit IRC
7482017-05-11T23:45:17  *** chatter29 has joined #bitcoin-core-dev
7492017-05-11T23:45:24  <chatter29> hey guys
7502017-05-11T23:45:34  <chatter29> allah is doing
7512017-05-11T23:45:40  <chatter29> sun is not doing allah is doing
7522017-05-11T23:45:41  <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
7532017-05-11T23:45:59  <chatter29> As-salāmu ʿalaykum (Arabic: السَّلَامُ عَلَيْكُمْ‎‎ [asːaˈlaːmu ʕaˈlaikum]) is a greeting in Arabic that means "peace be upon you". The greeting is a standard salutation among Muslims and is routinely used whenever and wherever Muslims gather and interact, whether socially or within worship and other contexts. [1] The typical response to the greeti
7542017-05-11T23:45:59  <chatter29> ng is waʿalaykumu s-salām (وَعَلَيْكُم السَّلَام [waʕaˈlaikumu sːaˈlaːm]; "and upon you, peace").
7552017-05-11T23:46:03  *** ChanServ sets mode: +o luke-jr
7562017-05-11T23:46:06  *** chatter29 was kicked by luke-jr (spam)
7572017-05-11T23:46:09  *** luke-jr sets mode: -o luke-jr
7582017-05-11T23:46:29  *** gm2053 has joined #bitcoin-core-dev
7592017-05-11T23:50:11  *** chatter29 has joined #bitcoin-core-dev
7602017-05-11T23:50:37  *** gm2052 has quit IRC
7612017-05-11T23:50:59  *** kline has joined #bitcoin-core-dev
7622017-05-11T23:51:42  *** chatter29 has quit IRC
7632017-05-11T23:52:22  *** kline has left #bitcoin-core-dev
7642017-05-11T23:54:10  *** Giszmo has quit IRC
7652017-05-11T23:57:27  *** NewLiberty has quit IRC
7662017-05-11T23:57:58  *** waxwing__ has joined #bitcoin-core-dev
7672017-05-11T23:59:10  *** mol has joined #bitcoin-core-dev