12016-06-09T00:09:43  *** TomMc has quit IRC
  22016-06-09T00:13:05  <dgenr8> adiabat: bloom filter digests would be great, but won't kill off connection bloom filters. people want to see unconfirmed activity
  32016-06-09T00:16:39  <gmaxwell> dgenr8: the addition of filtering the current transactions was a 12th hour addition to BIP37, and for many users saving an average of 13kbit/sec for a total loss of privacy is not all that interesting just to see unconfirmed transactions that their wallets can't even tell are at all remotely possily correct.
  42016-06-09T00:23:27  <dgenr8> gmaxwell: so you think wallet should be watching all live tx, or none, or "either of those, just not filtered"?
  52016-06-09T00:24:40  <gmaxwell> Or filtered, it's the wallets call. The exact behavior depends on the specific use case, and I think the specific use case for filtered is fairly narrow.
  62016-06-09T00:25:09  <gmaxwell> If the digests idea had come up at the time of BIP37, I think it would have been implemented and filtering of relayed transactions wouldn't have been.
  72016-06-09T00:28:31  *** blur3d has joined #bitcoin-core-dev
  82016-06-09T00:31:04  *** xiangfu has quit IRC
  92016-06-09T00:32:17  *** [b__b] has quit IRC
 102016-06-09T00:32:51  <dgenr8> one use case is "i'm told a tx was broadcast that pays me. i wonder if that's true"
 112016-06-09T00:33:21  *** murch has quit IRC
 122016-06-09T00:37:05  *** [b__b] has joined #bitcoin-core-dev
 132016-06-09T00:49:02  *** raedah has joined #bitcoin-core-dev
 142016-06-09T01:01:17  *** Ylbam has quit IRC
 152016-06-09T01:05:20  *** dermoth has quit IRC
 162016-06-09T01:05:59  *** dermoth has joined #bitcoin-core-dev
 172016-06-09T01:25:48  <gmaxwell> P2Pool is updated for CSV.
 182016-06-09T01:35:04  *** dermoth has quit IRC
 192016-06-09T01:35:31  <luke-jr> it needed updating?
 202016-06-09T01:35:47  <luke-jr> oh, because peers need to police each other
 212016-06-09T01:36:02  *** dermoth has joined #bitcoin-core-dev
 222016-06-09T01:45:01  *** [b__b] has quit IRC
 232016-06-09T01:48:50  <gmaxwell> also because it compensates for lack of softfork flags on gbt by not signaling higher versions than p2p knows about.
 242016-06-09T01:50:27  *** [b__b] has joined #bitcoin-core-dev
 252016-06-09T01:52:50  <GitHub140> [bitcoin] gmaxwell opened pull request #8179: Evict orphans which are included or precluded by accepted blocks. (master...reap_orphans) https://github.com/bitcoin/bitcoin/pull/8179
 262016-06-09T02:02:34  *** dgenr8 has quit IRC
 272016-06-09T02:02:59  *** dgenr8 has joined #bitcoin-core-dev
 282016-06-09T02:14:43  *** JackH has joined #bitcoin-core-dev
 292016-06-09T02:17:30  *** Chris_Stewart_5 has quit IRC
 302016-06-09T02:21:40  *** justanotheruser has quit IRC
 312016-06-09T02:22:23  *** justanotheruser has joined #bitcoin-core-dev
 322016-06-09T02:24:41  *** supasonic has joined #bitcoin-core-dev
 332016-06-09T02:56:05  <luke-jr> gmaxwell: ah, right
 342016-06-09T03:04:04  *** supasonic has quit IRC
 352016-06-09T03:04:33  *** supasonic has joined #bitcoin-core-dev
 362016-06-09T03:09:03  *** achow101 has quit IRC
 372016-06-09T03:40:33  *** molz has joined #bitcoin-core-dev
 382016-06-09T03:43:42  *** moli has quit IRC
 392016-06-09T04:02:19  *** adiabat has joined #bitcoin-core-dev
 402016-06-09T04:20:51  *** moli has joined #bitcoin-core-dev
 412016-06-09T04:23:03  *** molz has quit IRC
 422016-06-09T04:27:21  *** jtimon has quit IRC
 432016-06-09T04:28:09  *** _anthony_ has quit IRC
 442016-06-09T04:47:39  <iniana> Will miners who don't upgrade get their blocks orphaned immediately once the grace period is over (by not signalling the activated bit) or only when they mine an invalid block?
 452016-06-09T05:04:37  *** Giszmo has quit IRC
 462016-06-09T05:08:16  *** gevs has quit IRC
 472016-06-09T05:13:38  <GitHub77> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/4286f4302514...19ea17302e8f
 482016-06-09T05:13:39  <GitHub77> bitcoin/master b676f38 Cory Fields: depends: allow for CONFIG_SITE to be used rather than stealing prefix...
 492016-06-09T05:13:39  <GitHub77> bitcoin/master ad38204 Cory Fields: gitian: use CONFIG_SITE rather than hijacking the prefix
 502016-06-09T05:13:40  <GitHub77> bitcoin/master 7e7eb27 Cory Fields: gitian: create debug packages for linux/windows...
 512016-06-09T05:13:47  <GitHub1> [bitcoin] laanwj closed pull request #8167: gitian: Ship debug tarballs/zips with debug symbols (master...split-debug) https://github.com/bitcoin/bitcoin/pull/8167
 522016-06-09T05:21:49  *** gevs has joined #bitcoin-core-dev
 532016-06-09T05:22:35  *** xiangfu has joined #bitcoin-core-dev
 542016-06-09T05:23:23  *** NicolasDorier has quit IRC
 552016-06-09T05:23:24  *** wallet42 has quit IRC
 562016-06-09T05:23:25  <GitHub156> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/19ea17302e8f...f0299d80fd42
 572016-06-09T05:23:25  <GitHub156> bitcoin/master 74c1347 Wladimir J. van der Laan: gitian: Add --disable-bench to config flags for windows...
 582016-06-09T05:23:26  <GitHub156> bitcoin/master f0299d8 Wladimir J. van der Laan: Merge #8175: gitian: Add --disable-bench to config flags for windows...
 592016-06-09T05:23:30  <GitHub5> [bitcoin] laanwj closed pull request #8175: gitian: Add --disable-bench to config flags for windows (master...2016_06_disable_bench_windows) https://github.com/bitcoin/bitcoin/pull/8175
 602016-06-09T05:23:49  *** limpkin has quit IRC
 612016-06-09T05:24:15  *** mturquette has quit IRC
 622016-06-09T05:24:16  *** NicolasDorier has joined #bitcoin-core-dev
 632016-06-09T05:24:26  *** ibrightly has quit IRC
 642016-06-09T05:24:26  *** eragmus has quit IRC
 652016-06-09T05:25:04  *** zmanian__ has quit IRC
 662016-06-09T05:25:04  *** binns has quit IRC
 672016-06-09T05:25:05  *** CodeShark has quit IRC
 682016-06-09T05:26:09  <gmaxwell> iniana: the latter
 692016-06-09T05:27:43  <GitHub35> [bitcoin] luke-jr opened pull request #8180: Update luke-jr's PGP key (master...2016_pgp_update) https://github.com/bitcoin/bitcoin/pull/8180
 702016-06-09T05:28:15  *** eragmus has joined #bitcoin-core-dev
 712016-06-09T05:28:29  <gmaxwell> or even "if" not when, these txn are non-standard, so they won't likely mine them
 722016-06-09T05:28:34  *** CodeShark has joined #bitcoin-core-dev
 732016-06-09T05:28:46  *** ibrightly has joined #bitcoin-core-dev
 742016-06-09T05:29:30  <GitHub0> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f0299d80fd42...7e6dd7bee479
 752016-06-09T05:29:30  <GitHub0> bitcoin/master 77f63a4 Pieter Wuille: Fix two warnings for comparison between signed and unsigned
 762016-06-09T05:29:31  <GitHub0> bitcoin/master 7e6dd7b Wladimir J. van der Laan: Merge #8172: Fix two warnings for comparison between signed and unsigned...
 772016-06-09T05:29:40  <GitHub101> [bitcoin] laanwj closed pull request #8172: Fix two warnings for comparison between signed and unsigned (master...fixunsigned) https://github.com/bitcoin/bitcoin/pull/8172
 782016-06-09T05:30:08  *** binns has joined #bitcoin-core-dev
 792016-06-09T05:31:44  *** mturquette has joined #bitcoin-core-dev
 802016-06-09T05:32:19  <gmaxwell> Thanks. those have been bothering me.
 812016-06-09T05:32:31  *** limpkin has joined #bitcoin-core-dev
 822016-06-09T05:33:14  <luke-jr> ☺
 832016-06-09T05:33:56  *** ibrightly has quit IRC
 842016-06-09T05:33:58  *** zmanian__ has joined #bitcoin-core-dev
 852016-06-09T05:35:32  *** ibrightly has joined #bitcoin-core-dev
 862016-06-09T05:36:55  *** wallet42 has joined #bitcoin-core-dev
 872016-06-09T05:37:24  <GitHub102> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7e6dd7bee479...d36618585de6
 882016-06-09T05:37:24  <GitHub102> bitcoin/master e012f3c Wladimir J. van der Laan: util: Add ParseUInt32 and ParseUInt64...
 892016-06-09T05:37:25  <GitHub102> bitcoin/master d366185 Wladimir J. van der Laan: Merge #8168: util: Add ParseUInt32 and ParseUInt64...
 902016-06-09T05:37:33  <GitHub92> [bitcoin] laanwj closed pull request #8168: util: Add ParseUInt32 and ParseUInt64 (master...2016_06_parseuint) https://github.com/bitcoin/bitcoin/pull/8168
 912016-06-09T05:40:57  *** frankenmint has quit IRC
 922016-06-09T05:40:59  *** xiangfu has quit IRC
 932016-06-09T05:49:31  *** frankenmint has joined #bitcoin-core-dev
 942016-06-09T06:07:35  *** wallet42 has quit IRC
 952016-06-09T06:08:04  *** ibrightly has quit IRC
 962016-06-09T06:10:26  *** wallet42 has joined #bitcoin-core-dev
 972016-06-09T06:13:34  <GitHub168> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d36618585de6...1445835bd3c4
 982016-06-09T06:13:34  <GitHub168> bitcoin/master d3d02d5 Kaz Wesley: drop vAddrToSend after sending big addr message...
 992016-06-09T06:13:34  <GitHub168> bitcoin/master 1445835 Wladimir J. van der Laan: Merge #8154: drop vAddrToSend after sending big addr message...
