--- Day changed Thu Apr 27 2017
00:00 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]     
00:00 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
00:02 -!- tw2006 [~tw2006@2601:187:8480:2770:8595:db55:53ed:747a] has joined #bitcoin-core-dev     
00:03 -!- kexkey [~kexkey@162.219.176.21] has quit [Ping timeout: 260 seconds]     
00:05 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 240 seconds]     
00:06 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Disconnected by services]     
00:07 -!- tw2006 [~tw2006@2601:187:8480:2770:8595:db55:53ed:747a] has quit [Ping timeout: 240 seconds]     
00:08 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev     
00:12 -!- berndj [~berndj@mail.azna.co.za] has quit [Quit: ZNC - http://znc.in]     
00:16 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev     
00:19 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:25 -!- Victor_sueca is now known as Victorsueca     
00:48 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]     
00:52 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:53 -!- isis [~isis@abulafia.patternsinthevoid.net] has quit [Remote host closed the connection]     
01:14 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-asreyjuhbvplsjtu] has joined #bitcoin-core-dev     
01:16 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:29 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 268 seconds]     
01:30 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
01:30 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
01:31 -!- kungfuant [~root@ec2-52-59-253-251.eu-central-1.compute.amazonaws.com] has quit [Quit: leaving]     
01:31 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
01:32 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
01:37 -!- Don_John [~Don@2600:8800:548f:1500:dd71:3c3f:ed83:657e] has quit [Read error: Connection reset by peer]     
01:51 -!- tw2006 [~tw2006@2601:187:8480:2770:c137:6419:4921:d217] has joined #bitcoin-core-dev     
01:55 -!- Geovanni [~Geovanni@188.226.139.184] has joined #bitcoin-core-dev     
01:56 -!- tw2006 [~tw2006@2601:187:8480:2770:c137:6419:4921:d217] has quit [Ping timeout: 246 seconds]     
02:43 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
02:48 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 260 seconds]     
02:57 -!- jouke [~worst@unaffiliated/komkommer] has quit [Remote host closed the connection]     
02:59 -!- jouke [~worst@unaffiliated/komkommer] has joined #bitcoin-core-dev     
03:11 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 245 seconds]     
03:16 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
03:35 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
03:41 -!- tw2006 [~tw2006@2601:187:8480:2770:c0a4:5729:37a9:f3f6] has joined #bitcoin-core-dev     
03:45 -!- tw2006 [~tw2006@2601:187:8480:2770:c0a4:5729:37a9:f3f6] has quit [Ping timeout: 260 seconds]     
03:56 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
03:56 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
04:32 -!- goksinen [~goksinen@2604:2000:c591:8400:7982:4016:24a0:8917] has joined #bitcoin-core-dev     
04:33 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
04:36 -!- goksinen [~goksinen@2604:2000:c591:8400:7982:4016:24a0:8917] has quit [Ping timeout: 260 seconds]     
04:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
04:42 -!- kexkey [~kexkey@68.168.119.229] has joined #bitcoin-core-dev     
04:49 -!- tw2006 [~tw2006@2601:187:8480:2770:47b:d:ffbd:711f] has joined #bitcoin-core-dev     
05:04 -!- Geovanni [~Geovanni@188.226.139.184] has quit [Ping timeout: 260 seconds]     
05:26 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
05:28 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
05:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Quit: Gone frying asparagus or my Windows had a BSOD]     
05:31 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 260 seconds]     
05:34 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:d891:3b10:fc19:8501] has joined #bitcoin-core-dev     
05:34 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:d891:3b10:fc19:8501] has quit [Read error: Connection reset by peer]     
05:35 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:d891:3b10:fc19:8501] has joined #bitcoin-core-dev     
05:35 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:d891:3b10:fc19:8501] has quit [Read error: Connection reset by peer]     
05:46 < fanquake> Is there a dev meeting tonight?
05:51 -!- Ona [~Ona@188.226.139.184] has joined #bitcoin-core-dev     
05:53 < jonasschnelli> fanquake: Yes.
05:53 < jonasschnelli> fanquake: in 6h and 7min.
05:54 < fanquake> jonasschnelli 3am :|
05:54 < jonasschnelli> fanquake: hah. Yeah. Hard for OZ.
06:08 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
06:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:25 <@wumpus> yes the time is not exactly ideal for asia/OZ
06:43 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
06:45 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:d891:3b10:fc19:8501] has joined #bitcoin-core-dev     
06:45 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:d891:3b10:fc19:8501] has quit [Read error: Connection reset by peer]     
06:46 -!- nu11p7r [~nu11p7r@dfaefce4-1ec2-41ac-b8f9-6bd816c36ded.node.sporestack.com] has quit [Ping timeout: 255 seconds]     
06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Max SendQ exceeded]     
06:53 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
07:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
07:22 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
07:25 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
07:46 -!- altoz_ is now known as altoz     
07:53 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
07:54 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
07:58 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]     
08:00 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
08:42 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
08:42 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 268 seconds]     
08:44 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
08:44 -!- bsm1175321 [~mcelrath@135.84.167.210] has joined #bitcoin-core-dev     
08:49 -!- bsm1175321 [~mcelrath@135.84.167.210] has quit [Ping timeout: 260 seconds]     
08:53 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:08 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]     
09:21 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection]     
09:24 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:25 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/47535d7c3ec7...a550f6e415fd
09:25 < bitcoin-git> bitcoin/master 3edbd79 Alex Morcos: cleanup: reduce to one GetMinimumFee call signature
09:25 < bitcoin-git> bitcoin/master a550f6e Pieter Wuille: Merge #10283: Cleanup: reduce to one GetMinimumFee call signature...
09:26 < bitcoin-git> [bitcoin] sipa closed pull request #10283: Cleanup: reduce to one GetMinimumFee call signature (master...oneGetMinimumFee) https://github.com/bitcoin/bitcoin/pull/10283
09:41 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
09:42 -!- goksinen [~goksinen@50.75.193.138] has joined #bitcoin-core-dev     
09:43 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
09:46 -!- goksinen [~goksinen@50.75.193.138] has quit [Ping timeout: 240 seconds]     
09:59 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
10:21 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
10:23 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
10:28 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 260 seconds]     
10:38 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
10:44 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
10:45 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
10:49 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 260 seconds]     
10:55 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]     
10:55 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev     
11:04 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
11:13 -!- jcliff42 [~jcliff42@c-50-168-87-98.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
11:20 -!- tw2006 [~tw2006@2601:187:8480:2770:47b:d:ffbd:711f] has quit [Read error: Connection reset by peer]     
11:20 -!- tw2006 [~tw2006@2601:187:8480:2770:47b:d:ffbd:711f] has joined #bitcoin-core-dev     
11:22 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:26 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a550f6e415fd...4c924011f535
11:26 < bitcoin-git> bitcoin/master b51aaf1 practicalswift: Remove unused C++ code not covered by unit tests
11:26 < bitcoin-git> bitcoin/master 4c92401 Wladimir J. van der Laan: Merge #10075: Remove unused C++ code not covered by unit tests...
11:26 < bitcoin-git> [bitcoin] laanwj closed pull request #10075: Remove unused C++ code not covered by unit tests (master...unused) https://github.com/bitcoin/bitcoin/pull/10075
11:27 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection]     
11:27 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Read error: Connection reset by peer]     
11:33 -!- altoz [~Jimmy@cpe-24-55-54-186.austin.res.rr.com] has quit [Remote host closed the connection]     
11:34 -!- altoz [~Jimmy@24.55.54.186] has joined #bitcoin-core-dev     
11:35 -!- altoz [~Jimmy@24.55.54.186] has quit [Remote host closed the connection]     
11:36 -!- altoz [~Jimmy@cpe-24-55-54-186.austin.res.rr.com] has joined #bitcoin-core-dev     
11:36 -!- altoz [~Jimmy@cpe-24-55-54-186.austin.res.rr.com] has quit [Remote host closed the connection]     
11:37 -!- altoz [~Jimmy@24.55.54.186] has joined #bitcoin-core-dev     
11:38 -!- trippysa1mon [~trippy@83.162.202.182] has joined #bitcoin-core-dev     
11:38 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Excess Flood]     
11:38 -!- trippysalmon [~trippy@cyberdynesys.org] has quit [Remote host closed the connection]     
11:38 -!- thermoman [~thermoman@136.243.146.74] has quit [Remote host closed the connection]     
11:39 -!- jonasschnelli_ [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev     
11:39 -!- thermoman [~thermoman@wtf.foobar0815.de] has joined #bitcoin-core-dev     
11:40 -!- jonasschnelli_ [~jonasschn@2a01:4f8:200:7025::2] has quit [Client Quit]     
11:40 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev     
11:40 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Changing host]     
11:40 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev     
11:49 -!- Giszmo [~leo@ip-246-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev     
11:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
11:59 -!- jcliff42 [~jcliff42@c-50-168-87-98.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
12:01 < luke-jr> meeting?
12:01 < jonasschnelli> Yes     
12:01 < petertodd> yup     
12:01 < kanzure> yes     
12:02 < BlueMatt> wumpus, wherefor art thou wumpus 
12:02 <@wumpus> #startmeeting
12:02 < lightningbot> Meeting started Thu Apr 27 19:02:01 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:02 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:02 < jonasschnelli> I have two topic proposals: "hd-restore" and "limited NODE_NETWORK (NODE_NETWORK_LIMITED) signaling"
12:02 <@wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt 
12:02 <@wumpus> instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
12:02 < kanzure> hi.     
12:02 < instagibbs> here
12:02 < cfields> hi     
12:03 -!- edcba [~edcba@78.193.195.38] has joined #bitcoin-core-dev     
12:03 <@wumpus> #topic hd-restore (jonasschnelli)
12:03 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
12:03 < jtimon> suggested topic: summary of BlueMatt's overall plan for libconsensu
12:03 < kanzure> is this 10240?
12:03 < jtimon> if BlueMatt wants of course
12:03 < BlueMatt> jtimon: k, can share. jonasschnelli you have the floor :)
12:03 < jonasschnelli> Re. HD restore. I'm not sure if we should always try to restore funds or if we should check for the bestblock and compare it to the chain tip and only then restore
12:04 < jonasschnelli> The main stuff is in #10240
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/10240 | [WIP] Add basic HD wallet restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
12:04 < instagibbs> ack libconsensus discussion
12:04 < jonasschnelli> But I think we should only restore if the wallet's bestblock lacks behind
12:04 < instagibbs> oh sorry, didnt see topic set already :)
12:04 < jonasschnelli> Because...
12:04 < jonasschnelli> Encrypted wallets may need to unlock
12:05 < jonasschnelli> And also for performance / log reasons 
12:05 < BlueMatt> jonasschnelli: i assumed we'd always keep a buffer of X pubkeys around
12:05 < BlueMatt> because you may have wallet "forks"
12:05 < BlueMatt> not sure what you mean by "restore"?
12:05 < BlueMatt> (feel free to tell me to shut up and go read the pr)
12:05 < jonasschnelli> BlueMatt: By restore I mean always check the keypool keys and auto-extend (if only 50 [TBD] keys are left, topup to 100 [TBD]
12:05 < kanzure> looks like it's re: finding relevant transactions
12:06 < jonasschnelli> If we always restore... we would need to unlock encrypted wallet...
12:06 < jonasschnelli> (more often)
12:06 < sipa> jonasschnelli: my assumption was that we'd always mark seen keys as used (and we should do that independently)
12:06 < sipa> jonasschnelli: we should also always extend the keypool when we can
12:06 < BlueMatt> jonasschnelli: ah, you mean like "when do we extend keypool to watch buffer"?
12:06 < jonasschnelli> sipa: Yes. But what if we can't?
12:06 < sipa> jonasschnelli: and if the keypool runs out in a non-interactive setting, shutdown
12:07 < achow101> If it needs to generate keys you could prompt the user right when the main gui pops up
12:07 < jonasschnelli> And whats a save gap limit? I would assume >100 keys.
12:07 < BlueMatt> another option would be to stop updating best seen block
12:07 < BlueMatt> and then kick off a background rescan-from-that-height when wallet next unlocks
12:07 < jonasschnelli> If someone has handed out 101 keys and only the position 101 has payed...
12:07 < BlueMatt> if gap goes under some threshold
12:07 < kanzure> yea, trigger on next unlock is better than achow101 popup
12:07 < BlueMatt> achow101: needs to be cli-compatible, though
12:08 < jonasschnelli> achow101: GUI is solvable..
12:08 < sipa> jonasschnelli: if we fix the bdb flushing stupidity, generating new keys becomes very cheap
12:08 < jonasschnelli> I don't know how to solve the non GUI way
12:08 < sipa> jonasschnelli: shutdown. make sure it doesn't happen
12:08 < achow101> jonasschnelli: how would you hand out 101 keys if the 101st wasn't generated yet?
12:08 < BlueMatt> jonasschnelli: i mean keys are cheap, can do 250 or 500 or something crazy
12:08 < jonasschnelli> sipa: But how to unlock during init in the first place?
12:08 < sipa> jonasschnelli: you can't
12:08 < BlueMatt> jonasschnelli: but cant we just use the keypool number now as the "buffer"?
12:08 < sipa> ah, i see what you mean
12:08 < jonasschnelli> But right after we rescan and sync
12:09 < BlueMatt> and, like, the lower bound should be like keypool count / 2
12:09 < BlueMatt> sipa: you cant just shutdown mid-sync
12:09 < jonasschnelli> BlueMatt: Yes. But with the current 100 default, we would enforce a shutdown on startup for encrypted wallets
12:09 < sipa> BlueMatt: why not?
12:09 < sipa> it's an error condition that we cannot recover from
12:09  * BlueMatt re-proposes that we stop updating wallet's best height if our keypool falls below keypool / 2
12:09 < BlueMatt> and then rescan when keypool next gets filled
12:09 < sipa> hmm     
12:10 < jonasschnelli> IMO an explicit "restore-mode" with a "unlock during startup" (not sure how) would be preferable for encrypted wallets
12:10 < sipa> BlueMatt: you should also stop pruning
12:10 < BlueMatt> sipa: yes, that would be my major reservation
12:10 < BlueMatt> jonasschnelli: not sure you realistically can in a daemon setting
12:10 < jonasschnelli> is stdin a total nogo? *duck*
12:10 < sipa> so i guess we need a special "stop syncing" mode that we go into when the keypool runs out
12:10 < sipa> jonasschnelli: there is no stdin with -daemon
12:10 < BlueMatt> sipa: i guess you can stop pruning and if disk fills it will do the shutdown part for you :p
12:10 < sipa> BlueMatt: ugh
12:11 < BlueMatt> yea, i know
12:11 < jonasschnelli> sipa: Yes. But at least you could run in non-daemon headless
12:11 <@wumpus> yes a blocking mode makes sense in that case
12:11 < BlueMatt> ok, so blocking in pruning mode, rescan-later in non-pruning mode?
12:11 <@wumpus> and no, stdin is not an option, there should be no expectation with bitcoind that there's anyone at the terminal
12:11 < jonasschnelli> If you run with an encrypted wallet and the bestblock lacks behind, shutdown if we can't unlock over stdin
12:11 < BlueMatt> no stdin, just shutdown
12:11 < jonasschnelli> wumpus: So we have only RPC to unlock?
12:11 <@wumpus> everything should be scriptable
12:11 < BlueMatt> jonasschnelli: but only in prune mode
12:12 <@wumpus> jonasschnelli: yes
12:12 < jonasschnelli> But how do we unlock/extend before we sync?
12:12 <@wumpus> just wait until the wallet is unlocked to start
12:12 < jonasschnelli> rpc starts after chain sync
12:12 < sipa> jonasschnelli: you go into a blocking mode, and you continue after walletunlock
12:12 <@wumpus> right
12:12 < sipa> jonasschnelli: and no, no stdin ever
12:13 < jonasschnelli> but can we block the sync and wait for RPC wallettunlock?
12:13 < sipa> jonasschnelli: why not?
12:13 <@wumpus> sure
12:13 < jonasschnelli> (without changing too much)?
12:13 < BlueMatt> ProcessNewBlock { return false; }
12:13 < jonasschnelli> okay... sounds good. Need to take a closer look.
12:13 < sipa> add a function to validation.h to let the core know that validation cannot progress
12:13 < BlueMatt> maybe stop net too under the current net-pause stuff
12:13 < sipa> right
12:13 < jonasschnelli> Good point.
12:13 < kanzure> should it shutdown if wallet is not unlocked within a certain time period? if it's not shutdown users might expect it to still be syncing.
12:14 < jonasschnelli> Next question: what's a sane gap limit?
12:14 <@wumpus> the only precondition for getting out of Init() is that the genesis block has been processed, everything else can be delayed
12:14 < jonasschnelli> 100 seems way to low to me
12:14 < sipa> jonasschnelli: fix bdb flushing insanity, and raise it to 1000 or 10000
12:14 < BlueMatt> jonasschnelli: keypool / 2?
12:14 < jonasschnelli> (risk of losing funds is involved)
12:14 < BlueMatt> and we can bump keypool to 500
12:14 < achow101> how would you know that it is blocking and you need to walletunlock?
12:14 < kanzure> jonasschnelli: i think the answer will depend on performance.  also, do you really want to encourage users to use gaps? the answer might be yes..
12:15 < kanzure> achow101: yes that is why i suggested shutdown after a certain period of time. users might not realize that syncing is stopped otherwise.
12:15 < jonasschnelli> there my next concern pops up... all user will always have to have 500+ keypools. In an explicit restore more, only then we would need to have a large pool
12:15 < sipa> jonasschnelli: who cares about 500 keys'
12:15 < sipa> it's 16 kB of memory
12:15 < kanzure> i thought derivation time was the bottleneck?
12:15 < sipa> well, some small constant multiple of that
12:15 < jonasschnelli> Hmm... yes.
12:15 -!- tw2006 [~tw2006@2601:187:8480:2770:47b:d:ffbd:711f] has quit [Read error: Connection reset by peer]     
12:16 < jonasschnelli> If it just would be a pubkey and H160 onyl.. but it's also the privatre key! hell
12:16 <@wumpus> the memory usage of keys is not an issue, just generation time (and that's only due to bdb stupidity)
12:16 < sipa> kanzure: we can do ~10000 derivation steps per second on a single thread on modern CPU
12:16 -!- tw2006 [~tw2006@2601:187:8480:2770:47b:d:ffbd:711f] has joined #bitcoin-core-dev     
12:16 < kanzure> is that with bdb madness? :)
12:16 < sipa> and maybe 5 due to BDB flushing
12:16 <@wumpus> calling fsync after every key is not a good idea, it should create the entire keypool refill in one transaction
12:16 < luke-jr> IMO automatic pruning should probably have as a precondition that the wallet has updated to the block being pruned, if it doesn't already; then the wallet can just set its criteria for processing
12:17 < luke-jr> and if auto-pruning is enabled, block validation (safely) when the size is hit, until it can prune further?
12:17 < sipa> luke-jr: agree, but that's not a concern right now as the wallet updates synchronously... with BlueMatt's coming changes maybe that changes
12:17 < BlueMatt> yes, that changes, but it still shouldnt be too slow
12:17 < jonasschnelli> With HD, there would also be no need for the disk-keypool for unencrypted wallets,.. it's just legacy. We could always fill up in-mem
12:18 < BlueMatt> if your wallet falls behind consensus, you have a very, very large wallet
12:18 < BlueMatt> (and should pause sync anyway)
12:18 < sipa> right, the wallet should have the ability to pause syncing or prevent pruning
12:18 < jonasschnelli> Conclusion: a) always scan keypool and topup, b) extend keypool and gap-limit to 500+, c) block when encrypted until RPC unlocked.
12:19 < sipa> sgtm
12:19 <@wumpus> yes     
12:19 < jonasschnelli> thanks. That was effective
12:19 <@wumpus> #topic libconsensus (BlueMatt)
12:19 < BlueMatt> yes, so obviously this is all based on #771
12:19 < gribble> https://github.com/bitcoin/bitcoin/issues/771 | CBlockStore by TheBlueMatt · Pull Request #771 · bitcoin/bitcoin · GitHub
12:19 < BlueMatt> :)     
12:20 < jonasschnelli> (19 Jan 2012)
12:20 <@wumpus> archeology?
12:20 < BlueMatt> but pr #10279 creates a CChainState class which will hold things like mapBlockIndex chainActive, etc, etc
12:20 < gribble> https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
12:20 < BlueMatt> and have ProcessNewBlock Activate..., Connect, etc, etc, etc
12:20 < sipa> yay     
12:21 < BlueMatt> long-term that class' public interface will be libbitcoinconsensus, but right now its really just to clean up internal interfaces within validation.cpp
12:21 <@wumpus> sounds good to me
12:21 < BlueMatt> that class would get a pcoinsTip and related stuff to write/read blocks from disk
12:21 < BlueMatt> and then only be able to call that and pure functions (eg script validation)
12:21 < jtimon> BlueMatt: so what's the next thing we will be able to expose with these changes?
12:21 < cfields> ooh, +1
12:21 < BlueMatt> there is a bit of cleanup in the pr, but mostly its just moving into a class
12:22 < BlueMatt> jtimon: expose-wise? probably nothing for like 2 more releases "until its ready"
12:22  * BlueMatt is not a fan of libbitcoinconsensus being a grab-bag of random verification functions
12:22 < jtimon> the class itself? mhmm
12:22 < BlueMatt> i mean "the class"  but I assume via a C API
12:24 < BlueMatt> any other questions? or next topic?
12:24 < jtimon> yes, I know, and I'm very open to see what you want to expose, even if I don't renounce to the verifyWithoutChangingState x {block, header, tx, script} + getFlags() vision I had
12:24 < jtimon> but that's helpful, I can just imagine the class being exposed as a c api
12:25 <@wumpus> not directly, it's just another step toward being able to
12:25 <@wumpus> #topic limited NODE_NETWORK (NODE_NETWORK_LIMITED) signaling (jonasschnelli)
12:25 < petertodd> wumpus: +1
12:25 < jonasschnelli> I wanted to ask if a first step to announce pruned NODE_NETWORK would make sense.
12:26 < jonasschnelli> Could be NODE_NETWORK_LIMITED
12:26 < sipa> jonasschnelli: what would it entail?
12:26 < jonasschnelli> The only requirement is relay, and serve the last 144 blocks
12:26 < petertodd> jonasschnelli: ACK
12:26 <@wumpus> we had this discussion recently, I thnk the conclusion was to use two service bits
12:26 <@wumpus> (or one, at first)
12:26 < gmaxwell> what wumpus said.
12:26 < jonasschnelli> (which is almost always possible with the current auto-prune limit)
12:26 < sipa> i would suggest something that guarantees 1 day and 1 week
12:26 <@wumpus> one bit combination would be 144, one would be ~1000
12:26 < luke-jr> jonasschnelli: so segwit prune=550 wouldn't be allowed?
12:27  * BlueMatt resists the urge to bikeshed on the "1 week" number
12:27 < gmaxwell> Which should be 2 days and 2 weeks so the boundary condition doesn't leave you right out.
12:27 < sipa> BlueMatt: i have data!
12:27 < jonasschnelli> luke-jr: We would have to bump there
12:27 < gmaxwell> BlueMatt: sipa has data on request rates.
12:27 < BlueMatt> oh, true, thats right
12:27 <@wumpus> luke-jr: it's allowed, but it can't signal anything
12:27 < sipa> BlueMatt: i'll analyse the numbers again if there is interest
12:27 < gmaxwell> The only think to bikeshed is how much higher do we need the cutoff than his data, it should be at least a couple blocks higher because of reorgs/boundary conditions.
12:27 -!- mol [~molly@unaffiliated/molly] has quit [Quit: Leaving]     
12:28 < gmaxwell> our existing minimum sizing for pruning is sized out for 288 blocks, so I think we should just do that, it will make ~144 pretty reliable.
12:28 < bitcoin-git> [bitcoin] sipa opened pull request #10290: Add -stopatheight for benchmarking (master...shutdown_at_height) https://github.com/bitcoin/bitcoin/pull/10290
12:28 <@wumpus> yep     
12:28 < BlueMatt> sipa: ack without seeing code
12:28 < jonasschnelli> Two service bits seems to be great. Did anyone started with specs/BIP?
12:29 < sipa> BlueMatt: i just have a log of which depths of blocks are being fetched from my node
12:29 < cfields> how would NODE_NETWORK_LIMITED interact (if at all) with the remote peer's advertised height?
12:29 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
12:29 < sipa> BlueMatt: since february
12:30 < gmaxwell> cfields: I don't think it should?
12:30 < luke-jr> IMO would be nicer to have the new service bit require *some* historical storage, but I guess we're not running out..
12:30 < jonasschnelli> IMO the purpose is to signal "I have only a limited amount of blocks"
12:30 <@wumpus> cfields: not at all, we ignore that value
12:30 < BlueMatt> sipa: yes, i recall now
12:30 < cfields> ok, good
12:30 < gmaxwell> That advetised height shouldn't be used for almost anything.
12:30 <@wumpus> (as it's easily spoofable)
12:30 < jonasschnelli> The best-height in version doesn't matter IMO
12:30 <@wumpus> it isn't used at all
12:30 < sipa> i believe it is not used at all
12:30 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
12:30 < sipa> (by bitcoin core)
12:30 < luke-jr> I'm not sure why more than the last 1-2 blocks should be needed to indicate relaying
12:30 < jonasschnelli> wumpus: I  think it's used by SPV
12:31 < gmaxwell> luke-jr: because or reorgs.
12:31 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
12:31 < gmaxwell> if I can't serve you the parents of my tip, I can't help you reorg onto it, making my serving nearly useless.
12:31 <@wumpus> jonasschnelli: I meant in bitcoin core; I don't know about other implementations
12:31 < luke-jr> hmm     
12:31 < jonasschnelli> Is a min of 144 blocks to height?
12:31 < jonasschnelli> No... nm
12:31 < petertodd> luke-jr: and requiring nodes to have a GB or two of space for this is a trivial cost these days
12:31 < achow101> is the point of NODE_NETWORK_LIMITED just to tell nodes that they can request the most recent blocks from said node?
12:31 < luke-jr> assuming we only fetch blocks when reorging to their chain
12:32 < instagibbs> It's the unbounded growth that gets people to shut off nodes
12:32 < achow101> and right now you can't request any blocks from pruned nodes?
12:32 < gmaxwell> In any case the bit must promise more than nodes count on.
12:32 < sipa> achow101: pruned nodes don't even advertize they can relay blocks
12:32 < instagibbs> achow101, NODE_NETWORK is a flag for that, and it's missing from pruned nodes currently
12:32 < jonasschnelli> achow101: once you are in sync (>-144) you can pair with pruned peers and be fine
12:32 < achow101> ok     
12:32 < gmaxwell> Say nodes frequently need to catch up a day.  You only keep 144 blocks.   Peer needs to catch up a day, connects to you.. opps you can't help them because a day turned out to be 150 blocks, they wasted their time connecting to you for nothing.
12:33 < gmaxwell> So for this to be useful the requester has to be conservative and not try to talk to you unless it thinks you are _very_ likely to have what it needs, which means that you need a fair amount more than the target.
12:34 < gmaxwell> So to serve a day of blocks, you'll need a day and a half or so. Round it up to 288. 
12:34 < gmaxwell> petertodd: oh hi. long time no see.
12:34 < petertodd> gmaxwell: heh
12:34 < gmaxwell> and as mentioned, our pruning limit is already there.
12:34 < jonasschnelli> I just think we should allow the current auto-pruning 550 peers to signal relay and "limited amount of blocks around the tip".
12:35 < luke-jr> so 137 blocks?
12:35 < jonasschnelli> If we set NODE_NETWORK_LIMIT higher while allowing to prune shorter,.. this would wast potential peers
12:35 < petertodd> luke-jr: 1337 blocks
12:35 < gmaxwell> jonasschnelli: then that will never be used. 
12:35 < jonasschnelli> heh     
12:35 < gmaxwell> If we don't know how many blocks to except we'll never connect to them.
12:35 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Ping timeout: 268 seconds]     
12:36 < gmaxwell> This impacts the connection logic, we'll need logic that changes the requested services based on an estimate of how far back we are.
12:36 < sipa> when you're fully synced, why wouldn't you connect to a node that guarantees for example having the last 10 blocks?
12:36 < jonasschnelli> gmaxwell: Well, if we are in sync, you could be friendly and make space for the one who need sync and re-connect to limited peers?
12:36 < jonasschnelli> Yes. What sipa said
12:36 < jonasschnelli> I would expect the larger the chain grows the more pruned peers we will see
12:37 < jonasschnelli> (rought assumption)
12:37 < sipa> not that we should support pruning that much, but for bandwidth reasons it may be reasonable that someone wants to relay new blocks, but not historical ones
12:37 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 268 seconds]     
12:38 < petertodd> sipa: I think we can make a good argument that requiring nodes to have something like 1GB of storage for historical blocks isn't a big deal, and makes the logic around all this stuff simpler
12:38 < jonasschnelli> signaling the amount of block you have is also not extremly effective because of the addr-man, seed/crawl delay
12:38 < jonasschnelli> *blocks
12:38 < sipa> petertodd: again, not talking about storage, but about bandwidth
12:38 < sipa> it's an open question - i'm not convinced it's needed or useful
12:39 < jonasschnelli> Yes. Agree with sipa. Main pain point in historical blocks is upstream bandwidth
12:39 < gmaxwell> sipa sure that would also work: but (1) nodes that only keep ten blocks are a hazard to the network, and (2) there is no real reason to keep that little, and (3) we don't have signaling room to send out every tiny variation.
12:39 < petertodd> sipa: how much more bandwidth do your status say serving ~100 or whatever blocks is vs. 10?
12:39 < petertodd> sipa: I mean, you can just turn off NODE_NETWORK_LIMIT entirely
12:39 < jonasschnelli> gmaxwell: They would keep more but only willing to serve the last 10
12:39 < gmaxwell> sipa: if you want to limit your bandwidth, limit it.
12:39 < sipa> gmaxwell: well we have 3 possibilities
12:39 < jonasschnelli> NODE_NETWORK_LIMITED would be a limit
12:39 < sipa> fair enough, we have other mechanisms for limiting bandwidth
12:39 < edcba> QoS on historical blocks :)
12:40 < sipa> petertodd: i need to look again... it may not be that much difference
12:40 < gmaxwell> sipa: and we have had reorgs longer than 10 in recent memory, what happens if all of your peers are like that?
12:40 < BlueMatt> gmaxwell: we have?!
12:41 < sipa> BlueMatt: bip50 was 30 deep, iirc
12:41 < BlueMatt> oh, you mean the csv false-signaling reorgs?
12:41 < BlueMatt> yea, ok
12:41 < sipa> ok, i retract my suggestion for 10 deep
12:41 < jonasschnelli> Would the two bit amount-of-blocks-available signaling be effective regarding the delay of address distribution?
12:41 < BlueMatt> always need 2 * MAX_HUMAN_FIX_TIME_FACTOR for everything :p
12:42 < sipa> but we do have 3 possibilities with 2 bits... perhaps we can have a 3rd limit
12:42 < jonasschnelli> People tend to prune to MB rather then blocks (which could be a design mistake)
12:42 < gmaxwell> jonasschnelli: Why do you think it has much to do with address distribution delay at all?
12:42 < gmaxwell> if you keep the last 288 you keep the last 288.. you're not going to flicker that on and off.
12:42 < gmaxwell> jonasschnelli: the design guarentees that you'll have 288 blocks.
12:42 < gmaxwell> (of the software)
12:42 < jonasschnelli> gmaxwell: Maybe I'm looking to much to our seeders,... but the crawling till you serve IPs can be very delayed.
12:43 < gmaxwell> so?     
12:43 < jtimon> jonasschnelli: I think I agree on prunning by height being more useful
12:43 < gmaxwell> You'll signal you keep X if you're guarenteed to keep X.
12:43 < jtimon> or relative height rather
12:43 < sipa> s/height/depth/
12:43 < jonasschnelli> Okay. But prune=550 is a MB target. Does it guarantee and amount of blocks?
12:43 < jtimon> sipa: right, thanks
12:43 < jonasschnelli> *an     
12:44 < gmaxwell> jonasschnelli: it guarentees we'll keep 288 blocks. The whole feature was designed to guarentee that for reorg reasons, but people thought offering a MB centric UI would be more useful to users.
12:44 < gmaxwell> I think in the future we'll change it to a limited set of options.
12:44 < gmaxwell> Maybe all of them named after words for big in different languages, like starbucks. :P
12:44 < jonasschnelli> Okay. Fair enough... 
12:44 < achow101> gmaxwell: the MB option confuses people though since it includes the undo data. people see 550 and they assume it means 550 blocks since 1 MB blocks
12:44 < luke-jr> eh, 550 MB is only guaranteed 137 blocks with segwit
12:45 < luke-jr> oh, forgot undo data
12:45 < sipa> gmaxwell: "For me a venti depruned node, please"
12:45 <@wumpus> lol @ coffee names
12:45 < gmaxwell> luke-jr: then that needs to get fixed.
12:45 < jonasschnelli> lol     
12:45 < gmaxwell> sipa: with a double shot of xthin.
12:45 < jonasschnelli> pfff
12:46 < gmaxwell> luke-jr: easy fix.
12:46 < luke-jr> controversial fix
12:46 < sipa> gmaxwell: it'll break existing configs
12:46 < jonasschnelli> Okay. I can start writing a draft specs about the two bit (144/~1000) NODE_NETWORK_LIMITED.. will announce once I have something
12:46 < BlueMatt> sipa: I'm sorry, I dont speak starbucks
12:46 < gmaxwell> sipa: so?
12:47 < gmaxwell> jonasschnelli: seriously, like why did I bother commenting today?
12:47 < sipa> BlueMatt: venti is italian for 20. easy. that's obviously more than "grande" or "tall"
12:47 < gmaxwell> first peak is at 144, if _must_ keep more than that to be useful.
12:47 < BlueMatt> sipa: ehh, I'll stick with my *good* coffee, thanks
12:47 < BlueMatt> anyway, next topic?
12:48 <@wumpus> #topic high priority for review
12:48 < praxeology> My 2 cents: the UI should stay in MB, but underlying the variables stored by the software should be in block count... for the prune threshold.
12:48 <@wumpus> anything to add to project https://github.com/bitcoin/bitcoin/projects/8?
12:48  * BlueMatt suggests adding #10199 for morcos 
12:48 < gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
12:49 < BlueMatt> (who is out today)
12:49 < sipa> i'd like to get review on #10195 (which i think is ready)
12:49 < gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
12:49  * BlueMatt humbly requests rebase of #7729 which is on that list
12:49 < gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
12:49 < BlueMatt> sipa: pyou already have an entry....
12:49 < sipa> oh :(
12:49 <@wumpus> added 10199
12:50 < cfields> It's not urgent, but #10285 is first in a long line towards libevent
12:50 < sipa> ok, swap #10148 for #10195 then; 10148 needs more tests
12:50 < gribble> https://github.com/bitcoin/bitcoin/issues/10285 | net: refactor the connection process. moving towards async connections. by theuni · Pull Request #10285 · bitcoin/bitcoin · GitHub
12:50 < gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
12:50 < gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
12:50 < luke-jr> suggested topic? planned obsolecense
12:50 < jtimon> random though: what about maintaining the mb option an adding an incompatible one (you can only set one) with depth ? then the mb can be just an estimation that translates to depth on init, but you don't break old configs, only the expected guarantees about limits
12:51 < BlueMatt> luke-jr: NACK
12:51 < luke-jr> BlueMatt: NACK topic or NACK it altogether? :/
12:51 < achow101> luke-jr: planned obsolecense is a bad name for it
12:51 < BlueMatt> second
12:52 <@wumpus> added 10285, swapped #10148 for #10195
12:52  * luke-jr waits for topic change before going into discussion
12:52  * jtimon checks https://github.com/bitcoin/bitcoin/pull/8855 is on the priority list
12:52 < gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
12:52 < gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
12:52 < sipa> thanks
12:52 <@wumpus> #topic bitcoind expiration
12:53 < jonasschnelli> 10282
12:53 < jonasschnelli> #10282
12:53 < gribble> https://github.com/bitcoin/bitcoin/issues/10282 | Expire bitcoind & bitcoin-qt 7-8 years after its last change by luke-jr · Pull Request #10282 · bitcoin/bitcoin · GitHub
12:53 < luke-jr> BlueMatt: reasoning for NACK?
12:54 < cfields> luke-jr: maybe explain reasoning for doing so first?
12:54 < luke-jr> re achow101's comment, I don't really think it matters what we call it
12:54 < luke-jr> cfields: 10282 has a full explanation
12:54 < petertodd> any timeframe short enough to really be useful will probably be short enough to raise political risks...
12:54 < luke-jr> 1) it's basically guaranteed to be unsafe by then; 2) hardforks become softforks with enough lead time
12:55 < jtimon> I think if it's optional and disabled by default it kind of defeats the point, but I certainly don't want that for myself or the users I recommend to use bitcoin core
12:55 < sipa> luke-jr: i don't see how this has anything to do with consensus changes
12:55 < petertodd> also, is there any precedent for this kind of expiration in other software?
12:55 < BlueMatt> luke-jr: 110% sends the wrong message. if i expected any reasonable person to see that and think "I need to think for myself about what consensus of the network is" I'd be happy with it, but realistically the only people reading that will think "oh, I have to switch to the latest thing from Bitcoin Core, for whatever Bitcoin Core is according to my local google server"
12:55 < luke-jr> jtimon: what is the use case for running node software over 7 years after its release, without maintenance?
12:55 < gmaxwell> petertodd: yes, but I'm not aware of any that can be overridden.
12:56 < sipa> luke-jr: i think insecurity of the software is perhaps a good reason, but not consensus
12:56 < petertodd> gmaxwell: got any examples?
12:56 < gmaxwell> petertodd: see also the thing with debian and xscreensaver.
12:56 < luke-jr> BlueMatt: that's a problem independent of this IMO
12:56 < petertodd> gmaxwell: ah, yeah, that crazy situation...
12:56 -!- Don_John [~Don@2600:8800:548f:1500:3573:20cf:5453:4f0f] has joined #bitcoin-core-dev     
12:57 < BlueMatt> luke-jr: how is that independant of the thing which creates it? but, indeed, security may be a reasonable reason, not sure its justified, though
12:57 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
12:57 < BlueMatt> am i really not allowed to not upgrade the bitcoind I've got running behind by bitcoind/xyz firewall?
12:57 < luke-jr> BlueMatt: people will mostly all update before this triggers; probably using the insecure method you describre
12:57 < gmaxwell> I agree with petertodd's point about short enough to be useful is short enough to be problematic. :( But there are other not really useful features...
12:57 < BlueMatt> oops, bitcoind crashed in production
12:58 < luke-jr> BlueMatt: note this has an explicit override allowed
12:58 < petertodd> gmaxwell: and there's a larger point too: chances are the surrounding software on your machine is also not getting updated anyway, so you've got other big problems
12:58 < luke-jr> if you really don't want to upgrade, just add to your config file
12:58 < BlueMatt> luke-jr: yes, and you can do that /after/ your bitcoind has crashed
12:58 < jtimon> luke-jr: let's say my friend remembers what I told him about being up to date 6 years and 11 months after I helped him install bitcoin core
12:58 < BlueMatt> which is kinda shit
12:58 < gmaxwell> it would be nice to be able to say there are no nodes running older than X without the user deciding to keep them running.
12:58 < luke-jr> BlueMatt: you could do it before as well, but IMO after 7 years it's okay to force the user to do something
12:59 < gmaxwell> BlueMatt: yes, but the crash was an RCE and all your funds are now gone. :)
12:59 <@wumpus> if you run nodes in production you'll have some system to monitor it
12:59 < BlueMatt> gmaxwell: not if its the bitcoind that everything talks to on your network and it just sits behind sufficient layers of regularly-updated bitcoind firewalls
12:59 <@wumpus> and summon an operator on crashes
12:59 < BlueMatt> wumpus: lol, i meannnnn, maybe
13:00 < sipa> wumpus: hahaha, yes, with a server farm at the end of the rainbow
13:00 < luke-jr> BlueMatt: and what if it doesn't crash, but someone exploits your failure to enforce a softfork?
13:00 < jtimon> or shouldn't I recommend bitcoin core for a wallet?
13:00 < petertodd> wumpus: you should talk to some banking IT guys about how hard it is to get approval to update things :)
13:00 < luke-jr> jtimon: I don't understand your argument.
13:00 <@wumpus> petertodd: I'm not saying anything about updating
13:00 < instagibbs> jtimon, you can over-ride the setting, I believe
13:01 < petertodd> wumpus: literally touching a config option is an update by those standards
13:01 < jtimon> instagibbs: oh, I missed that
13:01 <@wumpus> only about crashes, if some software is important to your business and it crashes, you'll notice.
13:01 <@wumpus> anyhow
13:01 <@wumpus> #endmeeting
13:01 < lightningbot> Meeting ended Thu Apr 27 20:01:43 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:01 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-27-19.02.html
13:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-27-19.02.txt
13:01 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-27-19.02.log.html
13:01 < jtimon> luke-jr: sorry, I missed what instagibbs just said, should read the proposal I guess
13:03 < jnewbery> "after 7 years it's okay to force the user to do something" - not sure I understand this. Who's forcing the user to do something?
13:03 <@wumpus> heck my nodes do nothing imporant and even I have a one-liner script that sends me a mail on crash or unexpected exit
13:03 < luke-jr> jnewbery: 7 years after it's released, bitcoind/-qt would exit and refuse to start until the user chose to either upgrade it, or override the expiration
13:03 < jtimon> jnewbery: also, this is free software, you can't force users
13:04 < jnewbery> jtimon - right that's my point
13:04 < sipa> my node does something important, and i have a 0-line script that sends me an mail on crash (= people mail me that my website stopped updating)
13:04  * sipa hides
13:04 < luke-jr> jtimon: you can force users to *do something* :P
13:04 <@wumpus> sipa: well that works too
13:04 < luke-jr> sipa: haha
13:05  * BlueMatt has a feeling sipa's approach is more common
13:05 < jtimon> luke-jr: yes, but then I will disable the anti-feature for my friend the first time I help him install and tell him about updates
13:06 < luke-jr> jtimon: why?
13:06 < luke-jr> the "anti-feature" has no harm in any reasonable scenario
13:06  * BlueMatt would do the same
13:06 < jnewbery> I'd be happy for there to be a warning if running an old version, but I really don't like it automatically disabling a node after 7 years, particularly if the reason is "this enables a sort of certainty of old nodes ending by a deadline, turning any hardfork into a de facto softfork provided it is planned 8 years out."
13:06 <@wumpus> another possiblity would be to only refuse to start after 7 years, not stop if already running
13:06 <@wumpus> this would give less guarantees, but still
13:06 < jnewbery> In that case, we might as well have auto-update
13:06  * instagibbs imagining someone running a node non-stop for 7 years
13:06 <@wumpus> jnewbery: wow that's very black and white
13:06 < luke-jr> jnewbery: not the same thing at all; the user can always opt to bypass the expiration
13:06 < petertodd> wumpus: god help us if we ever release a version that gets the date wrong...
13:07 < BlueMatt> wumpus: yea, something much more watered down may be reasonable, including huge fat warnings if the software is like 2 years old
13:07 < BlueMatt> wumpus: the perception will be black and white as well
13:07 <@wumpus> petertodd: well it could mention the flag to override I guess
13:07 < jtimon> luke-jr: again, sorry, should read the proposal but "programmed obsolecense" definitely sounds like an anti-feature, after reading the proposal, if I think is a feature, will maybe just suggest to rename it
13:07 < BlueMatt> refusing to start with an error message mentioning the flag to override would be reasonable, but also largely useless
13:07 <@wumpus> anyhow, apparently the consensus is to not do it, that's fine
13:07 < BlueMatt> though maybe not just to remind users
13:08 < petertodd> wumpus: you still might have quite a bit of chaos of nodes being shut down all at once
13:08 <@wumpus> petertodd: that's why I suggested "<wumpus> another possiblity would be to only refuse to start after 7 years, not stop if already running"
13:08 <@wumpus> in any case, seems there's too much drawbacks to this
13:09 < sipa> wumpus: so all you need to do after 7 years is find a remote crashing bug, and use it on every remaining node (and finding a remote crash bug for 7 yo software doesn't sound hard...)
13:09 < sipa> :)     
13:09 < petertodd> wumpus: I'd think nodes get restarted reasonably often, and often by automatic means
13:09 < BlueMatt> wumpus: yes, your proposal i could get behind, mostly because it would inform users that they can add a conf option, making the "refuse to start" thing kinda moot, while still being really insistent on telling users to upgrade, which is fine
13:09 <@wumpus> BlueMatt: I think that's acceptable after 7 years
13:10 < sipa> i don't think that there is much difference between refusing to start vs stopping to work
13:10 <@wumpus> come on, 7 years is an eternity on the internet, we shouldn't bee too childish about this
13:10 < sipa> especially at that timeframe
13:10 <@wumpus> sipa: right
13:10 < BlueMatt> sipa: I tend to disagree
13:10 < jnewbery> wumpus: not helpful. I think people are raising legitimate concerns
13:10 <@wumpus> a startup check is simpler to implement and less error prone though
13:11 < BlueMatt> (re difference between startup and forced shutdown)
13:11 <@wumpus> jnewbery: really, a legitimate concern, that people are running 7 year old software in production?
13:11 < BlueMatt> wumpus: yes
13:11 -!- Giszmo [~leo@ip-246-233.219.201.nextelmovil.cl] has quit [Ping timeout: 268 seconds]     
13:11 < jnewbery> a legitimate concern that devs don't have the right to "force" users to do something
13:11 <@wumpus> sometimes it's just like people are just making up unlikely \things just to argue
13:11 < instagibbs> and can't be bothered to click through, or set a flag?
13:11 < BlueMatt> wumpus: 7 years is, in fact, *not* an eternity on the internet
13:12 < instagibbs> I understand it would need to be done right, but that's a little nuts.
13:12 <@wumpus> it wouldn't be forcing to do anything, as there is an override
13:12 <@wumpus> sigh
13:12 < BlueMatt> instagibbs: click through fine, shutdown *while running*?
13:12 < luke-jr> BlueMatt: it's only slightly shorter than Bitcoin's current lifetime
13:12 <@wumpus> BlueMatt: okay, what ever
13:12 < instagibbs> BlueMatt, sure, that's another dot on the matrix, I agree on that one
13:12 < jtimon> it should still be relatively easy for users to get out of the stuck situation in case they can't upgrade in the same system or something, like maybe deleting a filed named ~/.bitcoin/DELETE_ME_ONLY_IF_YOU_CANT_UPGRADE_IN_THIS_SYSTEM or something
13:13 < luke-jr> jtimon: yes, it's already easy to override
13:13 < BlueMatt> jtimon: conf flag seems neater, no one checks their bitcoin datadir
13:13 < luke-jr> we can make it easier perhaps by taking a YYYY instead of POSIX timestamp
13:13 < petertodd> gmaxwell: btw, re: your comment in the meeting, no-one's funding me to do any work on Bitcoin Core these days
13:13 < jtimon> luke-jr: BlueMatt: great
13:14 < luke-jr> jnewbery: nobody is forcing users to run Core at all.
13:15 < BlueMatt> wumpus: on a less controversial note, #7729 is ripe for rebase-and-review, no? or are we now so bogged down on major features that need review you're waiting? :/
13:15 < gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
13:15 < jnewbery> luke-jr indeed, and I don't think core devs should attempt to force users to upgrade
13:16 < luke-jr> jnewbery: we're not. by running Core, they would be opting in to being forced to either upgrade OR tell the software they don't want to
13:16 <@wumpus> BlueMatt: yes, I tried once, but so much moved around since that it's pretty much "re-do" instead of rebase
13:16 < BlueMatt> grr, sorry about that :/
13:16 < luke-jr> "forced" is really the wrong word here
13:16 < BlueMatt> luke-jr: thats ridiculous, you're living in a world where people have the time go read a ton of bitcoin core docs/code before running it, and do...neither of which are true
13:16 <@wumpus> I don't think we're going to agree on this luke-jr
13:16 < jtimon> yeah, as BlueMatt said, being annoying about upgrading is fine
13:17  * BlueMatt goes back to trying to make a dent in the review pile
13:17 < luke-jr> BlueMatt: not before, simply read a short notice when it tells them to make a decision
13:17 <@wumpus> when it detoriorates to arguing about what words to use it's better to just stop
13:17 -!- tw2006 [~tw2006@2601:187:8480:2770:47b:d:ffbd:711f] has quit [Remote host closed the connection]     
13:18 < luke-jr> jtimon: well, this proposal comes down to being annoying at worst, and BlueMatt doesn't like it either
13:18 < BlueMatt> luke-jr: which proposal now? refusing to startup or crashing while running?
13:18 <@wumpus> BlueMatt: IIRC I don't think any of the wallet changes that complicate rebasing #7729 are your fault, just a lot happened there
13:18 < BlueMatt> but, yea, I'm gonna go back to review, this has devolved
13:18 < gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
13:18 < luke-jr> BlueMatt: yes, being able to override it means it's merely annoying
13:19 < BlueMatt> wumpus: fair, but its on the rest of us to get it reviewed in a timely manner :p
13:19 < jtimon> luke-jr: as said, without reading it, my only concern that it wasn't relatively easy or undocumented for a user to overrule the annoyance
13:19 < michagogo> Last week we were talking about WSL and Gitian
13:19 <@wumpus> I would have liked quicker feedback on the API. But I think there's agreement on that now so implementation should be fairy simple
13:20 < michagogo> I haven't tried with VBox yet, but I can confirm that LXC doesn't work
13:20 < jtimon> what is the link again?
13:20 <@wumpus> what doesn't work?
13:20 < michagogo> make-base-vm fails, as does lxc-create
13:20 <@wumpus> building master using gitian?
13:20 < michagogo> No, running LXC in WSL
13:20 < luke-jr> no surprise there
13:20 <@wumpus> ohh. Yes we know that, that's an upstream problem
13:20 < michagogo> Right
13:20 <@wumpus> bother microsoft :)
13:20 < michagogo> I wasn't expecting it to, at all
13:21 < michagogo> But someone last week thought maybe it would, so I tried it
13:21 <@wumpus> even building depends in WSL currently doesn't work, due to some vague change in their ubuntu
13:21 < BlueMatt> microsoft: taking "compatibility" to a new level
13:21 <@wumpus> https://github.com/bitcoin/bitcoin/issues/10269
13:21 <@wumpus> BlueMatt: yeah embrace and extinguish, round N
13:22 < michagogo> Really? I didn't know that.
13:23 < michagogo> I remember when WSL was pretty new I tried it and it worked perfectly
13:23 <@wumpus> it worked at some point
13:24 < BlueMatt> it worked when they made the press release for all the people to try it, after that they only cared that it appeared to work so that windows folks build software that doesnt really work on linux, but claims to :p
13:24 < michagogo> It's times like this that I wish I had Windows 10 on my computer
13:24 < BlueMatt> ewwwwwww
13:25 < BlueMatt> thats worse than starbucks coffee!
13:25 < michagogo> I mean, I'm on Win7 right now
13:25 < BlueMatt> ouch
13:26 < michagogo> Haven't upgraded for two reasons. First, I don't use my computer at home so much lately (= the last couple years) and don't have so much time to spend with it to try and fix it if it gets messed up, smooth out the kinks, etc.
13:26 < michagogo> Second, at work I have 7, and I'm concerned that one of two things will happen
13:26 < edcba> 7yrs software in prod rotfl: in 2016 i was supporting xp at work...
13:27 -!- Giszmo [~leo@ip-42-226-107-190.nextelmovil.cl] has joined #bitcoin-core-dev     
13:27 < jtimon> is there an issue in win7's github for the bug on their side? let's just go concept ack there
13:27 < michagogo> Either it'll be too different and I won't adjust to it because I'll still be mostly using 7, and then my time with it will be annoying, or, it'll be amazing and I'll get used to having stuff from it, and then be sad when I go back to 7 at work
13:27 < michagogo> "win7's github"?
13:28 < jtimon> sorry, bad joke
13:28 < BlueMatt> michagogo: i think it was a joke :p
13:28 < BlueMatt> jtimon: i found it comical
13:28 < michagogo> Wait, which bug?
13:28 < michagogo> I first thought you meant Windows 10
13:28 < jtimon> BlueMatt: oh, thanks, I read your "I think" as a confirmation that it was bad
13:28 < michagogo> Because if Core builds on Ubuntu but not in WSL, that *is* a bug in WSL
13:29 <@wumpus> after all we did a gitian build very shortly ago, which uses the same version of ubuntu (14.04)
13:30 <@wumpus> maybe it's some magic with line endings or such
13:30 < michagogo> I think as of Creator Update, a couple weeks ago, new WSL installs are Xenial
13:30 <@wumpus> ugh     
13:30 < michagogo> Ugh? Why?
13:30 <@wumpus> the windows toolchain on xenial is kind of broken
13:31 < BlueMatt> no wonder wsl is broken
13:31 <@wumpus> yes, that explains it then
13:31 < michagogo> Really? Have bugs been filed?
13:31 <@wumpus> they can be happy they don't get executables
13:31 <@wumpus> I don't think it was ever narrowed down
13:32 < michagogo> Is there anything different besides gcc being replaced by mingw-w64?
13:32 <@wumpus> see "Ubuntu 16.04 Windows cross-build" on https://github.com/bitcoin/bitcoin/projects for a collection of issues
13:33 <@wumpus> it's a newer version of mingw-w64 that doesn't work so well
13:33 < michagogo> I was thinking of upgrading my Ubuntu VM (that I use mostly for gitian building) from Trusty to Xenial - should I not do that?
13:33 <@wumpus> fstack-protector produces broken executables, and there was some c++11 threading snafu
13:33 <@wumpus> could be that these are solved by now, I have no idea, haven't tried it for months
13:34 <@wumpus> you can't use xenial for gitian building without everyone else changing too
13:34 < michagogo> I meant for the host
13:34 <@wumpus> oh the host can be anything
13:34 < michagogo> Not changing the target container
13:34 <@wumpus> I use debian for the host
13:34 < jtimon> wumpus: btw, it would be nice to put BlueMatt 's libconsensus-related PRs in https://github.com/bitcoin/bitcoin/projects/6 (and always tag anything there with "consensus")
13:34 < michagogo> I wonder if I should delete my precise sandbox VM
13:35 <@wumpus> michagogo: yes, why not
13:35 <@wumpus> jtimon: ok
13:36 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
13:36 < jtimon> wumpus: thanks, I mean, not a priority, just would be somewhat helpful
13:41 < jtimon> btw BlueMatt thanks for https://github.com/bitcoin/bitcoin/pull/771 I shouldn't look at it much and look at the new things instead but like these things if I find the time
13:41 < BlueMatt> jtimon: lol, that was so long ago even I dont remember how it was designed
13:42 < jtimon> but you said it was based on it, so I was hoping some ideas remained
13:43 < jtimon> that's what makes it more interesting IMO, it could be the same general idea with very different code
13:44 < jtimon> or more or less the same code, which I would find more amusing
13:45 -!- tommyhot [tommyhot@85.248.229.194] has joined #bitcoin-core-dev     
13:45 -!- JackH [~laptop@79-73-191-98.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]     
13:55 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
14:01 < sipa> jtimon: i think the extent of the similarity is "encapsulate all the state related to blockchain censensus"
14:04 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
14:06 -!- Giszmo [~leo@ip-42-226-107-190.nextelmovil.cl] has quit [Ping timeout: 245 seconds]     
14:09 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
14:09 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
14:09 -!- CubicEarth [~cubiceart@50-1-104-188.dsl.dynamic.fusionbroadband.com] has joined #bitcoin-core-dev     
14:09 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
14:12 -!- Dyaheon [~Dya@91.156.192.24] has quit [Ping timeout: 240 seconds]     
14:13 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
14:14 -!- comboy [~quassel@tesuji.pl] has joined #bitcoin-core-dev     
14:17 < achow101> wumpus: michagogo windows cross compile on ubuntu xenial is still broken.
14:17 < achow101> on wsl, there's a different problem with depends failing
14:18 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev     
14:21 -!- Giszmo [~leo@ip-108-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev     
14:24 <@wumpus> achow101: yes, seems to be different issues - confusing
14:24 <@wumpus> building on xenial, for xenial works fine in any case
14:24 <@wumpus> it only breaks with windows in the picture (either as cross compile or WSL)
14:30 -!- praxeology [~praxeolog@unaffiliated/praxeology] has quit [Ping timeout: 240 seconds]     
14:33 < michagogo> Hm, if I have a VM with a snapshot and a bunch of changes since the snapshot, and I want to create a snapshot of the current state and delete the existing one
14:34 < michagogo> Does it matter at all whether I delete the current one before or after taking the new one, in terms of final size?
14:42 -!- Giszmo [~leo@ip-108-233.219.201.nextelmovil.cl] has quit [Ping timeout: 268 seconds]     
14:44 -!- marcoagner [~user@187.113.133.247] has joined #bitcoin-core-dev     
14:44 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
14:56 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
14:57 -!- Giszmo [~leo@ip-120-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev     
15:02 -!- tw2006 [~tw2006@2601:187:8480:2770:99d0:fec5:e18f:41df] has joined #bitcoin-core-dev     
15:11 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
15:13 -!- jamoes [~cretwich@104.193.170-247.PUBLIC.monkeybrains.net] has quit [Ping timeout: 246 seconds]     
15:17 -!- giannis [b2a2de29@gateway/web/freenode/ip.178.162.222.41] has joined #bitcoin-core-dev     
15:17 -!- eragmus [sid136308@gateway/web/irccloud.com/x-mtksrqpnfmjyyyyf] has quit [Ping timeout: 240 seconds]     
15:17 -!- giannis is now known as Guest50266     
15:18 -!- pindarhk [sid105966@gateway/web/irccloud.com/x-ytnibsuydjnzrgqu] has quit [Ping timeout: 240 seconds]     
15:18 -!- jamoes [~cretwich@104.193.170-247.PUBLIC.monkeybrains.net] has joined #bitcoin-core-dev     
15:18 -!- trotski2000 [sid206086@gateway/web/irccloud.com/x-sjpvetdnmvpievwd] has quit [Ping timeout: 240 seconds]     
15:20 -!- Guest50266 [b2a2de29@gateway/web/freenode/ip.178.162.222.41] has quit [Client Quit]     
15:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]     
15:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
15:26 -!- eragmus [sid136308@gateway/web/irccloud.com/x-lcrlxogkggnpkdpr] has joined #bitcoin-core-dev     
15:26 -!- trotski2000 [sid206086@gateway/web/irccloud.com/x-imwdbglqmznierqr] has joined #bitcoin-core-dev     
15:27 -!- pindarhk [sid105966@gateway/web/irccloud.com/x-zhaxliabrvbgbpoe] has joined #bitcoin-core-dev     
15:30 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
15:30 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 255 seconds]     
15:31 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
15:37 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
15:46 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
15:46 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]     
15:49 < bitcoin-git> [bitcoin] practicalswift closed pull request #9544: [trivial] Add end of namespace comments. Improve consistency. (master...consistent-use-of-end-of-namespace-comments) https://github.com/bitcoin/bitcoin/pull/9544
15:49 -!- [\\\] is now known as tripleslash     
15:51 < bitcoin-git> [bitcoin] practicalswift reopened pull request #9544: [trivial] Add end of namespace comments. Improve consistency. (master...consistent-use-of-end-of-namespace-comments) https://github.com/bitcoin/bitcoin/pull/9544
15:59 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
16:00 -!- Giszmo [~leo@ip-120-233.219.201.nextelmovil.cl] has quit [Ping timeout: 260 seconds]     
16:08 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
16:09 -!- gm2051 [~gm2051@2.124.85.23] has quit [Ping timeout: 240 seconds]     
16:20 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]     
16:23 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
16:24 -!- marcoagner [~user@187.113.133.247] has quit [Ping timeout: 258 seconds]     
16:32 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
16:33 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
16:37 -!- jamoes [~cretwich@104.193.170-247.PUBLIC.monkeybrains.net] has quit [Remote host closed the connection]     
16:37 -!- marcoagner [~user@187.113.138.208] has joined #bitcoin-core-dev     
16:50 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Remote host closed the connection]     
16:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
16:58 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
17:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []     
17:01 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
17:09 -!- tw2006 [~tw2006@2601:187:8480:2770:99d0:fec5:e18f:41df] has quit [Remote host closed the connection]     
17:22 -!- m8tion [~AndChat47@88.190.249.49] has joined #bitcoin-core-dev     
17:30 -!- m8tion [~AndChat47@88.190.249.49] has quit [Ping timeout: 268 seconds]     
17:35 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
17:39 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
17:40 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
17:41 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
17:45 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Ping timeout: 260 seconds]     
17:57 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
18:01 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 241 seconds]     
18:09 < BlueMatt> https://twitter.com/sigfpe/status/857748171778252800 <-- fuck c++
18:10 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Remote host closed the connection]     
18:10 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev     
18:11 -!- tw2006 [~tw2006@2601:187:8480:2770:88a1:8fed:7095:127d] has joined #bitcoin-core-dev     
18:12 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 248 seconds]     
18:13 < luke-jr> BlueMatt: looks like it only affects 'auto' typing
18:13 < BlueMatt> yes, that was my read
18:13 < BlueMatt> though still....fuck
18:13 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev     
18:14 < mryandao> when will core be re-written in Rust?
18:15 -!- tw2006 [~tw2006@2601:187:8480:2770:88a1:8fed:7095:127d] has quit [Ping timeout: 260 seconds]     
18:15 < BlueMatt> a) when rust stabilizes seriously, b) the consensus parts probably never
18:16  * midnightmagic stabs rust
18:16 < sipa> anyone is free to rewrite core in rust
18:16 < sipa> doesn't mean that anyone here has to
18:17 < BlueMatt> transliterating consensus code does not sound like fun......
18:17 < BlueMatt> (or possible)
18:18 -!- Don_John [~Don@2600:8800:548f:1500:3573:20cf:5453:4f0f] has quit [Quit: Later]     
18:21 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:2ddf:e713:3a8:1fb8] has quit [Quit: .]     
18:21 < midnightmagic> conformal confirms it..
18:23 < luke-jr> didn't someone already do a Rust full node impl?
18:24 < mryandao> yeah, parity
18:24 < BlueMatt> luke-jr: i mean they announced one, its very incomplete and has some major bugs current afaiu
18:24 < BlueMatt> ly     
18:24 < sipa> afaiu?
18:24 < BlueMatt> as far as i understand
18:24 < sipa> ah.     
18:25 < BlueMatt> ugh, our current list of major things for 0.15 isnt gonna make it at this rate
18:26 < luke-jr> to be expected
18:26 < luke-jr> bugs in Rust impl I mean
18:41 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
18:41 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
18:43 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 246 seconds]     
18:45 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
18:47 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Ping timeout: 260 seconds]     
18:48 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds]     
18:49 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving]     
18:54 -!- tw2006 [~tw2006@2601:187:8480:2770:1d0a:f92c:4f4d:952d] has joined #bitcoin-core-dev     
19:00 -!- dermoth [~thomas@dsl-66-36-130-50.mtl.aei.ca] has quit [Read error: Connection reset by peer]     
19:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-asreyjuhbvplsjtu] has quit [Quit: Connection closed for inactivity]     
19:00 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]     
19:01 -!- dermoth [~thomas@dsl-66-36-130-50.mtl.aei.ca] has joined #bitcoin-core-dev     
19:02 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
19:05 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Disconnected by services]     
19:06 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 260 seconds]     
19:07 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev     
19:07 -!- aj [~aj@139.162.42.226] has joined #bitcoin-core-dev     
19:17 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
19:25 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
19:25 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
19:26 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
19:27 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
19:31 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Remote host closed the connection]     
19:33 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
19:33 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev     
19:34 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
19:38 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Ping timeout: 240 seconds]     
19:40 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
19:40 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection]     
19:41 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev     
19:41 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev     
19:41 -!- isis [~isis@abulafia.patternsinthevoid.net] has quit [Remote host closed the connection]     
19:45 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Ping timeout: 246 seconds]     
19:45 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev     
19:45 -!- isis [~isis@abulafia.patternsinthevoid.net] has quit [Remote host closed the connection]     
19:53 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev     
19:59 -!- CubicEarth [~cubiceart@50-1-104-188.dsl.dynamic.fusionbroadband.com] has quit [Remote host closed the connection]     
20:07 -!- CubicEarth [~cubiceart@50-1-104-188.dsl.dynamic.fusionbroadband.com] has joined #bitcoin-core-dev     
20:11 -!- CubicEarth [~cubiceart@50-1-104-188.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 260 seconds]     
20:21 -!- nu11p7r [~nu11p7r@dfaefce4-1ec2-41ac-b8f9-6bd816c36ded.node.sporestack.com] has joined #bitcoin-core-dev     
20:40 -!- goksinen [~goksinen@2604:2000:c591:8400:5da7:1097:b3a0:c85d] has joined #bitcoin-core-dev     
20:41 -!- dodomojo [~goksinen@2604:2000:c591:8400:6c23:3d7:4f2a:4fe4] has joined #bitcoin-core-dev     
20:44 -!- goksinen [~goksinen@2604:2000:c591:8400:5da7:1097:b3a0:c85d] has quit [Ping timeout: 258 seconds]     
21:01 -!- tw2006 [~tw2006@2601:187:8480:2770:1d0a:f92c:4f4d:952d] has quit [Remote host closed the connection]     
21:02 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection]     
21:18 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has quit [Remote host closed the connection]     
21:19 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has joined #bitcoin-core-dev     
21:20 -!- kexkey [~kexkey@68.168.119.229] has quit [Ping timeout: 252 seconds]     
21:49 -!- marcoagn1 [~user@179.177.243.148] has joined #bitcoin-core-dev     
21:50 -!- dodomojo [~goksinen@2604:2000:c591:8400:6c23:3d7:4f2a:4fe4] has quit [Read error: Connection reset by peer]     
21:50 -!- marcoagner [~user@187.113.138.208] has quit [Ping timeout: 240 seconds]     
21:52 -!- CubicEarth [~cubiceart@50-1-104-188.dsl.dynamic.fusionbroadband.com] has joined #bitcoin-core-dev     
21:54 -!- dermoth_ [~thomas@216.221.51.255] has joined #bitcoin-core-dev     
21:55 -!- dermoth [~thomas@dsl-66-36-130-50.mtl.aei.ca] has quit [Disconnected by services]     
21:55 -!- dermoth_ is now known as dermoth     
21:56 -!- CubicEarth [~cubiceart@50-1-104-188.dsl.dynamic.fusionbroadband.com] has quit [Remote host closed the connection]     
21:59 -!- CubicEarth [~cubiceart@50-1-104-188.dsl.dynamic.fusionbroadband.com] has joined #bitcoin-core-dev     
22:01 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
22:20 -!- juscamarena_ [~justin@47.148.176.74] has quit [Remote host closed the connection]     
22:22 -!- juscamarena_ [~justin@47.148.176.74] has joined #bitcoin-core-dev     
22:28 -!- gm2051 [~gm2051@2a02:c7d:12e:100:255f:b68:2676:b33d] has joined #bitcoin-core-dev     
22:37 -!- juscamarena_ [~justin@47.148.176.74] has quit [Remote host closed the connection]     
22:39 -!- juscamarena_ [~justin@47.148.176.74] has joined #bitcoin-core-dev     
22:41 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
22:41 -!- juscamarena_ [~justin@47.148.176.74] has quit [Remote host closed the connection]     
22:45 -!- goksinen [~goksinen@2604:2000:c591:8400:850d:79cd:aad1:8920] has joined #bitcoin-core-dev     
22:50 -!- tw2006 [~tw2006@2601:187:8480:2770:6c95:dd8b:8090:8c4c] has joined #bitcoin-core-dev     
22:55 -!- tw2006 [~tw2006@2601:187:8480:2770:6c95:dd8b:8090:8c4c] has quit [Ping timeout: 260 seconds]     
23:00 -!- dermoth [~thomas@216.221.51.255] has quit [Read error: Connection reset by peer]     
23:00 -!- gm2052 [~gm2051@2a02:c7d:12e:100:281b:113f:fb7d:d96e] has joined #bitcoin-core-dev     
23:00 -!- dermoth [~thomas@216.221.51.255] has joined #bitcoin-core-dev     
23:02 -!- gm2053 [~gm2051@2a02:c7d:12e:100:9d3d:bcaf:1e4b:226a] has joined #bitcoin-core-dev     
23:04 -!- gm2051 [~gm2051@2a02:c7d:12e:100:255f:b68:2676:b33d] has quit [Ping timeout: 245 seconds]     
23:04 -!- nu11p7r [~nu11p7r@dfaefce4-1ec2-41ac-b8f9-6bd816c36ded.node.sporestack.com] has quit [Ping timeout: 260 seconds]     
23:05 -!- gm2051 [~gm2051@2a02:c7d:12e:100:dd80:6092:31b0:8e5d] has joined #bitcoin-core-dev     
23:06 -!- gm2052 [~gm2051@2a02:c7d:12e:100:281b:113f:fb7d:d96e] has quit [Ping timeout: 258 seconds]     
23:06 -!- gm2053 [~gm2051@2a02:c7d:12e:100:9d3d:bcaf:1e4b:226a] has quit [Ping timeout: 258 seconds]     
23:07 -!- gm2052 [~gm2051@2a02:c7d:12e:100:d47e:5c7a:be13:4959] has joined #bitcoin-core-dev     
23:10 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
23:11 -!- gm2051 [~gm2051@2a02:c7d:12e:100:dd80:6092:31b0:8e5d] has quit [Ping timeout: 258 seconds]     
23:11 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
23:56 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]