--- Day changed Thu Jun 09 2016 00:04 < 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) 00:08 < jonasschnelli> sipa: Willing to test https://github.com/bitcoin/bitcoin/pull/8035? Would be great to make progress before 0.13 here. 00:08 < 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? 00:19 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xkflfwcunnfppyaq] has joined #bitcoin-core-dev 00:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 00:27 < paveljanik> github Unircorn 8) 00:28 < jonasschnelli> argh... again... 00:28 < jonasschnelli> We need a decentralized github web. :) 00:29 < sipa> You mean git? 00:29 < jonasschnelli> hehe... 00:29 < jonasschnelli> Yes. With the option of creating issues, public announcements of pull requests, etc. 00:47 < 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 00:49 < warren> Does the git repo use signed merge commits? 00:49 < btcdrak> wumpus: maintenance is a bitch. 00:50 < sipa> warren: we always gpg sign merge commits 00:50 < btcdrak> warren: yes. 00:50 < sipa> warren: and there is a script to verify that 00:52 < jonasschnelli> wumpus: you mean mirroring the github data? 00:52 < jonasschnelli> Or just the git? 00:52 < wumpus> just the git 00:53 < jonasschnelli> Okay. That would be trivial. 00:53 < wumpus> we do mirror the github data in a github repository, could also push that there 00:53 < jonasschnelli> btcdrak: where is bitcoincore.org hosted? 00:53 < btcdrak> I'm sure the odd Github Unicorn doesnt cause us _that_ much trouble. 00:53 < btcdrak> jonasschnelli: the website is at github :) 00:53 < sipa> wumpus: wgat 00:53 -!- adiabat [~adiabat@159.203.193.74] has quit [Quit: Leaving.] 00:53 < jonasschnelli> Yes. But we can't work on a decentralized system on a centralized github. :) 00:53 < btcdrak> but can set a DNS entry to any server... 00:53 < btcdrak> (a subdomain I mean) 00:54 < btcdrak> jonasschnelli: decentralisation is a myth in this case. 00:54 < wumpus> we've been signing merge commits consistently from ~2013 or so, and were one of the first projects to do this 00:55 < sipa> unfortunately git commit ids are only sha1 :( 00:55 < wumpus> well it's not perfect security but certainly puts of a barrier, which is the point of any security feature 00:55 < btcdrak> i love how this entire conversation comes up almost verbatim again every now and again :) 00:56 < wumpus> we're like broken records 00:56 < btcdrak> mayeb I should write a FAQ :-p 00:58 < 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 00:58 < wumpus> please include a "database corrupted" entry 00:59 < wumpus> really doesn't help that everyone creates a new issue every time they get that 00:59 < wumpus> where 99 out of 100 times it's simply a hardware problem 01:00 < btcdrak> agreed, I think there are a bunch of common issue we could cover. 01:00 < wumpus> we really should discourage people from creating new issues about that, unless there's new information to report 01:00 < wumpus> maybe they could post to an existing issue for statistics or something 01:01 < gmaxwell> change the message to "Apparent hardware error" :) 01:02 < 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 01:03 < wumpus> gmaxwell: yes, that would be a good idea 01:04 < paveljanik> maybe even a link to the FAQ entry about this? 01:06 < sipa> nobody believes you when you tell them their hardware is broken 01:06 < gmaxwell> a few do. 01:06 < wumpus> still, it helps to have it written down somewhere 01:06 < wumpus> in a clear way 01:06 < wumpus> instead of repeating it all the time, increasingly annoyed :) 01:06 < gmaxwell> I actually think they believe it from the sofware more than names on IRC. 01:07 < 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' 01:07 < gmaxwell> and they show up "hey you morons still haven't fixed this!" 01:07 < gmaxwell> they also run -rescan ten times and it won't go away and why should they have to run it an eleventh!? 01:08 < gmaxwell> Is there a german word for where you both feel apologetic towards someone and want to strangle them? 01:10 < wumpus> the thing is, even if there are software bugs involved, opening more issues about it isn't going to help a thing 01:11 < 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. 01:11 < wumpus> I think I'm going to create one 'data corruption' issue and close the others as duplicates 01:11 < gmaxwell> Same reason why reports seldom have the information required to reproduce the issue. 01:12 < wumpus> well most issues are fairly good in that regard 01:12 < gmaxwell> if we had simply forgotten, reporting again would help-- and we do, from time to time, forget actual issues. 01:12 < wumpus> generally not issues that are reported on github 01:12 < gmaxwell> Right. 01:12 < wumpus> sure, if something is said on IRC or the mailing list it gets lost 01:12 < gmaxwell> at least not while they're still open. 01:12 < wumpus> the point of an issue tracker is to have a persistent URL for an issue 01:13 < gmaxwell> But clearly we've fogotten the data corruption because it keeps hapenning. :P QED. 01:13 < wumpus> if it gets too crowded it loses its value 01:14 < wumpus> then it's just like mentioning it once on reddit, no one will ever look back to it 01:14 < wumpus> heh 01:14 < wumpus> well every time I had actual data corruption I investigated in depth 01:16 < 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? 01:17 < gmaxwell> it's called bitcoind. 01:17 < wumpus> it will take long to detect errors, so no one will run that 01:17 < wumpus> heh exactly 01:17 < gmaxwell> it's not just leveldb though, the cpu load from signature validation triggers memory errors on some systems. 01:17 < jonasschnelli> Okay.. :) 01:17 < gmaxwell> when we have wumpus' snapshot stuff perhaps we could also do other things to retry/recover in the face of error. 01:18 < wumpus> there are just so many types of hardware problems that can result in corruptions 01:18 < gmaxwell> I have mixed feelings, users really shouldn't count on faulty computers... esp for handling irreversable money... 01:19 < wumpus> and there is software to detect hardware problems, that's a completely orthogonal thing :) 01:19 < jonasschnelli> Right. Agree. 01:19 < 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...) 01:20 < 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. 01:20 < jonasschnelli> Wumpuses snapshot idea would be a live-safer for such situations 01:23 < GitHub178> [bitcoin] laanwj closed pull request #7938: [0.12.2] Backports (0.12...Mf1604-012backp) https://github.com/bitcoin/bitcoin/pull/7938 01:23 < GitHub74> [bitcoin] laanwj pushed 15 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/e7ec24e336dc...20d00a180ee6 01:23 < GitHub74> bitcoin/0.12 9095594 ptschip: Do not download transactions during inital sync... 01:23 < GitHub74> bitcoin/0.12 a9e73f7 instagibbs: Fix and cleanup listreceivedbyX documentation... 01:23 < GitHub74> bitcoin/0.12 64fd0ce jloughry: fix spelling of advertise in src and doc... 01:28 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has quit [Remote host closed the connection] 01:29 < paveljanik> Can you kick travis on #8109 please? 01:30 < paveljanik> ah, I can do that myself by simply rebasing it. 01:41 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has joined #bitcoin-core-dev 01:42 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 01:43 -!- challisto [~challisto@c-76-16-149-33.hsd1.il.comcast.net] has joined #bitcoin-core-dev 01:43 -!- challisto [~challisto@c-76-16-149-33.hsd1.il.comcast.net] has quit [Changing host] 01:43 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev 01:44 -!- challisto [~challisto@unaffiliated/challisto] has quit [Client Quit] 01:47 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 250 seconds] 01:51 < GitHub89> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b5279f89c9a...172cd7f10c7e 01:51 < GitHub89> bitcoin/master cdf7dff Jonas Schnelli: OSX diskimages need 0775 folder permissions... 01:51 < GitHub89> bitcoin/master 172cd7f Wladimir J. van der Laan: Merge #8169: OSX diskimages need 0775 folder permissions... 01:51 < 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 01:53 < GitHub177> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/0f8d574e8f6521c07ae204b4f8b61d1534f03c21 01:53 < GitHub177> bitcoin/0.12 0f8d574 Jonas Schnelli: OSX diskimages need 0775 folder permissions... 01:55 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 244 seconds] 01:56 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev 01:56 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Remote host closed the connection] 02:03 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 244 seconds] 02:08 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev 02:08 -!- ozanyurt [~ozanyurt@178.162.216.49] has quit [Quit: Textual IRC Client: www.textualapp.com] 02:12 < 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 02:14 < GitHub131> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/172cd7f10c7e...fd9881ae6782 02:14 < GitHub131> bitcoin/master fa58c76 MarcoFalke: [gitian] Default reference_datetime to commit author date 02:14 < GitHub131> bitcoin/master fa42a67 MarcoFalke: [gitian] hardcode datetime for depends 02:14 < GitHub131> bitcoin/master fd9881a Wladimir J. van der Laan: Merge #7283: [gitian] Default reference_datetime to commit author date... 02:14 < 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 02:17 < 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 02:22 < 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 02:22 -!- edward [~edward@4angle.com] has left #bitcoin-core-dev ["Leaving"] 02:30 -!- STAFFSCOINS_ [521b07f8@gateway/web/freenode/ip.82.27.7.248] has quit [K-Lined] 02:30 -!- iniana [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [K-Lined] 02:30 -!- assder [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has quit [K-Lined] 02:47 -!- fedefranz [~ffranzoni@84.89.157.108] has joined #bitcoin-core-dev 02:49 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev 03:06 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 03:08 -!- AaronvanW [~ewout@220pc230.sshunet.nl] has joined #bitcoin-core-dev 03:08 -!- AaronvanW [~ewout@220pc230.sshunet.nl] has quit [Changing host] 03:08 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:26 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Ping timeout: 240 seconds] 03:28 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev 03:31 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit] 03:43 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 03:43 < MarcoFalke> wumpus: Can you explain why you left BUILD_DATE in share/genbuild.sh ? 03:43 < MarcoFalke> Is it used elsewhere? 03:46 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has quit [Read error: Connection reset by peer] 03:46 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has joined #bitcoin-core-dev 03:51 -!- spikeheadon [~spikes@122.175.246.22] has joined #bitcoin-core-dev 03:51 -!- spikey [~spikes@122.175.246.22] has joined #bitcoin-core-dev 03:52 -!- spikey [~spikes@122.175.246.22] has quit [Remote host closed the connection] 04:30 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 04:32 < wumpus> MarcoFalke: probably an oversight, or I wasn't sure, let me see 04:33 < wumpus> yes that can definitely go 04:59 -!- spikey [~spikes@122.168.199.215] has joined #bitcoin-core-dev 05:03 -!- spikeheadon [~spikes@122.175.246.22] has quit [Ping timeout: 240 seconds] 05:11 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xkflfwcunnfppyaq] has quit [Quit: Connection closed for inactivity] 05:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:23 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has quit [Remote host closed the connection] 05:47 -!- lysobit- [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 250 seconds] 05:48 -!- musalbas [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 272 seconds] 06:27 < 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(??) 06:27 < instagibbs> "// getbalance and "getbalance * 1 true" should return the same number" 06:28 < instagibbs> oh the latter is probably me being dumb, but I still am getting weird balances 06:29 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 06:30 < sipa> instagibbs: https://github.com/bitcoin/bitcoin/pull/7715 ? 06:32 < instagibbs> thanks, is that comment supposed to be correct? I'm getting different balances 06:36 < sipa> are you typing "getbalance * 1 true" on the command line? that will expand * to the list of files in your current directory 06:36 < instagibbs> i was, but i escaped it yes 06:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 06:37 < instagibbs> If I send funds to myself in regtest, it immediately shows up in getbalance, but not getbalance * 1 true 06:37 < sipa> then how do you get a parsing error? 06:37 < instagibbs> no that was my 2nd issue, now fixed 06:37 < sipa> ah, getbalance will show unconfirmed sends from yourself 06:37 < instagibbs> well... I will change that comment then 06:37 < instagibbs> thanks 06:38 < sipa> that comment is very very old 06:38 < sipa> 2010, i expect 06:39 < instagibbs> 2015? 06:39 < instagibbs> according to git blame 06:39 < sipa> oh 06:39 < instagibbs> dgenr8 one-line addition 06:40 < instagibbs> Anyways, I'll PR if that's expected behavior 06:41 < sipa> if you disable -spendzeroconfchange, it may work 06:41 < sipa> s/work/hold true/ 06:41 < instagibbs> ok 06:52 < instagibbs> still a slight difference with spendzeroconfchange disabled, hmm 06:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:52 -!- G1lius [~stefangil@94.242.219.130] has joined #bitcoin-core-dev 07:10 -!- spikeheadon [~spikes@38.95.109.70] has joined #bitcoin-core-dev 07:11 -!- spikeheadon [~spikes@38.95.109.70] has quit [Max SendQ exceeded] 07:11 -!- spikeheadon [~spikes@38.95.109.70] has joined #bitcoin-core-dev 07:12 -!- spikey [~spikes@122.168.199.215] has quit [Ping timeout: 244 seconds] 07:12 -!- spikeheadon [~spikes@38.95.109.70] has quit [Max SendQ exceeded] 07:13 -!- spikeheadon [~spikes@38.95.109.70] has joined #bitcoin-core-dev 07:14 -!- spikeheadon [~spikes@38.95.109.70] has quit [Max SendQ exceeded] 07:15 -!- spikeheadon [~spikes@38.95.109.70] has joined #bitcoin-core-dev 07:16 -!- spikeheadon [~spikes@38.95.109.70] has quit [Max SendQ exceeded] 07:16 -!- spikeheadon [~spikes@38.95.109.70] has joined #bitcoin-core-dev 07:18 -!- spikeheadon [~spikes@38.95.109.70] has quit [Max SendQ exceeded] 07:18 -!- spikeheadon [~spikes@38.95.109.70] has joined #bitcoin-core-dev 07:29 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev 07:32 < GitHub84> [bitcoin] sipa pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd9881ae6782...7ce9ac5c83b1 07:33 < GitHub84> bitcoin/master 5ec0cde Suhas Daftuar: Refactor logic for converting mempool entries to JSON 07:33 < GitHub84> bitcoin/master 8f7b5dc Suhas Daftuar: Add getmempoolancestors RPC call 07:33 < GitHub84> bitcoin/master 0dfd869 Suhas Daftuar: Add getmempooldescendants RPC call 07:33 < 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 07:42 < GitHub198> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7ce9ac5c83b1...f7b1bfc9a347 07:42 < GitHub198> bitcoin/master 3144449 Pieter Wuille: Add git and github tips and tricks to developer notes 07:42 < GitHub198> bitcoin/master f7b1bfc Wladimir J. van der Laan: Merge #8178: Add git and github tips and tricks to developer notes... 07:42 < 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 07:44 < GitHub172> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f7b1bfc9a347...32b7294177e5 07:44 < GitHub172> bitcoin/master 0d53a9e Luke Dashjr: Update luke-jr's PGP key... 07:44 < GitHub172> bitcoin/master 32b7294 Wladimir J. van der Laan: Merge #8180: Update luke-jr's PGP key... 07:44 < GitHub194> [bitcoin] laanwj closed pull request #8180: Update luke-jr's PGP key (master...2016_pgp_update) https://github.com/bitcoin/bitcoin/pull/8180 07:52 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 08:02 -!- dingus [~grubles@unaffiliated/grubles] has quit [Read error: Connection reset by peer] 08:19 -!- spikeheadon [~spikes@38.95.109.70] has quit [Ping timeout: 240 seconds] 08:20 < 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) 08:21 < dgenr8> instagibbs: also sendfrom "A" seems to not work in a test I just just (it selected a utxo not belonging to "A") 08:21 < dgenr8> justdid 08:22 < instagibbs> yeah i opened an issue 08:22 < instagibbs> since im not sure what the comment should be changed to 08:22 < instagibbs> there are nooks and crannies depending on settings you are running 08:25 < dgenr8> agreed that since -spendzeroconfchange affects the result of getbalance, the comment is too general. prolly just remove it 08:26 < sipa> dgenr8: sendfrom just subtracts the balance from A; it always uses all utxos 08:26 < sipa> dgenr8: as accounts don't own utxos in any way 08:26 < instagibbs> dgenr8, yes I think removal is best 08:32 -!- blur3d [~blur3d@49.187.26.218] has quit [Ping timeout: 276 seconds] 08:32 -!- fengling [~fengling@124.205.63.0] has joined #bitcoin-core-dev 08:34 < sipa> dgenr8: also, do you feel like addresses the comments on your partition check improvement? 08:34 < sipa> *addressing 08:36 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 08:38 -!- spikeheadon [~spikes@199.115.115.209] has joined #bitcoin-core-dev 08:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 08:47 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 272 seconds] 08:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:55 -!- spikeheadon [~spikes@199.115.115.209] has quit [Ping timeout: 276 seconds] 08:55 -!- fengling [~fengling@124.205.63.0] has quit [Ping timeout: 240 seconds] 08:55 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 08:56 -!- grubles is now known as dingus 08:57 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 09:02 -!- fedefranz [~ffranzoni@84.89.157.108] has left #bitcoin-core-dev [] 09:02 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 09:04 -!- G1lius [~stefangil@94.242.219.130] has quit [Read error: Connection reset by peer] 09:08 -!- mkarrer_ [~mkarrer@3.red-83-55-151.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 09:08 -!- mkarrer [~mkarrer@3.red-83-55-151.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer] 09:08 -!- mkarrer_ [~mkarrer@3.red-83-55-151.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 09:23 -!- fengling [~fengling@124.205.63.0] has joined #bitcoin-core-dev 09:32 < gmaxwell> 2016-06-09 08:46:38.763465 [0%]...[50%]...[99%]...[DONE]. 09:32 < gmaxwell> Is it really okay to dribble out a log entry over a long time? Not going to break external log handling? 09:36 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 09:51 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer] 09:51 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 10:02 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Quit: leaving] 10:03 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .] 10:05 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 10:07 -!- JackH_ [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 10:08 -!- JackH [~Jack@79-73-185-113.dynamic.dsl.as9105.com] has quit [Ping timeout: 250 seconds] 10:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 10:18 -!- spikeheadon [~spikes@107.169.246.6] has joined #bitcoin-core-dev 10:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:28 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 10:45 < GitHub16> [bitcoin] theuni opened pull request #8184: WIP: OSX toolchain bump (master...osx-sdk-bump) https://github.com/bitcoin/bitcoin/pull/8184 10:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 11:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 11:15 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 11:17 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 11:20 < wumpus> gmaxwell: sure, an external log handler would just wait for the line to complete 11:21 < gmaxwell> K. I've never considered that case before and thought it potentially useful to raise the question. 11:21 < wumpus> there's no rule that log messages need to be written within a certain time 11:21 < gmaxwell> well generally we should write them a line at a time or otherwise we'll get log entries split by threads. 11:22 < wumpus> yes, that came up during review too, it can be done here because there is nothing else running at that time 11:22 < wumpus> and this is less spammy than printing a line for every N% 11:23 < gmaxwell> Right. I agree that it can be done here. 11:26 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-yocfnzfbqiscqcye] has joined #bitcoin-core-dev 11:32 -!- BakSAj [59b1487b@gateway/web/freenode/ip.89.177.72.123] has joined #bitcoin-core-dev 11:32 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev 11:33 < BakSAj> hi 11:36 < BakSAj> http://bitcoin.sipa.be/ver9-2k.png 11:36 < BakSAj> i like the picture :-) 11:36 < BakSAj> not sure if we make it to 95% in this diff period 11:36 < gmaxwell> mostly depends on KNC going offline again or not. 11:37 < adam3us> they maybe selling the equipment 11:42 < BakSAj> lets hope... 11:43 < BakSAj> on the other hand its a bit sad that hash will get little more centralized when this EU miner ends 11:47 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Quit: laurentmt] 11:48 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev 11:48 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-btoxsexdzqtodijk] has quit [Ping timeout: 240 seconds] 11:50 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-gxpomwonphpiiorn] has joined #bitcoin-core-dev 11:55 -!- hsmiths2 [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev 11:58 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Read error: Connection reset by peer] 12:00 < jonasschnelli> meeting? 12:00 < gmaxwell> Meeting time. 12:00 < wumpus> yes 12:00 < wumpus> #meetingstart 12:00 < wumpus> #startmeeting 12:00 < lightningbot> Meeting started Thu Jun 9 19:00:38 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:00 -!- sean___ [~sean@c-50-170-183-94.hsd1.co.comcast.net] has joined #bitcoin-core-dev 12:00 -!- sean___ is now known as ebfull 12:01 < gmaxwell> phantomcircuit: sipa: morcos: sdaftuar: btcdrak: jonasschnelli: luke-jr: 12:01 < 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. 12:01 < gmaxwell> petertodd: MarcoFalke: 12:01 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Quit: laurentmt] 12:01 < wumpus> #link 0.13 release schedule: https://github.com/bitcoin/bitcoin/issues/7679 12:01 < MarcoFalke> any topic suggestions today? 12:02 < gmaxwell> We can talk some about ongoing compact block testings, I have a few things to report. 12:02 < 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 12:02 < 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 12:02 < gmaxwell> instagibbs: nickler: NicolasDorier: CodeShark: 12:03 < CodeShark> yo 12:03 < MarcoFalke> cfields_: I think p2p refactor can go in after the feature freeze? 12:03 < gmaxwell> We apparently can no longer compile on hosts with only 2GB ram with defaults. 12:03 < 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 12:03 < MarcoFalke> I mean it is not a new feature ;) 12:04 < gmaxwell> well it was more like 1.5GB ram before. 12:04 -!- jeremyrubin [~jeremyrub@biohazard-cafe.mit.edu] has joined #bitcoin-core-dev 12:04 < wumpus> others have not yet finished: #7598 (Refactor CreateNewBlock to be a method of the BlockAssembler class) 12:04 < jonasschnelli> gmaxwell: I compiled on a 2GG AARCH this week successfully. 12:04 < jonasschnelli> *GB 12:04 < gmaxwell> We have docs that say 1.5GB, they're gonna be like the blocksize on bitcoin.org :) 12:04 < wumpus> #7600 Mining: Select transactions using feerate-with-ancestors 12:04 < wumpus> depends on what else is running on the machine 12:05 < gmaxwell> I've been going through #7598/#7600. 12:05 < wumpus> #topic compile-time memory usage 12:05 < wumpus> what can *concretely* be done here? 12:05 < jonasschnelli> would kick out boost help? 12:05 < luke-jr> -O0 12:06 < wumpus> is it something worrying? 12:06 < cfields_> has anyone measured to see if there are particular objects that are especially guilty? 12:06 < CodeShark> what's eating up all the RAM? 12:06 < wumpus> yes, we have cfields_ 12:06 < cfields_> ie. main.cpp/net.cpp ? 12:06 < luke-jr> CodeShark: ld/GCC doesn't free memory 12:06 < wumpus> especialy some autogenerated c++ files 12:06 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev 12:06 < wumpus> I made some tables back in the issue about this 12:06 < gmaxwell> main.cpp, matt has a patch that moves all the mempool stuff out of it taht apparently gets it back to 1.5GB. 12:06 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit] 12:06 < luke-jr> CFLAGS="-O0 -g0 --param ggc-min-expand=0 --param ggc-min-heapsize=32768" 12:06 < wumpus> #link https://github.com/bitcoin/bitcoin/issues/7471 12:06 < gmaxwell> I dunno why he hasn't PRed it, I asked him to. 12:07 < cfields_> wumpus: thanks 12:07 < wumpus> eeh that's the wrong one 12:07 < gmaxwell> wumpus: unthanks 12:07 < wumpus> well it is about the same subject 12:07 < wumpus> #link https://github.com/bitcoin/bitcoin/issues/6658 12:07 < wumpus> lots of people have posted about it, but there doesn't seem to be a clear solution 12:08 < jonasschnelli> main.cpp -> 1248524bytes ... ^^ 12:08 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 12:08 < wumpus> reducing the number of included headers works, I think 12:08 < sipa> present 12:08 < cfields_> I have PRs which break up net.h/netbase.h, i'd be curious to see if those make a significant difference 12:09 < gmaxwell> in any case, something to be aware of and nudge a bit at... some refactorings to move code around would help. 12:09 < wumpus> also building with clang helps 12:09 < wumpus> it uses a lot less memory at the same compile settings, usually 12:09 < gmaxwell> and be independantly good for reasons unrelated to peak memory usage. 12:10 < cfields_> i'd assume that mem usage correlates solidly with compile time 12:10 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds] 12:10 < CodeShark> not so sure - lots of small files might mean the bottleneck is disk access 12:11 < sipa> CodeShark: come on 12:11 < CodeShark> in any case, it would be good to bring down the peak mem usage 12:11 < wumpus> the bottleneck in compilation is hardly ever disk access, at least *reading* disk access 12:11 < sipa> reading in 100 files? 12:11 < sipa> sequentially 12:12 < BakSAj> would be cool, if btc full nodes could continue to be runnable on Rasberry Pi ... with 1GB RAM 12:12 < jeremyrubin> BakSAj: runnable is not compileable on? 12:12 < 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. 12:12 < 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 12:13 < cfields_> heh, disk is negligible. It's easy to see where time is spent with -ftime-report. 12:13 < wumpus> but like always: measure before you start talking about bottlenecks 12:13 < 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 12:13 < BakSAj> jeremyrubin: preferably both compileable and operatable 12:13 < wumpus> BakSAj: for small embedded systems you should use cross-compilation 12:14 < cfields_> jonasschnelli: i'm halfway through the changes needed there. 12:14 < jeremyrubin> i have had machines take a bit of time on autogen.sh fyi 12:14 < jonasschnelli> cfields_: nice. Focus on Qt5.6 first. :) 12:14 -!- hsmiths2 [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 250 seconds] 12:14 < wumpus> you can cross compile on ARM using depends, we just don't distribute ARM binaries 12:14 < cfields_> jonasschnelli: actually, arm/aarch64 already work fine with depends. Just have to use NO_QT=1 manually. 12:14 < wumpus> s/on/to 12:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 12:14 < 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. 12:14 < wumpus> cfields_: yes, it works fine 12:14 < luke-jr> for comparison, webkit-based stuff typically uses up to 12 GB RAM with debug symbols, and much much less without.. 12:14 < gmaxwell> er isn't the empty set, you get what I mean. 12:15 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev 12:15 < cfields_> luke-jr: oh, good point... 12:15 < wumpus> it's *very easy* tocross compile for ARM 12:15 < jonasschnelli> I think NO_QT=1 for ARM/AARCH64 could be a start (even for "official binaries"). 12:15 < wumpus> with the depends system 12:15 < wumpus> jonasschnelli: yes 12:15 < cfields_> the gitian-debug PR turns on debug symbols, so gitian mem requirement is bumped after that. 12:15 < gmaxwell> wumpus: a lot of people using rpi2 like systems do not have another linux host. 12:15 < luke-jr> wumpus: that builds static binaries, which is wasteful on RAM 12:15 < jonasschnelli> Also ARM is used more and more for GUI systems. 12:15 < jeremyrubin> can autogen.sh be made faster? 12:16 < wumpus> jeremyrubin: no 12:16 < wumpus> not by us, at least 12:16 < 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 12:16 < 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. 12:16 < BakSAj> since suprisingly many nodes run on rpi 12:16 < jeremyrubin> wumpus: maybe the one thing that is fixed by a faster disk 12:16 < luke-jr> jonasschnelli: I'm thinking more of Bitcoin-Qt 12:16 < cfields_> jonasschnelli: as qt's gui plugin situation improves, we may be able to move back to the shared-qt builds 12:17 < 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 12:17 < MarcoFalke> jonasschnelli: I think we already have notes on how to corss compile to arm? 12:17 < jonasschnelli> Agree. Static linking qt is not ideal. But lets don't roll this up again. 12:17 < MarcoFalke> https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#arm-cross-compilation 12:17 < btcdrak> oh meeting 12:17 < jonasschnelli> MarcoFalke: notes, yes. But it should be included in our release builds (gitian) 12:17 < MarcoFalke> jup, agree 12:17 < cfields_> jonasschnelli: sorry, i meant that directly in the context of shipping arm+gui binaries 12:17 < luke-jr> jonasschnelli: for now, people just compile natively to avoid static, so suggesting cross-compile isn't a real option 12:18 < 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 :) 12:18 * gmaxwell looks forward to arm (+gui) binaries in the sometime future. 12:18 < 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 12:18 * luke-jr fully intends to use an ARM system with Core(Knots) as his hot wallet in some months. 12:18 < cfields_> jeremyrubin: you can use a quicker shell for autogen. IIRC dash vs. bash shaves a few seconds off 12:19 < luke-jr> autogen.sh isn't even part of building; it's a developer tool 12:19 < wumpus> well arm non-GUI binaries would already be a great step forward, one step at a tme 12:19 < cfields_> wumpus: ah, as a feature-freeze request: ok to plan on arm bins (without gui) for 0.13 ? 12:19 < luke-jr> if you're running autogen.sh, that means you're running from git, and you shouldn't do that 12:19 < cfields_> i can try to have that done today 12:19 < jonasschnelli> cfields_: ack, +1 12:19 < wumpus> I think arm gui would be prett much a per-distro afair 12:19 < wumpus> cfields_: sure! 12:19 < luke-jr> cfields_: +1 12:19 < jeremyrubin> luke-jr: are we making build faster for developers or for users? 12:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:19 < gmaxwell> +1 12:19 < cfields_> ok 12:20 < luke-jr> jeremyrubin: I think the concern is "ability to build" rather than "speed to build" 12:20 < gmaxwell> jeremyrubin: users shouldn't need to run autogen-- if they get the source tarballs we have, it should already be autogenned. 12:20 < cfields_> ^^ 12:20 < BakSAj> cool, rpi fans will love you :-) 12:20 < 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 12:20 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion] 12:20 < BakSAj> next step - run full node on cell phone :-) 12:21 < jeremyrubin> wumpus: ++ 12:21 < luke-jr> BakSAj: I believe a number of people have done this. 12:21 < wumpus> BakSAj: people are doing that actually, that's one of the motivations for the ARM binaries 12:21 < BakSAj> lol ok 12:21 < luke-jr> next step is therefore to support SPV mode when bandwidth is expensive ;) 12:21 < gmaxwell> BakSAj: abcore, it works fine. 12:21 < jonasschnelli> luke-jr: +1 12:21 < luke-jr> but that's post-0.13 IMO 12:21 < wumpus> absolutely 12: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 12:22 < luke-jr> can we get in [8-bit] key generation type? 12:23 < jonasschnelli> 32bit! 12:23 < jonasschnelli> You can provide a migration patch for Knots 12:23 < jonasschnelli> Isn't that trivial? 12:23 < BakSAj> will 0.13 contain just segwit code or actual softfork also? tnx 12:24 < jonasschnelli> SW SF can be 0.13.1 12:24 < jonasschnelli> SW are mostly not coupled with major releases 12:24 < jeremyrubin> I think that 0.13.1 will be worse for upgrade times 12:24 < wumpus> SW should be released in a minor release 12:24 < jeremyrubin> does anyone have data on that 12:24 < gmaxwell> BakSAj: major releases do not contain network consensus changes. 12:24 < sdaftuar> do we think segwit is going in to 0.13? 12:24 < sdaftuar> (without activation scheduled) 12:24 < jeremyrubin> wumpus: isn't it a major change? 12:24 < petertodd> sdaftuar: you mean, 0.13.0, or 0.13.x>0? 12:24 < 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 12:24 < sdaftuar> 0.13.0 12:24 < btcdrak> sdaftuar: yes, sipa wanted to merge it soon to master 12:25 < CodeShark> what happened to doing it in 0.12.x? 12:25 < luke-jr> jonasschnelli: maybe this needs more off-meeting discussion then 12:25 < btcdrak> (without mainnet defs) 12:25 < jonasschnelli> luke-jr: agree 12:25 < sdaftuar> seems like there are still open issues, and no ACKs 12:25 < wumpus> jeremyrubin: well from what I've heard minor releases are usually more popular, especialy .1, as some people don't trust .0 :) 12:25 < gmaxwell> CodeShark: nothing, there are confused questions. 12:25 < sdaftuar> so i don't see how it's going to be merged in the next week 12:25 < btcdrak> sdaftuar: why? 12:25 < luke-jr> jeremyrubin: segwit is a major change to Bitcoin - not Bitcoin Core. 12:25 * jonasschnelli thinks sipa is allowed to merge without ACK 12:25 < 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. 12:26 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 12:26 < jeremyrubin> wumpus: interesting... I do tend to not upgrade any of my software major versions for 6 months. diversion over 12:26 < sipa> well merging segwit without fork enabled is not in contradiction with "not doing a consensus change in a major release" 12:26 < jonasschnelli> agree 12:26 < CodeShark> right 12:26 < wumpus> sure 12:26 < luke-jr> no objections to merging segwit code without activation 12:26 < jonasschnelli> Also, getting ACK for SW is extremly hard. Nobody wants to take the risk. 12:26 < gmaxwell> sure, there are code motion logistics that favor merging it. 12:26 < sdaftuar> to be clear i'm not talking about any kind of release policy, just code-readiness / review 12:26 < btcdrak> jeremyrubin: see out lifecycle docs https://github.com/bitcoin-core/bitcoincore.org/pull/179 12:27 < btcdrak> s/out/our/ 12:27 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:27 < wumpus> so is SW ready for merge (into master/0.13)? 12:28 < sdaftuar> it has no ACKs, and some open issues to be resolved 12:28 < wumpus> ok 12:28 < jonasschnelli> major open issue? Or more nitish stuff? 12:28 < sdaftuar> minor 12:28 < wumpus> if it is not critical it can also be fixed in a later pull 12:28 < sdaftuar> but bugs, not style nits 12:29 < wumpus> oh known bugs should be addressed in the pull itself 12:29 < sipa> i think everything will be addressed in my next batch of patches 12:29 < btcdrak> sipa: great! 12:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 12:29 < luke-jr> sipa: does that include expanding 2nd push to 75 bytes max? or is that still an open thing? 12:29 < gmaxwell> should people be acking the reviwew PR or the rebase/reorg? 12:30 < sipa> luke-jr: this is the place to ask, and i would say no, there is no point 12:30 < sipa> but perhaps others have another opinion 12:30 < btcdrak> luke-jr: I didnt understand where 75 came from. 12:30 < sipa> btcdrak: up to 75 is easy 12:30 < luke-jr> btcdrak: largest size that wouldn't require additional testing 12:31 < gmaxwell> has to do with the opcode types changing for different sizes of push. 12:31 < sipa> so, opinions? 12:31 < btcdrak> 32->40->75 seems like a big jump 12:32 < gmaxwell> btcdrak: from the code perspective they're all the same. 12:32 < 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 12:32 < luke-jr> more tolerant enables softforks, so should be preferred over useless limits 12:33 < 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. 12:33 < gmaxwell> (of course, IsStandardness should be strictly limited) 12:33 < luke-jr> to expand the limit later requires a hardfork 12:34 < luke-jr> yes, node policy should reject any unknown witnesses period 12:34 < CodeShark> ok, I think luke-jr has a strong argument 12:34 < btcdrak> that makes sense 12:34 < sipa> there should be no need for more than 256-bit hash + some versioning metadata 12:35 < sipa> and setting it to more gives it the impression that there is 12:35 < petertodd> sipa: or, to be precise if there is that means Bitcoin is more broken than that 12:35 < sipa> petertodd: exactly 12:35 < jeremyrubin> luke-jr: in general I agree with keeping flexible, but do you have an example for sipa of why you'd want it? 12:35 < 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. 12:35 < luke-jr> sipa: it doesn't need to give that impression. I don't think we need to predict the future too much here. 12:36 -!- kxie [2f2168ed@gateway/web/freenode/ip.47.33.104.237] has joined #bitcoin-core-dev 12:36 < 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. 12:36 < sipa> i'd rather not rely on isstandardness when reasoning about longer term future 12:37 < petertodd> in a MR implementation I did, it turned out to be very advantageous if the things in the MMR were fixed side forperformance 12:37 < 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 12:37 < 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. 12:37 < luke-jr> for example, we could have added the maturity stuff in the 2nd push if we didn't have nSequence 12:37 < gmaxwell> Yes, I really wish UTXO entries were fixed size. 12:37 < sdaftuar> sipa: isn't there a strong deterrent against abuse, because your funds are anyone-can-spend to older nodes? 12:37 -!- _anthony_ [~anthony@ec2-54-164-183-56.compute-1.amazonaws.com] has joined #bitcoin-core-dev 12:37 < luke-jr> gmaxwell: you'd need a new commitment entirely 12:38 < luke-jr> gmaxwell: in addition to the current one 12:38 < sipa> sdaftuar: there is no rule preventing 0-value outputs 12:38 < _anthony_> just use the private key of a payment address to store the 256 bits 12:38 < sdaftuar> ah, good point 12:38 < sipa> (if you ignore relay polify) 12:39 < 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 12:39 < gmaxwell> if one assumes a fixed size utxo entry, luke's suggestion basically doubles the utxo set size. 12:39 < 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 12:39 < luke-jr> gmaxwell: we can't assume that today, and if we softfork an assumption tomorrow, we can limit this then also 12:40 < gmaxwell> We've probably spent more time discussing it now than the decision is worth. 12:41 < wumpus> ok, next topic? 12:41 < wumpus> #topic compact block testing 12:41 < luke-jr> so we use 75 for now, and discuss reducing it later? 12:41 < gmaxwell> (and that time could be better spent reviewing/testing more corner cases... lets continue discussion elsewhere I guess) 12:42 < btcdrak> so compact blocks... 12:42 < 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. 12:42 < gmaxwell> Things seem to be working well there, instagibbs has posted some charts. 12:42 < wumpus> I've been running a compact blocks node for a few days, no crashes to report :) 12:43 < instagibbs> yes i love charts http://imgur.com/iq2lRGl 12:43 < 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. 12:43 < instagibbs> blue stuff is in kB fwiw 12:43 < wumpus> lots of succesfully reconstructed blocks 12:43 < luke-jr> (ugh, Travis is apparently "detecting abuse" on the Bitcoin code itself, so every clone will be affected?) 12:43 < btcdrak> Two large mining pools have also been running them, connected to their pool nodes for block source, one is behind the GFW 12:43 < instagibbs> blue dot == 0 fetched txns 12:44 < 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. 12:44 < instagibbs> I intended to review the PR then got ill. Still planning to review. 12:44 < 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. 12:45 < wumpus> luke-jr: (offtopic) that started happening with the parallel testing I think 12:45 < sipa> gmaxwell: agree 12:45 -!- mn3monic [~guido@unaffiliated/mn3monic] has joined #bitcoin-core-dev 12:45 < MarcoFalke> luke-jr: Shoot them an email 12:45 < gmaxwell> The compact block code is now rebased on top of the sharedptr work, so it's now a fair bit simpler. 12:45 < luke-jr> MarcoFalke: I have. My concern is more than just whitelisting individual repos though. (Let's continue discussion after the meeting) 12:45 < instagibbs> gmaxwell, matt's rebase is on that now? 12:45 < instagibbs> err pr is rebased* 12:46 < gmaxwell> instagibbs: yes. 12:46 < gmaxwell> matt's PR is on master as of last night. 12:46 < sipa> yes, forget my branch 12:46 < CodeShark> what PR#? 12:46 < instagibbs> #8086 12:47 < wumpus> #link https://github.com/bitcoin/bitcoin/pull/8068 12:47 < 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 12:47 < gmaxwell> Based on the issues I found, probably the interaction with block fetching logic needs more review. 12:47 < btcdrak> cfields_: if it deploys in 0.13 it wont be necessary 12:47 < gmaxwell> cfields_: IMO I don't see a need to preferrentially peer. I expect support to become sufficiently ubiquitious fast enough. 12:47 < wumpus> #action forget sipa's compact blocks branch and use thebluematt's PR 12:48 -!- adiabat [~adiabat@159.203.193.74] has joined #bitcoin-core-dev 12:48 < gmaxwell> it's not something that anyone has a reason to not support, except for just not having implemented it. 12:48 < btcdrak> hrm, action point is to forget :) 12:48 < sipa> cfields_: the argument brought up before was tgat service bits should be used for critical 12:48 < sipa> for critically required services 12:48 < gmaxwell> like your node won't work right if you don't have peers with the right services. 12:48 < wumpus> btcdrak: yeah for people testing the code to use the other branch 12:48 < luke-jr> makes sense 12:48 < sipa> and the only time when yoi critically need a compact block peer is as a miner, who should be curating their connections anyway 12:48 < jeremyrubin> in #8086 where is the salt generated btw? 12:49 < cfields_> hmm, fair enough 12:49 < wumpus> and miners can look at the protocol version to see if their peer supports compact blocks? 12:49 < gmaxwell> jeremyrubin: 12:49 < gmaxwell> +CBlockHeaderAndShortTxIDs::CBlockHeaderAndShortTxIDs(const CBlock& block) : 12:49 < gmaxwell> + nonce(GetRand(std::numeric_limits::max())), 12:50 < luke-jr> wumpus: I don't think we can assume a specific protocol version supports it 12:50 < luke-jr> if we have a future version with better compact blocks, we may want to drop support for the current one 12:50 < jeremyrubin> thanks 12:50 < 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 12:50 < gmaxwell> wumpus: you can do the handshake. 12:50 < sipa> wumpus: no, miners should connect to a known peer that supports it 12:50 < luke-jr> Lightsword: neither are likely to be necessary 12:51 < wumpus> gmaxwell: right 12:51 < 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. 12:51 < sipa> wumpus: because just supporting compact blocks is not enough, they also need to have good uptime and reliability latency, bandwodth, ... 12:51 < sipa> gmaxwell: we have 64 12:51 < gmaxwell> Same difference. (really? hmph!) 12:51 < jeremyrubin> I would suggest either writing the entropy to a file once or having it settable in a config file 12:51 < wumpus> we should have a concept of temporary service bits, like for the versionbits 12:52 < sipa> jeremyrubin: that's a good idea but orthogonal 12:52 < luke-jr> as long as nobody relies on service bits, they can be temporary 12:52 < btcdrak> we dont need preferential peering for compact blocks. It wont take long for wide network support. 12:52 < luke-jr> ie, use them as hints 12:52 < cfields_> don't we have a range designated for playground? 12:52 < luke-jr> yes 12:52 < jeremyrubin> sipa: (yes, sorry, just reviewing it now) 12:52 < Lightsword> a service bit to indicate a secondary service bit field needs to be used? 12:52 < luke-jr> one of which is currently getting full-RBF temporary usage 12:52 < wumpus> Lightsword: that would completely make it unuseful for preferential peering 12:52 < gmaxwell> jeremyrubin: uh. I'm not sure what you're talking about there... the nonces are per block and should not be predictable. 12:53 < wumpus> Lightsword: (as neither addr messages nor the DNS seeds would be aware of the secondary mechanism) 12:53 < gmaxwell> statically configuring it would be broken. 12:53 < wumpus> why would you want to fix the entropy statically? 12:53 < instagibbs> gmaxwell, perhaps setting cmpctblock as a tie-breaker for keeping connection? 12:53 < gmaxwell> Okay, in any case, I think thats all I've got there. 12:53 < btcdrak> ding ding, we have 7 mins remaining 12:53 < instagibbs> well, I guess "he sent me blocks fast" is/will be one, same thing 12:53 < cfields_> static entropy is much easier to test :p 12:53 < gmaxwell> instagibbs: sounds like a fine additional ranker in the connection management stuff. 12:54 < wumpus> instagibbs: +1 12:54 < sipa> indeed 12:54 < jeremyrubin> cfields_: yep 12:54 < gmaxwell> instagibbs: though yea, the 'most recent blocks' probably mostly covers it. 12:54 < BakSAj> which version are compact blocks planned for? 12:54 < sipa> related to that: please review gmaxwell's patch for adding fast blkck and tx relayers for not evicted 12:54 < jeremyrubin> gmaxwell: it doesn't harm security so long as it's kept secret from peers 12:54 < btcdrak> BakSAj: 0.13.0 12:54 < instagibbs> sipa, which number 12:54 < sipa> instagibbs: sec 12:55 < jeremyrubin> gmaxwell: nvm -- forgot you have to send it? 12:55 < gmaxwell> jeremyrubin: the nonce used for compact blocks must be sent to peers or they can't recover the block. 12:55 < petertodd> wumpus: we do have temporary service bits 12:55 < BakSAj> btcdrak: thanks! 12:55 < sdaftuar> gmaxwell: thoughts on #7598/#7600? you said above that you'd started review 12:55 < Lightsword> isn’t it likely we’re going to overhaul the p2p protocol by the time we run out of service bits? 12:55 < sdaftuar> i still think it should be a priority to get those PRs merged for 0.13.0... 12:55 < instagibbs> I don't think connecting to cmpctblock peers will be hard unless we get sybil'd by AWS forks 12:55 < gmaxwell> sdaftuar: I like them and will ACK soon, once I come up with a useful way to test. 12:56 < sipa> sdaftuar: me too, i started revieweing but got caught up on other things 12:56 < gmaxwell> sdaftuar: I agree. 12:56 < sipa> Lightsword: maybe 12:56 < sipa> Lightsword: it's often hard to predict how long protocols live 12:56 < gmaxwell> I think important big PRs I'd really like to have in 0.13 are SW, Compact blocks, CFPF related, and BIP32. 12:56 < sdaftuar> gmaxwell: ok, let me know if you want help with the sim environment i shared with you, i think that makes it easy 12:56 < instagibbs> sipa, https://github.com/bitcoin/bitcoin/pull/8084 12:56 < gmaxwell> There are a bunch of small things (including all of mine) 12:57 < sipa> instagibbs: that one, thanks 12:57 < 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 :) 12:57 < sipa> cfields_: for how long? 12:58 < sipa> a month? 12:58 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev 12:58 < 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 12:58 < 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 12:58 < wumpus> also SW is special 12:58 < sipa> Lightsword: we should also have an evil bit that abusive nodes should set 12:58 < gmaxwell> Lightsword: "the I am a DOS attack master node, please connect to me" flag? 12:58 < Chris_St1> brilliant 12:58 < btcdrak> sipa: ^.^ 12:58 < wumpus> as we discussed above it's a consensus change so it can't be enabled in a major release first 12:59 < cfields_> sipa: for ~10 days. I'll be gone for a month total, but working for the last few weeks. 12:59 < sipa> i see 12:59 < wumpus> he announced that well in advance 12:59 < gmaxwell> lynch him! 12:59 < luke-jr> cfields_: review of https://github.com/bitcoin/bitcoin/pull/5872 ? :D 12:59 < gmaxwell> oh in advance, okay. 12:59 < gmaxwell> :P 12:59 < BakSAj> :-) 12:59 < cfields_> luke-jr: added to the list, thanks 13:00 < sipa> *ding dong* 13:00 < instagibbs> wumpus, all-but-SF SW would be nice 13:00 < wumpus> #endmeeting 13:00 < lightningbot> Meeting ended Thu Jun 9 20:00:05 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-09-19.00.html 13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-09-19.00.txt 13:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-09-19.00.log.html 13:00 < luke-jr> FWIW, I will also be travelling June 20th-early July (but probably semi-available and working) 13:00 < sipa> thanks all, this was an interesting meeting 13:00 < cfields_> along the same lines, review plea for #8128 13:00 < wumpus> instagibbs: I know, just wanted the situation around SW to be clear for people reading the logs 13:01 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 240 seconds] 13:01 < instagibbs> +1 13:01 < BakSAj> btw, is there a rough estimate when 0.13.1 may come? 13:01 < BakSAj> or version with segwit sf 13:01 < instagibbs> Probably when a certain Softfork is ready.... 13:01 < gmaxwell> yea, my comments were assuming that it would be released in 0.12.x first, but parallel included in master. 13:01 < luke-jr> BakSAj: "when it's ready" 13:01 < btcdrak> BakSAj: SW will be released in 0.12.x 13:01 < gmaxwell> BakSAj: 0.12.x 13:02 < cfields_> luke-jr: btw, i believe I found your issue wrt out-of-tree build and chowning 13:02 < gmaxwell> BakSAj: development operats long ahead of public release, we're often working up to a year ahead of whats released. 13:02 < cfields_> luke-jr: we rely on "git diff" to update the index, but it can't if .git is read-only. 13:02 < luke-jr> aha 13:02 < BakSAj> uf little confused 13:03 < BakSAj> now you release 0.13.0 with segwit code 13:03 < 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. 13:03 < btcdrak> gmaxwell: BlueMatt just pushed the fixes to #8068 compact blocks 13:03 < BakSAj> but then 0.12.2 with code and activation comes 13:03 < instagibbs> BakSAj, ok, so 0.13 isn't out. That means if SW is released, it goes into 0.12.2 13:03 < instagibbs> then will still show up in 0.13 13:03 < 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. 13:04 < BakSAj> wont this bring confusion whether to run 0.12.2 or 0.13 ? 13:04 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 13:04 < instagibbs> btcdrak, sigh, my block hit rate is going to poop :( 13:04 < cfields_> luke-jr: could you verify that your process works if you add a "chown -R user:user" after the "chown -R root:root ." ? 13:04 < sipa> BakSAj: what os are you running? 13:04 < luke-jr> BakSAj: there is no one version everyone must run 13:05 < gmaxwell> instagibbs: start up the relay node client for a bit to prefill your mempool. 13:05 < BakSAj> sipa ? 13:05 < luke-jr> cfields_: eh, that sounds like a noop? 13:05 < instagibbs> gmaxwell, hmm ok pretty sure I have that installed 13:05 < btcdrak> instagibbs: well you could spin up a new node instead... 13:05 < sipa> BakSAj: what version of your os are you running. 13:05 < cfields_> luke-jr: er, sorry... 13:05 < cfields_> luke-jr: "chown -R user:user .git" 13:05 < BakSAj> sipa: for full node? 13:05 < btcdrak> instagibbs: rsync your chainstate etc. 13:05 < sipa> BakSAj: whatever, i'm trying to make an analogu 13:06 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 13:06 < BakSAj> lol, win10 13:06 < sipa> BakSAj: you run 0.12.x to get more stable/tested code 13:06 < sipa> BakSAj: you run 0.13.0 to get the latest and greates 13:06 < sipa> and segwit is independent of that 13:06 < sipa> it will be released in a point update to both 13:07 < gmaxwell> SW is not a client feature, it's part of the network protocol. 13:07 < BakSAj> i understand how sw livecycle usually works, but im confused about thing that 0.13.0 wont have SF active 13:07 < 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 13:07 < 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. 13:07 < luke-jr> SW introduction is independent from Core's release cycle 13:08 < sipa> BakSAj: because in order to enable SW, we need many code changes 13:08 < sipa> BakSAj: it's a pita to keep maintaining those in parallel when we know the code worms 13:08 < sipa> *works 13:08 < BakSAj> ah 13:08 < 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 13:09 < BakSAj> i had bad assumption about 0.13.0 13:09 < BakSAj> guys, thanks for explanation 13:09 < gmaxwell> btcdrak: in the future, please wait for travis to finish before nagging people to update. :) 13:09 < BakSAj> got it now 13:10 -!- bsm1175322 [~mcelrath@38.121.165.60] has joined #bitcoin-core-dev 13:10 < BakSAj> https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/ 13:10 < BakSAj> mayb needs little refurbish 13:10 < BakSAj> dates and staff 13:11 -!- bsm1175321 [~mcelrath@38.121.165.30] has quit [Ping timeout: 250 seconds] 13:11 < instagibbs> BakSAj, the section on the site about life cycle needs a refurb 13:11 < BakSAj> if i can speak for little educated public :-) i would prefer complex btc roadmap 13:11 < BakSAj> not just capacity increase roadmap 13:12 < btcdrak> gmaxwell: noted 13:13 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 13:15 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 13:15 -!- bsm1175322 [~mcelrath@38.121.165.60] has quit [Remote host closed the connection] 13:17 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 13:19 -!- spikey [~spikes@122.175.246.22] has joined #bitcoin-core-dev 13:23 -!- spikeheadon [~spikes@107.169.246.6] has quit [Ping timeout: 250 seconds] 13:24 -!- spikeheadon [~spikes@23.247.155.3] has joined #bitcoin-core-dev 13:25 -!- spikey [~spikes@122.175.246.22] has quit [Ping timeout: 240 seconds] 13:30 -!- ozanyurt [~ozanyurt@178.162.216.49] has joined #bitcoin-core-dev 13:44 -!- ebfull [~sean@c-50-170-183-94.hsd1.co.comcast.net] has quit [Quit: leaving] 13:46 -!- BakSAj [59b1487b@gateway/web/freenode/ip.89.177.72.123] has quit [Quit: Page closed] 13:50 < 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" 13:50 < dgenr8> sipa: it looks like there is no way query ledger entries like this (or those created by move) :/ 13:51 < 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 13:52 < sipa> dgenr8: receive accounts are a property of incoming payments, not utxos 13:52 < sipa> dgenr8: the fact that a send is not reflected in getbalance is a bug 13:53 < dgenr8> I guess was speaking loosely ... i mean it has a txid and a vout, and it is unspent :) 14:07 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev 14:07 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit] 14:10 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Ping timeout: 260 seconds] 14:11 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 14:13 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 246 seconds] 14:15 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev 14:23 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 14:53 -!- _anthony_ [~anthony@ec2-54-164-183-56.compute-1.amazonaws.com] has quit [Quit: WeeChat 1.3] 15:14 < 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 15:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:33 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 15:50 < 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 15:53 -!- spikeheadon [~spikes@23.247.155.3] has quit [Ping timeout: 240 seconds] 15:56 -!- zooko` [~user@208.70.31.231] has joined #bitcoin-core-dev 16:02 -!- zooko` [~user@208.70.31.231] has quit [Read error: Connection reset by peer] 16:03 -!- zooko` [~user@208.70.31.231] has joined #bitcoin-core-dev 16:08 < 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 16:11 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 16:40 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 16:43 -!- blur3d [~blur3d@49.187.26.218] has joined #bitcoin-core-dev 16:49 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 260 seconds] 16:51 -!- skyraider [uid41097@gateway/web/irccloud.com/x-kecxmnruylyhrjyb] has joined #bitcoin-core-dev 16:53 -!- AaronvanW [~ewout@220pc230.sshunet.nl] has joined #bitcoin-core-dev 16:53 -!- AaronvanW [~ewout@220pc230.sshunet.nl] has quit [Changing host] 16:53 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:59 -!- zooko` [~user@208.70.31.231] has quit [Ping timeout: 264 seconds] 17:03 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 264 seconds] 17:10 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 17:11 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has joined #bitcoin-core-dev 17:17 -!- dingus [~grubles@unaffiliated/grubles] has quit [Quit: brb] 17:17 -!- binns [sid105317@21/bitcoin/binns] has quit [Ping timeout: 264 seconds] 17:18 -!- eragmus [sid136308@gateway/web/irccloud.com/x-mychxenjvjpxdhtq] has quit [Ping timeout: 264 seconds] 17:18 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev 17:21 -!- eragmus [sid136308@gateway/web/irccloud.com/x-euknuprnwapdmjif] has joined #bitcoin-core-dev 17:22 -!- binns [sid105317@21/bitcoin/binns] has joined #bitcoin-core-dev 17:27 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 17:29 -!- dingus [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 17:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-yocfnzfbqiscqcye] has quit [Quit: Connection closed for inactivity] 17:52 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 18:02 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev 18:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 18:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 18:05 -!- dermoth [~thomas@dsl-66-36-129-228.mtl.aei.ca] has quit [Read error: Connection reset by peer] 18:05 -!- dermoth [~thomas@dsl-66-36-129-228.mtl.aei.ca] has joined #bitcoin-core-dev 18:07 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 18:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 18:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 18:35 -!- dermoth [~thomas@dsl-66-36-129-228.mtl.aei.ca] has quit [Read error: Connection reset by peer] 18:36 -!- dermoth [~thomas@dsl-66-36-129-228.mtl.aei.ca] has joined #bitcoin-core-dev 19:01 -!- skyraider [uid41097@gateway/web/irccloud.com/x-kecxmnruylyhrjyb] has quit [Quit: Connection closed for inactivity] 19:30 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 19:43 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 19:44 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 19:46 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 20:05 -!- fengling [~fengling@124.205.63.0] has quit [Ping timeout: 240 seconds] 20:12 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Quit: Leaving] 20:14 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds] 20:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 20:30 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Quit: Leaving] 20:31 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev 20:36 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 244 seconds] 20:36 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev 20:45 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:46 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:05 -!- fengling [~fengling@124.205.63.0] has joined #bitcoin-core-dev 21:21 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 240 seconds] 21:54 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.] 22:11 -!- fengling [~fengling@124.205.63.0] has quit [Ping timeout: 240 seconds] 22:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:01 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rlgxopdkhtohvzkg] has joined #bitcoin-core-dev 23:03 -!- blur3d [~blur3d@49.187.26.218] has quit [Quit: blur3d] 23:14 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has quit [Remote host closed the connection] 23:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:31 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev