1 2016-06-09T00:09:43  *** TomMc has quit IRC
  2 2016-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
  3 2016-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.
  4 2016-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"?
  5 2016-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.
  6 2016-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.
  7 2016-06-09T00:28:31  *** blur3d has joined #bitcoin-core-dev
  8 2016-06-09T00:31:04  *** xiangfu has quit IRC
  9 2016-06-09T00:32:17  *** [b__b] has quit IRC
 10 2016-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"
 11 2016-06-09T00:33:21  *** murch has quit IRC
 12 2016-06-09T00:37:05  *** [b__b] has joined #bitcoin-core-dev
 13 2016-06-09T00:49:02  *** raedah has joined #bitcoin-core-dev
 14 2016-06-09T01:01:17  *** Ylbam has quit IRC
 15 2016-06-09T01:05:20  *** dermoth has quit IRC
 16 2016-06-09T01:05:59  *** dermoth has joined #bitcoin-core-dev
 17 2016-06-09T01:25:48  <gmaxwell> P2Pool is updated for CSV.
 18 2016-06-09T01:35:04  *** dermoth has quit IRC
 19 2016-06-09T01:35:31  <luke-jr> it needed updating?
 20 2016-06-09T01:35:47  <luke-jr> oh, because peers need to police each other
 21 2016-06-09T01:36:02  *** dermoth has joined #bitcoin-core-dev
 22 2016-06-09T01:45:01  *** [b__b] has quit IRC
 23 2016-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.
 24 2016-06-09T01:50:27  *** [b__b] has joined #bitcoin-core-dev
 25 2016-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
 26 2016-06-09T02:02:34  *** dgenr8 has quit IRC
 27 2016-06-09T02:02:59  *** dgenr8 has joined #bitcoin-core-dev
 28 2016-06-09T02:14:43  *** JackH has joined #bitcoin-core-dev
 29 2016-06-09T02:17:30  *** Chris_Stewart_5 has quit IRC
 30 2016-06-09T02:21:40  *** justanotheruser has quit IRC
 31 2016-06-09T02:22:23  *** justanotheruser has joined #bitcoin-core-dev
 32 2016-06-09T02:24:41  *** supasonic has joined #bitcoin-core-dev
 33 2016-06-09T02:56:05  <luke-jr> gmaxwell: ah, right
 34 2016-06-09T03:04:04  *** supasonic has quit IRC
 35 2016-06-09T03:04:33  *** supasonic has joined #bitcoin-core-dev
 36 2016-06-09T03:09:03  *** achow101 has quit IRC
 37 2016-06-09T03:40:33  *** molz has joined #bitcoin-core-dev
 38 2016-06-09T03:43:42  *** moli has quit IRC
 39 2016-06-09T04:02:19  *** adiabat has joined #bitcoin-core-dev
 40 2016-06-09T04:20:51  *** moli has joined #bitcoin-core-dev
 41 2016-06-09T04:23:03  *** molz has quit IRC
 42 2016-06-09T04:27:21  *** jtimon has quit IRC
 43 2016-06-09T04:28:09  *** _anthony_ has quit IRC
 44 2016-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?
 45 2016-06-09T05:04:37  *** Giszmo has quit IRC
 46 2016-06-09T05:08:16  *** gevs has quit IRC
 47 2016-06-09T05:13:38  <GitHub77> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/4286f4302514...19ea17302e8f
 48 2016-06-09T05:13:39  <GitHub77> bitcoin/master b676f38 Cory Fields: depends: allow for CONFIG_SITE to be used rather than stealing prefix...
 49 2016-06-09T05:13:39  <GitHub77> bitcoin/master ad38204 Cory Fields: gitian: use CONFIG_SITE rather than hijacking the prefix
 50 2016-06-09T05:13:40  <GitHub77> bitcoin/master 7e7eb27 Cory Fields: gitian: create debug packages for linux/windows...
 51 2016-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
 52 2016-06-09T05:21:49  *** gevs has joined #bitcoin-core-dev
 53 2016-06-09T05:22:35  *** xiangfu has joined #bitcoin-core-dev
 54 2016-06-09T05:23:23  *** NicolasDorier has quit IRC
 55 2016-06-09T05:23:24  *** wallet42 has quit IRC
 56 2016-06-09T05:23:25  <GitHub156> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/19ea17302e8f...f0299d80fd42
 57 2016-06-09T05:23:25  <GitHub156> bitcoin/master 74c1347 Wladimir J. van der Laan: gitian: Add --disable-bench to config flags for windows...
 58 2016-06-09T05:23:26  <GitHub156> bitcoin/master f0299d8 Wladimir J. van der Laan: Merge #8175: gitian: Add --disable-bench to config flags for windows...
 59 2016-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
 60 2016-06-09T05:23:49  *** limpkin has quit IRC
 61 2016-06-09T05:24:15  *** mturquette has quit IRC
 62 2016-06-09T05:24:16  *** NicolasDorier has joined #bitcoin-core-dev
 63 2016-06-09T05:24:26  *** ibrightly has quit IRC
 64 2016-06-09T05:24:26  *** eragmus has quit IRC
 65 2016-06-09T05:25:04  *** zmanian__ has quit IRC
 66 2016-06-09T05:25:04  *** binns has quit IRC
 67 2016-06-09T05:25:05  *** CodeShark has quit IRC
 68 2016-06-09T05:26:09  <gmaxwell> iniana: the latter
 69 2016-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
 70 2016-06-09T05:28:15  *** eragmus has joined #bitcoin-core-dev
 71 2016-06-09T05:28:29  <gmaxwell> or even "if" not when, these txn are non-standard, so they won't likely mine them
 72 2016-06-09T05:28:34  *** CodeShark has joined #bitcoin-core-dev
 73 2016-06-09T05:28:46  *** ibrightly has joined #bitcoin-core-dev
 74 2016-06-09T05:29:30  <GitHub0> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f0299d80fd42...7e6dd7bee479
 75 2016-06-09T05:29:30  <GitHub0> bitcoin/master 77f63a4 Pieter Wuille: Fix two warnings for comparison between signed and unsigned
 76 2016-06-09T05:29:31  <GitHub0> bitcoin/master 7e6dd7b Wladimir J. van der Laan: Merge #8172: Fix two warnings for comparison between signed and unsigned...
 77 2016-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
 78 2016-06-09T05:30:08  *** binns has joined #bitcoin-core-dev
 79 2016-06-09T05:31:44  *** mturquette has joined #bitcoin-core-dev
 80 2016-06-09T05:32:19  <gmaxwell> Thanks. those have been bothering me.
 81 2016-06-09T05:32:31  *** limpkin has joined #bitcoin-core-dev
 82 2016-06-09T05:33:14  <luke-jr> ☺
 83 2016-06-09T05:33:56  *** ibrightly has quit IRC
 84 2016-06-09T05:33:58  *** zmanian__ has joined #bitcoin-core-dev
 85 2016-06-09T05:35:32  *** ibrightly has joined #bitcoin-core-dev
 86 2016-06-09T05:36:55  *** wallet42 has joined #bitcoin-core-dev
 87 2016-06-09T05:37:24  <GitHub102> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7e6dd7bee479...d36618585de6
 88 2016-06-09T05:37:24  <GitHub102> bitcoin/master e012f3c Wladimir J. van der Laan: util: Add ParseUInt32 and ParseUInt64...
 89 2016-06-09T05:37:25  <GitHub102> bitcoin/master d366185 Wladimir J. van der Laan: Merge #8168: util: Add ParseUInt32 and ParseUInt64...
 90 2016-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
 91 2016-06-09T05:40:57  *** frankenmint has quit IRC
 92 2016-06-09T05:40:59  *** xiangfu has quit IRC
 93 2016-06-09T05:49:31  *** frankenmint has joined #bitcoin-core-dev
 94 2016-06-09T06:07:35  *** wallet42 has quit IRC
 95 2016-06-09T06:08:04  *** ibrightly has quit IRC
 96 2016-06-09T06:10:26  *** wallet42 has joined #bitcoin-core-dev
 97 2016-06-09T06:13:34  <GitHub168> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d36618585de6...1445835bd3c4
 98 2016-06-09T06:13:34  <GitHub168> bitcoin/master d3d02d5 Kaz Wesley: drop vAddrToSend after sending big addr message...
 99 2016-06-09T06:13:34  <GitHub168> bitcoin/master 1445835 Wladimir J. van der Laan: Merge #8154: drop vAddrToSend after sending big addr message...