1002016-06-09T06:13:43  <GitHub102> [bitcoin] laanwj closed pull request #8154: drop vAddrToSend after sending big addr message (master...drop-vAddrToSend) https://github.com/bitcoin/bitcoin/pull/8154
1012016-06-09T06:20:28  *** ibrightly has joined #bitcoin-core-dev
1022016-06-09T06:25:44  <GitHub197> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1445835bd3c4...0b5279f89c9a
1032016-06-09T06:25:45  <GitHub197> bitcoin/master c2715d3 Pavel Janík: Do not shadow local variables
1042016-06-09T06:25:45  <GitHub197> bitcoin/master 0b5279f Wladimir J. van der Laan: Merge #8166: src/test: Do not shadow local variables...
1052016-06-09T06:25:53  <GitHub194> [bitcoin] laanwj closed pull request #8166: src/test: Do not shadow local variables (master...20160607_shadowing_tests) https://github.com/bitcoin/bitcoin/pull/8166
1062016-06-09T06:28:10  *** Guyver2 has joined #bitcoin-core-dev
1072016-06-09T06:36:15  <GitHub92> [bitcoin] laanwj closed pull request #7398: Improve seed generation script for clarity (master...contrib-seeds) https://github.com/bitcoin/bitcoin/pull/7398
1082016-06-09T07:04:47  <gmaxwell> Hm. I think with the 0.13 sorted inv behavior can actually wipe out the orphan map when we have no outstanding unresponded getdata for transactions from any peers.  (this wouldn't be a good idea with the pre 0.13 behavior in the network, so we probably shouldn't do that now)
1092016-06-09T07:08:24  <jonasschnelli> sipa: Willing to test https://github.com/bitcoin/bitcoin/pull/8035? Would be great to make progress before 0.13 here.
1102016-06-09T07:08:49  <jonasschnelli> You also mentioned here (https://github.com/bitcoin/bitcoin/pull/8035#issuecomment-223058733) that " There are a few nits left to address.". Can you point me to them?
1112016-06-09T07:19:28  *** Ylbam has joined #bitcoin-core-dev
1122016-06-09T07:20:17  *** Guyver2 has quit IRC
1132016-06-09T07:27:10  <paveljanik> github Unircorn 8)
1142016-06-09T07:28:45  <jonasschnelli> argh... again...
1152016-06-09T07:28:55  <jonasschnelli> We need a decentralized github web. :)
1162016-06-09T07:29:21  <sipa> You mean git?
1172016-06-09T07:29:26  <jonasschnelli> hehe...
1182016-06-09T07:29:48  <jonasschnelli> Yes. With the option of creating issues, public announcements of pull requests, etc.
1192016-06-09T07:47:55  <wumpus> there have been ideas to create a git.bitcoincore.org which mirrors the repository and where one can clone from if the github repository is offline, the thing is, no one really has time to set up and babysit such things
1202016-06-09T07:49:24  <warren> Does the git repo use signed merge commits?
1212016-06-09T07:49:55  <btcdrak> wumpus: maintenance is a bitch.
1222016-06-09T07:50:04  <sipa> warren: we always gpg sign merge commits
1232016-06-09T07:50:05  <btcdrak> warren: yes.
1242016-06-09T07:50:16  <sipa> warren: and there is a script to verify that
1252016-06-09T07:52:29  <jonasschnelli> wumpus: you mean mirroring the github data?
1262016-06-09T07:52:42  <jonasschnelli> Or just the git?
1272016-06-09T07:52:51  <wumpus> just the git
1282016-06-09T07:53:01  <jonasschnelli> Okay. That would be trivial.
1292016-06-09T07:53:12  <wumpus> we do mirror the github data in a github repository, could also push that there
1302016-06-09T07:53:16  <jonasschnelli> btcdrak: where is bitcoincore.org hosted?
1312016-06-09T07:53:17  <btcdrak> I'm sure the odd Github Unicorn doesnt cause us _that_ much trouble.
1322016-06-09T07:53:32  <btcdrak> jonasschnelli: the website is at github :)
1332016-06-09T07:53:33  <sipa> wumpus: wgat
1342016-06-09T07:53:38  *** adiabat has quit IRC
1352016-06-09T07:53:40  <jonasschnelli> Yes. But we can't work on a decentralized system on a centralized github. :)
1362016-06-09T07:53:43  <btcdrak> but can set a DNS entry to any server...
1372016-06-09T07:53:50  <btcdrak> (a subdomain I mean)
1382016-06-09T07:54:28  <btcdrak> jonasschnelli: decentralisation is a myth in this case.
1392016-06-09T07:54:42  <wumpus> we've been signing merge commits consistently from ~2013 or so, and were one of the first projects to do this
1402016-06-09T07:55:03  <sipa> unfortunately git commit ids are only sha1 :(
1412016-06-09T07:55:55  <wumpus> well it's not perfect security but certainly puts of a barrier, which is the point of any security feature
1422016-06-09T07:55:58  <btcdrak> i love how this entire conversation comes up almost verbatim again every now and again :)
1432016-06-09T07:56:23  <wumpus> we're like broken records
1442016-06-09T07:56:33  <btcdrak> mayeb I should write a FAQ :-p
1452016-06-09T07:58:42  <btcdrak> but seriously, my point is: someone sees a Unicorn, and rather than press F5, it ignites a sledge hammer to crack peanut response :-D
1462016-06-09T07:58:55  <wumpus> please include a "database corrupted" entry
1472016-06-09T07:59:09  <wumpus> really doesn't help that everyone creates a new issue every time they get that
1482016-06-09T07:59:34  <wumpus> where 99 out of 100 times it's simply a hardware problem
1492016-06-09T08:00:04  <btcdrak> agreed, I think there are a bunch of common issue we could cover.
1502016-06-09T08:00:07  <wumpus> we really should discourage people from creating new issues about that, unless there's new information to report
1512016-06-09T08:00:24  <wumpus> maybe they could post to an existing issue for statistics or something
1522016-06-09T08:01:46  <gmaxwell> change the message to "Apparent hardware error" :)
1532016-06-09T08:02:47  <wumpus> gcc has the same thing, where people keep reporting SEGV crashes caused by overclocked or otherwise flakey CPUs, while compiling run-of-the-mill software
1542016-06-09T08:03:41  <wumpus> gmaxwell: yes, that would be a good idea
1552016-06-09T08:04:18  <paveljanik> maybe even a link to the FAQ entry about this?
1562016-06-09T08:06:17  <sipa> nobody believes you when you tell them their hardware is broken
1572016-06-09T08:06:27  <gmaxwell> a few do.
1582016-06-09T08:06:29  <wumpus> still, it helps to have it written down somewhere
1592016-06-09T08:06:35  <wumpus> in a clear way
1602016-06-09T08:06:44  <wumpus> instead of repeating it all the time, increasingly annoyed :)
1612016-06-09T08:06:46  <gmaxwell> I actually think they believe it from the sofware more than names on IRC.
1622016-06-09T08:07:11  <gmaxwell> well whats worse is that they search the log entry, and find other people explaining that it's totally not hardware and the software is buggy and what not'
1632016-06-09T08:07:19  <gmaxwell> and they show up "hey you morons still haven't fixed this!"
1642016-06-09T08:07:44  <gmaxwell> they also run -rescan ten times and it won't go away and why should they have to run it an eleventh!?
1652016-06-09T08:08:19  <gmaxwell> Is there a german word for where you both feel apologetic towards someone and want to strangle them?
1662016-06-09T08:10:36  <wumpus> the thing is, even if there are software bugs involved, opening more issues about it isn't going to help a thing
1672016-06-09T08:11:20  <gmaxwell> A lot of people just don't have a good mental model of how this whole thing works. Like, if it's still buggy and reported, then why haven't we fixed it? obviously we don't care or are lazy.
1682016-06-09T08:11:22  <wumpus> I think I'm going to create one 'data corruption' issue and close the others as duplicates
1692016-06-09T08:11:50  <gmaxwell> Same reason why reports seldom have the information required to reproduce the issue.
1702016-06-09T08:12:27  <wumpus> well most issues are fairly good in that regard
1712016-06-09T08:12:28  <gmaxwell> if we had simply forgotten, reporting again would help-- and we do, from time to time, forget actual issues.
1722016-06-09T08:12:42  <wumpus> generally not issues that are reported on github
1732016-06-09T08:12:49  <gmaxwell> Right.
1742016-06-09T08:12:52  <wumpus> sure, if something is said on IRC or the mailing list it gets lost
1752016-06-09T08:12:56  <gmaxwell> at least not while they're still open.
1762016-06-09T08:12:59  <wumpus> the point of an issue tracker is to have a persistent URL for an issue
1772016-06-09T08:13:30  <gmaxwell> But clearly we've fogotten the data corruption because it keeps hapenning. :P QED.
1782016-06-09T08:13:33  <wumpus> if it gets too crowded it loses its value
1792016-06-09T08:14:01  <wumpus> then it's just like mentioning it once on reddit, no one will ever look back to it
1802016-06-09T08:14:10  <wumpus> heh
1812016-06-09T08:14:28  <wumpus> well every time I had actual data corruption I investigated in depth
1822016-06-09T08:16:52  <jonasschnelli> What about providing a script/cli-tool (C++) that would perform some heave leveldb tests with block like data? Something like a bitcoin-hardware-test?
1832016-06-09T08:17:07  <gmaxwell> it's called bitcoind.
1842016-06-09T08:17:19  <wumpus> it will take long to detect errors, so no one will run that
1852016-06-09T08:17:25  <wumpus> heh exactly
1862016-06-09T08:17:28  <gmaxwell> it's not just leveldb though, the cpu load from signature validation triggers memory errors on some systems.
1872016-06-09T08:17:30  <jonasschnelli> Okay.. :)
1882016-06-09T08:17:59  <gmaxwell> when we have wumpus' snapshot stuff perhaps we could also do other things to retry/recover in the face of error.
1892016-06-09T08:18:33  <wumpus> there are just so many types of hardware problems that can result in corruptions
1902016-06-09T08:18:39  <gmaxwell> I have mixed feelings, users really shouldn't count on faulty computers... esp for handling irreversable money...
1912016-06-09T08:19:05  <wumpus> and there is software to detect hardware problems, that's a completely orthogonal thing :)
1922016-06-09T08:19:29  <jonasschnelli> Right. Agree.
1932016-06-09T08:19:32  <gmaxwell> many are resolved just by being able to go back to earlier state... obviously flying writes that corrupt data at rest.. well not much then can be done there... (well, we do have forward error correction code...)
1942016-06-09T08:20:19  <jonasschnelli> I just had serval crashes on my Pine64 (due to false configuration and maybe USB issues). I always had to reindex/IBD from the scratch.
1952016-06-09T08:20:33  <jonasschnelli> Wumpuses snapshot idea would be a live-safer for such situations
1962016-06-09T08:23:15  <GitHub178> [bitcoin] laanwj closed pull request #7938: [0.12.2] Backports (0.12...Mf1604-012backp) https://github.com/bitcoin/bitcoin/pull/7938
1972016-06-09T08:23:18  <GitHub74> [bitcoin] laanwj pushed 15 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/e7ec24e336dc...20d00a180ee6
1982016-06-09T08:23:19  <GitHub74> bitcoin/0.12 9095594 ptschip: Do not download transactions during inital sync...
1992016-06-09T08:23:19  <GitHub74> bitcoin/0.12 a9e73f7 instagibbs: Fix and cleanup listreceivedbyX documentation...
2002016-06-09T08:23:20  <GitHub74> bitcoin/0.12 64fd0ce jloughry: fix spelling of advertise in src and doc...
2012016-06-09T08:28:16  *** frankenmint has quit IRC
2022016-06-09T08:29:55  <paveljanik> Can you kick travis on #8109 please?
2032016-06-09T08:30:55  <paveljanik> ah, I can do that myself by simply rebasing it.
2042016-06-09T08:41:58  *** frankenmint has joined #bitcoin-core-dev
2052016-06-09T08:42:04  *** jannes has joined #bitcoin-core-dev
2062016-06-09T08:43:33  *** challisto has joined #bitcoin-core-dev
2072016-06-09T08:44:13  *** challisto has quit IRC
2082016-06-09T08:47:57  *** kadoban has quit IRC
2092016-06-09T08:51:16  <GitHub89> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b5279f89c9a...172cd7f10c7e
2102016-06-09T08:51:16  <GitHub89> bitcoin/master cdf7dff Jonas Schnelli: OSX diskimages need 0775 folder permissions...
2112016-06-09T08:51:17  <GitHub89> bitcoin/master 172cd7f Wladimir J. van der Laan: Merge #8169: OSX diskimages need 0775 folder permissions...
2122016-06-09T08:51:29  <GitHub110> [bitcoin] laanwj closed pull request #8169: OSX diskimages need 0775 folder permissions (master...2016/06/fix_gitian_osx) https://github.com/bitcoin/bitcoin/pull/8169
2132016-06-09T08:53:10  <GitHub177> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/0f8d574e8f6521c07ae204b4f8b61d1534f03c21
2142016-06-09T08:53:10  <GitHub177> bitcoin/0.12 0f8d574 Jonas Schnelli: OSX diskimages need 0775 folder permissions...
2152016-06-09T08:55:51  *** supasonic has quit IRC
2162016-06-09T08:56:21  *** supasonic has joined #bitcoin-core-dev
2172016-06-09T08:56:23  *** supasonic has quit IRC
2182016-06-09T09:03:16  *** hsmiths has quit IRC
2192016-06-09T09:08:05  *** hsmiths has joined #bitcoin-core-dev
2202016-06-09T09:08:50  *** ozanyurt has quit IRC
2212016-06-09T09:12:51  <GitHub37> [bitcoin] laanwj opened pull request #8181: build: Get rid of `CLIENT_DATE` (master...2016_06_bye_client_date) https://github.com/bitcoin/bitcoin/pull/8181
2222016-06-09T09:14:37  <GitHub131> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/172cd7f10c7e...fd9881ae6782
2232016-06-09T09:14:38  <GitHub131> bitcoin/master fa58c76 MarcoFalke: [gitian] Default reference_datetime to commit author date
2242016-06-09T09:14:38  <GitHub131> bitcoin/master fa42a67 MarcoFalke: [gitian] hardcode datetime for depends
2252016-06-09T09:14:39  <GitHub131> bitcoin/master fd9881a Wladimir J. van der Laan: Merge #7283: [gitian] Default reference_datetime to commit author date...
2262016-06-09T09:14:42  <GitHub186> [bitcoin] laanwj closed pull request #7283: [gitian] Default reference_datetime to commit author date (master...MarcoFalke-2016-gitianTimeDefault) https://github.com/bitcoin/bitcoin/pull/7283
2272016-06-09T09:17:51  <GitHub19> [bitcoin] jonasschnelli opened pull request #8182: [Qt] Add simple opt-in-RBF support (master...2016/04/qt_rbf_set_new) https://github.com/bitcoin/bitcoin/pull/8182
2282016-06-09T09:22:13  <GitHub148> [bitcoin] jonasschnelli closed pull request #7819: [Qt] Simple opt-in-RBF checkbox (master...2016/04/qt_rbf_set) https://github.com/bitcoin/bitcoin/pull/7819
2292016-06-09T09:22:58  *** edward has left #bitcoin-core-dev
2302016-06-09T09:30:00  *** STAFFSCOINS_ has quit IRC
2312016-06-09T09:30:01  *** iniana has quit IRC
2322016-06-09T09:30:01  *** assder has quit IRC
2332016-06-09T09:47:17  *** fedefranz has joined #bitcoin-core-dev
2342016-06-09T09:49:26  *** laurentmt has joined #bitcoin-core-dev
2352016-06-09T10:06:16  *** AaronvanW has quit IRC
2362016-06-09T10:08:53  *** AaronvanW has joined #bitcoin-core-dev
2372016-06-09T10:08:54  *** AaronvanW has quit IRC
2382016-06-09T10:08:54  *** AaronvanW has joined #bitcoin-core-dev
2392016-06-09T10:26:41  *** laurentmt has quit IRC
2402016-06-09T10:28:48  *** laurentmt has joined #bitcoin-core-dev
2412016-06-09T10:31:00  *** laurentmt has quit IRC
2422016-06-09T10:43:18  *** MarcoFalke has joined #bitcoin-core-dev
2432016-06-09T10:43:45  <MarcoFalke> wumpus: Can you explain why you left BUILD_DATE in share/genbuild.sh ?
2442016-06-09T10:43:51  <MarcoFalke> Is it used elsewhere?
2452016-06-09T10:46:22  *** frankenmint has quit IRC
2462016-06-09T10:46:33  *** frankenmint has joined #bitcoin-core-dev
2472016-06-09T10:51:45  *** spikeheadon has joined #bitcoin-core-dev
2482016-06-09T10:51:50  *** spikey has joined #bitcoin-core-dev
2492016-06-09T11:30:47  *** cryptapus has joined #bitcoin-core-dev
2502016-06-09T11:32:33  <wumpus> MarcoFalke: probably an oversight, or I wasn't sure, let me see
2512016-06-09T11:33:16  <wumpus> yes that can definitely go
2522016-06-09T11:59:54  *** spikey has joined #bitcoin-core-dev
2532016-06-09T12:03:41  *** spikeheadon has quit IRC
2542016-06-09T12:11:17  *** Ylbam has quit IRC
2552016-06-09T12:20:58  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2562016-06-09T12:23:37  *** frankenmint has quit IRC
2572016-06-09T12:47:59  *** lysobit- has quit IRC
2582016-06-09T12:48:24  *** musalbas has quit IRC
2592016-06-09T13:27:48  <instagibbs> is there a list of known issues with getbalance? I'm getting inconsistencies, and the comments in the code give me instructions which causes a json parsing error(??)
2602016-06-09T13:27:52  <instagibbs> "// getbalance and "getbalance * 1 true" should return the same number"
2612016-06-09T13:28:16  <instagibbs> oh the latter is probably me being dumb, but I still am getting weird balances
2622016-06-09T13:29:48  *** TomMc has joined #bitcoin-core-dev
2632016-06-09T13:30:05  <sipa> instagibbs: https://github.com/bitcoin/bitcoin/pull/7715 ?
2642016-06-09T13:32:07  <instagibbs> thanks, is that comment supposed to be correct? I'm getting different balances
2652016-06-09T13:36:00  <sipa> are you typing "getbalance * 1 true" on the command line? that will expand * to the list of files in your current directory
2662016-06-09T13:36:22  <instagibbs> i was, but i escaped it yes
2672016-06-09T13:36:32  *** Chris_Stewart_5 has quit IRC
2682016-06-09T13:37:01  <instagibbs> If I send funds to myself in regtest, it immediately shows up in getbalance, but not getbalance * 1 true
2692016-06-09T13:37:01  <sipa> then how do you get a parsing error?
2702016-06-09T13:37:17  <instagibbs> no that was my 2nd issue, now fixed
2712016-06-09T13:37:23  <sipa> ah, getbalance will show unconfirmed sends from yourself
2722016-06-09T13:37:35  <instagibbs> well... I will change that comment then
2732016-06-09T13:37:41  <instagibbs> thanks
2742016-06-09T13:38:14  <sipa> that comment is very very old
2752016-06-09T13:38:21  <sipa> 2010, i expect
2762016-06-09T13:39:25  <instagibbs> 2015?
2772016-06-09T13:39:33  <instagibbs> according to git blame
2782016-06-09T13:39:53  <sipa> oh
2792016-06-09T13:39:56  <instagibbs> dgenr8 one-line addition
2802016-06-09T13:40:18  <instagibbs> Anyways, I'll PR if that's expected behavior
2812016-06-09T13:41:21  <sipa> if you disable -spendzeroconfchange, it may work
2822016-06-09T13:41:26  <sipa> s/work/hold true/
2832016-06-09T13:41:53  <instagibbs> ok
2842016-06-09T13:52:13  <instagibbs> still a slight difference with spendzeroconfchange disabled, hmm
2852016-06-09T13:52:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2862016-06-09T13:52:54  *** G1lius has joined #bitcoin-core-dev
2872016-06-09T14:10:00  *** spikeheadon has joined #bitcoin-core-dev
2882016-06-09T14:11:35  *** spikeheadon has quit IRC
2892016-06-09T14:11:55  *** spikeheadon has joined #bitcoin-core-dev
2902016-06-09T14:12:34  *** spikey has quit IRC
2912016-06-09T14:12:43  *** spikeheadon has quit IRC
2922016-06-09T14:13:23  *** spikeheadon has joined #bitcoin-core-dev
2932016-06-09T14:14:48  *** spikeheadon has quit IRC
2942016-06-09T14:15:10  *** spikeheadon has joined #bitcoin-core-dev
2952016-06-09T14:16:13  *** spikeheadon has quit IRC
2962016-06-09T14:16:34  *** spikeheadon has joined #bitcoin-core-dev
2972016-06-09T14:18:09  *** spikeheadon has quit IRC
2982016-06-09T14:18:30  *** spikeheadon has joined #bitcoin-core-dev
2992016-06-09T14:29:22  *** Giszmo has joined #bitcoin-core-dev
3002016-06-09T14:32:59  <GitHub84> [bitcoin] sipa pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd9881ae6782...7ce9ac5c83b1
3012016-06-09T14:33:00  <GitHub84> bitcoin/master 5ec0cde Suhas Daftuar: Refactor logic for converting mempool entries to JSON
3022016-06-09T14:33:00  <GitHub84> bitcoin/master 8f7b5dc Suhas Daftuar: Add getmempoolancestors RPC call
3032016-06-09T14:33:01  <GitHub84> bitcoin/master 0dfd869 Suhas Daftuar: Add getmempooldescendants RPC call
3042016-06-09T14:33:04  <GitHub151> [bitcoin] sipa closed pull request #7292: [RPC] Expose ancestor/descendant information over RPC (master...add-chain-info) https://github.com/bitcoin/bitcoin/pull/7292
3052016-06-09T14:42:49  <GitHub198> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7ce9ac5c83b1...f7b1bfc9a347
3062016-06-09T14:42:49  <GitHub198> bitcoin/master 3144449 Pieter Wuille: Add git and github tips and tricks to developer notes
3072016-06-09T14:42:50  <GitHub198> bitcoin/master f7b1bfc Wladimir J. van der Laan: Merge #8178: Add git and github tips and tricks to developer notes...
3082016-06-09T14:42:59  <GitHub125> [bitcoin] laanwj closed pull request #8178: Add git and github tips and tricks to developer notes (master...docgit) https://github.com/bitcoin/bitcoin/pull/8178
3092016-06-09T14:44:36  <GitHub172> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f7b1bfc9a347...32b7294177e5
3102016-06-09T14:44:36  <GitHub172> bitcoin/master 0d53a9e Luke Dashjr: Update luke-jr's PGP key...
3112016-06-09T14:44:37  <GitHub172> bitcoin/master 32b7294 Wladimir J. van der Laan: Merge #8180: Update luke-jr's PGP key...
3122016-06-09T14:44:46  <GitHub194> [bitcoin] laanwj closed pull request #8180: Update luke-jr's PGP key (master...2016_pgp_update) https://github.com/bitcoin/bitcoin/pull/8180
3132016-06-09T14:52:25  *** Guyver2 has joined #bitcoin-core-dev
3142016-06-09T15:02:14  *** dingus has quit IRC
3152016-06-09T15:19:04  *** spikeheadon has quit IRC
3162016-06-09T15:20:39  <dgenr8> instagibbs: getbalance and getbalance "" appear to differ in their treatment of 0-conf utxos from self.  getbalance "" 1 seems to always includes them.  getbalance "*" follows from getbalance "" (since "" is just a specific account)
3172016-06-09T15:21:42  <dgenr8> instagibbs: also sendfrom "A" seems to not work in a test I just just (it selected a utxo not belonging to "A")
3182016-06-09T15:21:48  <dgenr8> justdid
3192016-06-09T15:22:03  <instagibbs> yeah i opened an issue
3202016-06-09T15:22:12  <instagibbs> since im not sure what the comment should be changed to
3212016-06-09T15:22:25  <instagibbs> there are nooks and crannies depending on settings you are running
3222016-06-09T15:25:50  <dgenr8> agreed that since -spendzeroconfchange affects the result of getbalance, the comment is too general.  prolly just remove it
3232016-06-09T15:26:08  <sipa> dgenr8: sendfrom just subtracts the balance from A; it always uses all utxos
3242016-06-09T15:26:25  <sipa> dgenr8: as accounts don't own utxos in any way
3252016-06-09T15:26:41  <instagibbs> dgenr8, yes I think removal is best
3262016-06-09T15:32:06  *** blur3d has quit IRC
3272016-06-09T15:32:45  *** fengling has joined #bitcoin-core-dev
3282016-06-09T15:34:33  <sipa> dgenr8: also, do you feel like addresses the comments on your partition check improvement?
3292016-06-09T15:34:43  <sipa> *addressing
3302016-06-09T15:36:00  *** jtimon has joined #bitcoin-core-dev
3312016-06-09T15:38:10  *** spikeheadon has joined #bitcoin-core-dev
3322016-06-09T15:38:33  *** Chris_Stewart_5 has quit IRC
3332016-06-09T15:47:38  *** jtimon has quit IRC
3342016-06-09T15:51:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3352016-06-09T15:55:30  *** spikeheadon has quit IRC
3362016-06-09T15:55:44  *** fengling has quit IRC
3372016-06-09T15:55:54  *** grubles has joined #bitcoin-core-dev
3382016-06-09T15:56:09  *** grubles is now known as dingus
3392016-06-09T15:57:05  *** jtimon has joined #bitcoin-core-dev
3402016-06-09T16:02:29  *** fedefranz has left #bitcoin-core-dev
3412016-06-09T16:02:38  *** kadoban has joined #bitcoin-core-dev
3422016-06-09T16:04:17  *** G1lius has quit IRC
3432016-06-09T16:08:35  *** mkarrer_ has joined #bitcoin-core-dev
3442016-06-09T16:08:35  *** mkarrer has quit IRC
3452016-06-09T16:08:42  *** mkarrer_ has quit IRC
3462016-06-09T16:23:18  *** fengling has joined #bitcoin-core-dev
3472016-06-09T16:32:17  <gmaxwell> 2016-06-09 08:46:38.763465 [0%]...[50%]...[99%]...[DONE].
3482016-06-09T16:32:38  <gmaxwell> Is it really okay to dribble out a log entry over a long time?  Not going to break external log handling?
3492016-06-09T16:36:52  *** achow101 has joined #bitcoin-core-dev
3502016-06-09T16:51:11  *** aureianimus_ has quit IRC
3512016-06-09T16:51:45  *** aureianimus_ has joined #bitcoin-core-dev
3522016-06-09T17:02:19  *** jcorgan has quit IRC
3532016-06-09T17:03:48  *** PaulCape_ has quit IRC
3542016-06-09T17:05:26  *** PaulCapestany has joined #bitcoin-core-dev
3552016-06-09T17:07:51  *** JackH_ has joined #bitcoin-core-dev
3562016-06-09T17:08:52  *** JackH has quit IRC
3572016-06-09T17:09:47  *** Chris_Stewart_5 has quit IRC
3582016-06-09T17:18:56  *** spikeheadon has joined #bitcoin-core-dev
3592016-06-09T17:23:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3602016-06-09T17:28:05  *** bsm1175321 has joined #bitcoin-core-dev
3612016-06-09T17:45:10  <GitHub16> [bitcoin] theuni opened pull request #8184: WIP: OSX toolchain bump (master...osx-sdk-bump) https://github.com/bitcoin/bitcoin/pull/8184
3622016-06-09T17:55:01  *** Chris_Stewart_5 has quit IRC
3632016-06-09T18:11:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3642016-06-09T18:15:11  *** molz has joined #bitcoin-core-dev
3652016-06-09T18:17:34  *** moli has quit IRC
3662016-06-09T18:20:44  <wumpus> gmaxwell: sure, an external log handler would just wait for the line to complete
3672016-06-09T18:21:19  <gmaxwell> K. I've never considered that case before and thought it potentially useful to raise the question.
3682016-06-09T18:21:20  <wumpus> there's no rule that log messages need to be written within a certain time
3692016-06-09T18:21:57  <gmaxwell> well generally we should write them a line at a time or otherwise we'll get log entries split by threads.
3702016-06-09T18:22:43  <wumpus> yes, that came up during review too, it can be done here because there is nothing else running at that time
3712016-06-09T18:22:50  <wumpus> and this is less spammy than printing a line for every N%
3722016-06-09T18:23:14  <gmaxwell> Right. I agree that it can be done here.
3732016-06-09T18:26:32  *** Ylbam has joined #bitcoin-core-dev
3742016-06-09T18:32:33  *** BakSAj has joined #bitcoin-core-dev
3752016-06-09T18:32:46  *** laurentmt has joined #bitcoin-core-dev
3762016-06-09T18:33:14  <BakSAj> hi
3772016-06-09T18:36:00  <BakSAj> http://bitcoin.sipa.be/ver9-2k.png
3782016-06-09T18:36:05  <BakSAj> i like the picture :-)
3792016-06-09T18:36:21  <BakSAj> not sure if we make it to 95% in this diff period
3802016-06-09T18:36:46  <gmaxwell> mostly depends on KNC going offline again or not.
3812016-06-09T18:37:12  <adam3us> they maybe selling the equipment
3822016-06-09T18:42:34  <BakSAj> lets hope...
3832016-06-09T18:43:39  <BakSAj> on the other hand its a bit sad that hash will get little more centralized when this EU miner ends
3842016-06-09T18:47:38  *** laurentmt has quit IRC
3852016-06-09T18:48:07  *** laurentmt has joined #bitcoin-core-dev
3862016-06-09T18:48:34  *** zmanian__ has quit IRC
3872016-06-09T18:50:38  *** zmanian__ has joined #bitcoin-core-dev
3882016-06-09T18:55:37  *** hsmiths2 has joined #bitcoin-core-dev
3892016-06-09T18:58:09  *** hsmiths has quit IRC
3902016-06-09T19:00:17  <jonasschnelli> meeting?
3912016-06-09T19:00:25  <gmaxwell> Meeting time.
3922016-06-09T19:00:29  <wumpus> yes
3932016-06-09T19:00:35  <wumpus> #meetingstart
3942016-06-09T19:00:38  <wumpus> #startmeeting
3952016-06-09T19:00:38  <lightningbot> Meeting started Thu Jun  9 19:00:38 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3962016-06-09T19:00:38  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3972016-06-09T19:00:47  *** sean___ has joined #bitcoin-core-dev
3982016-06-09T19:00:52  *** sean___ is now known as ebfull
3992016-06-09T19:01:01  <gmaxwell> phantomcircuit: sipa: morcos: sdaftuar: btcdrak: jonasschnelli: luke-jr:
4002016-06-09T19:01:22  <wumpus> first at PSA: the feature freeze for 0.13 is next week. Make sure that whatever features need to be merged are merged before that time. If there are any pulls that require special attention, or are ready, let me know.
4012016-06-09T19:01:25  <gmaxwell> petertodd: MarcoFalke:
4022016-06-09T19:01:38  *** laurentmt has quit IRC
4032016-06-09T19:01:39  <wumpus> #link 0.13 release schedule: https://github.com/bitcoin/bitcoin/issues/7679
4042016-06-09T19:01:52  <MarcoFalke> any topic suggestions today?
4052016-06-09T19:02:23  <gmaxwell> We can talk some about ongoing compact block testings, I have a few things to report.
4062016-06-09T19:02:42  <wumpus> last meeting there was talk of release lifecycles documentation, btcdrak and David Harding have been working on that page here: https://github.com/bitcoin-core/bitcoincore.org/pull/179 https://github.com/btcdrak/bitcoincore.org/pull/2  this needs review
4072016-06-09T19:02:53  <cfields_> wumpus: I have 2 p2p refactor PRs that i'd _very_ much like to have in 0.13. I'm not sure how you're considering those in terms of freezing
4082016-06-09T19:02:54  <gmaxwell> instagibbs: nickler: NicolasDorier: CodeShark:
4092016-06-09T19:03:14  <CodeShark> yo
4102016-06-09T19:03:23  <MarcoFalke> cfields_: I think p2p refactor can go in after the feature freeze?
4112016-06-09T19:03:29  <gmaxwell> We apparently can no longer compile on hosts with only 2GB ram with defaults.
4122016-06-09T19:03:39  <wumpus> other TODOs from last week: review and merge #8126 (std::shared_ptr based CTransaction storage in mempool) - that was done, #7935 (Versionbits: GBT support) - also done
4132016-06-09T19:03:46  <MarcoFalke> I mean it is not a new feature ;)
4142016-06-09T19:04:04  <gmaxwell> well it was more like 1.5GB ram before.
4152016-06-09T19:04:06  *** jeremyrubin has joined #bitcoin-core-dev
4162016-06-09T19:04:35  <wumpus> others have not yet finished: #7598 (Refactor CreateNewBlock to be a method of the BlockAssembler class)
4172016-06-09T19:04:37  <jonasschnelli> gmaxwell: I compiled on a 2GG AARCH this week successfully.
4182016-06-09T19:04:41  <jonasschnelli> *GB
4192016-06-09T19:04:46  <gmaxwell> We have docs that say 1.5GB, they're gonna be like the blocksize on bitcoin.org :)
4202016-06-09T19:04:49  <wumpus> #7600  Mining: Select transactions using feerate-with-ancestors
4212016-06-09T19:04:55  <wumpus> depends on what else is running on the machine
4222016-06-09T19:05:34  <gmaxwell> I've been going through #7598/#7600.
4232016-06-09T19:05:38  <wumpus> #topic compile-time memory usage
4242016-06-09T19:05:45  <wumpus> what can *concretely* be done here?
4252016-06-09T19:05:58  <jonasschnelli> would kick out boost help?
4262016-06-09T19:05:59  <luke-jr> -O0
4272016-06-09T19:06:01  <wumpus> is it something worrying?
4282016-06-09T19:06:08  <cfields_> has anyone measured to see if there are particular objects that are especially guilty?
4292016-06-09T19:06:11  <CodeShark> what's eating up all the RAM?
4302016-06-09T19:06:14  <wumpus> yes, we have cfields_
4312016-06-09T19:06:20  <cfields_> ie. main.cpp/net.cpp ?
4322016-06-09T19:06:21  <luke-jr> CodeShark: ld/GCC doesn't free memory
4332016-06-09T19:06:22  <wumpus> especialy some autogenerated c++ files
4342016-06-09T19:06:30  *** laurentmt has joined #bitcoin-core-dev
4352016-06-09T19:06:33  <wumpus> I made some tables back in the issue about this
4362016-06-09T19:06:37  <gmaxwell> main.cpp, matt has a patch that moves all the mempool stuff out of it taht apparently gets it back to 1.5GB.
4372016-06-09T19:06:48  *** laurentmt has quit IRC
4382016-06-09T19:06:50  <luke-jr> CFLAGS="-O0 -g0 --param ggc-min-expand=0 --param ggc-min-heapsize=32768"
4392016-06-09T19:06:54  <wumpus> #link https://github.com/bitcoin/bitcoin/issues/7471
4402016-06-09T19:06:54  <gmaxwell> I dunno why he hasn't PRed it, I asked him to.
4412016-06-09T19:07:00  <cfields_> wumpus: thanks
4422016-06-09T19:07:10  <wumpus> eeh that's the wrong one
4432016-06-09T19:07:22  <gmaxwell> wumpus: unthanks
4442016-06-09T19:07:30  <wumpus> well it is about the same subject
4452016-06-09T19:07:33  <wumpus> #link https://github.com/bitcoin/bitcoin/issues/6658
4462016-06-09T19:07:52  <wumpus> lots of people have posted about it, but there doesn't seem to be a clear solution
4472016-06-09T19:08:00  <jonasschnelli> main.cpp -> 1248524bytes ... ^^
4482016-06-09T19:08:33  *** moli has joined #bitcoin-core-dev
4492016-06-09T19:08:37  <wumpus> reducing the number of included headers works, I think
4502016-06-09T19:08:41  <sipa> present
4512016-06-09T19:08:46  <cfields_> I have PRs which break up net.h/netbase.h, i'd be curious to see if those make a significant difference
4522016-06-09T19:09:00  <gmaxwell> in any case, something to be aware of and nudge a bit at... some refactorings to move code around would help.
4532016-06-09T19:09:13  <wumpus> also building with clang helps
4542016-06-09T19:09:21  <wumpus> it uses a lot less memory at the same compile settings, usually
4552016-06-09T19:09:25  <gmaxwell> and be independantly good for reasons unrelated to peak memory usage.
4562016-06-09T19:10:05  <cfields_> i'd assume that mem usage correlates solidly with compile time
4572016-06-09T19:10:41  *** molz has quit IRC
4582016-06-09T19:10:55  <CodeShark> not so sure - lots of small files might mean the bottleneck is disk access
4592016-06-09T19:11:29  <sipa> CodeShark: come on
4602016-06-09T19:11:32  <CodeShark> in any case, it would be good to bring down the peak mem usage
4612016-06-09T19:11:32  <wumpus> the bottleneck in compilation is hardly ever disk access, at least *reading* disk access
4622016-06-09T19:11:37  <sipa> reading in 100 files?
4632016-06-09T19:11:43  <sipa> sequentially
4642016-06-09T19:12:08  <BakSAj> would be cool, if btc full nodes could continue to be runnable on Rasberry Pi ... with 1GB RAM
4652016-06-09T19:12:37  <jeremyrubin> BakSAj: runnable is not compileable on?
4662016-06-09T19:12:40  <gmaxwell> not sure there is much else to say here.  I only brought it up for general awareness issues, since I think it's likely a death by 1000 cuts that can be improved in a multitude of ways.
4672016-06-09T19:12:54  <wumpus> seek/read access for source files is only a problem for really huge projects, and then especially when the source is hosted on some horrible network file system (like clearcase), in any case bitcoin doesn't even come close
4682016-06-09T19:13:03  <cfields_> heh, disk is negligible. It's easy to see where time is spent with -ftime-report.
4692016-06-09T19:13:17  <wumpus> but like always: measure before you start talking about bottlenecks
4702016-06-09T19:13:35  <jonasschnelli> I think adding cross compile depends options for ARM and AARCH64 would also reduce the "memory problem" (at least the amount of complains): https://github.com/bitcoin/bitcoin/issues/8162
4712016-06-09T19:13:58  <BakSAj> jeremyrubin: preferably both compileable and operatable
4722016-06-09T19:13:59  <wumpus> BakSAj: for small embedded systems you should use cross-compilation
4732016-06-09T19:14:03  <cfields_> jonasschnelli: i'm halfway through the changes needed there.
4742016-06-09T19:14:13  <jeremyrubin> i have had machines take a bit of time on autogen.sh fyi
4752016-06-09T19:14:18  <jonasschnelli> cfields_: nice. Focus on Qt5.6 first. :)
4762016-06-09T19:14:31  *** hsmiths2 has quit IRC
4772016-06-09T19:14:34  <wumpus> you can cross compile on ARM using depends, we just don't distribute ARM binaries
4782016-06-09T19:14:37  <cfields_> jonasschnelli: actually, arm/aarch64 already work fine with depends. Just have to use NO_QT=1 manually.
4792016-06-09T19:14:40  <wumpus> s/on/to
4802016-06-09T19:14:41  *** Chris_Stewart_5 has quit IRC
4812016-06-09T19:14:42  <gmaxwell> I'm skeptical that the intersection of rpi users that complain about compile issues and people who will cross compile is the emptyset. But cross compiling is good.
4822016-06-09T19:14:44  <wumpus> cfields_: yes, it works fine
4832016-06-09T19:14:51  <luke-jr> for comparison, webkit-based stuff typically uses up to 12 GB RAM with debug symbols, and much much less without..
4842016-06-09T19:14:56  <gmaxwell> er isn't the empty set, you get what I mean.
4852016-06-09T19:15:01  *** hsmiths has joined #bitcoin-core-dev
4862016-06-09T19:15:07  <cfields_> luke-jr: oh, good point...
4872016-06-09T19:15:13  <wumpus> it's *very easy* tocross compile for ARM
4882016-06-09T19:15:14  <jonasschnelli> I think NO_QT=1 for ARM/AARCH64 could be a start (even for "official binaries").
4892016-06-09T19:15:20  <wumpus> with the depends system
4902016-06-09T19:15:24  <wumpus> jonasschnelli: yes
4912016-06-09T19:15:28  <cfields_> the gitian-debug PR turns on debug symbols, so gitian mem requirement is bumped after that.
4922016-06-09T19:15:37  <gmaxwell> wumpus: a lot of people using rpi2 like systems do not have another linux host.
4932016-06-09T19:15:42  <luke-jr> wumpus: that builds static binaries, which is wasteful on RAM
4942016-06-09T19:15:44  <jonasschnelli> Also ARM is used more and more for GUI systems.
4952016-06-09T19:15:50  <jeremyrubin> can autogen.sh be made faster?
4962016-06-09T19:16:01  <wumpus> jeremyrubin: no
4972016-06-09T19:16:15  <wumpus> not by us, at least
4982016-06-09T19:16:15  <BakSAj> ok, thanks for explaining.. personally i had no trouble compiling 0.12.1 on rpi 3, was afraid that minimum requirements will raise with future releases
4992016-06-09T19:16:32  <jonasschnelli> luke-jr: if you want to run bitcoind on a RiP (or similar) static builds are fine. Mostly you don't have tons of other tools that could share libraries installed.
5002016-06-09T19:16:32  <BakSAj> since suprisingly many nodes run on rpi
5012016-06-09T19:16:44  <jeremyrubin> wumpus: maybe the one thing that is fixed by a faster disk
5022016-06-09T19:16:50  <luke-jr> jonasschnelli: I'm thinking more of Bitcoin-Qt
5032016-06-09T19:16:59  <cfields_> jonasschnelli: as qt's gui plugin situation improves, we may be able to move back to the shared-qt builds
5042016-06-09T19:17:05  <wumpus> I'm sure minimum requirements will raise with future releases, that's just the way things are, we'll try to raise them not too much though
5052016-06-09T19:17:11  <MarcoFalke> jonasschnelli: I think we already have notes on how to corss compile to arm?
5062016-06-09T19:17:13  <jonasschnelli> Agree. Static linking qt is not ideal. But lets don't roll this up again.
5072016-06-09T19:17:14  <MarcoFalke> https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#arm-cross-compilation
5082016-06-09T19:17:23  <btcdrak> oh meeting
5092016-06-09T19:17:35  <jonasschnelli> MarcoFalke: notes, yes. But it should be included in our release builds (gitian)
5102016-06-09T19:17:42  <MarcoFalke> jup, agree
5112016-06-09T19:17:46  <cfields_> jonasschnelli: sorry, i meant that directly in the context of shipping arm+gui binaries
5122016-06-09T19:17:56  <luke-jr> jonasschnelli: for now, people just compile natively to avoid static, so suggesting cross-compile isn't a real option
5132016-06-09T19:18:06  <wumpus> jeremyrubin: I'm not sure. I have no idea what autogen.sh would be spending time on. But it seems more a GNU problem thatn a bitcoin core problem :)
5142016-06-09T19:18:09  * gmaxwell looks forward to arm (+gui) binaries in the sometime future.
5152016-06-09T19:18:23  <wumpus> jeremyrubin: I'm surprised it's autogen.sh taking a lot of time not configure, which has this huge list of scripts to execute for probing
5162016-06-09T19:18:48  * luke-jr fully intends to use an ARM system with Core(Knots) as his hot wallet in some months.
5172016-06-09T19:18:50  <cfields_> jeremyrubin: you can use a quicker shell for autogen. IIRC dash vs. bash shaves a few seconds off
5182016-06-09T19:19:15  <wumpus> well arm non-GUI binaries would already be a great step forward, one step at a tme
5192016-06-09T19:19:15  <luke-jr> autogen.sh isn't even part of building; it's a developer tool
5202016-06-09T19:19:17  <cfields_> wumpus: ah, as a feature-freeze request: ok to plan on arm bins (without gui) for 0.13 ?
5212016-06-09T19:19:27  <luke-jr> if you're running autogen.sh, that means you're running from git, and you shouldn't do that
5222016-06-09T19:19:30  <cfields_> i can try to have that done today
5232016-06-09T19:19:30  <jonasschnelli> cfields_: ack, +1
5242016-06-09T19:19:33  <wumpus> I think arm gui would be prett much a per-distro afair
5252016-06-09T19:19:36  <wumpus> cfields_: sure!
5262016-06-09T19:19:37  <luke-jr> cfields_: +1
5272016-06-09T19:19:39  <jeremyrubin> luke-jr: are we making build faster for developers or for users?
5282016-06-09T19:19:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5292016-06-09T19:19:45  <gmaxwell> +1
5302016-06-09T19:19:47  <cfields_> ok
5312016-06-09T19:20:06  <luke-jr> jeremyrubin: I think the concern is "ability to build" rather than "speed to build"
5322016-06-09T19:20:11  <gmaxwell> jeremyrubin: users shouldn't need to run autogen-- if they get the source tarballs we have, it should already be autogenned.
5332016-06-09T19:20:26  <cfields_> ^^
5342016-06-09T19:20:36  <BakSAj> cool, rpi fans will love you :-)
5352016-06-09T19:20:44  <wumpus> but the people actually doing a lot of builds are developers, only they would care about a few more/less seconds in the build scripting
5362016-06-09T19:20:50  *** Arnavion has quit IRC
5372016-06-09T19:20:57  <BakSAj> next step - run full node on cell phone :-)
5382016-06-09T19:21:01  <jeremyrubin> wumpus: ++
5392016-06-09T19:21:11  <luke-jr> BakSAj: I believe a number of people have done this.
5402016-06-09T19:21:18  <wumpus> BakSAj: people are doing that actually, that's one of the motivations for the ARM binaries
5412016-06-09T19:21:28  <BakSAj> lol ok
5422016-06-09T19:21:28  <luke-jr> next step is therefore to support SPV mode when bandwidth is expensive ;)
5432016-06-09T19:21:30  <gmaxwell> BakSAj: abcore, it works fine.
5442016-06-09T19:21:39  <jonasschnelli> luke-jr: +1
5452016-06-09T19:21:41  <luke-jr> but that's post-0.13 IMO
5462016-06-09T19:21:45  <wumpus> absolutely
5472016-06-09T19:22:22  <wumpus> in any case it's too late to start on anything new for 0.13, for that we have to consider which of the current pulls can go in
5482016-06-09T19:22:47  <luke-jr> can we get in [8-bit] key generation type?
5492016-06-09T19:23:32  <jonasschnelli> 32bit!
5502016-06-09T19:23:41  <jonasschnelli> You can provide a migration patch for Knots
5512016-06-09T19:23:52  <jonasschnelli> Isn't that trivial?
5522016-06-09T19:23:53  <BakSAj> will 0.13 contain just segwit code or actual softfork also? tnx
5532016-06-09T19:24:03  <jonasschnelli> SW SF can be 0.13.1
5542016-06-09T19:24:17  <jonasschnelli> SW are mostly not coupled with major releases
5552016-06-09T19:24:21  <jeremyrubin> I think that 0.13.1 will be worse for upgrade times
5562016-06-09T19:24:24  <wumpus> SW should be released in a minor release
5572016-06-09T19:24:26  <jeremyrubin> does anyone have data on that
5582016-06-09T19:24:29  <gmaxwell> BakSAj: major releases do not contain network consensus changes.
5592016-06-09T19:24:31  <sdaftuar> do we think segwit is going in to 0.13?
5602016-06-09T19:24:42  <sdaftuar> (without activation scheduled)
5612016-06-09T19:24:52  <jeremyrubin> wumpus: isn't it a major change?
5622016-06-09T19:24:52  <petertodd> sdaftuar: you mean, 0.13.0, or 0.13.x>0?
5632016-06-09T19:24:53  <luke-jr> jonasschnelli: migration is not very practical if 32-bit uses the same version number in Core as 8-bit in Knots already is
5642016-06-09T19:24:57  <sdaftuar> 0.13.0
5652016-06-09T19:24:59  <btcdrak> sdaftuar: yes, sipa wanted to merge it soon to master
5662016-06-09T19:25:01  <CodeShark> what happened to doing it in 0.12.x?
5672016-06-09T19:25:02  <luke-jr> jonasschnelli: maybe this needs more off-meeting discussion then
5682016-06-09T19:25:08  <btcdrak> (without mainnet defs)
5692016-06-09T19:25:08  <jonasschnelli> luke-jr: agree
5702016-06-09T19:25:15  <sdaftuar> seems like there are still open issues, and no ACKs
5712016-06-09T19:25:16  <wumpus> jeremyrubin: well from what I've heard minor releases are usually more popular, especialy .1, as some people don't trust .0  :)
5722016-06-09T19:25:26  <gmaxwell> CodeShark: nothing, there are confused questions.
5732016-06-09T19:25:27  <sdaftuar> so i don't see how it's going to be merged in the next week
5742016-06-09T19:25:48  <btcdrak> sdaftuar: why?
5752016-06-09T19:25:48  <luke-jr> jeremyrubin: segwit is a major change to Bitcoin - not Bitcoin Core.
5762016-06-09T19:25:51  * jonasschnelli thinks sipa is allowed to merge without ACK
5772016-06-09T19:25:52  <gmaxwell> jeremyrubin: we have a long thought out published spec on this, please don't divert the meeting to debating it. I can direct you to the information after the meeting.
5782016-06-09T19:26:04  *** Arnavion has joined #bitcoin-core-dev
5792016-06-09T19:26:07  <jeremyrubin> wumpus: interesting... I do tend to not upgrade any of my software major versions for 6 months. diversion over
5802016-06-09T19:26:27  <sipa> well merging segwit without fork enabled is not in contradiction with "not doing a consensus change in a major release"
5812016-06-09T19:26:36  <jonasschnelli> agree
5822016-06-09T19:26:41  <CodeShark> right
5832016-06-09T19:26:47  <wumpus> sure
5842016-06-09T19:26:49  <luke-jr> no objections to merging segwit code without activation
5852016-06-09T19:26:50  <jonasschnelli> Also, getting ACK for SW is extremly hard. Nobody wants to take the risk.
5862016-06-09T19:26:51  <gmaxwell> sure, there are code motion logistics that favor merging it.
5872016-06-09T19:26:51  <sdaftuar> to be clear i'm not talking about any kind of release policy, just code-readiness / review
5882016-06-09T19:26:54  <btcdrak> jeremyrubin: see out lifecycle docs https://github.com/bitcoin-core/bitcoincore.org/pull/179
5892016-06-09T19:27:07  <btcdrak> s/out/our/
5902016-06-09T19:27:08  *** Chris_St1 has joined #bitcoin-core-dev
5912016-06-09T19:27:57  <wumpus> so is SW ready for merge (into master/0.13)?
5922016-06-09T19:28:06  <sdaftuar> it has no ACKs, and some open issues to be resolved
5932016-06-09T19:28:31  <wumpus> ok
5942016-06-09T19:28:33  <jonasschnelli> major open issue? Or more nitish stuff?
5952016-06-09T19:28:35  <sdaftuar> minor
5962016-06-09T19:28:49  <wumpus> if it is not critical it can also be fixed in a later pull
5972016-06-09T19:28:51  <sdaftuar> but bugs, not style nits
5982016-06-09T19:29:09  <wumpus> oh known bugs should be addressed in the pull itself
5992016-06-09T19:29:21  <sipa> i think everything will be addressed in my next batch of patches
6002016-06-09T19:29:29  <btcdrak> sipa: great!
6012016-06-09T19:29:41  *** Chris_Stewart_5 has quit IRC
6022016-06-09T19:29:42  <gmaxwell> should people be acking the reviwew PR or the rebase/reorg?
6032016-06-09T19:29:42  <luke-jr> sipa: does that include expanding 2nd push to 75 bytes max? or is that still an open thing?
6042016-06-09T19:30:19  <sipa> luke-jr: this is the place to ask, and i would say no, there is no point
6052016-06-09T19:30:27  <sipa> but perhaps others have another opinion
6062016-06-09T19:30:32  <btcdrak> luke-jr: I didnt understand where 75 came from.
6072016-06-09T19:30:42  <sipa> btcdrak: up to 75 is easy
6082016-06-09T19:30:43  <luke-jr> btcdrak: largest size that wouldn't require additional testing
6092016-06-09T19:31:18  <gmaxwell> has to do with the opcode types changing for different sizes of push.
6102016-06-09T19:31:47  <sipa> so, opinions?
6112016-06-09T19:31:51  <btcdrak> 32->40->75 seems like a big jump
6122016-06-09T19:32:06  <gmaxwell> btcdrak: from the code perspective they're all the same.
6132016-06-09T19:32:19  <luke-jr> my opinion is there is no point limiting it (beyond the impl/test cost of >75), and such limits could very well prevent future softforks
6142016-06-09T19:32:49  <luke-jr> more tolerant enables softforks, so should be preferred over useless limits
6152016-06-09T19:33:08  <gmaxwell> Luke-jr's argument has merit in my opinion-- it can be reduced later, but I don't have a strongly held view. I'm not aware of a DOS attack risk created by not having the stricter limit earlier.
6162016-06-09T19:33:44  <gmaxwell> (of course, IsStandardness should be strictly limited)
6172016-06-09T19:33:44  <luke-jr> to expand the limit later requires a hardfork
6182016-06-09T19:34:00  <luke-jr> yes, node policy should reject any unknown witnesses period
6192016-06-09T19:34:23  <CodeShark> ok, I think luke-jr has a strong argument
6202016-06-09T19:34:27  <btcdrak> that makes sense
6212016-06-09T19:34:47  <sipa> there should be no need for more than 256-bit hash + some versioning metadata
6222016-06-09T19:35:14  <sipa> and setting it to more gives it the impression that there is
6232016-06-09T19:35:16  <petertodd> sipa: or, to be precise if there is that means Bitcoin is more broken than that
6242016-06-09T19:35:24  <sipa> petertodd: exactly
6252016-06-09T19:35:33  <jeremyrubin> luke-jr: in general I agree with keeping flexible, but do you have an example for sipa of why you'd want it?
6262016-06-09T19:35:36  <gmaxwell> The biggest harm I see is that allowing a larger size here does limit the ability to make utxo entries limited in size in the future, potentially. But it could be done later.  It also enabled policy bypass to abuse the utxo set for data storage, though it's not much of an issue there.
6272016-06-09T19:35:42  <luke-jr> sipa: it doesn't need to give that impression. I don't think we need to predict the future too much here.
6282016-06-09T19:36:12  *** kxie has joined #bitcoin-core-dev
6292016-06-09T19:36:23  <gmaxwell> luke-jr: for example, if you were to argue that we might someday need 512 bit hashes, I'd agree-- but then I'd point out that in that case there would need to be a hardfork to change all the other things.
6302016-06-09T19:36:26  <sipa> i'd rather not rely on isstandardness when reasoning about longer term future
6312016-06-09T19:37:01  <petertodd> in a MR implementation I did, it turned out to be very advantageous if the things in the MMR were fixed side forperformance
6322016-06-09T19:37:13  <luke-jr> jeremyrubin: any case where we would need indicators in the UTXO set itself; but I don't have a concrete example at this time
6332016-06-09T19:37:19  <gmaxwell> Also, not allowing it in SW doesn't preclude it in the future, you'd just need to use a different version type signaling in that case.
6342016-06-09T19:37:35  <luke-jr> for example, we could have added the maturity stuff in the 2nd push if we didn't have nSequence
6352016-06-09T19:37:43  <gmaxwell> Yes, I really wish UTXO entries were fixed size.
6362016-06-09T19:37:53  <sdaftuar> sipa: isn't there a strong deterrent against abuse, because your funds are anyone-can-spend to older nodes?
6372016-06-09T19:37:56  *** _anthony_ has joined #bitcoin-core-dev
6382016-06-09T19:37:59  <luke-jr> gmaxwell: you'd need a new commitment entirely
6392016-06-09T19:38:13  <luke-jr> gmaxwell: in addition to the current one
6402016-06-09T19:38:24  <sipa> sdaftuar: there is no rule preventing 0-value outputs
6412016-06-09T19:38:34  <_anthony_> just use the private key of a payment address to store the 256 bits
6422016-06-09T19:38:37  <sdaftuar> ah, good point
6432016-06-09T19:38:41  <sipa> (if you ignore relay polify)
6442016-06-09T19:39:09  <luke-jr> abuse is already possible. this doesn't make it worse. if in the future we make it better, we can limit this at the same time
6452016-06-09T19:39:28  <gmaxwell> if one assumes a fixed size utxo entry, luke's suggestion basically doubles the utxo set size.
6462016-06-09T19:39:32  <petertodd> sipa: though, for that specific case I find it ahrd to think of a abuse use-case that'd care about that, given you could screw up the usse-case by spending those outputs
6472016-06-09T19:39:51  <luke-jr> gmaxwell: we can't assume that today, and if we softfork an assumption tomorrow, we can limit this then also
6482016-06-09T19:40:44  <gmaxwell> We've probably spent more time discussing it now than the decision is worth.
6492016-06-09T19:41:14  <wumpus> ok, next topic?
6502016-06-09T19:41:24  <wumpus> #topic compact block testing
6512016-06-09T19:41:27  <luke-jr> so we use 75 for now, and discuss reducing it later?
6522016-06-09T19:41:33  <gmaxwell> (and that time could be better spent reviewing/testing more corner cases... lets continue discussion elsewhere I guess)
6532016-06-09T19:42:34  <btcdrak> so compact blocks...
6542016-06-09T19:42:41  <gmaxwell> OK. So there are some number of nodes running compactblocks on the public network.. I have 12 peers at the moment, matt has another half dozen in the new relay network that I'm not connected to.
6552016-06-09T19:42:52  <gmaxwell> Things seem to be working well there, instagibbs has posted some charts.
6562016-06-09T19:42:56  <wumpus> I've been running a compact blocks node for a few days, no crashes to report :)
6572016-06-09T19:43:16  <instagibbs> yes i love charts http://imgur.com/iq2lRGl
6582016-06-09T19:43:26  <gmaxwell> I've been conducting some new tests with a network of nodes with a modified version of compact blocks that reduces the hash size to 16 bits in order to test corner cases around collisions.
6592016-06-09T19:43:27  <instagibbs> blue stuff is in kB fwiw
6602016-06-09T19:43:30  <wumpus> lots of succesfully reconstructed blocks
6612016-06-09T19:43:31  <luke-jr> (ugh, Travis is apparently "detecting abuse" on the Bitcoin code itself, so every clone will be affected?)
6622016-06-09T19:43:36  <btcdrak> Two large mining pools have also been running them, connected to their pool nodes for block source, one is behind the GFW
6632016-06-09T19:43:40  <instagibbs> blue dot == 0 fetched txns
6642016-06-09T19:44:20  <gmaxwell> I found a few bugs, which matt has fixed but not pushed to the PR yet.  Bugs were things like if the cmptblk message was rubbish, it would wait for the peer to timeout before requesting the block normally.
6652016-06-09T19:44:48  <instagibbs> I intended to review the PR then got ill. Still planning to review.
6662016-06-09T19:44:57  <gmaxwell> I think this particular testing technique of modifying the code to make rare cases common is pretty effective and will result in good testing of most of those corner cases.
6672016-06-09T19:45:05  <wumpus> luke-jr: (offtopic) that started happening with the parallel testing I think
6682016-06-09T19:45:08  <sipa> gmaxwell: agree
6692016-06-09T19:45:18  *** mn3monic has joined #bitcoin-core-dev
6702016-06-09T19:45:19  <MarcoFalke> luke-jr: Shoot them an email
6712016-06-09T19:45:39  <gmaxwell> The compact block code is now rebased on top of the sharedptr work, so it's now a fair bit simpler.
6722016-06-09T19:45:54  <luke-jr> MarcoFalke: I have. My concern is more than just whitelisting individual repos though. (Let's continue discussion after the meeting)
6732016-06-09T19:45:54  <instagibbs> gmaxwell, matt's rebase is on that now?
6742016-06-09T19:45:59  <instagibbs> err pr is rebased*
6752016-06-09T19:46:01  <gmaxwell> instagibbs: yes.
6762016-06-09T19:46:12  <gmaxwell> matt's PR is on master as of last night.
6772016-06-09T19:46:20  <sipa> yes, forget my branch
6782016-06-09T19:46:34  <CodeShark> what PR#?
6792016-06-09T19:46:48  <instagibbs> #8086
6802016-06-09T19:47:07  <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8068
6812016-06-09T19:47:15  <cfields_> has there been discussion of a servicebit for compact blocks? Now that we have the dns seed prefixes, that would allow for very quick discovery
6822016-06-09T19:47:23  <gmaxwell> Based on the issues I found, probably the interaction with block fetching logic needs more review.
6832016-06-09T19:47:37  <btcdrak> cfields_: if it deploys in 0.13 it wont be necessary
6842016-06-09T19:47:43  <gmaxwell> cfields_: IMO I don't see a need to preferrentially peer. I expect support to become sufficiently ubiquitious fast enough.
6852016-06-09T19:47:46  <wumpus> #action forget sipa's compact blocks branch and use thebluematt's PR
6862016-06-09T19:48:10  *** adiabat has joined #bitcoin-core-dev
6872016-06-09T19:48:10  <gmaxwell> it's not something that anyone has a reason to not support, except for just not having implemented it.
6882016-06-09T19:48:13  <btcdrak> hrm, action point is to forget :)
6892016-06-09T19:48:16  <sipa> cfields_: the argument brought up before was tgat service bits should be used for critical
6902016-06-09T19:48:28  <sipa> for critically required services
6912016-06-09T19:48:41  <gmaxwell> like your node won't work right if you don't have peers with the right services.
6922016-06-09T19:48:46  <wumpus> btcdrak: yeah for people testing the code to use the other branch
6932016-06-09T19:48:49  <luke-jr> makes sense
6942016-06-09T19:48:55  <sipa> and the only time when yoi critically need a compact block peer is as a miner, who should be curating their connections anyway
6952016-06-09T19:48:59  <jeremyrubin> in #8086 where is the salt generated btw?
6962016-06-09T19:49:09  <cfields_> hmm, fair enough
6972016-06-09T19:49:35  <wumpus> and miners can look at the protocol version to see if their peer supports compact blocks?
6982016-06-09T19:49:48  <gmaxwell> jeremyrubin:
6992016-06-09T19:49:49  <gmaxwell> +CBlockHeaderAndShortTxIDs::CBlockHeaderAndShortTxIDs(const CBlock& block) :
7002016-06-09T19:49:52  <gmaxwell> +        nonce(GetRand(std::numeric_limits<uint64_t>::max())),
7012016-06-09T19:50:12  <luke-jr> wumpus: I don't think we can assume a specific protocol version supports it
7022016-06-09T19:50:27  <luke-jr> if we have a future version with better compact blocks, we may want to drop support for the current one
7032016-06-09T19:50:28  <jeremyrubin> thanks
7042016-06-09T19:50:29  <Lightsword> I think using service bits is a good idea, mainually curtailing connections is very time consuming and raisies the barrier to entry for mining
7052016-06-09T19:50:32  <gmaxwell> wumpus: you can do the handshake.
7062016-06-09T19:50:36  <sipa> wumpus: no, miners should connect to a known peer that supports it
7072016-06-09T19:50:41  <luke-jr> Lightsword: neither are likely to be necessary
7082016-06-09T19:51:09  <wumpus> gmaxwell: right
7092016-06-09T19:51:22  <gmaxwell> Please, service bits are basically forever and we only have 32 of them, I expect the window between some and nearly all use of this to only be a few months to a year long.
7102016-06-09T19:51:24  <sipa> wumpus: because just supporting compact blocks is not enough, they also need to have good uptime and reliability  latency, bandwodth, ...
7112016-06-09T19:51:29  <sipa> gmaxwell: we have 64
7122016-06-09T19:51:41  <gmaxwell> Same difference. (really? hmph!)
7132016-06-09T19:51:46  <jeremyrubin> I would suggest either writing the entropy to a file once or having it settable in a config file
7142016-06-09T19:51:48  <wumpus> we should have a concept of temporary service bits, like for the versionbits
7152016-06-09T19:52:05  <sipa> jeremyrubin: that's a good idea but orthogonal
7162016-06-09T19:52:11  <luke-jr> as long as nobody relies on service bits, they can be temporary
7172016-06-09T19:52:16  <btcdrak> we dont need preferential peering for compact blocks. It wont take long for wide network support.
7182016-06-09T19:52:17  <luke-jr> ie, use them as hints
7192016-06-09T19:52:23  <cfields_> don't we have a range designated for playground?
7202016-06-09T19:52:27  <luke-jr> yes
7212016-06-09T19:52:31  <jeremyrubin> sipa: (yes, sorry, just reviewing it now)
7222016-06-09T19:52:34  <Lightsword> a service bit to indicate a secondary service bit field needs to be used?
7232016-06-09T19:52:47  <luke-jr> one of which is currently getting full-RBF temporary usage
7242016-06-09T19:52:50  <wumpus> Lightsword: that would completely make it unuseful for preferential peering
7252016-06-09T19:52:50  <gmaxwell> jeremyrubin: uh. I'm not sure what you're talking about there... the nonces are per block and should not be predictable.
7262016-06-09T19:53:12  <wumpus> Lightsword: (as neither addr messages nor the DNS seeds would be aware of the secondary mechanism)
7272016-06-09T19:53:14  <gmaxwell> statically configuring it would be broken.
7282016-06-09T19:53:29  <wumpus> why would you want to fix the entropy statically?
7292016-06-09T19:53:33  <instagibbs> gmaxwell, perhaps setting cmpctblock as a tie-breaker for keeping connection?
7302016-06-09T19:53:41  <gmaxwell> Okay, in any case, I think thats all I've got there.
7312016-06-09T19:53:50  <btcdrak> ding ding, we have 7 mins remaining
7322016-06-09T19:53:52  <instagibbs> well, I guess "he sent me blocks fast" is/will be one, same thing
7332016-06-09T19:53:54  <cfields_> static entropy is much easier to test :p
7342016-06-09T19:53:54  <gmaxwell> instagibbs: sounds like a fine additional ranker in the connection management stuff.
7352016-06-09T19:54:05  <wumpus> instagibbs: +1
7362016-06-09T19:54:06  <sipa> indeed
7372016-06-09T19:54:13  <jeremyrubin> cfields_: yep
7382016-06-09T19:54:16  <gmaxwell> instagibbs: though yea, the 'most recent blocks' probably mostly covers it.
7392016-06-09T19:54:35  <BakSAj> which version are compact blocks planned for?
7402016-06-09T19:54:40  <sipa> related to that: please review gmaxwell's patch for adding fast blkck and tx relayers for not evicted
7412016-06-09T19:54:41  <jeremyrubin> gmaxwell: it doesn't harm security so long as it's kept secret from peers
7422016-06-09T19:54:50  <btcdrak> BakSAj: 0.13.0
7432016-06-09T19:54:51  <instagibbs> sipa, which number
7442016-06-09T19:54:59  <sipa> instagibbs: sec
7452016-06-09T19:55:04  <jeremyrubin> gmaxwell: nvm -- forgot you have to send it?
7462016-06-09T19:55:07  <gmaxwell> jeremyrubin: the nonce used for compact blocks must be sent to peers or they can't recover the block.
7472016-06-09T19:55:12  <petertodd> wumpus: we do have temporary service bits
7482016-06-09T19:55:19  <BakSAj> btcdrak: thanks!
7492016-06-09T19:55:33  <sdaftuar> gmaxwell: thoughts on #7598/#7600? you said above that you'd started review
7502016-06-09T19:55:40  <Lightsword> isn’t it likely we’re going to overhaul the p2p protocol by the time we run out of service bits?
7512016-06-09T19:55:45  <sdaftuar> i still think it should be a priority to get those PRs merged for 0.13.0...
7522016-06-09T19:55:47  <instagibbs> I don't think connecting to cmpctblock peers will be hard unless we get sybil'd by AWS forks
7532016-06-09T19:55:57  <gmaxwell> sdaftuar: I like them and will ACK soon, once I come up with a useful way to test.
7542016-06-09T19:56:08  <sipa> sdaftuar: me too, i started revieweing but got caught up on other things
7552016-06-09T19:56:09  <gmaxwell> sdaftuar: I agree.
7562016-06-09T19:56:24  <sipa> Lightsword: maybe
7572016-06-09T19:56:41  <sipa> Lightsword: it's often hard to predict how long protocols live
7582016-06-09T19:56:47  <gmaxwell> I think important big PRs I'd really like to have in 0.13 are SW, Compact blocks, CFPF related, and BIP32.
7592016-06-09T19:56:51  <sdaftuar> gmaxwell: ok, let me know if you want help with the sim environment i shared with you, i think that makes it easy
7602016-06-09T19:56:54  <instagibbs> sipa, https://github.com/bitcoin/bitcoin/pull/8084
7612016-06-09T19:56:59  <gmaxwell> There are a bunch of small things (including all of mine)
7622016-06-09T19:57:16  <sipa> instagibbs: that one, thanks
7632016-06-09T19:57:45  <cfields_> off-topic: quickly, before I forget. I'll be headed out of town on Friday and only reachable for emergencies for ~10 days. If anyone needs anything from me before I go, speak up now :)
7642016-06-09T19:57:58  <sipa> cfields_: for how long?
7652016-06-09T19:58:03  <sipa> a month?
7662016-06-09T19:58:04  *** supasonic has joined #bitcoin-core-dev
7672016-06-09T19:58:04  <Lightsword> maybe we should just have a service bit for flagging fast relay nodes/miners in general for preferential peering rather than making it flag compact blocks specifically
7682016-06-09T19:58:17  <wumpus> only features have to be in before the feature freeze, anything that can be interpreted as bug fixes or anti-DoS measures doesn't have the deadline of next week
7692016-06-09T19:58:20  <wumpus> also SW is special
7702016-06-09T19:58:30  <sipa> Lightsword: we should also have an evil bit that abusive nodes should set
7712016-06-09T19:58:45  <gmaxwell> Lightsword: "the I am a DOS attack master node, please connect to me" flag?
7722016-06-09T19:58:48  <Chris_St1> brilliant
7732016-06-09T19:58:51  <btcdrak> sipa: ^.^
7742016-06-09T19:58:56  <wumpus> as we discussed above it's a consensus change so it can't be enabled in a major release first
7752016-06-09T19:59:04  <cfields_> sipa: for ~10 days. I'll be gone for a month total, but working for the last few weeks.
7762016-06-09T19:59:10  <sipa> i see
7772016-06-09T19:59:23  <wumpus> he announced that well in advance
7782016-06-09T19:59:30  <gmaxwell> lynch him!
7792016-06-09T19:59:33  <luke-jr> cfields_: review of https://github.com/bitcoin/bitcoin/pull/5872 ? :D
7802016-06-09T19:59:36  <gmaxwell> oh in advance, okay.
7812016-06-09T19:59:38  <gmaxwell> :P
7822016-06-09T19:59:47  <BakSAj> :-)
7832016-06-09T19:59:54  <cfields_> luke-jr: added to the list, thanks
7842016-06-09T20:00:01  <sipa> *ding dong*
7852016-06-09T20:00:03  <instagibbs> wumpus, all-but-SF SW would be nice
7862016-06-09T20:00:05  <wumpus> #endmeeting
7872016-06-09T20:00:06  <lightningbot> Meeting ended Thu Jun  9 20:00:05 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7882016-06-09T20:00:06  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-09-19.00.html
7892016-06-09T20:00:06  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-09-19.00.txt
7902016-06-09T20:00:06  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-09-19.00.log.html
7912016-06-09T20:00:18  <luke-jr> FWIW, I will also be travelling June 20th-early July (but probably semi-available and working)
7922016-06-09T20:00:24  <sipa> thanks all, this was an interesting meeting
7932016-06-09T20:00:29  <cfields_> along the same lines, review plea for #8128
7942016-06-09T20:00:57  <wumpus> instagibbs: I know, just wanted the situation around SW to be clear for people reading the logs
7952016-06-09T20:01:04  *** cryptapus has quit IRC
7962016-06-09T20:01:05  <instagibbs> +1
7972016-06-09T20:01:35  <BakSAj> btw, is there a rough estimate when 0.13.1 may come?
7982016-06-09T20:01:47  <BakSAj> or version with segwit sf
7992016-06-09T20:01:48  <instagibbs> Probably when a certain Softfork is ready....
8002016-06-09T20:01:49  <gmaxwell> yea, my comments were assuming that it would be released in 0.12.x first, but parallel included in master.
8012016-06-09T20:01:53  <luke-jr> BakSAj: "when it's ready"
8022016-06-09T20:01:55  <btcdrak> BakSAj: SW will be released in 0.12.x
8032016-06-09T20:01:57  <gmaxwell> BakSAj: 0.12.x
8042016-06-09T20:02:05  <cfields_> luke-jr: btw, i believe I found your issue wrt out-of-tree build and chowning
8052016-06-09T20:02:23  <gmaxwell> BakSAj: development operats long ahead of public release, we're often working up to a year ahead of whats released.
8062016-06-09T20:02:32  <cfields_> luke-jr: we rely on "git diff" to update the index, but it can't if .git is read-only.
8072016-06-09T20:02:48  <luke-jr> aha
8082016-06-09T20:02:52  <BakSAj> uf little confused
8092016-06-09T20:03:06  <BakSAj> now you release 0.13.0 with segwit code
8102016-06-09T20:03:11  <gmaxwell> the interest in merging SW in master mostly comes from the fact that it isn't merged is holding people back from some changes because they don't want to make the SW rebases more complex.
8112016-06-09T20:03:14  <btcdrak> gmaxwell: BlueMatt just pushed the fixes to #8068 compact blocks
8122016-06-09T20:03:18  <BakSAj> but then 0.12.2 with code and activation comes
8132016-06-09T20:03:22  <instagibbs> BakSAj, ok, so 0.13 isn't out. That means if SW is released, it goes into 0.12.2
8142016-06-09T20:03:29  <instagibbs> then will still show up in 0.13
8152016-06-09T20:03:56  <gmaxwell> For example, I wrote a patch to remove three loops over all transactions in accetblock... then shelved it, because its just a tiny speedup, and would conflict with the SW patches.
8162016-06-09T20:04:07  <BakSAj> wont this bring confusion whether to run 0.12.2 or 0.13 ?
8172016-06-09T20:04:17  *** molz has joined #bitcoin-core-dev
8182016-06-09T20:04:37  <instagibbs> btcdrak, sigh, my block hit rate is going to poop :(
8192016-06-09T20:04:38  <cfields_> luke-jr: could you verify that your process works if you add a "chown -R user:user" after the "chown -R root:root ." ?
8202016-06-09T20:04:47  <sipa> BakSAj: what os are you running?
8212016-06-09T20:04:51  <luke-jr> BakSAj: there is no one version everyone must run
8222016-06-09T20:05:01  <gmaxwell> instagibbs: start up the relay node client for a bit to prefill your mempool.
8232016-06-09T20:05:07  <BakSAj> sipa ?
8242016-06-09T20:05:08  <luke-jr> cfields_: eh, that sounds like a noop?
8252016-06-09T20:05:15  <instagibbs> gmaxwell, hmm ok pretty sure I have that installed
8262016-06-09T20:05:18  <btcdrak> instagibbs: well you could spin up a new node instead...
8272016-06-09T20:05:19  <sipa> BakSAj: what version of your os are you running.
8282016-06-09T20:05:24  <cfields_> luke-jr: er, sorry...
8292016-06-09T20:05:34  <cfields_> luke-jr: "chown -R user:user .git"
8302016-06-09T20:05:40  <BakSAj> sipa: for full node?
8312016-06-09T20:05:52  <btcdrak> instagibbs: rsync your chainstate etc.
8322016-06-09T20:05:55  <sipa> BakSAj: whatever, i'm trying to make an analogu
8332016-06-09T20:06:04  *** moli has quit IRC
8342016-06-09T20:06:07  <BakSAj> lol, win10
8352016-06-09T20:06:10  <sipa> BakSAj: you run 0.12.x to get more stable/tested code
8362016-06-09T20:06:24  <sipa> BakSAj: you run 0.13.0 to get the latest and greates
8372016-06-09T20:06:39  <sipa> and segwit is independent of that
8382016-06-09T20:06:50  <sipa> it will be released in a point update to both
8392016-06-09T20:07:09  <gmaxwell> SW is not a client feature, it's part of the network protocol.
8402016-06-09T20:07:21  <BakSAj> i understand how sw livecycle usually works, but im confused about thing that 0.13.0 wont have SF active
8412016-06-09T20:07:43  <luke-jr> BakSAj: if 0.13.0 is released before SW, it won't have SW; if it is released after SW, it won't remove SW
8422016-06-09T20:07:59  <gmaxwell> BakSAj: it may or may not, but it won't be the first release with it. 0.12.x (likely 0.12.2) will.
8432016-06-09T20:07:59  <luke-jr> SW introduction is independent from Core's release cycle
8442016-06-09T20:08:03  <sipa> BakSAj: because in order to enable SW, we need many code changes
8452016-06-09T20:08:29  <sipa> BakSAj: it's a pita to keep maintaining those in parallel when we know the code worms
8462016-06-09T20:08:32  <sipa> *works
8472016-06-09T20:08:46  <BakSAj> ah
8482016-06-09T20:08:51  <luke-jr> BakSAj: if 0.12.1 and 0.13.0 are released before SW, then SW will be added in 0.13.1 and 0.12.2; if only 0.12.1 is released before SW, then it will be added to 0.12.2, and the later 0.13.0 will also have it still
8492016-06-09T20:09:01  <BakSAj> i had bad assumption about 0.13.0
8502016-06-09T20:09:07  <BakSAj> guys, thanks for explanation
8512016-06-09T20:09:19  <gmaxwell> btcdrak: in the future, please wait for travis to finish before nagging people to update. :)
8522016-06-09T20:09:33  <BakSAj> got it now
8532016-06-09T20:10:20  *** bsm1175322 has joined #bitcoin-core-dev
8542016-06-09T20:10:32  <BakSAj> https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
8552016-06-09T20:10:38  <BakSAj> mayb needs little refurbish
8562016-06-09T20:10:43  <BakSAj> dates and staff
8572016-06-09T20:11:17  *** bsm1175321 has quit IRC
8582016-06-09T20:11:24  <instagibbs> BakSAj, the section on the site about life cycle needs a refurb
8592016-06-09T20:11:34  <BakSAj> if i can speak for little educated public :-) i would prefer complex btc roadmap
8602016-06-09T20:11:49  <BakSAj> not just capacity increase roadmap
8612016-06-09T20:12:52  <btcdrak> gmaxwell: noted
8622016-06-09T20:13:02  *** jtimon has quit IRC
8632016-06-09T20:15:07  *** moli has joined #bitcoin-core-dev
8642016-06-09T20:15:48  *** bsm1175322 has quit IRC
8652016-06-09T20:17:35  *** molz has quit IRC
8662016-06-09T20:19:53  *** spikey has joined #bitcoin-core-dev
8672016-06-09T20:23:51  *** spikeheadon has quit IRC
8682016-06-09T20:24:05  *** spikeheadon has joined #bitcoin-core-dev
8692016-06-09T20:25:41  *** spikey has quit IRC
8702016-06-09T20:30:01  *** ozanyurt has joined #bitcoin-core-dev
8712016-06-09T20:44:42  *** ebfull has quit IRC
8722016-06-09T20:46:27  *** BakSAj has quit IRC
8732016-06-09T20:50:03  <dgenr8> sipa: on .11.0 and .12.0 (I didn't try newer), after sendfrom "A", no subtraction from A is reflected in listaccounts or getbalance "A"
8742016-06-09T20:50:24  <dgenr8> sipa: it looks like there is no way query ledger entries like this (or those created by move) :/
8752016-06-09T20:51:30  <dgenr8> sipa: listunspent shows account A as an attribute of a utxo with address created by getnewaddress A.  sendfrom A should probably wipe that out ...  but that strays into trying to fix it
8762016-06-09T20:52:23  <sipa> dgenr8: receive accounts are a property of incoming payments, not utxos
8772016-06-09T20:52:50  <sipa> dgenr8: the fact that a send is not reflected in getbalance is a bug
8782016-06-09T20:53:18  <dgenr8> I guess was speaking loosely ... i mean it has a txid and a vout, and it is unspent :)
8792016-06-09T21:07:39  *** laurentmt has joined #bitcoin-core-dev
8802016-06-09T21:07:40  *** laurentmt has quit IRC
8812016-06-09T21:10:40  *** achow101 has quit IRC
8822016-06-09T21:11:54  *** Chris_St1 has quit IRC
8832016-06-09T21:13:00  *** Evel-Knievel has quit IRC
8842016-06-09T21:15:20  *** Evel-Knievel has joined #bitcoin-core-dev
8852016-06-09T21:23:42  *** achow101 has joined #bitcoin-core-dev
8862016-06-09T21:53:11  *** _anthony_ has quit IRC
8872016-06-09T22:14:00  <GitHub89> [bitcoin] MarcoFalke opened pull request #8185: [0.12.2] Various qa and test backports (0.12...Mf1606-qaBackports) https://github.com/bitcoin/bitcoin/pull/8185
8882016-06-09T22:27:48  *** Guyver2 has quit IRC
8892016-06-09T22:33:57  *** AaronvanW has quit IRC
8902016-06-09T22:50:43  <GitHub176> [bitcoin] MarcoFalke opened pull request #8186: [0.12.2] backport: getblockchaininfo: make bip9_softforks an object, not an array. (0.12...Mf1606-rpcBip9Backport) https://github.com/bitcoin/bitcoin/pull/8186
8912016-06-09T22:53:04  *** spikeheadon has quit IRC
8922016-06-09T22:56:14  *** zooko` has joined #bitcoin-core-dev
8932016-06-09T23:02:35  *** zooko` has quit IRC
8942016-06-09T23:03:52  *** zooko` has joined #bitcoin-core-dev
8952016-06-09T23:08:02  <GitHub153> [bitcoin] MarcoFalke opened pull request #8187: [WIP] [0.12.2] backport: [qa] Switch to py3 (0.12...Mf1606-qaPy3Backport) https://github.com/bitcoin/bitcoin/pull/8187
8962016-06-09T23:11:37  *** jtimon has joined #bitcoin-core-dev
8972016-06-09T23:40:25  *** MarcoFalke has left #bitcoin-core-dev
8982016-06-09T23:43:39  *** blur3d has joined #bitcoin-core-dev
8992016-06-09T23:49:55  *** ghtdak has quit IRC
9002016-06-09T23:51:04  *** skyraider has joined #bitcoin-core-dev
9012016-06-09T23:53:41  *** AaronvanW has joined #bitcoin-core-dev
9022016-06-09T23:53:58  *** AaronvanW has quit IRC
9032016-06-09T23:53:58  *** AaronvanW has joined #bitcoin-core-dev
9042016-06-09T23:59:52  *** zooko` has quit IRC