100 2016-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
101 2016-06-09T06:20:28  *** ibrightly has joined #bitcoin-core-dev
102 2016-06-09T06:25:44  <GitHub197> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1445835bd3c4...0b5279f89c9a
103 2016-06-09T06:25:45  <GitHub197> bitcoin/master c2715d3 Pavel Janík: Do not shadow local variables
104 2016-06-09T06:25:45  <GitHub197> bitcoin/master 0b5279f Wladimir J. van der Laan: Merge #8166: src/test: Do not shadow local variables...
105 2016-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
106 2016-06-09T06:28:10  *** Guyver2 has joined #bitcoin-core-dev
107 2016-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
108 2016-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)
109 2016-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.
110 2016-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?
111 2016-06-09T07:19:28  *** Ylbam has joined #bitcoin-core-dev
112 2016-06-09T07:20:17  *** Guyver2 has quit IRC
113 2016-06-09T07:27:10  <paveljanik> github Unircorn 8)
114 2016-06-09T07:28:45  <jonasschnelli> argh... again...
115 2016-06-09T07:28:55  <jonasschnelli> We need a decentralized github web. :)
116 2016-06-09T07:29:21  <sipa> You mean git?
117 2016-06-09T07:29:26  <jonasschnelli> hehe...
118 2016-06-09T07:29:48  <jonasschnelli> Yes. With the option of creating issues, public announcements of pull requests, etc.
119 2016-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
120 2016-06-09T07:49:24  <warren> Does the git repo use signed merge commits?
121 2016-06-09T07:49:55  <btcdrak> wumpus: maintenance is a bitch.
122 2016-06-09T07:50:04  <sipa> warren: we always gpg sign merge commits
123 2016-06-09T07:50:05  <btcdrak> warren: yes.
124 2016-06-09T07:50:16  <sipa> warren: and there is a script to verify that
125 2016-06-09T07:52:29  <jonasschnelli> wumpus: you mean mirroring the github data?
126 2016-06-09T07:52:42  <jonasschnelli> Or just the git?
127 2016-06-09T07:52:51  <wumpus> just the git
128 2016-06-09T07:53:01  <jonasschnelli> Okay. That would be trivial.
129 2016-06-09T07:53:12  <wumpus> we do mirror the github data in a github repository, could also push that there
130 2016-06-09T07:53:16  <jonasschnelli> btcdrak: where is bitcoincore.org hosted?
131 2016-06-09T07:53:17  <btcdrak> I'm sure the odd Github Unicorn doesnt cause us _that_ much trouble.
132 2016-06-09T07:53:32  <btcdrak> jonasschnelli: the website is at github :)
133 2016-06-09T07:53:33  <sipa> wumpus: wgat
134 2016-06-09T07:53:38  *** adiabat has quit IRC
135 2016-06-09T07:53:40  <jonasschnelli> Yes. But we can't work on a decentralized system on a centralized github. :)
136 2016-06-09T07:53:43  <btcdrak> but can set a DNS entry to any server...
137 2016-06-09T07:53:50  <btcdrak> (a subdomain I mean)
138 2016-06-09T07:54:28  <btcdrak> jonasschnelli: decentralisation is a myth in this case.
139 2016-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
140 2016-06-09T07:55:03  <sipa> unfortunately git commit ids are only sha1 :(
141 2016-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
142 2016-06-09T07:55:58  <btcdrak> i love how this entire conversation comes up almost verbatim again every now and again :)
143 2016-06-09T07:56:23  <wumpus> we're like broken records
144 2016-06-09T07:56:33  <btcdrak> mayeb I should write a FAQ :-p
145 2016-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
146 2016-06-09T07:58:55  <wumpus> please include a "database corrupted" entry
147 2016-06-09T07:59:09  <wumpus> really doesn't help that everyone creates a new issue every time they get that
148 2016-06-09T07:59:34  <wumpus> where 99 out of 100 times it's simply a hardware problem
149 2016-06-09T08:00:04  <btcdrak> agreed, I think there are a bunch of common issue we could cover.
150 2016-06-09T08:00:07  <wumpus> we really should discourage people from creating new issues about that, unless there's new information to report
151 2016-06-09T08:00:24  <wumpus> maybe they could post to an existing issue for statistics or something
152 2016-06-09T08:01:46  <gmaxwell> change the message to "Apparent hardware error" :)
153 2016-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
154 2016-06-09T08:03:41  <wumpus> gmaxwell: yes, that would be a good idea
155 2016-06-09T08:04:18  <paveljanik> maybe even a link to the FAQ entry about this?
156 2016-06-09T08:06:17  <sipa> nobody believes you when you tell them their hardware is broken
157 2016-06-09T08:06:27  <gmaxwell> a few do.
158 2016-06-09T08:06:29  <wumpus> still, it helps to have it written down somewhere
159 2016-06-09T08:06:35  <wumpus> in a clear way
160 2016-06-09T08:06:44  <wumpus> instead of repeating it all the time, increasingly annoyed :)
161 2016-06-09T08:06:46  <gmaxwell> I actually think they believe it from the sofware more than names on IRC.
162 2016-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'
163 2016-06-09T08:07:19  <gmaxwell> and they show up "hey you morons still haven't fixed this!"
164 2016-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!?
165 2016-06-09T08:08:19  <gmaxwell> Is there a german word for where you both feel apologetic towards someone and want to strangle them?
166 2016-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
167 2016-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.
168 2016-06-09T08:11:22  <wumpus> I think I'm going to create one 'data corruption' issue and close the others as duplicates
169 2016-06-09T08:11:50  <gmaxwell> Same reason why reports seldom have the information required to reproduce the issue.
170 2016-06-09T08:12:27  <wumpus> well most issues are fairly good in that regard
171 2016-06-09T08:12:28  <gmaxwell> if we had simply forgotten, reporting again would help-- and we do, from time to time, forget actual issues.
172 2016-06-09T08:12:42  <wumpus> generally not issues that are reported on github
173 2016-06-09T08:12:49  <gmaxwell> Right.
174 2016-06-09T08:12:52  <wumpus> sure, if something is said on IRC or the mailing list it gets lost
175 2016-06-09T08:12:56  <gmaxwell> at least not while they're still open.
176 2016-06-09T08:12:59  <wumpus> the point of an issue tracker is to have a persistent URL for an issue
177 2016-06-09T08:13:30  <gmaxwell> But clearly we've fogotten the data corruption because it keeps hapenning. :P QED.
178 2016-06-09T08:13:33  <wumpus> if it gets too crowded it loses its value
179 2016-06-09T08:14:01  <wumpus> then it's just like mentioning it once on reddit, no one will ever look back to it
180 2016-06-09T08:14:10  <wumpus> heh
181 2016-06-09T08:14:28  <wumpus> well every time I had actual data corruption I investigated in depth
182 2016-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?
183 2016-06-09T08:17:07  <gmaxwell> it's called bitcoind.
184 2016-06-09T08:17:19  <wumpus> it will take long to detect errors, so no one will run that
185 2016-06-09T08:17:25  <wumpus> heh exactly
186 2016-06-09T08:17:28  <gmaxwell> it's not just leveldb though, the cpu load from signature validation triggers memory errors on some systems.
187 2016-06-09T08:17:30  <jonasschnelli> Okay.. :)
188 2016-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.
189 2016-06-09T08:18:33  <wumpus> there are just so many types of hardware problems that can result in corruptions
190 2016-06-09T08:18:39  <gmaxwell> I have mixed feelings, users really shouldn't count on faulty computers... esp for handling irreversable money...
191 2016-06-09T08:19:05  <wumpus> and there is software to detect hardware problems, that's a completely orthogonal thing :)
192 2016-06-09T08:19:29  <jonasschnelli> Right. Agree.
193 2016-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...)
194 2016-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.
195 2016-06-09T08:20:33  <jonasschnelli> Wumpuses snapshot idea would be a live-safer for such situations
196 2016-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
197 2016-06-09T08:23:18  <GitHub74> [bitcoin] laanwj pushed 15 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/e7ec24e336dc...20d00a180ee6
198 2016-06-09T08:23:19  <GitHub74> bitcoin/0.12 9095594 ptschip: Do not download transactions during inital sync...
199 2016-06-09T08:23:19  <GitHub74> bitcoin/0.12 a9e73f7 instagibbs: Fix and cleanup listreceivedbyX documentation...
200 2016-06-09T08:23:20  <GitHub74> bitcoin/0.12 64fd0ce jloughry: fix spelling of advertise in src and doc...
201 2016-06-09T08:28:16  *** frankenmint has quit IRC
202 2016-06-09T08:29:55  <paveljanik> Can you kick travis on #8109 please?
203 2016-06-09T08:30:55  <paveljanik> ah, I can do that myself by simply rebasing it.
204 2016-06-09T08:41:58  *** frankenmint has joined #bitcoin-core-dev
205 2016-06-09T08:42:04  *** jannes has joined #bitcoin-core-dev
206 2016-06-09T08:43:33  *** challisto has joined #bitcoin-core-dev
207 2016-06-09T08:44:13  *** challisto has quit IRC
208 2016-06-09T08:47:57  *** kadoban has quit IRC
209 2016-06-09T08:51:16  <GitHub89> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b5279f89c9a...172cd7f10c7e
210 2016-06-09T08:51:16  <GitHub89> bitcoin/master cdf7dff Jonas Schnelli: OSX diskimages need 0775 folder permissions...
211 2016-06-09T08:51:17  <GitHub89> bitcoin/master 172cd7f Wladimir J. van der Laan: Merge #8169: OSX diskimages need 0775 folder permissions...
212 2016-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
213 2016-06-09T08:53:10  <GitHub177> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/0f8d574e8f6521c07ae204b4f8b61d1534f03c21
214 2016-06-09T08:53:10  <GitHub177> bitcoin/0.12 0f8d574 Jonas Schnelli: OSX diskimages need 0775 folder permissions...
215 2016-06-09T08:55:51  *** supasonic has quit IRC
216 2016-06-09T08:56:21  *** supasonic has joined #bitcoin-core-dev
217 2016-06-09T08:56:23  *** supasonic has quit IRC
218 2016-06-09T09:03:16  *** hsmiths has quit IRC
219 2016-06-09T09:08:05  *** hsmiths has joined #bitcoin-core-dev
220 2016-06-09T09:08:50  *** ozanyurt has quit IRC
221 2016-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
222 2016-06-09T09:14:37  <GitHub131> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/172cd7f10c7e...fd9881ae6782
223 2016-06-09T09:14:38  <GitHub131> bitcoin/master fa58c76 MarcoFalke: [gitian] Default reference_datetime to commit author date
224 2016-06-09T09:14:38  <GitHub131> bitcoin/master fa42a67 MarcoFalke: [gitian] hardcode datetime for depends
225 2016-06-09T09:14:39  <GitHub131> bitcoin/master fd9881a Wladimir J. van der Laan: Merge #7283: [gitian] Default reference_datetime to commit author date...
226 2016-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
227 2016-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
228 2016-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
229 2016-06-09T09:22:58  *** edward has left #bitcoin-core-dev
230 2016-06-09T09:30:00  *** STAFFSCOINS_ has quit IRC
231 2016-06-09T09:30:01  *** iniana has quit IRC
232 2016-06-09T09:30:01  *** assder has quit IRC
233 2016-06-09T09:47:17  *** fedefranz has joined #bitcoin-core-dev
234 2016-06-09T09:49:26  *** laurentmt has joined #bitcoin-core-dev
235 2016-06-09T10:06:16  *** AaronvanW has quit IRC
236 2016-06-09T10:08:53  *** AaronvanW has joined #bitcoin-core-dev
237 2016-06-09T10:08:54  *** AaronvanW has quit IRC
238 2016-06-09T10:08:54  *** AaronvanW has joined #bitcoin-core-dev
239 2016-06-09T10:26:41  *** laurentmt has quit IRC
240 2016-06-09T10:28:48  *** laurentmt has joined #bitcoin-core-dev
241 2016-06-09T10:31:00  *** laurentmt has quit IRC
242 2016-06-09T10:43:18  *** MarcoFalke has joined #bitcoin-core-dev
243 2016-06-09T10:43:45  <MarcoFalke> wumpus: Can you explain why you left BUILD_DATE in share/genbuild.sh ?
244 2016-06-09T10:43:51  <MarcoFalke> Is it used elsewhere?
245 2016-06-09T10:46:22  *** frankenmint has quit IRC
246 2016-06-09T10:46:33  *** frankenmint has joined #bitcoin-core-dev
247 2016-06-09T10:51:45  *** spikeheadon has joined #bitcoin-core-dev
248 2016-06-09T10:51:50  *** spikey has joined #bitcoin-core-dev
249 2016-06-09T11:30:47  *** cryptapus has joined #bitcoin-core-dev
250 2016-06-09T11:32:33  <wumpus> MarcoFalke: probably an oversight, or I wasn't sure, let me see
251 2016-06-09T11:33:16  <wumpus> yes that can definitely go
252 2016-06-09T11:59:54  *** spikey has joined #bitcoin-core-dev
253 2016-06-09T12:03:41  *** spikeheadon has quit IRC
254 2016-06-09T12:11:17  *** Ylbam has quit IRC
255 2016-06-09T12:20:58  *** Chris_Stewart_5 has joined #bitcoin-core-dev
256 2016-06-09T12:23:37  *** frankenmint has quit IRC
257 2016-06-09T12:47:59  *** lysobit- has quit IRC
258 2016-06-09T12:48:24  *** musalbas has quit IRC
259 2016-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(??)
260 2016-06-09T13:27:52  <instagibbs> "// getbalance and "getbalance * 1 true" should return the same number"
261 2016-06-09T13:28:16  <instagibbs> oh the latter is probably me being dumb, but I still am getting weird balances
262 2016-06-09T13:29:48  *** TomMc has joined #bitcoin-core-dev
263 2016-06-09T13:30:05  <sipa> instagibbs: https://github.com/bitcoin/bitcoin/pull/7715 ?
264 2016-06-09T13:32:07  <instagibbs> thanks, is that comment supposed to be correct? I'm getting different balances
265 2016-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
266 2016-06-09T13:36:22  <instagibbs> i was, but i escaped it yes
267 2016-06-09T13:36:32  *** Chris_Stewart_5 has quit IRC
268 2016-06-09T13:37:01  <instagibbs> If I send funds to myself in regtest, it immediately shows up in getbalance, but not getbalance * 1 true
269 2016-06-09T13:37:01  <sipa> then how do you get a parsing error?
270 2016-06-09T13:37:17  <instagibbs> no that was my 2nd issue, now fixed
271 2016-06-09T13:37:23  <sipa> ah, getbalance will show unconfirmed sends from yourself
272 2016-06-09T13:37:35  <instagibbs> well... I will change that comment then
273 2016-06-09T13:37:41  <instagibbs> thanks
274 2016-06-09T13:38:14  <sipa> that comment is very very old
275 2016-06-09T13:38:21  <sipa> 2010, i expect
276 2016-06-09T13:39:25  <instagibbs> 2015?
277 2016-06-09T13:39:33  <instagibbs> according to git blame
278 2016-06-09T13:39:53  <sipa> oh
279 2016-06-09T13:39:56  <instagibbs> dgenr8 one-line addition
280 2016-06-09T13:40:18  <instagibbs> Anyways, I'll PR if that's expected behavior
281 2016-06-09T13:41:21  <sipa> if you disable -spendzeroconfchange, it may work
282 2016-06-09T13:41:26  <sipa> s/work/hold true/
283 2016-06-09T13:41:53  <instagibbs> ok
284 2016-06-09T13:52:13  <instagibbs> still a slight difference with spendzeroconfchange disabled, hmm
285 2016-06-09T13:52:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
286 2016-06-09T13:52:54  *** G1lius has joined #bitcoin-core-dev
287 2016-06-09T14:10:00  *** spikeheadon has joined #bitcoin-core-dev
288 2016-06-09T14:11:35  *** spikeheadon has quit IRC
289 2016-06-09T14:11:55  *** spikeheadon has joined #bitcoin-core-dev
290 2016-06-09T14:12:34  *** spikey has quit IRC
291 2016-06-09T14:12:43  *** spikeheadon has quit IRC
292 2016-06-09T14:13:23  *** spikeheadon has joined #bitcoin-core-dev
293 2016-06-09T14:14:48  *** spikeheadon has quit IRC
294 2016-06-09T14:15:10  *** spikeheadon has joined #bitcoin-core-dev
295 2016-06-09T14:16:13  *** spikeheadon has quit IRC
296 2016-06-09T14:16:34  *** spikeheadon has joined #bitcoin-core-dev
297 2016-06-09T14:18:09  *** spikeheadon has quit IRC
298 2016-06-09T14:18:30  *** spikeheadon has joined #bitcoin-core-dev
299 2016-06-09T14:29:22  *** Giszmo has joined #bitcoin-core-dev
300 2016-06-09T14:32:59  <GitHub84> [bitcoin] sipa pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd9881ae6782...7ce9ac5c83b1
301 2016-06-09T14:33:00  <GitHub84> bitcoin/master 5ec0cde Suhas Daftuar: Refactor logic for converting mempool entries to JSON
302 2016-06-09T14:33:00  <GitHub84> bitcoin/master 8f7b5dc Suhas Daftuar: Add getmempoolancestors RPC call
303 2016-06-09T14:33:01  <GitHub84> bitcoin/master 0dfd869 Suhas Daftuar: Add getmempooldescendants RPC call
304 2016-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
305 2016-06-09T14:42:49  <GitHub198> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7ce9ac5c83b1...f7b1bfc9a347
306 2016-06-09T14:42:49  <GitHub198> bitcoin/master 3144449 Pieter Wuille: Add git and github tips and tricks to developer notes
307 2016-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...
308 2016-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
309 2016-06-09T14:44:36  <GitHub172> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f7b1bfc9a347...32b7294177e5
310 2016-06-09T14:44:36  <GitHub172> bitcoin/master 0d53a9e Luke Dashjr: Update luke-jr's PGP key...
311 2016-06-09T14:44:37  <GitHub172> bitcoin/master 32b7294 Wladimir J. van der Laan: Merge #8180: Update luke-jr's PGP key...
312 2016-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
313 2016-06-09T14:52:25  *** Guyver2 has joined #bitcoin-core-dev
314 2016-06-09T15:02:14  *** dingus has quit IRC
315 2016-06-09T15:19:04  *** spikeheadon has quit IRC
316 2016-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)
317 2016-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")
318 2016-06-09T15:21:48  <dgenr8> justdid
319 2016-06-09T15:22:03  <instagibbs> yeah i opened an issue
320 2016-06-09T15:22:12  <instagibbs> since im not sure what the comment should be changed to
321 2016-06-09T15:22:25  <instagibbs> there are nooks and crannies depending on settings you are running
322 2016-06-09T15:25:50  <dgenr8> agreed that since -spendzeroconfchange affects the result of getbalance, the comment is too general.  prolly just remove it
323 2016-06-09T15:26:08  <sipa> dgenr8: sendfrom just subtracts the balance from A; it always uses all utxos
324 2016-06-09T15:26:25  <sipa> dgenr8: as accounts don't own utxos in any way
325 2016-06-09T15:26:41  <instagibbs> dgenr8, yes I think removal is best
326 2016-06-09T15:32:06  *** blur3d has quit IRC
327 2016-06-09T15:32:45  *** fengling has joined #bitcoin-core-dev
328 2016-06-09T15:34:33  <sipa> dgenr8: also, do you feel like addresses the comments on your partition check improvement?
329 2016-06-09T15:34:43  <sipa> *addressing
330 2016-06-09T15:36:00  *** jtimon has joined #bitcoin-core-dev
331 2016-06-09T15:38:10  *** spikeheadon has joined #bitcoin-core-dev
332 2016-06-09T15:38:33  *** Chris_Stewart_5 has quit IRC
333 2016-06-09T15:47:38  *** jtimon has quit IRC
334 2016-06-09T15:51:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
335 2016-06-09T15:55:30  *** spikeheadon has quit IRC
336 2016-06-09T15:55:44  *** fengling has quit IRC
337 2016-06-09T15:55:54  *** grubles has joined #bitcoin-core-dev
338 2016-06-09T15:56:09  *** grubles is now known as dingus
339 2016-06-09T15:57:05  *** jtimon has joined #bitcoin-core-dev
340 2016-06-09T16:02:29  *** fedefranz has left #bitcoin-core-dev
341 2016-06-09T16:02:38  *** kadoban has joined #bitcoin-core-dev
342 2016-06-09T16:04:17  *** G1lius has quit IRC
343 2016-06-09T16:08:35  *** mkarrer_ has joined #bitcoin-core-dev
344 2016-06-09T16:08:35  *** mkarrer has quit IRC
345 2016-06-09T16:08:42  *** mkarrer_ has quit IRC
346 2016-06-09T16:23:18  *** fengling has joined #bitcoin-core-dev
347 2016-06-09T16:32:17  <gmaxwell> 2016-06-09 08:46:38.763465 [0%]...[50%]...[99%]...[DONE].
348 2016-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?
349 2016-06-09T16:36:52  *** achow101 has joined #bitcoin-core-dev
350 2016-06-09T16:51:11  *** aureianimus_ has quit IRC
351 2016-06-09T16:51:45  *** aureianimus_ has joined #bitcoin-core-dev
352 2016-06-09T17:02:19  *** jcorgan has quit IRC
353 2016-06-09T17:03:48  *** PaulCape_ has quit IRC
354 2016-06-09T17:05:26  *** PaulCapestany has joined #bitcoin-core-dev
355 2016-06-09T17:07:51  *** JackH_ has joined #bitcoin-core-dev
356 2016-06-09T17:08:52  *** JackH has quit IRC
357 2016-06-09T17:09:47  *** Chris_Stewart_5 has quit IRC
358 2016-06-09T17:18:56  *** spikeheadon has joined #bitcoin-core-dev
359 2016-06-09T17:23:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
360 2016-06-09T17:28:05  *** bsm1175321 has joined #bitcoin-core-dev
361 2016-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
362 2016-06-09T17:55:01  *** Chris_Stewart_5 has quit IRC
363 2016-06-09T18:11:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
364 2016-06-09T18:15:11  *** molz has joined #bitcoin-core-dev
365 2016-06-09T18:17:34  *** moli has quit IRC
366 2016-06-09T18:20:44  <wumpus> gmaxwell: sure, an external log handler would just wait for the line to complete
367 2016-06-09T18:21:19  <gmaxwell> K. I've never considered that case before and thought it potentially useful to raise the question.
368 2016-06-09T18:21:20  <wumpus> there's no rule that log messages need to be written within a certain time
369 2016-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.
370 2016-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
371 2016-06-09T18:22:50  <wumpus> and this is less spammy than printing a line for every N%
372 2016-06-09T18:23:14  <gmaxwell> Right. I agree that it can be done here.
373 2016-06-09T18:26:32  *** Ylbam has joined #bitcoin-core-dev
374 2016-06-09T18:32:33  *** BakSAj has joined #bitcoin-core-dev
375 2016-06-09T18:32:46  *** laurentmt has joined #bitcoin-core-dev
376 2016-06-09T18:33:14  <BakSAj> hi
377 2016-06-09T18:36:00  <BakSAj> http://bitcoin.sipa.be/ver9-2k.png
378 2016-06-09T18:36:05  <BakSAj> i like the picture :-)
379 2016-06-09T18:36:21  <BakSAj> not sure if we make it to 95% in this diff period
380 2016-06-09T18:36:46  <gmaxwell> mostly depends on KNC going offline again or not.
381 2016-06-09T18:37:12  <adam3us> they maybe selling the equipment
382 2016-06-09T18:42:34  <BakSAj> lets hope...
383 2016-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
384 2016-06-09T18:47:38  *** laurentmt has quit IRC
385 2016-06-09T18:48:07  *** laurentmt has joined #bitcoin-core-dev
386 2016-06-09T18:48:34  *** zmanian__ has quit IRC
387 2016-06-09T18:50:38  *** zmanian__ has joined #bitcoin-core-dev
388 2016-06-09T18:55:37  *** hsmiths2 has joined #bitcoin-core-dev
389 2016-06-09T18:58:09  *** hsmiths has quit IRC
390 2016-06-09T19:00:17  <jonasschnelli> meeting?
391 2016-06-09T19:00:25  <gmaxwell> Meeting time.
392 2016-06-09T19:00:29  <wumpus> yes
393 2016-06-09T19:00:35  <wumpus> #meetingstart
394 2016-06-09T19:00:38  <wumpus> #startmeeting
395 2016-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.
396 2016-06-09T19:00:38  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
397 2016-06-09T19:00:47  *** sean___ has joined #bitcoin-core-dev
398 2016-06-09T19:00:52  *** sean___ is now known as ebfull
399 2016-06-09T19:01:01  <gmaxwell> phantomcircuit: sipa: morcos: sdaftuar: btcdrak: jonasschnelli: luke-jr:
400 2016-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.
401 2016-06-09T19:01:25  <gmaxwell> petertodd: MarcoFalke:
402 2016-06-09T19:01:38  *** laurentmt has quit IRC
403 2016-06-09T19:01:39  <wumpus> #link 0.13 release schedule: https://github.com/bitcoin/bitcoin/issues/7679
404 2016-06-09T19:01:52  <MarcoFalke> any topic suggestions today?
405 2016-06-09T19:02:23  <gmaxwell> We can talk some about ongoing compact block testings, I have a few things to report.
406 2016-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
407 2016-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
408 2016-06-09T19:02:54  <gmaxwell> instagibbs: nickler: NicolasDorier: CodeShark:
409 2016-06-09T19:03:14  <CodeShark> yo
410 2016-06-09T19:03:23  <MarcoFalke> cfields_: I think p2p refactor can go in after the feature freeze?
411 2016-06-09T19:03:29  <gmaxwell> We apparently can no longer compile on hosts with only 2GB ram with defaults.
412 2016-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
413 2016-06-09T19:03:46  <MarcoFalke> I mean it is not a new feature ;)
414 2016-06-09T19:04:04  <gmaxwell> well it was more like 1.5GB ram before.
415 2016-06-09T19:04:06  *** jeremyrubin has joined #bitcoin-core-dev
416 2016-06-09T19:04:35  <wumpus> others have not yet finished: #7598 (Refactor CreateNewBlock to be a method of the BlockAssembler class)
417 2016-06-09T19:04:37  <jonasschnelli> gmaxwell: I compiled on a 2GG AARCH this week successfully.
418 2016-06-09T19:04:41  <jonasschnelli> *GB
419 2016-06-09T19:04:46  <gmaxwell> We have docs that say 1.5GB, they're gonna be like the blocksize on bitcoin.org :)
420 2016-06-09T19:04:49  <wumpus> #7600  Mining: Select transactions using feerate-with-ancestors
421 2016-06-09T19:04:55  <wumpus> depends on what else is running on the machine
422 2016-06-09T19:05:34  <gmaxwell> I've been going through #7598/#7600.
423 2016-06-09T19:05:38  <wumpus> #topic compile-time memory usage
424 2016-06-09T19:05:45  <wumpus> what can *concretely* be done here?
425 2016-06-09T19:05:58  <jonasschnelli> would kick out boost help?
426 2016-06-09T19:05:59  <luke-jr> -O0
427 2016-06-09T19:06:01  <wumpus> is it something worrying?
428 2016-06-09T19:06:08  <cfields_> has anyone measured to see if there are particular objects that are especially guilty?
429 2016-06-09T19:06:11  <CodeShark> what's eating up all the RAM?
430 2016-06-09T19:06:14  <wumpus> yes, we have cfields_
431 2016-06-09T19:06:20  <cfields_> ie. main.cpp/net.cpp ?
432 2016-06-09T19:06:21  <luke-jr> CodeShark: ld/GCC doesn't free memory
433 2016-06-09T19:06:22  <wumpus> especialy some autogenerated c++ files
434 2016-06-09T19:06:30  *** laurentmt has joined #bitcoin-core-dev
435 2016-06-09T19:06:33  <wumpus> I made some tables back in the issue about this
436 2016-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.
437 2016-06-09T19:06:48  *** laurentmt has quit IRC
438 2016-06-09T19:06:50  <luke-jr> CFLAGS="-O0 -g0 --param ggc-min-expand=0 --param ggc-min-heapsize=32768"
439 2016-06-09T19:06:54  <wumpus> #link https://github.com/bitcoin/bitcoin/issues/7471
440 2016-06-09T19:06:54  <gmaxwell> I dunno why he hasn't PRed it, I asked him to.
441 2016-06-09T19:07:00  <cfields_> wumpus: thanks
442 2016-06-09T19:07:10  <wumpus> eeh that's the wrong one
443 2016-06-09T19:07:22  <gmaxwell> wumpus: unthanks
444 2016-06-09T19:07:30  <wumpus> well it is about the same subject
445 2016-06-09T19:07:33  <wumpus> #link https://github.com/bitcoin/bitcoin/issues/6658
446 2016-06-09T19:07:52  <wumpus> lots of people have posted about it, but there doesn't seem to be a clear solution
447 2016-06-09T19:08:00  <jonasschnelli> main.cpp -> 1248524bytes ... ^^
448 2016-06-09T19:08:33  *** moli has joined #bitcoin-core-dev
449 2016-06-09T19:08:37  <wumpus> reducing the number of included headers works, I think
450 2016-06-09T19:08:41  <sipa> present
451 2016-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
452 2016-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.
453 2016-06-09T19:09:13  <wumpus> also building with clang helps
454 2016-06-09T19:09:21  <wumpus> it uses a lot less memory at the same compile settings, usually
455 2016-06-09T19:09:25  <gmaxwell> and be independantly good for reasons unrelated to peak memory usage.
456 2016-06-09T19:10:05  <cfields_> i'd assume that mem usage correlates solidly with compile time
457 2016-06-09T19:10:41  *** molz has quit IRC
458 2016-06-09T19:10:55  <CodeShark> not so sure - lots of small files might mean the bottleneck is disk access
459 2016-06-09T19:11:29  <sipa> CodeShark: come on
460 2016-06-09T19:11:32  <CodeShark> in any case, it would be good to bring down the peak mem usage
461 2016-06-09T19:11:32  <wumpus> the bottleneck in compilation is hardly ever disk access, at least *reading* disk access
462 2016-06-09T19:11:37  <sipa> reading in 100 files?
463 2016-06-09T19:11:43  <sipa> sequentially
464 2016-06-09T19:12:08  <BakSAj> would be cool, if btc full nodes could continue to be runnable on Rasberry Pi ... with 1GB RAM
465 2016-06-09T19:12:37  <jeremyrubin> BakSAj: runnable is not compileable on?
466 2016-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.
467 2016-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
468 2016-06-09T19:13:03  <cfields_> heh, disk is negligible. It's easy to see where time is spent with -ftime-report.
469 2016-06-09T19:13:17  <wumpus> but like always: measure before you start talking about bottlenecks
470 2016-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
471 2016-06-09T19:13:58  <BakSAj> jeremyrubin: preferably both compileable and operatable
472 2016-06-09T19:13:59  <wumpus> BakSAj: for small embedded systems you should use cross-compilation
473 2016-06-09T19:14:03  <cfields_> jonasschnelli: i'm halfway through the changes needed there.
474 2016-06-09T19:14:13  <jeremyrubin> i have had machines take a bit of time on autogen.sh fyi
475 2016-06-09T19:14:18  <jonasschnelli> cfields_: nice. Focus on Qt5.6 first. :)
476 2016-06-09T19:14:31  *** hsmiths2 has quit IRC
477 2016-06-09T19:14:34  <wumpus> you can cross compile on ARM using depends, we just don't distribute ARM binaries
478 2016-06-09T19:14:37  <cfields_> jonasschnelli: actually, arm/aarch64 already work fine with depends. Just have to use NO_QT=1 manually.
479 2016-06-09T19:14:40  <wumpus> s/on/to
480 2016-06-09T19:14:41  *** Chris_Stewart_5 has quit IRC
481 2016-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.
482 2016-06-09T19:14:44  <wumpus> cfields_: yes, it works fine
483 2016-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..
484 2016-06-09T19:14:56  <gmaxwell> er isn't the empty set, you get what I mean.
485 2016-06-09T19:15:01  *** hsmiths has joined #bitcoin-core-dev
486 2016-06-09T19:15:07  <cfields_> luke-jr: oh, good point...
487 2016-06-09T19:15:13  <wumpus> it's *very easy* tocross compile for ARM
488 2016-06-09T19:15:14  <jonasschnelli> I think NO_QT=1 for ARM/AARCH64 could be a start (even for "official binaries").
489 2016-06-09T19:15:20  <wumpus> with the depends system
490 2016-06-09T19:15:24  <wumpus> jonasschnelli: yes
491 2016-06-09T19:15:28  <cfields_> the gitian-debug PR turns on debug symbols, so gitian mem requirement is bumped after that.
492 2016-06-09T19:15:37  <gmaxwell> wumpus: a lot of people using rpi2 like systems do not have another linux host.
493 2016-06-09T19:15:42  <luke-jr> wumpus: that builds static binaries, which is wasteful on RAM
494 2016-06-09T19:15:44  <jonasschnelli> Also ARM is used more and more for GUI systems.
495 2016-06-09T19:15:50  <jeremyrubin> can autogen.sh be made faster?
496 2016-06-09T19:16:01  <wumpus> jeremyrubin: no
497 2016-06-09T19:16:15  <wumpus> not by us, at least
498 2016-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
499 2016-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.
500 2016-06-09T19:16:32  <BakSAj> since suprisingly many nodes run on rpi
501 2016-06-09T19:16:44  <jeremyrubin> wumpus: maybe the one thing that is fixed by a faster disk
502 2016-06-09T19:16:50  <luke-jr> jonasschnelli: I'm thinking more of Bitcoin-Qt
503 2016-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
504 2016-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
505 2016-06-09T19:17:11  <MarcoFalke> jonasschnelli: I think we already have notes on how to corss compile to arm?
506 2016-06-09T19:17:13  <jonasschnelli> Agree. Static linking qt is not ideal. But lets don't roll this up again.
507 2016-06-09T19:17:14  <MarcoFalke> https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#arm-cross-compilation
508 2016-06-09T19:17:23  <btcdrak> oh meeting
509 2016-06-09T19:17:35  <jonasschnelli> MarcoFalke: notes, yes. But it should be included in our release builds (gitian)
510 2016-06-09T19:17:42  <MarcoFalke> jup, agree
511 2016-06-09T19:17:46  <cfields_> jonasschnelli: sorry, i meant that directly in the context of shipping arm+gui binaries
512 2016-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
513 2016-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 :)
514 2016-06-09T19:18:09  * gmaxwell looks forward to arm (+gui) binaries in the sometime future.
515 2016-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
516 2016-06-09T19:18:48  * luke-jr fully intends to use an ARM system with Core(Knots) as his hot wallet in some months.
517 2016-06-09T19:18:50  <cfields_> jeremyrubin: you can use a quicker shell for autogen. IIRC dash vs. bash shaves a few seconds off
518 2016-06-09T19:19:15  <wumpus> well arm non-GUI binaries would already be a great step forward, one step at a tme
519 2016-06-09T19:19:15  <luke-jr> autogen.sh isn't even part of building; it's a developer tool
520 2016-06-09T19:19:17  <cfields_> wumpus: ah, as a feature-freeze request: ok to plan on arm bins (without gui) for 0.13 ?
521 2016-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
522 2016-06-09T19:19:30  <cfields_> i can try to have that done today
523 2016-06-09T19:19:30  <jonasschnelli> cfields_: ack, +1
524 2016-06-09T19:19:33  <wumpus> I think arm gui would be prett much a per-distro afair
525 2016-06-09T19:19:36  <wumpus> cfields_: sure!
526 2016-06-09T19:19:37  <luke-jr> cfields_: +1
527 2016-06-09T19:19:39  <jeremyrubin> luke-jr: are we making build faster for developers or for users?
528 2016-06-09T19:19:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
529 2016-06-09T19:19:45  <gmaxwell> +1
530 2016-06-09T19:19:47  <cfields_> ok
531 2016-06-09T19:20:06  <luke-jr> jeremyrubin: I think the concern is "ability to build" rather than "speed to build"
532 2016-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.
533 2016-06-09T19:20:26  <cfields_> ^^
534 2016-06-09T19:20:36  <BakSAj> cool, rpi fans will love you :-)
535 2016-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
536 2016-06-09T19:20:50  *** Arnavion has quit IRC
537 2016-06-09T19:20:57  <BakSAj> next step - run full node on cell phone :-)
538 2016-06-09T19:21:01  <jeremyrubin> wumpus: ++
539 2016-06-09T19:21:11  <luke-jr> BakSAj: I believe a number of people have done this.
540 2016-06-09T19:21:18  <wumpus> BakSAj: people are doing that actually, that's one of the motivations for the ARM binaries
541 2016-06-09T19:21:28  <BakSAj> lol ok
542 2016-06-09T19:21:28  <luke-jr> next step is therefore to support SPV mode when bandwidth is expensive ;)
543 2016-06-09T19:21:30  <gmaxwell> BakSAj: abcore, it works fine.
544 2016-06-09T19:21:39  <jonasschnelli> luke-jr: +1
545 2016-06-09T19:21:41  <luke-jr> but that's post-0.13 IMO
546 2016-06-09T19:21:45  <wumpus> absolutely
547 2016-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
548 2016-06-09T19:22:47  <luke-jr> can we get in [8-bit] key generation type?
549 2016-06-09T19:23:32  <jonasschnelli> 32bit!
550 2016-06-09T19:23:41  <jonasschnelli> You can provide a migration patch for Knots
551 2016-06-09T19:23:52  <jonasschnelli> Isn't that trivial?
552 2016-06-09T19:23:53  <BakSAj> will 0.13 contain just segwit code or actual softfork also? tnx
553 2016-06-09T19:24:03  <jonasschnelli> SW SF can be 0.13.1
554 2016-06-09T19:24:17  <jonasschnelli> SW are mostly not coupled with major releases
555 2016-06-09T19:24:21  <jeremyrubin> I think that 0.13.1 will be worse for upgrade times
556 2016-06-09T19:24:24  <wumpus> SW should be released in a minor release
557 2016-06-09T19:24:26  <jeremyrubin> does anyone have data on that
558 2016-06-09T19:24:29  <gmaxwell> BakSAj: major releases do not contain network consensus changes.
559 2016-06-09T19:24:31  <sdaftuar> do we think segwit is going in to 0.13?
560 2016-06-09T19:24:42  <sdaftuar> (without activation scheduled)
561 2016-06-09T19:24:52  <jeremyrubin> wumpus: isn't it a major change?
562 2016-06-09T19:24:52  <petertodd> sdaftuar: you mean, 0.13.0, or 0.13.x>0?
563 2016-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
564 2016-06-09T19:24:57  <sdaftuar> 0.13.0
565 2016-06-09T19:24:59  <btcdrak> sdaftuar: yes, sipa wanted to merge it soon to master
566 2016-06-09T19:25:01  <CodeShark> what happened to doing it in 0.12.x?
567 2016-06-09T19:25:02  <luke-jr> jonasschnelli: maybe this needs more off-meeting discussion then
568 2016-06-09T19:25:08  <btcdrak> (without mainnet defs)
569 2016-06-09T19:25:08  <jonasschnelli> luke-jr: agree
570 2016-06-09T19:25:15  <sdaftuar> seems like there are still open issues, and no ACKs
571 2016-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  :)
572 2016-06-09T19:25:26  <gmaxwell> CodeShark: nothing, there are confused questions.
573 2016-06-09T19:25:27  <sdaftuar> so i don't see how it's going to be merged in the next week
574 2016-06-09T19:25:48  <btcdrak> sdaftuar: why?
575 2016-06-09T19:25:48  <luke-jr> jeremyrubin: segwit is a major change to Bitcoin - not Bitcoin Core.
576 2016-06-09T19:25:51  * jonasschnelli thinks sipa is allowed to merge without ACK
577 2016-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.
578 2016-06-09T19:26:04  *** Arnavion has joined #bitcoin-core-dev
579 2016-06-09T19:26:07  <jeremyrubin> wumpus: interesting... I do tend to not upgrade any of my software major versions for 6 months. diversion over
580 2016-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"
581 2016-06-09T19:26:36  <jonasschnelli> agree
582 2016-06-09T19:26:41  <CodeShark> right
583 2016-06-09T19:26:47  <wumpus> sure
584 2016-06-09T19:26:49  <luke-jr> no objections to merging segwit code without activation
585 2016-06-09T19:26:50  <jonasschnelli> Also, getting ACK for SW is extremly hard. Nobody wants to take the risk.
586 2016-06-09T19:26:51  <gmaxwell> sure, there are code motion logistics that favor merging it.
587 2016-06-09T19:26:51  <sdaftuar> to be clear i'm not talking about any kind of release policy, just code-readiness / review
588 2016-06-09T19:26:54  <btcdrak> jeremyrubin: see out lifecycle docs https://github.com/bitcoin-core/bitcoincore.org/pull/179
589 2016-06-09T19:27:07  <btcdrak> s/out/our/
590 2016-06-09T19:27:08  *** Chris_St1 has joined #bitcoin-core-dev
591 2016-06-09T19:27:57  <wumpus> so is SW ready for merge (into master/0.13)?
592 2016-06-09T19:28:06  <sdaftuar> it has no ACKs, and some open issues to be resolved
593 2016-06-09T19:28:31  <wumpus> ok
594 2016-06-09T19:28:33  <jonasschnelli> major open issue? Or more nitish stuff?
595 2016-06-09T19:28:35  <sdaftuar> minor
596 2016-06-09T19:28:49  <wumpus> if it is not critical it can also be fixed in a later pull
597 2016-06-09T19:28:51  <sdaftuar> but bugs, not style nits
598 2016-06-09T19:29:09  <wumpus> oh known bugs should be addressed in the pull itself
599 2016-06-09T19:29:21  <sipa> i think everything will be addressed in my next batch of patches
600 2016-06-09T19:29:29  <btcdrak> sipa: great!
601 2016-06-09T19:29:41  *** Chris_Stewart_5 has quit IRC
602 2016-06-09T19:29:42  <gmaxwell> should people be acking the reviwew PR or the rebase/reorg?
603 2016-06-09T19:29:42  <luke-jr> sipa: does that include expanding 2nd push to 75 bytes max? or is that still an open thing?
604 2016-06-09T19:30:19  <sipa> luke-jr: this is the place to ask, and i would say no, there is no point
605 2016-06-09T19:30:27  <sipa> but perhaps others have another opinion
606 2016-06-09T19:30:32  <btcdrak> luke-jr: I didnt understand where 75 came from.
607 2016-06-09T19:30:42  <sipa> btcdrak: up to 75 is easy
608 2016-06-09T19:30:43  <luke-jr> btcdrak: largest size that wouldn't require additional testing
609 2016-06-09T19:31:18  <gmaxwell> has to do with the opcode types changing for different sizes of push.
610 2016-06-09T19:31:47  <sipa> so, opinions?
611 2016-06-09T19:31:51  <btcdrak> 32->40->75 seems like a big jump
612 2016-06-09T19:32:06  <gmaxwell> btcdrak: from the code perspective they're all the same.
613 2016-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
614 2016-06-09T19:32:49  <luke-jr> more tolerant enables softforks, so should be preferred over useless limits
615 2016-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.
616 2016-06-09T19:33:44  <gmaxwell> (of course, IsStandardness should be strictly limited)
617 2016-06-09T19:33:44  <luke-jr> to expand the limit later requires a hardfork
618 2016-06-09T19:34:00  <luke-jr> yes, node policy should reject any unknown witnesses period
619 2016-06-09T19:34:23  <CodeShark> ok, I think luke-jr has a strong argument
620 2016-06-09T19:34:27  <btcdrak> that makes sense
621 2016-06-09T19:34:47  <sipa> there should be no need for more than 256-bit hash + some versioning metadata
622 2016-06-09T19:35:14  <sipa> and setting it to more gives it the impression that there is
623 2016-06-09T19:35:16  <petertodd> sipa: or, to be precise if there is that means Bitcoin is more broken than that
624 2016-06-09T19:35:24  <sipa> petertodd: exactly
625 2016-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?
626 2016-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.
627 2016-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.
628 2016-06-09T19:36:12  *** kxie has joined #bitcoin-core-dev
629 2016-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.
630 2016-06-09T19:36:26  <sipa> i'd rather not rely on isstandardness when reasoning about longer term future
631 2016-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
632 2016-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
633 2016-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.
634 2016-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
635 2016-06-09T19:37:43  <gmaxwell> Yes, I really wish UTXO entries were fixed size.
636 2016-06-09T19:37:53  <sdaftuar> sipa: isn't there a strong deterrent against abuse, because your funds are anyone-can-spend to older nodes?
637 2016-06-09T19:37:56  *** _anthony_ has joined #bitcoin-core-dev
638 2016-06-09T19:37:59  <luke-jr> gmaxwell: you'd need a new commitment entirely
639 2016-06-09T19:38:13  <luke-jr> gmaxwell: in addition to the current one
640 2016-06-09T19:38:24  <sipa> sdaftuar: there is no rule preventing 0-value outputs
641 2016-06-09T19:38:34  <_anthony_> just use the private key of a payment address to store the 256 bits
642 2016-06-09T19:38:37  <sdaftuar> ah, good point
643 2016-06-09T19:38:41  <sipa> (if you ignore relay polify)
644 2016-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
645 2016-06-09T19:39:28  <gmaxwell> if one assumes a fixed size utxo entry, luke's suggestion basically doubles the utxo set size.
646 2016-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
647 2016-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
648 2016-06-09T19:40:44  <gmaxwell> We've probably spent more time discussing it now than the decision is worth.
649 2016-06-09T19:41:14  <wumpus> ok, next topic?
650 2016-06-09T19:41:24  <wumpus> #topic compact block testing
651 2016-06-09T19:41:27  <luke-jr> so we use 75 for now, and discuss reducing it later?
652 2016-06-09T19:41:33  <gmaxwell> (and that time could be better spent reviewing/testing more corner cases... lets continue discussion elsewhere I guess)
653 2016-06-09T19:42:34  <btcdrak> so compact blocks...
654 2016-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.
655 2016-06-09T19:42:52  <gmaxwell> Things seem to be working well there, instagibbs has posted some charts.
656 2016-06-09T19:42:56  <wumpus> I've been running a compact blocks node for a few days, no crashes to report :)
657 2016-06-09T19:43:16  <instagibbs> yes i love charts http://imgur.com/iq2lRGl
658 2016-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.
659 2016-06-09T19:43:27  <instagibbs> blue stuff is in kB fwiw
660 2016-06-09T19:43:30  <wumpus> lots of succesfully reconstructed blocks
661 2016-06-09T19:43:31  <luke-jr> (ugh, Travis is apparently "detecting abuse" on the Bitcoin code itself, so every clone will be affected?)
662 2016-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
663 2016-06-09T19:43:40  <instagibbs> blue dot == 0 fetched txns
664 2016-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.
665 2016-06-09T19:44:48  <instagibbs> I intended to review the PR then got ill. Still planning to review.
666 2016-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.
667 2016-06-09T19:45:05  <wumpus> luke-jr: (offtopic) that started happening with the parallel testing I think
668 2016-06-09T19:45:08  <sipa> gmaxwell: agree
669 2016-06-09T19:45:18  *** mn3monic has joined #bitcoin-core-dev
670 2016-06-09T19:45:19  <MarcoFalke> luke-jr: Shoot them an email
671 2016-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.
672 2016-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)
673 2016-06-09T19:45:54  <instagibbs> gmaxwell, matt's rebase is on that now?
674 2016-06-09T19:45:59  <instagibbs> err pr is rebased*
675 2016-06-09T19:46:01  <gmaxwell> instagibbs: yes.
676 2016-06-09T19:46:12  <gmaxwell> matt's PR is on master as of last night.
677 2016-06-09T19:46:20  <sipa> yes, forget my branch
678 2016-06-09T19:46:34  <CodeShark> what PR#?
679 2016-06-09T19:46:48  <instagibbs> #8086
680 2016-06-09T19:47:07  <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8068
681 2016-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
682 2016-06-09T19:47:23  <gmaxwell> Based on the issues I found, probably the interaction with block fetching logic needs more review.
683 2016-06-09T19:47:37  <btcdrak> cfields_: if it deploys in 0.13 it wont be necessary
684 2016-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.
685 2016-06-09T19:47:46  <wumpus> #action forget sipa's compact blocks branch and use thebluematt's PR
686 2016-06-09T19:48:10  *** adiabat has joined #bitcoin-core-dev
687 2016-06-09T19:48:10  <gmaxwell> it's not something that anyone has a reason to not support, except for just not having implemented it.
688 2016-06-09T19:48:13  <btcdrak> hrm, action point is to forget :)
689 2016-06-09T19:48:16  <sipa> cfields_: the argument brought up before was tgat service bits should be used for critical
690 2016-06-09T19:48:28  <sipa> for critically required services
691 2016-06-09T19:48:41  <gmaxwell> like your node won't work right if you don't have peers with the right services.
692 2016-06-09T19:48:46  <wumpus> btcdrak: yeah for people testing the code to use the other branch
693 2016-06-09T19:48:49  <luke-jr> makes sense
694 2016-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
695 2016-06-09T19:48:59  <jeremyrubin> in #8086 where is the salt generated btw?
696 2016-06-09T19:49:09  <cfields_> hmm, fair enough
697 2016-06-09T19:49:35  <wumpus> and miners can look at the protocol version to see if their peer supports compact blocks?
698 2016-06-09T19:49:48  <gmaxwell> jeremyrubin:
699 2016-06-09T19:49:49  <gmaxwell> +CBlockHeaderAndShortTxIDs::CBlockHeaderAndShortTxIDs(const CBlock& block) :
700 2016-06-09T19:49:52  <gmaxwell> +        nonce(GetRand(std::numeric_limits<uint64_t>::max())),
701 2016-06-09T19:50:12  <luke-jr> wumpus: I don't think we can assume a specific protocol version supports it
702 2016-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
703 2016-06-09T19:50:28  <jeremyrubin> thanks
704 2016-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
705 2016-06-09T19:50:32  <gmaxwell> wumpus: you can do the handshake.
706 2016-06-09T19:50:36  <sipa> wumpus: no, miners should connect to a known peer that supports it
707 2016-06-09T19:50:41  <luke-jr> Lightsword: neither are likely to be necessary
708 2016-06-09T19:51:09  <wumpus> gmaxwell: right
709 2016-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.
710 2016-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, ...
711 2016-06-09T19:51:29  <sipa> gmaxwell: we have 64
712 2016-06-09T19:51:41  <gmaxwell> Same difference. (really? hmph!)
713 2016-06-09T19:51:46  <jeremyrubin> I would suggest either writing the entropy to a file once or having it settable in a config file
714 2016-06-09T19:51:48  <wumpus> we should have a concept of temporary service bits, like for the versionbits
715 2016-06-09T19:52:05  <sipa> jeremyrubin: that's a good idea but orthogonal
716 2016-06-09T19:52:11  <luke-jr> as long as nobody relies on service bits, they can be temporary
717 2016-06-09T19:52:16  <btcdrak> we dont need preferential peering for compact blocks. It wont take long for wide network support.
718 2016-06-09T19:52:17  <luke-jr> ie, use them as hints
719 2016-06-09T19:52:23  <cfields_> don't we have a range designated for playground?
720 2016-06-09T19:52:27  <luke-jr> yes
721 2016-06-09T19:52:31  <jeremyrubin> sipa: (yes, sorry, just reviewing it now)
722 2016-06-09T19:52:34  <Lightsword> a service bit to indicate a secondary service bit field needs to be used?
723 2016-06-09T19:52:47  <luke-jr> one of which is currently getting full-RBF temporary usage
724 2016-06-09T19:52:50  <wumpus> Lightsword: that would completely make it unuseful for preferential peering
725 2016-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.
726 2016-06-09T19:53:12  <wumpus> Lightsword: (as neither addr messages nor the DNS seeds would be aware of the secondary mechanism)
727 2016-06-09T19:53:14  <gmaxwell> statically configuring it would be broken.
728 2016-06-09T19:53:29  <wumpus> why would you want to fix the entropy statically?
729 2016-06-09T19:53:33  <instagibbs> gmaxwell, perhaps setting cmpctblock as a tie-breaker for keeping connection?
730 2016-06-09T19:53:41  <gmaxwell> Okay, in any case, I think thats all I've got there.
731 2016-06-09T19:53:50  <btcdrak> ding ding, we have 7 mins remaining
732 2016-06-09T19:53:52  <instagibbs> well, I guess "he sent me blocks fast" is/will be one, same thing
733 2016-06-09T19:53:54  <cfields_> static entropy is much easier to test :p
734 2016-06-09T19:53:54  <gmaxwell> instagibbs: sounds like a fine additional ranker in the connection management stuff.
735 2016-06-09T19:54:05  <wumpus> instagibbs: +1
736 2016-06-09T19:54:06  <sipa> indeed
737 2016-06-09T19:54:13  <jeremyrubin> cfields_: yep
738 2016-06-09T19:54:16  <gmaxwell> instagibbs: though yea, the 'most recent blocks' probably mostly covers it.
739 2016-06-09T19:54:35  <BakSAj> which version are compact blocks planned for?
740 2016-06-09T19:54:40  <sipa> related to that: please review gmaxwell's patch for adding fast blkck and tx relayers for not evicted
741 2016-06-09T19:54:41  <jeremyrubin> gmaxwell: it doesn't harm security so long as it's kept secret from peers
742 2016-06-09T19:54:50  <btcdrak> BakSAj: 0.13.0
743 2016-06-09T19:54:51  <instagibbs> sipa, which number
744 2016-06-09T19:54:59  <sipa> instagibbs: sec
745 2016-06-09T19:55:04  <jeremyrubin> gmaxwell: nvm -- forgot you have to send it?
746 2016-06-09T19:55:07  <gmaxwell> jeremyrubin: the nonce used for compact blocks must be sent to peers or they can't recover the block.
747 2016-06-09T19:55:12  <petertodd> wumpus: we do have temporary service bits
748 2016-06-09T19:55:19  <BakSAj> btcdrak: thanks!
749 2016-06-09T19:55:33  <sdaftuar> gmaxwell: thoughts on #7598/#7600? you said above that you'd started review
750 2016-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?
751 2016-06-09T19:55:45  <sdaftuar> i still think it should be a priority to get those PRs merged for 0.13.0...
752 2016-06-09T19:55:47  <instagibbs> I don't think connecting to cmpctblock peers will be hard unless we get sybil'd by AWS forks
753 2016-06-09T19:55:57  <gmaxwell> sdaftuar: I like them and will ACK soon, once I come up with a useful way to test.
754 2016-06-09T19:56:08  <sipa> sdaftuar: me too, i started revieweing but got caught up on other things
755 2016-06-09T19:56:09  <gmaxwell> sdaftuar: I agree.
756 2016-06-09T19:56:24  <sipa> Lightsword: maybe
757 2016-06-09T19:56:41  <sipa> Lightsword: it's often hard to predict how long protocols live
758 2016-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.
759 2016-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
760 2016-06-09T19:56:54  <instagibbs> sipa, https://github.com/bitcoin/bitcoin/pull/8084
761 2016-06-09T19:56:59  <gmaxwell> There are a bunch of small things (including all of mine)
762 2016-06-09T19:57:16  <sipa> instagibbs: that one, thanks
763 2016-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 :)
764 2016-06-09T19:57:58  <sipa> cfields_: for how long?
765 2016-06-09T19:58:03  <sipa> a month?
766 2016-06-09T19:58:04  *** supasonic has joined #bitcoin-core-dev
767 2016-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
768 2016-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
769 2016-06-09T19:58:20  <wumpus> also SW is special
770 2016-06-09T19:58:30  <sipa> Lightsword: we should also have an evil bit that abusive nodes should set
771 2016-06-09T19:58:45  <gmaxwell> Lightsword: "the I am a DOS attack master node, please connect to me" flag?
772 2016-06-09T19:58:48  <Chris_St1> brilliant
773 2016-06-09T19:58:51  <btcdrak> sipa: ^.^
774 2016-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
775 2016-06-09T19:59:04  <cfields_> sipa: for ~10 days. I'll be gone for a month total, but working for the last few weeks.
776 2016-06-09T19:59:10  <sipa> i see
777 2016-06-09T19:59:23  <wumpus> he announced that well in advance
778 2016-06-09T19:59:30  <gmaxwell> lynch him!
779 2016-06-09T19:59:33  <luke-jr> cfields_: review of https://github.com/bitcoin/bitcoin/pull/5872 ? :D
780 2016-06-09T19:59:36  <gmaxwell> oh in advance, okay.
781 2016-06-09T19:59:38  <gmaxwell> :P
782 2016-06-09T19:59:47  <BakSAj> :-)
783 2016-06-09T19:59:54  <cfields_> luke-jr: added to the list, thanks
784 2016-06-09T20:00:01  <sipa> *ding dong*
785 2016-06-09T20:00:03  <instagibbs> wumpus, all-but-SF SW would be nice
786 2016-06-09T20:00:05  <wumpus> #endmeeting
787 2016-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)
788 2016-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
789 2016-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
790 2016-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
791 2016-06-09T20:00:18  <luke-jr> FWIW, I will also be travelling June 20th-early July (but probably semi-available and working)
792 2016-06-09T20:00:24  <sipa> thanks all, this was an interesting meeting
793 2016-06-09T20:00:29  <cfields_> along the same lines, review plea for #8128
794 2016-06-09T20:00:57  <wumpus> instagibbs: I know, just wanted the situation around SW to be clear for people reading the logs
795 2016-06-09T20:01:04  *** cryptapus has quit IRC
796 2016-06-09T20:01:05  <instagibbs> +1
797 2016-06-09T20:01:35  <BakSAj> btw, is there a rough estimate when 0.13.1 may come?
798 2016-06-09T20:01:47  <BakSAj> or version with segwit sf
799 2016-06-09T20:01:48  <instagibbs> Probably when a certain Softfork is ready....
800 2016-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.
801 2016-06-09T20:01:53  <luke-jr> BakSAj: "when it's ready"
802 2016-06-09T20:01:55  <btcdrak> BakSAj: SW will be released in 0.12.x
803 2016-06-09T20:01:57  <gmaxwell> BakSAj: 0.12.x
804 2016-06-09T20:02:05  <cfields_> luke-jr: btw, i believe I found your issue wrt out-of-tree build and chowning
805 2016-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.
806 2016-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.
807 2016-06-09T20:02:48  <luke-jr> aha
808 2016-06-09T20:02:52  <BakSAj> uf little confused
809 2016-06-09T20:03:06  <BakSAj> now you release 0.13.0 with segwit code
810 2016-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.
811 2016-06-09T20:03:14  <btcdrak> gmaxwell: BlueMatt just pushed the fixes to #8068 compact blocks
812 2016-06-09T20:03:18  <BakSAj> but then 0.12.2 with code and activation comes
813 2016-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
814 2016-06-09T20:03:29  <instagibbs> then will still show up in 0.13
815 2016-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.
816 2016-06-09T20:04:07  <BakSAj> wont this bring confusion whether to run 0.12.2 or 0.13 ?
817 2016-06-09T20:04:17  *** molz has joined #bitcoin-core-dev
818 2016-06-09T20:04:37  <instagibbs> btcdrak, sigh, my block hit rate is going to poop :(
819 2016-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 ." ?
820 2016-06-09T20:04:47  <sipa> BakSAj: what os are you running?
821 2016-06-09T20:04:51  <luke-jr> BakSAj: there is no one version everyone must run
822 2016-06-09T20:05:01  <gmaxwell> instagibbs: start up the relay node client for a bit to prefill your mempool.
823 2016-06-09T20:05:07  <BakSAj> sipa ?
824 2016-06-09T20:05:08  <luke-jr> cfields_: eh, that sounds like a noop?
825 2016-06-09T20:05:15  <instagibbs> gmaxwell, hmm ok pretty sure I have that installed
826 2016-06-09T20:05:18  <btcdrak> instagibbs: well you could spin up a new node instead...
827 2016-06-09T20:05:19  <sipa> BakSAj: what version of your os are you running.
828 2016-06-09T20:05:24  <cfields_> luke-jr: er, sorry...
829 2016-06-09T20:05:34  <cfields_> luke-jr: "chown -R user:user .git"
830 2016-06-09T20:05:40  <BakSAj> sipa: for full node?
831 2016-06-09T20:05:52  <btcdrak> instagibbs: rsync your chainstate etc.
832 2016-06-09T20:05:55  <sipa> BakSAj: whatever, i'm trying to make an analogu
833 2016-06-09T20:06:04  *** moli has quit IRC
834 2016-06-09T20:06:07  <BakSAj> lol, win10
835 2016-06-09T20:06:10  <sipa> BakSAj: you run 0.12.x to get more stable/tested code
836 2016-06-09T20:06:24  <sipa> BakSAj: you run 0.13.0 to get the latest and greates
837 2016-06-09T20:06:39  <sipa> and segwit is independent of that
838 2016-06-09T20:06:50  <sipa> it will be released in a point update to both
839 2016-06-09T20:07:09  <gmaxwell> SW is not a client feature, it's part of the network protocol.
840 2016-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
841 2016-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
842 2016-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.
843 2016-06-09T20:07:59  <luke-jr> SW introduction is independent from Core's release cycle
844 2016-06-09T20:08:03  <sipa> BakSAj: because in order to enable SW, we need many code changes
845 2016-06-09T20:08:29  <sipa> BakSAj: it's a pita to keep maintaining those in parallel when we know the code worms
846 2016-06-09T20:08:32  <sipa> *works
847 2016-06-09T20:08:46  <BakSAj> ah
848 2016-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
849 2016-06-09T20:09:01  <BakSAj> i had bad assumption about 0.13.0
850 2016-06-09T20:09:07  <BakSAj> guys, thanks for explanation
851 2016-06-09T20:09:19  <gmaxwell> btcdrak: in the future, please wait for travis to finish before nagging people to update. :)
852 2016-06-09T20:09:33  <BakSAj> got it now
853 2016-06-09T20:10:20  *** bsm1175322 has joined #bitcoin-core-dev
854 2016-06-09T20:10:32  <BakSAj> https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
855 2016-06-09T20:10:38  <BakSAj> mayb needs little refurbish
856 2016-06-09T20:10:43  <BakSAj> dates and staff
857 2016-06-09T20:11:17  *** bsm1175321 has quit IRC
858 2016-06-09T20:11:24  <instagibbs> BakSAj, the section on the site about life cycle needs a refurb
859 2016-06-09T20:11:34  <BakSAj> if i can speak for little educated public :-) i would prefer complex btc roadmap
860 2016-06-09T20:11:49  <BakSAj> not just capacity increase roadmap
861 2016-06-09T20:12:52  <btcdrak> gmaxwell: noted
862 2016-06-09T20:13:02  *** jtimon has quit IRC
863 2016-06-09T20:15:07  *** moli has joined #bitcoin-core-dev
864 2016-06-09T20:15:48  *** bsm1175322 has quit IRC
865 2016-06-09T20:17:35  *** molz has quit IRC
866 2016-06-09T20:19:53  *** spikey has joined #bitcoin-core-dev
867 2016-06-09T20:23:51  *** spikeheadon has quit IRC
868 2016-06-09T20:24:05  *** spikeheadon has joined #bitcoin-core-dev
869 2016-06-09T20:25:41  *** spikey has quit IRC
870 2016-06-09T20:30:01  *** ozanyurt has joined #bitcoin-core-dev
871 2016-06-09T20:44:42  *** ebfull has quit IRC
872 2016-06-09T20:46:27  *** BakSAj has quit IRC
873 2016-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"
874 2016-06-09T20:50:24  <dgenr8> sipa: it looks like there is no way query ledger entries like this (or those created by move) :/
875 2016-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
876 2016-06-09T20:52:23  <sipa> dgenr8: receive accounts are a property of incoming payments, not utxos
877 2016-06-09T20:52:50  <sipa> dgenr8: the fact that a send is not reflected in getbalance is a bug
878 2016-06-09T20:53:18  <dgenr8> I guess was speaking loosely ... i mean it has a txid and a vout, and it is unspent :)
879 2016-06-09T21:07:39  *** laurentmt has joined #bitcoin-core-dev
880 2016-06-09T21:07:40  *** laurentmt has quit IRC
881 2016-06-09T21:10:40  *** achow101 has quit IRC
882 2016-06-09T21:11:54  *** Chris_St1 has quit IRC
883 2016-06-09T21:13:00  *** Evel-Knievel has quit IRC
884 2016-06-09T21:15:20  *** Evel-Knievel has joined #bitcoin-core-dev
885 2016-06-09T21:23:42  *** achow101 has joined #bitcoin-core-dev
886 2016-06-09T21:53:11  *** _anthony_ has quit IRC
887 2016-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
888 2016-06-09T22:27:48  *** Guyver2 has quit IRC
889 2016-06-09T22:33:57  *** AaronvanW has quit IRC
890 2016-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
891 2016-06-09T22:53:04  *** spikeheadon has quit IRC
892 2016-06-09T22:56:14  *** zooko` has joined #bitcoin-core-dev
893 2016-06-09T23:02:35  *** zooko` has quit IRC
894 2016-06-09T23:03:52  *** zooko` has joined #bitcoin-core-dev
895 2016-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
896 2016-06-09T23:11:37  *** jtimon has joined #bitcoin-core-dev
897 2016-06-09T23:40:25  *** MarcoFalke has left #bitcoin-core-dev
898 2016-06-09T23:43:39  *** blur3d has joined #bitcoin-core-dev
899 2016-06-09T23:49:55  *** ghtdak has quit IRC
900 2016-06-09T23:51:04  *** skyraider has joined #bitcoin-core-dev
901 2016-06-09T23:53:41  *** AaronvanW has joined #bitcoin-core-dev
902 2016-06-09T23:53:58  *** AaronvanW has quit IRC
903 2016-06-09T23:53:58  *** AaronvanW has joined #bitcoin-core-dev
904 2016-06-09T23:59:52  *** zooko` has quit IRC