--- Day changed Thu Aug 31 2017
00:01 -!- Evel-Knievel [~Evel-Knie@178-119-237-211.access.telenet.be] has joined #bitcoin-core-dev     
00:01 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 260 seconds]     
00:06 -!- Gunnie [~kamk@2.82.cust.tetanet.cz] has quit [Quit: My computer has gone to sleep. ZZZzzz…]     
00:06 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
00:14 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:17 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
00:18 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
00:25 -!- sltrain_ [45a4d9ef@gateway/web/freenode/ip.69.164.217.239] has joined #bitcoin-core-dev     
00:32 -!- sltrain_ [45a4d9ef@gateway/web/freenode/ip.69.164.217.239] has quit [Quit: Page closed]     
00:32 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
00:42 < jl2012> is there any easy way to list all segwit txs in the mempool?
00:44 -!- praxeology [~praxeolog@cpe-173-172-191-20.tx.res.rr.com] has joined #bitcoin-core-dev     
00:46 -!- clarkmoody [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
00:46 -!- praxeology1 [~praxeolog@cpe-173-172-191-20.tx.res.rr.com] has quit [Ping timeout: 248 seconds]     
01:07 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:18 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]     
01:20 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
01:22 -!- praxeology [~praxeolog@cpe-173-172-191-20.tx.res.rr.com] has quit [Changing host]     
01:22 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
01:22 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-core-dev     
01:28 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
01:31 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:41 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has quit [Ping timeout: 252 seconds]     
01:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:55 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has joined #bitcoin-core-dev     
01:56 -!- JackH [~laptop@46.231.18.66] has quit [Ping timeout: 240 seconds]     
02:13 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
02:15 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
02:47 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds]     
02:49 -!- shesek [~shesek@bzq-84-110-56-10.red.bezeqint.net] has joined #bitcoin-core-dev     
02:50 -!- wvr [~wvr@121.red-83-45-36.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
03:07 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-core-dev     
03:16 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
03:24 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 246 seconds]     
03:34 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt]     
03:35 -!- shesek [~shesek@bzq-84-110-56-10.red.bezeqint.net] has quit [Ping timeout: 240 seconds]     
03:45 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
03:52 -!- str4d [~str4d@host81-158-166-149.range81-158.btcentralplus.com] has joined #bitcoin-core-dev     
03:56 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
04:08 -!- Gunnie [~kamk@109.202.82.2] has joined #bitcoin-core-dev     
04:16 -!- meshcollider_ [uid246294@gateway/web/irccloud.com/x-bqqxodtzvdyxsvyb] has joined #bitcoin-core-dev     
04:18 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
04:18 -!- str4d [~str4d@host81-158-166-149.range81-158.btcentralplus.com] has quit [Ping timeout: 252 seconds]     
04:18 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
04:19 -!- Aaronvan_ is now known as AaronvanW     
04:26 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
04:28 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 248 seconds]     
04:39 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
04:40 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
04:43 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has quit [Ping timeout: 240 seconds]     
04:44 -!- ChesterVal [~paulcolli@host-78-147-41-65.as13285.net] has joined #bitcoin-core-dev     
04:57 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
05:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
05:00 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
05:00 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has joined #bitcoin-core-dev     
05:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
05:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:43 -!- To7 [~theo@2604:2000:1382:b7:7852:2e5d:c2c3:407e] has joined #bitcoin-core-dev     
05:43 -!- To7 [~theo@2604:2000:1382:b7:7852:2e5d:c2c3:407e] has quit [Client Quit]     
06:01 < wumpus> I won't be at the dev meeting today - just getting settled in here at SF and have a few days holiday
06:02 -!- bitsegwit [~seggggwit@c-217-115-42-58.cust.bredband2.com] has quit [Read error: Connection reset by peer]     
06:07 < instagibbs> Synced rc3 in 5 hours on my laptop with default dbcache, very tame IO use. Very nice work!
06:10 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
06:11 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
06:12 -!- shesek [~shesek@bzq-79-182-160-64.red.bezeqint.net] has joined #bitcoin-core-dev     
06:33 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 1.4]     
06:34 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:36 -!- shesek [~shesek@bzq-79-182-160-64.red.bezeqint.net] has quit [Ping timeout: 240 seconds]     
06:43 < bitcoin-git> [bitcoin] sdaftuar opened pull request #11203: RPC: add wtxid to mempool entry output (master...2017-08-add-wtxid-to-mempool-entry) https://github.com/bitcoin/bitcoin/pull/11203
06:44 < sdaftuar> jl2012: i don't see an easy way to list all segwit tx's in the mempool currently, but i just opened #11203 which would make it pretty straightforward (just compare txid to wtxid)
06:54 -!- meshcollider_ [uid246294@gateway/web/irccloud.com/x-bqqxodtzvdyxsvyb] has quit [Quit: Connection closed for inactivity]     
07:15 -!- sstone [~sstone@3.46-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
07:18 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
07:27 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
07:29 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
07:39 -!- esotericnonsense [~esoteric@gateway/vpn/privateinternetaccess/esotericnonsense] has quit [Ping timeout: 260 seconds]     
07:40 -!- sturles [~sturles@unaffiliated/sturles] has quit [Ping timeout: 240 seconds]     
07:40 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
07:40 -!- esotericnonsense [~esoteric@gateway/vpn/privateinternetaccess/esotericnonsense] has joined #bitcoin-core-dev     
07:47 -!- adiabat [~adiabat@45.63.20.152] has quit [Quit: WeeChat 1.4]     
07:53 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
07:58 -!- adiabat [~adiabat@45.63.20.152] has joined #bitcoin-core-dev     
07:59 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Quit: Leaving]     
08:03 -!- sturles [~sturles@unaffiliated/sturles] has joined #bitcoin-core-dev     
08:07 < gmaxwell> sdaftuar: this should work: ./bitcoin-cli getblocktemplate | jq '.transactions | .[] | select(.hash != .txid) | .txid'
08:07 < gmaxwell> but that only does it with the blocktemplate.
08:09 < sdaftuar> gmaxwell: yeah so that only gets segwit tx's in the top of the mempool, rather than the whole mempool
08:10 < sdaftuar> btw you just improved my life substantially by teaching me about jq
08:12 < sstone> hi, I have a question about SPV nodes: does bitcoin core include tx witness data in filtered blocks sent to SPV client ? 
08:13 < sdaftuar> sstone: not currently, though there's an open PR on that topic.  see #10350
08:13 < bitcoin-git> [bitcoin] santyraghavan opened pull request #11204: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/11204
08:16 < sstone> sdaftuar: thanks !
08:19 -!- shesek [~shesek@bzq-79-182-160-64.red.bezeqint.net] has joined #bitcoin-core-dev     
08:22 < gmaxwell> sstone: if you have a usecase for that I'd like to learn more. I understand codeshark's and I assume we'll do it for his but his is kind of weird and obscure.
08:26 -!- Gunnie [~kamk@109.202.82.2] has quit [Quit: My computer has gone to sleep. ZZZzzz…]     
08:26 -!- shesek [~shesek@bzq-79-182-160-64.red.bezeqint.net] has quit [Ping timeout: 240 seconds]     
08:27 < sstone> our use case is light-weight (mobile for example) LN compatible wallets. There are cases when you will want to monitor the blockchain and extract preimages from witness data
08:28 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 246 seconds]     
08:39 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has quit [Ping timeout: 248 seconds]     
08:41 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
08:51 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has joined #bitcoin-core-dev     
08:54 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
08:55 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
08:55 -!- praxeology [~praxeolog@unaffiliated/praxeology] has quit [Quit: Leaving.]     
08:59 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds]     
09:07 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds]     
09:08 -!- Yogaqueef [~textual@dsl-hkibng42-5673c3-32.dhcp.inet.fi] has quit [Quit: Textual IRC Client: www.textualapp.com]     
09:10 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
09:14 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:24 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
09:25 -!- sstone [~sstone@3.46-14-84.ripe.coltfrance.com] has quit [Quit: Leaving]     
09:34 -!- blznblzn2 [~blzn@2605:6001:f28d:e600:cf36:4af4:2baf:900a] has joined #bitcoin-core-dev     
09:46 < bitcoin-git> [bitcoin] jnewbery closed pull request #10591: [tests] make pruning.py faster (master...fastprune) https://github.com/bitcoin/bitcoin/pull/10591
09:53 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
09:56 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
10:01 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
10:02 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:13 -!- timothy [tredaelli@redhat/timothy] has quit [Ping timeout: 240 seconds]     
10:14 -!- illpadrino [bab65263@gateway/web/freenode/ip.186.182.82.99] has joined #bitcoin-core-dev     
10:14 < illpadrino> hello all
10:14 < illpadrino> Does anyone have experience with Bitcoin ATM? I am thinking to put one in Paraguay
10:16 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
10:23 < Lauda> Wrong chat, go to #bitcoin.
10:23 -!- klkk [615588c6@gateway/web/freenode/ip.97.85.136.198] has joined #bitcoin-core-dev     
10:28 < warren> https://github.com/bitcoincore/  is this associated with anyone here?
10:29 < gmaxwell> warren: IIRC it's controlled by a github employee and they refused to give it up.
10:32  * sturles thinks you should rename Bitcoin Core back to Bitcoin.
10:36  * esotericnonsense agrees
10:41 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
10:44 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
10:44 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:45 -!- shesek [~shesek@bzq-84-110-56-10.cablep.bezeqint.net] has joined #bitcoin-core-dev     
10:47 -!- JackH [~laptop@46.231.18.66] has quit [Ping timeout: 240 seconds]     
10:55  * luke-jr disagrees.
10:56 < luke-jr> it was annoying to have to constantly explain to people that Core is not Bitcoin
10:58 -!- karelb [~karelb@li1380-211.members.linode.com] has quit [Quit: Bye!]     
10:59 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
11:00 -!- rjak2 [~rjak@unaffiliated/rjak] has joined #bitcoin-core-dev     
11:00 -!- rjak [~rjak@unaffiliated/rjak] has quit [Disconnected by services]     
11:00 < warren> Could rename it to Badger? (only half joking)
11:00 -!- rjak2 is now known as rjak     
11:00 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
11:00 < warren> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/9483  will you be able to rebase this soon?
11:02 < instagibbs> luke-jr, NotBitcoin
11:02 < instagibbs> agreed with luke-jr 
11:19 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has quit [Ping timeout: 240 seconds]     
11:20 -!- praxeology [~praxeolog@cpe-173-172-191-20.tx.res.rr.com] has joined #bitcoin-core-dev     
11:20 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #11204: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/11204
11:25 < bitcoin-git> [bitcoin] danra opened pull request #11205: Make fixed CAmounts and related sanity function constexpr (master...refactor/constexpr-amount) https://github.com/bitcoin/bitcoin/pull/11205
11:29 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:31 -!- asimplecoder [c6fc99e2@gateway/web/freenode/ip.198.252.153.226] has joined #bitcoin-core-dev     
11:31 < asimplecoder> hey 
11:31 < asimplecoder> anyone online?
11:34 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 246 seconds]     
11:34 -!- Giszmo [~leo@ip-227-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev     
11:35 < sipa> no     
11:37 < bitcoin-git> [bitcoin] polyetilen opened pull request #11206: Update optionsdialog.ui (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11206
11:40 -!- Veseli_Zagorec [~Veseli_Za@dh207-66-71.xnet.hr] has joined #bitcoin-core-dev     
11:47 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
11:54 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
11:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
11:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
11:58 -!- meshcollider_ [uid246294@gateway/web/irccloud.com/x-wssvnuqmqebjaqhg] has joined #bitcoin-core-dev     
11:58 -!- meshcollider_ is now known as meshcollider     
12:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
12:01 < achow101> Meeting?
12:02 < sdaftuar> here
12:02 < jnewbery> hello
12:02 < meshcollider> hi     
12:02 < sipa> hi     
12:02 < cfields> hi     
12:04 < sdaftuar> wumpus said above that he'd be skipping today
12:04 < achow101> Oh     
12:05 < cfields> well we can still discuss :)
12:05 < luke-jr> hi     
12:05 < cfields> gmaxwell: have your mass ping handy?
12:05 < achow101> Whatever shall we do without our fearless leader? :P
12:05 < luke-jr> someone should do the startmeeting command
12:05 < luke-jr> (and chair)
12:05 < sipa> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
12:05 < sipa> #startmeeting
12:05 < lightningbot> Meeting started Thu Aug 31 19:05:58 2017 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:05 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:06 < sipa> I'm not sure whether gmaxwell is available right now
12:06 < sipa> topics?
12:06 < meshcollider> it still lists wumpus as present lol
12:07 < achow101> Anything with 0.15.0?
12:07 < luke-jr> meshcollider: it's not a list of present people, just a mention to wake them up
12:07 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
12:07 < gmaxwell> I'm not really here.
12:07 < kanzure> hi.     
12:07 < luke-jr> achow101: there's a string issue, but not sure it matters much
12:07 < luke-jr> the debug log tooltip IIRC
12:07 < cfields> any observed 0.15 bugs?
12:07 < sipa> what is up with #11198?
12:08 < kanzure> next meeting unlikely to be on irc
12:08 < achow101> (I'm not really here, hard to irc on a bike)
12:09 < gmaxwell> cfields: there was someone complaining rc3 is crashing on windows
12:09 < luke-jr> what is #11198? (I'm stuck at CLI)
12:09 < morcos> heh, i am here, for a change
12:09 -!- Roger2x [55ceb93a@gateway/web/freenode/ip.85.206.185.58] has joined #bitcoin-core-dev     
12:09 < sipa> #topic 0.15.0
12:09 < cfields> sipa: heh, that hardly seems like something worth waiting for
12:09 < gmaxwell> achow101 was going to try reproducing.
12:09 < sipa> luke-jr: Fix display of package name on 'open config file' tooltip
12:09 < cfields> gmaxwell: hmm, link? or discussion?
12:09 < achow101> The rc3 problem was fixed with iirc
12:09 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
12:09 < achow101> (the windows crash thing)
12:10 < instagibbs> present
12:10 < gmaxwell> cfields: https://bitcointalk.org/index.php?topic=2132893.0
12:10 < instagibbs> gmaxwell, running fine here on windows fwiw
12:10 < gmaxwell> ohcrap this again:
12:10 < luke-jr> IMO a tooltip doesn't need to block final, but since we're waiting a week anyway, might as well do a RC with it? (maybe merge in the -acceptnonstdtxn fix too)
12:10 < gmaxwell> Problem solved!  Running bitcoin-qt with the '-resetguisettings' switch fixed it.  Thanks to MeshCollider on github for the fix! Smiley
12:10 < gmaxwell> ^ that is now the third person I've seen screwed by this.
12:10 < gmaxwell> did we change something that created this problem
12:10 < luke-jr> gmaxwell: that's the crash?
12:10 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
12:10 < gmaxwell> luke-jr: apparently it wasn't actually a crash
12:11 < gmaxwell> the symptom is you start bitcoin and it vanishes after the splash
12:11 < sipa> just the window appearing in an offscreen location?
12:11 < luke-jr> ah     
12:11 < sipa> can we add a test for that?
12:11 < luke-jr> sipa: we do already IIRC
12:11 < sipa> (if window is beyond screen coordinates, reset gui settings automatically)
12:11 < sipa> jonasschnelli: ^
12:11 < gmaxwell> 16:19 < gmaxwell> jonasschnelli: I just had someone on IRC that had their GUI not displaying after upgrading to 0.14.2 ... this fixed it https://github.com/bitcoin/bitcoin/issues/7869#issuecomment-209265754  is there some underlying bug we need to fix?
12:12 < gmaxwell> 11:19 < jonasschnelli> gmaxwell: most possible problem of a not-appearing GUI is probably persisted windows coordinates outside of the screen boundaries.
12:12 < gmaxwell> 11:20 < jonasschnelli> could be fixed by checking the screen bounds against the QSettings coords 
12:12 < gmaxwell> 11:21 < jonasschnelli> -resetguisettings will just evict all user based Qt overrides (and things like window coordinates)
12:12 < meshcollider> #11171 for reference
12:12 < sipa> thnaks
12:12 -!- Veseli_Zagorec [~Veseli_Za@dh207-66-71.xnet.hr] has quit [Quit: Leaving]     
12:12 < gmaxwell> it worries me that I've never seen this complain before and now three in a few weeks, all with people testing 0.15rc
12:13 < gmaxwell> complaint*
12:13 < luke-jr> gmaxwell: could it be the Qt version bump?
12:13 < gmaxwell> thats beyond my pay grade to speculate.
12:14 < cfields> gmaxwell: all windows complaints?
12:14 < gmaxwell> yes     
12:14 < luke-jr> a shame the users have done the workaround..
12:14 < gmaxwell> it's a pretty bad failure mode, silently gone...
12:14 < luke-jr> if we can get it reproduced again, it'd be nice to get the registry entries involved
12:14 < cfields> i wonder if they're all multi-monitor
12:14 < gmaxwell> luke-jr: well I told one to do it because it was a hail mary... I had no idea it would actually fix it.
12:14 < luke-jr> cfields: hmm, monitors of different sizes maybe?
12:15 < gmaxwell> we can ask.
12:15 < cfields> luke-jr: i was thinking: bitcoin-qt on monitor 2, shutdown, restart with only monitor 1
12:15 < luke-jr> I could totally see different-sized monitors confusing this
12:15 < luke-jr> cfields: am I wrong that we don't check for visible coordinates?
12:15 < luke-jr> err, that we do*
12:16 < luke-jr> (which would probably fail if the monitors are different sizes, due to blocked-off regions within the total dimensions)
12:16 < cfields> luke-jr: no clue
12:16 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
12:17 < achow101> Gmaxwell: I believe it's a registry problem
12:17 < achow101> Since qsettings stores things in registry
12:18 < sipa> achow101: i think the registry is just a storage medium
12:18 < gmaxwell> did we just start doing this... or
12:18 < sipa> i think bitcoin-qt has done that since forver, and nothing changed wrt to that now
12:18 < achow101> Gmaxwell: I don't think so. It's been reported a few times before with older versions
12:19 < meshcollider> relevant code? https://github.com/bitcoin/bitcoin/blob/master/src/qt/guiutil.cpp#L852
12:20 < BlueMatt> we always see a flood of reports of old issues upon new rc's
12:20 < gmaxwell> yea, okay!
12:21 < MarcoFalke> The "Fix for issues with startup and multiple monitors on windows." is already included https://github.com/bitcoin/bitcoin/commit/e9ff818b69c2f8ce4a151d1a81a3e22a4319c93d
12:22 < ryanofsky> that doesn't seem like a sufficient fix if x and y are just outside screen geometry
12:22 < jtimon> anything else regarding 0.15 ?
12:22 < luke-jr> MarcoFalke: new in 0.15?
12:22 < MarcoFalke> jup     
12:22 < luke-jr> maybe it's the problem..?
12:23 < MarcoFalke> Yes, I think the fix is not sufficient
12:24 < ryanofsky> would need to add || pos.x() > screen.width() || pos.y() > screen.height()
12:24 < gmaxwell> from that code it looks obvious how to fix this.
12:24 < gmaxwell> what ryanofsky said
12:24 < gmaxwell> well almost obvious
12:24 < luke-jr> that won't work for the different-sizes scenario, but sure
12:24 < achow101> replicated the problem. will write up how in the issue after this class I am in
12:24 < gmaxwell> ryanofsky: that one will lets the window be at width(),height(). :P
12:24 < BlueMatt> yea, no idea what QApplication::desktop()->screenNumber(parent) == -1 does, but guess it doesnt work on win....someone able to test?
12:25 < achow101> tl;dr look at the registry for qsettings for nWindowPos
12:25 < ryanofsky> BlueMatt, that is probably the check for no longer connected multimonitor
12:25 < meshcollider> ^^ if its -1 means the screen doesn't exist
12:25 < achow101> if the setting is for an off screen point, nothing will show
12:25 < gmaxwell> yea but it may do nothing on windows, perhaps on windows the window is just off screen.
12:26 < BlueMatt> ryanofsky: yea, but that should work if you're on no screen? no idea
12:26 < BlueMatt> anyway, I'll stop speculating above my paygrade
12:26 < sipa> can someone open a bug?
12:26 < BlueMatt> ^ that
12:27 < gmaxwell> just reopen 7869 perhaps
12:27 < jtimon> perhaps also PR ryanofsky's potential solution ?
12:27 < sipa> i don't think we need to solve this problem in this meeting (though there seem few other topics)
12:27 < ryanofsky> i think achow101 said he would write it up?
12:27 < luke-jr> so that's 3 things for an rc4 I guess?
12:27 < sipa> luke-jr: 3?
12:27 < achow101> I'll make a new issue with the thing I just found
12:27 < gmaxwell> We should talk about progress for full segwit support.
12:27 < meshcollider> whats the 3rd?
12:27 < instagibbs> gmaxwell, ack
12:28 < sipa> achow101: thanks!
12:28 < luke-jr> sipa: 1) positioning; 2) debug log tooltip; 3) acceptnonstdtxn help
12:28 < morcos> i know i'm the cause of rc3, but i actually advocate for drawing the line somewhere
12:28 < luke-jr> maybe 4) Polish translation update
12:28 < morcos> it wasn't clear to me if we have to wait 2 weeks now until we have a new RC
12:28 < luke-jr> morcos: IMO the positioning issue is sufficient to warrant rc4
12:28 < morcos> if so i think none of those are maybe sufficient for RC4
12:28 < sipa> morcos: let's discuss this when wumpus is available
12:29 < luke-jr> especially if users are encountering it
12:29 < morcos> ok. at the very least lets, note that its a question, instead of a conclusion that there will be RC4
12:29 < meshcollider> yeah and first lets make sure the fix for the positioning issue actually solves the problem lol
12:29 < morcos> luke-jr: but there is a workaround no?
12:29 < morcos> how much valuable info do you lose my resetguisettings
12:29 < sipa> meshcollider: indeed
12:29 < luke-jr> morcos: not a nice one - you lose all your other GUI settings
12:29 < achow101> morcos: all gui settings
12:30 < achow101> it can also be fixed with regedt
12:30 < sipa> achow101 said he'd open a bug with relevant information - let's discuss there when we have that
12:30 < luke-jr> k     
12:30 < sipa> #topic full segwit support
12:31 < sipa> i have a question: should we 1) automatically add witness redeem scripts for newly generated addresses, or 2) bypass the restriction that the redeemscript must be available for P2WPKH when the pubkey itself is available?
12:32 < morcos> sipa: could you explain that a bit more thoroughly
12:32 < BlueMatt> sipa: #1
12:32 < sipa> the downside of 2) is that we'd accept segwit payments to converted-p2pkh-to-p2wpkh addresses (which i think is a bad property), but that it significantly reduced the overhead of adding a key
12:32 < meshcollider> I'd say 1 is better
12:33 < BlueMatt> i guess drawback of 1 is you cant receive via segwit to old addresses?
12:33 < BlueMatt> I'm ok with that
12:33 < sipa> BlueMatt: i would call that an advantage
12:33 < BlueMatt> agreed
12:33 < sipa> ideally we don't accept anything to an address that wasn't given out
12:33 < sdaftuar> ^ that
12:33 < gmaxwell> we should really try to avoid accepting an address that we'd never issue if at all possible, it's very dangerous if people think they can do that and have it work.
12:33 < meshcollider> I guess there'd still be a way to manually do it if you wanted to though right?
12:33 < luke-jr> indeed, if we accept segwit to non-segwit addresses, people might get a false impression it's supported, and lose money
12:33 < Chris_Stewart_5> is #1 really that expensive? 
12:34 < sipa> alternatively, we can also have a boolean in the key meta data saying that the "corresponding" address is segwit
12:34 < sipa> in which case we bypass the need-redeemscript property, but just for keys with that flag set
12:34 < sipa> but at the cost of extra complexity
12:34 < morcos> sipa: is hte issue wiht 1) bloat?
12:34 < luke-jr> but when generating an address, it should only automatically add it if the user wants a witness address; we need to support at least P2SH-wrapper addresses until Bech32 adoption is widespread..
12:34 < sipa> morcos: yes, just bloat
12:34 < gmaxwell> manually sure, it's like importing a key.
12:35 < sipa> luke-jr: that brings us to another question - my view is that we shouldn't support choosing on a per-address basis whether it should be segwit or not; just a wallet-wide flag that you now want segwit
12:35 < luke-jr> sipa: I like the key metadata approach; that lets us refuse non-segwit payments to segwit keys
12:35 < sipa> the reason for that is for interaction with hd auto topup
12:35 < gmaxwell> ^ I think so to, wallet wide because of recovery.
12:35 < instagibbs> i think wallets make a lot more sense if by default you do one or the other, and support importing otherwise
12:35 < morcos> sipa: +1 on no per-address choosing
12:36 < luke-jr> sipa: then nobody can reasonably use p2wpkh until support for bech32 is universal? :/
12:36 < gmaxwell> importing one shows that violate the wallet wide is fine.
12:36 < morcos> the whole point of segwit (well one of them) is we think thats the right way to do transactions)
12:36 < BlueMatt> sipa: we could also do that on-disk, but in-memory keep the bloat-y version?
12:36 < sdaftuar> how will the migration to bech32 work?
12:36 < instagibbs> luke-jr, is there any reason we cant return multiple address types? thinking out loud :)
12:36 < sipa> luke-jr: i think we'll be forced to support bech32 as an optional thing and treat bech32 and its p2sh embdeed version identially
12:36 < luke-jr> also, doesn't this mean you can't upgrade existing wallets?
12:36 < gmaxwell> sdaftuar: send to it first, and when ~everyone can send it it, we start generating addresses.
12:36 < instagibbs> if we're doing a hard switchover, we can break api a bit?
12:37 < luke-jr> instagibbs: eww :(
12:37 < gmaxwell> sipa: ugh.
12:37 < sipa> gmaxwell: there's no way we can switch over an entire wallet to bech32
12:37 < sipa> at least not the first ... year?
12:37 < gmaxwell> certantly not today!
12:37 < gmaxwell> yes sure. and
12:37 < instagibbs> luke-jr, elaborate the ew
12:37 < luke-jr> sipa: that's why per-address is useful
12:37 < sipa> luke-jr: but per-address is inherently incompatible with hd auto topup
12:37 < gmaxwell> luke-jr: per-address is not backup durable.
12:38 < luke-jr> hmm     
12:38 < luke-jr> what if we use separate HD chains for each type?
12:38 < gmaxwell> why are we expanding scope to recieve BIP173 addresses. I think we should not make this scope expansion now.
12:38 < morcos> gmaxwell: what did you not like, having bech32 and p2sh both supported together?
12:38 < sipa> i think we have two options (which apply to both segwit/legacy and to p2sh/bech32): treat them as identical and accept payments to both, or switch over the wallet entirely
12:38 < BlueMatt> <luke-jr> also, doesn't this mean you can't upgrade existing wallets? <-- yea. this. the discussion about hd-upgrade kinda devolved (I've been mia for a week so may be behind), but it seems to me with the current disk structure we need hd-upgrade before we can do segwit-upgrade unless we want to start forking the -upgradewallet stuff
12:39 < gmaxwell> morcos: because then people can randomly turn your addresses to the other kind which you've never given out and pay you.
12:39 < BlueMatt> yea, I think its unacceptable to do that cause we have shit like breaking uncompressed keys, so we really, really dont want to support people blindly converting addresses, sets a terrible understanding
12:39 < sipa> my view is that we should treat bech32 and p2sh as identical - because, by design, they are identical - every segwit version is supposed to work in both
12:39 < luke-jr> BlueMatt: even the ability to upgrade an existing HD wallet to a segwit+HD wallet would be nice
12:39 < gmaxwell> the pre-segwit vs segwit version of that question is incredibly dangerous.   p2sh-embed vs not, is perhaps less so.
12:39 < sipa> but we should not treat segwit and p2pkh as identical
12:39 < morcos> so we can do this in 2 stages?  switch whole wallet to p2sh embedded segwit, and then in 6-12 mos switch whole wallet to bech32?
12:40 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
12:40 -!- asimplecoder [c6fc99e2@gateway/web/freenode/ip.198.252.153.226] has quit [Ping timeout: 260 seconds]     
12:40 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 248 seconds]     
12:40 < gmaxwell> sipa: we should have specified this as part of the segwit bips then. :(  but okay, it could be done.
12:40 < BlueMatt> sipa: I'm ok with that
12:40 < gmaxwell> morcos: that was my expectation, and we will have to do is regardless at least in terms of what addresses we return.
12:40 < jtimon> sipa: well, we could , for example switch over enterily for segwit/legacy but treat identical for p2sh/bech32, no?
12:40 < sipa> jtimon: that's exactly what i'm suggesting
12:40 < BlueMatt> morcos: i think sipa is advocating for (and I like) - switch wallet over to "segwit" and give users the addresses in p2sh-embedded form, but really thats a ui-level thing
12:41  * jtimon nods
12:41 < BlueMatt> and maybe a flag for "i gave this address out as version X"
12:41 < sipa> however, the bech32 question is not very urgent now
12:41 < sipa> while switchover the segwit is
12:41 < sipa> i guess there are a) support both for our own keys b) use separate hd chains for segwit c) switchover wallet as a whole
12:41 < morcos> BlueMatt: right so we'd be capable of receiving a bech32 payment, but we would not give those out for some time?
12:41 < sipa> i think (c) is best
12:41 < BlueMatt> morcos: yes
12:42 < instagibbs> BlueMatt, and send I hope?
12:42 < BlueMatt> sipa: wait, I'm  confused...does c include a and b?
12:42 < luke-jr> (c) will slow adoption
12:42 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
12:42 < sipa> BlueMatt: they are 3 distinct possibilities
12:43 < achow101> (c) works well with multi wallet
12:43 < sipa> (c) means there is a wallet-wide flag that says "SEGWIT: YES", and if so, all new addresses are generated as segwit, and integrated with hd topup
12:43 < sipa> but no separate chains for segwit or not
12:43 < instagibbs> achow101, right, my ledger support will likely simply utilize multiwallet for crossover
12:43 < gmaxwell> sipa: and if we wanted to convert an old wallet we could just import all the keys.
12:43 < BlueMatt> sipa: ah, yes, back to my previous question...what form does that flag take
12:43 < sipa> BlueMatt: i see
12:43 < BlueMatt> sipa: cause its damn-dirty to add a flag like that and not use our versioning stuff
12:43 < achow101> If we do that, we can also implement the optional features thing for wallets
12:43 < BlueMatt> but using our versioning stuff means we need hd-upgrade
12:44 < sipa> BlueMatt: i want to get rid of the version stuff and have feature flags
12:44 < BlueMatt> which i think we need, but may delay things
12:44 < BlueMatt> sipa: but exponential blowup of feature options :(
12:44 < sipa> BlueMatt: yes...
12:45 < sipa> so perhaps the question is: is there any reason why wallets shouldn't have that segwit flag (apart from backup reasons)
12:45  * BlueMatt sees no reason to *not* use existing versioning, but only question is possible delay
12:45 < instagibbs> BlueMatt, sorry delay how
12:45 < BlueMatt> sipa: yes, like anything else in the wallet, if user doesnt say -upgradewallet, we'd prefer to not break their backward compat
12:45 < BlueMatt> instagibbs: because if we use the versioning stuff, hd-upgrade must happen first
12:46 < morcos> Someone should write up a more comprehensive wallet plan.  The only thing that's clear is we need to support any kind of wallet that has existed in the past
12:46 < instagibbs> Ah, user delay, noted
12:46 < meshcollider> well it would only happen when they choose to upgrade to segwit only, so you can just give them a warning then right
12:46 < jtimon> sipa: what if the payer can't pay to segwit ? I think that's why luke wants to be able to genreate legacy for receiving, no?
12:46 < instagibbs> morcos, some people will be in person in a few days.... would be a good time to review such a doc
12:46 < morcos> But we don't need to support any possible combination..  So we shouldn't have segwit non-HD chain split wallets for example
12:46 < sipa> jtimon: every wallet can send to P2SH
12:46 < morcos> so lets make sure there is no way to create that
12:46 < BlueMatt> morcos: we've generally supported opening new wallets with old versions as long as they are un-upgraded, too
12:46 < jtimon> sipa: , oh, right, never mind
12:46 < gmaxwell> for upgrading I think we'd set the flag, start exploring the segwit address chain from 0 and import all the old keys as whatever they are.
12:46 < sipa> BlueMatt: yes, understood, but apart from that, is there any reason why someone would not want their wallet to construct segwit outputs?
12:47 < sipa> *addresses
12:47 < BlueMatt> morcos: yes, well then we need a "list of acceptable feature flag combinations" against which we check the wallet on load.... :/
12:47 < gmaxwell> sipa: no, only wallets that are trying to stay unupgraded.
12:47 < morcos> or for instance having segwit implies HD-chain split...
12:47 < BlueMatt> sipa: not to my knowledge, no
12:47 < sipa> so do we need a flag at all?
12:47 < sipa> as opposed to just start doing it automatically in a new version
12:47 < BlueMatt> only upgrade, to me
12:47 < BlueMatt> well we'd need users to do a -walletupgrade
12:48 < sipa> i don't think so
12:48 < BlueMatt> errr, I'm not a fan of that
12:48 < meshcollider> If you give them the setting somewhere in Qt then it can give them a compat warning when they go to upgrade it
12:48 < BlueMatt> that'd be the first time we break opening new wallets with an old version by default (and have no way to not break it!)
12:48 < sipa> maybe i'm missing something, but i see no failure scenario
12:48 < BlueMatt> i guess if we do that we should switch to bdb 5
12:48 < gmaxwell> if there is a reason we're unaware of the user can stay on the old version until we add support for whatever we want.
12:48 < luke-jr> sipa: downgrading
12:48 < sipa> luke-jr: elaborate
12:49 < sipa> old versions will produce old addresses, and not add the witness redeem script
12:49 < luke-jr> sipa: if I take my wallet, use it with 0.16, I should be able to use the same wallet with 0.12 again
12:49 < jtimon> do we want to support downgrading wallets?
12:49 < luke-jr> until I use -walletupgrade ofc
12:49 < BlueMatt> sipa: its always been the case that you can pretty easily run your wallet with an old version as long as it is not upgraded
12:49 < BlueMatt> with no significant feature loss
12:49 < sipa> new versions will produce new address, add their redeemscript, and when downgrading, those addresses will keep working
12:49 < BlueMatt> and definitely not with missing transactions
12:49 < sipa> BlueMatt: i don't see a problem
12:49 < achow101> So upgrade it with a version number
12:49 < luke-jr> sipa: old versions don't know how to sign for segwit UTXOs..
12:49 < BlueMatt> sipa: missing transactions
12:49 < sipa> BlueMatt: ?
12:50 < sipa> segwit address will work fine in older versions, if we use the redeemscript add construction
12:50 < BlueMatt> if you receive a payment using segwit and then open that wallet with an old version, it will not be there
12:50 < sipa> yes it will be
12:50 < sipa> at least down to 0.13.0
12:50 < luke-jr> sipa: and it will spend?
12:50 < sipa> luke-jr: yes
12:50 < sipa> luke-jr: the signing code for segwit works fine
12:50 < BlueMatt> mm, fair, though will fail for native segwit, I suppose?
12:50 < sipa> yes     
12:50 < sipa> but ignore bech32 for now
12:51 < jtimon> dow we want to support wallet downgrade beyond 0.13 ?
12:51 < luke-jr> sipa: okay, so how does this all work for people who actively do not wish to use segwit transactions?
12:51 < sipa> jtimon: that's a good question
12:51 < BlueMatt> ohhhhhhhhhh, wait, errrrrr, wont everythin break anyway cause it wont deserialize segwit-formatted txn in the wallet pre-0.13.0?
12:51 < sipa> BlueMatt: yes
12:51 < BlueMatt> lol, ok, well we're not fixing that one
12:51 < BlueMatt> so I dont care
12:51 < morcos> we're talking about 2 different things...  are you saying if i open an 0.12 wallet in 0.16, then i can't reopen it in 0.12
12:51 < sipa> i guess BlueMatt answered jtimon's question
12:51 < morcos> that sounds like a terrible idea
12:51 < gmaxwell> I think it's fine if use of segwit makes the wallet 0.15.1+ 
12:51 < sipa> morcos: that's already the case...
12:51 < morcos> if you upgrade it, then yeah of course you don't need to be able to go backwards
12:52 < BlueMatt> gmaxwell: I'm not ok with that, I think
12:52 < luke-jr> sipa: why?
12:52 < morcos> sipa: huh?
12:52 < gmaxwell> wut     
12:52 < sipa> morcos: because of what BlueMatt says
12:52 < morcos> i don't think so at all
12:52 < BlueMatt> gmaxwell: I'm fine with it being 0.13.0, which it already is
12:52 < morcos> hmm.
12:52 < sipa> you can receive a segwit transaction that pays you (via legacy output)
12:52 < morcos> i don't think so
12:52 < BlueMatt> gmaxwell: do we have any need to make it 0.15.1?
12:52 < sipa> that will be stored as a segwit txn in your wallet
12:52 < gmaxwell> I bet it doesn't work for 0.13.0
12:52 < BlueMatt> do we get any features from that, really?
12:52 < sipa> which 0.12 won't open
12:52 < morcos> oh maybe 
12:52 < morcos> durn
12:52 < luke-jr> ugh     
12:52 < meshcollider> Not if you just open the wallet without generating new addresses though ?
12:52 < gmaxwell> BlueMatt: how about testing resources if nothing else... but also you'll corrupt your wallet, when it doesn't know how to extend the keypool.
12:53 < luke-jr> does that mean if 0.12 receives a segwit tx, it will break newer??
12:53 < sipa> meshcollider: there can be a segwit address that pays you via a plain old p2pkh address
12:53 < BlueMatt> gmaxwell: if the wallet is un-upgraded it wont break?
12:53 < BlueMatt> gmaxwell: obviously if its an hd wallet old versions will refuse to open
12:53 < gmaxwell> BlueMatt: if it's unupgraded it's not giving out segwit addresses.
12:53 < BlueMatt> gmaxwell: though testing resources are obviously always an issue
12:54 < BlueMatt> gmaxwell: sipa was proposing that it give out segwit addresses even if it is unupgraded
12:54 < luke-jr> what happens right now, if we have a segwit tx in the wallet without witness data? :/
12:54 < gmaxwell> BlueMatt: how the heck does this even work for HD chains.
12:54 < instagibbs> 6 minutes
12:54 < meshcollider> sipa
12:54 < sipa> gmaxwell: it will work fine, unless you downgrade at the same time as you recover
12:54 < BlueMatt> gmaxwell: hd doesnt matter...wait, sipa was saying no new hd chain, maybe we should reopen that part of the discussion :p
12:55 < meshcollider> isnt that only the case if you gave out the address
12:55 < sipa> meshcollider: no
12:55 < sipa> 19:53:19 < sipa> meshcollider: there can be a segwit address that pays you via a plain old p2pkh address
12:55 < sipa> ^ in that case you don't ever generated a segwit address
12:55 < meshcollider> Can anyone generate that themselves?
12:55 < jtimon> in any case, is the question adding a new wallet version or not?
12:55 < BlueMatt> lol, sounds like we've got a lot to discuss next week
12:55 < BlueMatt> homework: everyone go farmiliarize yourself with wallet
12:55 < BlueMatt> ALL OF WALLET =D
12:55 < achow101> I'm horribly confused now
12:56 < sipa> meshcollider: no, but the sender can be segwit enabled while you aren't
12:56 < luke-jr> BlueMatt: every time I do that, I get the inclination to throw it all away and start from scratch :x
12:56 < cfields> heh, we desperately need to break this discussion up into chunks
12:56 < BlueMatt> cfields: yes
12:56 < instagibbs> can someone whip up a table or something of concerns
12:56 < instagibbs> action item?
12:57 < luke-jr> kanzure has one
12:57 < luke-jr> just needs updating
12:57 < achow101> Kanzure: add to list?
12:57 < meshcollider> oh I see yeah, true
12:57 < instagibbs> oh, for that too, if you're in SF next week
12:57 < cfields> kanzure: and update it so that it's backwards compatible to the last list, please.
12:57 < achow101> Lol     
12:57 < sipa> a) how to deal with 0.13.1 through 0.15.0 receiving a segwit transaction and then downgrading to 0.12.x or below
12:58 < sipa> b) how to switch to generating segwit addresses
12:58 < sipa> c) how to switch to generating bech32 addresses
12:58 < jtimon> I won't go this time :( have productive discussions there, and fun too!
12:58 < BlueMatt> d) how to deal with 0.15.1 downgradingg to 0.13.1 (in both hd and non-hd modes)
12:59 < BlueMatt> e) whether to use a new hd chain for segwit addresses
12:59 < sipa> e falls under b
12:59 < BlueMatt> err, ok
12:59 < gmaxwell> BlueMatt: please just don't support that. It makes no sense to back and revalidate segwit wallet support in old versions.
12:59 < gmaxwell> we will not manage to adequately test it and it will sharply constrain our implementation choices.
12:59 < sipa> any last minute short topic?
12:59 < BlueMatt> gmaxwell: then we should explicitly break it...but, anyway, lets have this discussion next week
12:59 < gmaxwell> and lead to weird corner case bugs.
13:00 < instagibbs> sipa, activate schnorr?
13:00 < sipa> #endmeeting
13:00 < lightningbot> Meeting ended Thu Aug 31 20:00:02 2017 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/2017/bitcoin-core-dev.2017-08-31-19.05.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.log.html
13:00 < instagibbs> too late, over
13:00 < jtimon> gmaxwell: besides, is downgrading such an important use case?
13:00 < BlueMatt> if we dont support downgrading, I very, very strongly support switching to bdb5 for wallet
13:00 < gmaxwell> instagibbs: schnorr is cancled.
13:00 < instagibbs> gmaxwell, ah shite.
13:00 < chainhead> aggregated signatures
13:00 < gmaxwell> Yea, AggSig.
13:00 < luke-jr> BlueMatt: what does bdb5 have over 4?
13:00 < meshcollider> eventually we want to remove bdb entirely right
13:00 < sipa> nothing we care about, except likely being slightly longer supported in OSes
13:01 < achow101> luke-jr it's actually in package managers by default
13:01 < BlueMatt> luke-jr: not having every goddamned distro build with the backward-compat-break option?
13:01 < esotericnonsense> is there a specific goal in mind with regard to downgrading? a 'support period' as such? it seems to me that defining that would be useful. say, 1 major version back, otherwise all bets are off.
13:01 < BlueMatt> luke-jr: its purely a make-distros-keep-our-wallets-sane thing
13:01 < sipa> esotericnonsense: https://bitcoincore.org/en/lifecycle/
13:01 < luke-jr> sipa: that's never applied to wallets though
13:01 < sipa> 0.12 is EOL
13:02 < luke-jr> wallets were supposed to remain compat to 0.3 even :/
13:02 < sipa> we still stupport wallet files from 0.3.0 (and even lower, i think)
13:02 < BlueMatt> luke-jr: well the second segwit activated that broke - we can now put transactions in the wallet (today) that have witnesses and those versions will fail to deserialize, I presume
13:02 < BlueMatt> er, yes, but loading them should still be fine
13:02 < luke-jr> BlueMatt: sounds like a bug :(
13:02 < sipa> downgrading that far back is probably broken in multiple other ways too
13:03 < luke-jr> BlueMatt: why don't we store them stripped?
13:03 < sipa> luke-jr: iirc, no
13:03 < luke-jr> sipa: ?
13:03 < sipa> if i recall correctly, we do not store wallet transactions stripped
13:03 < luke-jr> "why?" is not a boolean question :p
13:04  * sipa lunch
13:04 < esotericnonsense> i would be curious to know how many users actually express a desire to downgrade significantly (i.e. beyond some sort of emergency 'we found out .15.1 is broken, go back to .15' scenario). but I feel that I'm interrupting and so will shuffle off.
13:04 < jtimon> so our goal is to make 0.15.1 wallets dongradeable to 0.12 ? that's I think too ambitious...
13:04 < BlueMatt> esotericnonsense: I think its really just an "emergency-need-to-downgrade" support thing
13:05 < BlueMatt> which, realistically, just means you need to be able to downgrade to the latest stable of the previous version
13:05 < morcos> we have to stop using confusing technology
13:05 < morcos> we don't support any downgrading now do we 
13:05 < morcos> we just support not-upgrading
13:05 < BlueMatt> jtimon: I dont think thats possible, 0.13.1 may be possible, but, indeed, is also ambitious
13:05 < morcos> or at least we used to
13:05 < BlueMatt> morcos: i think you can create an old-version wallet
13:05 < luke-jr> morcos: we've always supported downgrading 0.X wallets back to 0.X
13:05 < morcos> why are you calling downgrading it
13:05 < BlueMatt> morcos: we theoretically try to avoid breaking downgrading if you did not explicitly upgrade your wallet
13:05 < BlueMatt> (with -walletupgrade)
13:06 -!- Roger2x [55ceb93a@gateway/web/freenode/ip.85.206.185.58] has quit [Quit: Page closed]     
13:06 < morcos> if you take 0.10 wallet and run it in 0.14, it doesn't get upgraded automatically does it, its still a 0.10 wallet
13:06 < luke-jr> morcos: that's the goal, yes
13:06 < BlueMatt> correct
13:06 < morcos> so you don't have to downgrade it to use it in 0.10
13:06 < luke-jr> morcos: apparently we broke that in 0.13.1
13:06 < morcos> you never upgraded it
13:06 < BlueMatt> grrr, terminology
13:06 < morcos> yes i understand
13:06 < morcos> but stop saying downgrade
13:06 < BlueMatt> you downgraded your node
13:06 < morcos> that implies you take a bech32 segwit hd-split schnorr sig aggregation wallet with tons of txs and convert it back to some old format
13:06 < luke-jr> it sounds like a simple fix would be to just store txs stripped in the wallet
13:07 < sipa> luke-jr: a reason to not stre wallet txn as stripped: if you rebroadcast an unconfirmed tx, it needs to include the witness
13:07 < morcos> not that you were using an old format wallet in a new piece of software but not using any of those features
13:07 < jtimon> BlueMatt: right, to 14.2 sounds reasonable " just means you need to be able to downgrade to the latest stable of the previous version"
13:07 < luke-jr> sipa: does this break right now, if we received the tx with 0.12?
13:07  * BlueMatt -> food
13:07 < GAit> jnewbery: want me to just squash or rebase too?
13:07 < BlueMatt> to-be-continued next week :)
13:07 < luke-jr> BlueMatt: kk
13:08 < luke-jr> I need to get back to something too, so next week sgtm
13:09 < meshcollider> next week is sf right? will you guys have a meeting summary online or something for those that aren't going
13:09 < kanzure> i will type things
13:09 < meshcollider> awesome thanks :)
13:11 < achow101> What about doing a voice recording?
13:12 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
13:12 < kanzure> nah     
13:12 < kanzure> https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html
13:14 < jnewbery> GAit: no need to rebase if there are no merge conflicts
13:15 < GAit> jnewbery: didn't rebase - however last time while there was no merge conflict the semantic changed and broke the tests :)
13:15 < GAit> thanks
13:17 < kanzure> cfields: please clarify if that was a joke or not
13:17 < cfields> kanzure: heh, yes
13:18 < kanzure> oh sipa's list?
13:18 < kanzure> "yes" to an "or" tsk tsk
13:19 < bitcoin-git> [bitcoin] MeshCollider opened pull request #11208: Fixing offscreen GUI issue (master...201709_offscreen_fix) https://github.com/bitcoin/bitcoin/pull/11208
13:20 < kanzure> added.
13:23 -!- tuberculo [~tuberculo@2804:14d:5ce6:a98e:4bb4:8d10:b72:efb8] has joined #bitcoin-core-dev     
13:24 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has joined #bitcoin-core-dev     
13:30 -!- klkk [615588c6@gateway/web/freenode/ip.97.85.136.198] has quit [Ping timeout: 260 seconds]     
13:31 -!- dermoth_ [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
13:31 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Disconnected by services]     
13:31 -!- dermoth_ is now known as dermoth     
13:32 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
13:33 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds]     
13:36 -!- tuberculo [~tuberculo@2804:14d:5ce6:a98e:4bb4:8d10:b72:efb8] has quit [Ping timeout: 252 seconds]     
13:36 < gmaxwell> sipa: can you propose a BIP modification to say that anything that accepts p2sh embedded segwit should also accept the non-embedded form  or something
13:36 < gmaxwell> I can buy your argument that it's reasonable to support both forms.
13:36 < gmaxwell> But it's weird if if its totally adhoc.
13:39 < luke-jr> seems a bit late for that
13:40 < luke-jr> do other wallets support it?
13:40 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
13:40 < gmaxwell> ::sigh::
13:40 < gmaxwell> it's bad if its inconsistent.
13:40 < gmaxwell> "I converted this address, and it worked, I converted that address and the funds vanished into space"
13:41 < luke-jr> people shouldn't try to "convert" addresses anyway. :/
13:42 < gmaxwell> indeed, which is why I think it's bad to add both key types.
13:42 < kanzure> yep, wallets should only be expected to receive whatever was given
13:43 < kanzure> (by getnewaddress etc)
13:43 < gmaxwell> but we do end up with another migration problem with the later switch to bech32, which would be sad.
13:54 < sipa> luke-jr, gmaxwell: unfortunately, that means we'll be forced to have a separate chain for bech32 addresses
13:54 < sipa> perhaps that's the best solution
13:56 < instagibbs> sipa, in the case of migrating again? 
13:56 < luke-jr> probably more future-proof too
13:59 < gmaxwell> sipa: that is what I expected us to do
13:59 < gmaxwell> we'll also have this same thing for future sig versions like a v1 with aggsig.
14:00 < gmaxwell> as an aside the masterkey lines in our dumps should include flags for this stuff
14:00 < gmaxwell> but I coudl also buy the parallel for v0 and p2sh embedded... it would have some migration advantages.
14:01 < gmaxwell> (I'm worried that we shouldn't do anything to delay supporting this though.)
14:10 < morcos> I'm not sure I understand why you have to switch to a new chain.  Why can't you just "upgrade" your old chain to support a new address type.. or is the idea that once you support bech32 you'll no longer support the p2sh version
14:10 < morcos> or that a new bech32 chain won't i mean
14:11 < sipa> morcos: if we want to be strict, and only accept payments to bech32 when a bech32 addr was given out, and p2sh/p2wpkh when that was given out, they need to be separate chains, or you need to drop support for one of them entirely
14:11 < gmaxwell> so if you are adding keys for both types, it means that people can 'convert' your addresses and have it work, which is a funds loss risk when they do it someplace where it doesn't work.
14:11 < sipa> otherwise you can't know when rescanning which is one
14:13 < gmaxwell> We could take a position that we'll always do dual p2sh embedded and native (at least for the forseeable future) in parallel... but that will still be a risk for every wallet that isn't us, and for bitcoin core users with explicitly imported keys, when something thinks it can convert.
14:13 < gmaxwell> and we cannot do dual-addresses for pre-segwit+segwit because of things like uncompressed keys.
14:15 < gmaxwell> Because as sipa points out p2sh embedding would work for _all_ segwit, we could realistically do dual support there.
14:16 < morcos> I don't know.  I guess I'm not 100% sold on the philosophy.   It kind of seems to me that if someone does pay you to an address you didn't give them.. You're going to want to find some way to recover those funds no?
14:17 < morcos> I mean I get why we don't want to encourage a culture of loosey-goosey hide the key in your backyard or however you put it gmaxwell
14:17 < gmaxwell> morcos: thats kind of the issue... then your keys are embedded in an HSM and it's virtually impossible for you to do that... or to do so you need to do dangerous crap with private keys, 
14:18 < gmaxwell> So basically if this is supported as a reasonable and customary practice, then it creates an effective obligation to do it.
14:18 < morcos> But to me there is a tenous link btwn the fact that the wallet would be smart enough to accept it and people actually being encouraged to do it
14:19 < instagibbs> also doesn't this basically require someone to understand bech32, but decide to wrap in p2sh?
14:19 < morcos> You could even add some sort of flag or warning on txs that were received using unexpected address types
14:19 < luke-jr> if someone pays to an address I didn't give them, they burned the bitcoins. they didn't pay me.
14:19 < instagibbs> most cases should be the sender simply not understanding the bech32?
14:19 < gmaxwell> morcos: things that work are what people do, this is the lesson from history  -- in bitcoin but also in every internet protocol.  If we make it work we need to be ready to support it.
14:20 < gmaxwell> People deciding what to do don't read specs, they try them out and they do whatever works.
14:21 < gmaxwell> I think we could reasonably support p2sh-embedded and segwit duality. Sipa points out that it'll work universally.
14:21 < morcos> well perhaps we could solve the problem i'm more concerned with in a different way by making different paths in the HD wallet
14:21 < morcos> so the same key never was used for both
14:21 < morcos> but you don't have to change master keys
14:21 < gmaxwell> morcos: you do that by using a different path.
14:21 < morcos> the issue i don't like is invalidating peoples backups
14:21 < gmaxwell> Which is what other wallets are also doing for segwit suppot, fwiw.
14:21 < morcos> so when we're talking about switching to a new chain for bech32, we'r ejust talking about a new path?
14:22 < sipa> morcos: yes
14:22 < morcos> that seems much more reasonable to me
14:22 < gmaxwell> I assume but the backup is somewhat invalidated because the backup doesn't have the metadata to tell it what paths are used. This is also true for the hdsplit.
14:22 < sipa> and perhaps if we plan to do that, we should do the same for p2sh-p2wpkh
14:22 < morcos> ignore my objections then...   seems like we should do a quick online survey of other wallet providers and assess whether most have expected that p2sh wrapped == bech32, that is if you accept one you accept the other
14:22 < sipa> there is a distinction in that bech32 or not is probably something we do want to do on a per-key basis
14:22 < morcos> and unless thats nearly universal, we shouldn't introduce it
14:23 < luke-jr> gmaxwell: backups can be expected invalidated when -walletupgrade is used
14:23 < gmaxwell> Esp for BIP173; the transition can't really be done abruptly unless its seriously delayed.
14:23 < instagibbs> morcos, most are doing bip49 I think, which only is about nested
14:23 < morcos> luke-jr: why?  shouldn't you just be able to -upgrade your backup
14:23 < gmaxwell> while if we do dual embedded and native then probably I can use bech32 on day one, e.g. my exchange supports it, so I have it pay me via a 173 address.
14:23 < instagibbs> not sure what they're expecting to do with bech32
14:24 < sipa> morcos: that doesn't work for upgrading to hd, to hd split, nor for adding new chains
14:24 < gmaxwell> morcos: just the backup doesn't know where and when the pathing change happened.
14:24 < luke-jr> morcos: hmm, it might work in this case, but IMO we shouldn't *expect* it to
14:24 < gmaxwell> i suppose you could replay the same actions and have it work, but it's tricky and easy to screw up.
14:25 < gmaxwell> e.g. backup your wallet on day 0 with no segwith, use 100,000 keys... upgrade it later... use another 10000 keys... erase wallet... now how do you reproduce this...
14:25 < gmaxwell> you need to know to expand the keypool 100,000 keys, then switch...
14:25 < luke-jr> gmaxwell: if segwit uses a new path/chain, this would just work I guess
14:25 < morcos> well, i was assuming the path branch happened at the beginning, but maybe that was a bad assumption
14:26 < morcos> in which case you'd just look ahead whatever the number of keys is on all paths
14:26 < gmaxwell> yes, it should happen at the beggin... how do we know to go to 100,000...
14:26 < gmaxwell> okay, thats a more keypools solution.
14:26 < luke-jr> gmaxwell: start monitoring both chains at their beginning, and extend each as needed
14:26 < morcos> the same way we know to go to 100k if we never did anything and you backedup your wallet with nothing in it
14:26 < gmaxwell> perhaps... this has some other tradeoffs. 
14:27 < morcos> i don't understand how you don't have to do that anyway
14:27 < gmaxwell> e.g. say we have 4 segwit versions, and so now we have 10 keypools. 
14:27 < gmaxwell> but only one of them has ever been used.
14:28 < morcos> so what happens when you upgrade your wallet?  don't you have to still keep keypools for your old chains anyway?
14:28 < morcos> or are you suggesting the upgrade is the user saying, i have no pending payments forever in the future for any address i've ever given out
14:29 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
14:29 < gmaxwell> yep. that was my thinking.. just import all the keys that are already used.
14:29 < luke-jr> gmaxwell: if we're worried about it, we should just stop using keypools?
14:29 < adiabat> not to complicate things further, but my wallet software supports bech32 / p2wpkh but ignores nested completely
14:29 < gmaxwell> it's not even clear to me that we should support upgrading.
14:30 < gmaxwell> for something that changes your key paths perhaps we should only support that for new wallets.   If you want old keys in it, you can import.
14:30 < sipa> gmaxwell: there is no 'import'
14:30 < gmaxwell> importmulti
14:30 < sipa> gmaxwell: the effect of an import is exactly the same as just adding a key
14:30 < sipa> gmaxwell: i mean that every key we generate is implicitly 'imported'
14:30 < gmaxwell> import doesn't have anything to do with maintaining a keypool.
14:30 < gmaxwell> yes, it's that PLUS keypool management.
14:31 < luke-jr> time to reboot, bbl
14:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
14:31 < sipa> gmaxwell: i just mean that is what we already doing
14:31 < sipa> gmaxwell: saying "switching to a new keypool and treating all the existing keys as imported" is exactly the same as "switching to a new keypool"
14:32 < gmaxwell> yes, but it's distinct from following all keypools which is what I was discussing with morcos.
14:32 < morcos> gmaxwell: yeah i think if i understand what sipa is saying, once you've made the decision to start giving out addresses on a new chain, you no longer need to maintain a keypool for your old chain
14:32 < sipa> ok, s/switching to/adding/g in my above statement
14:33 < sipa> still same thing - the 'importing' thing is besides the point
14:33 < morcos> youv've already got the current keypool as keys in your wallet, and its exactly as if you imported
14:33 < gmaxwell> morcos: right thats an option, but it's not 'backup durable'
14:33 < morcos> why not?
14:33 < gmaxwell> because you restore a backup then don't do the upgrade or do instantly before scanning all the keys
14:33 -!- illpadrino [bab65263@gateway/web/freenode/ip.186.182.82.99] has quit [Ping timeout: 260 seconds]     
14:34 < morcos> hmm.. i see, its just more complicated to get it right i suppose
14:34 < gmaxwell> and when we do the upgrade to we trigger a full (pruning incompatible multihour long) rescan
14:34 < morcos> but the advantage of supporting 2 keypools is we can start issuing bech32 earlier
14:34 < morcos> which seems a big gain
14:34 < gmaxwell> Or we could just do dual-embedded and bech32.
14:34 < morcos> hmm     
14:35 < gmaxwell> in which case it's just one keypool and we could use bech32 all the time, but there is a risk of people converting.
14:35 < gmaxwell> For rapid bech32 deployment that is best by far.
14:35 < morcos> but also means we can't ever easily stop supporting the old style
14:35 < gmaxwell> because it lets you immediately use bech32 when you have a counterparty that supports it.
14:35 < gmaxwell> morcos: right, we could for newer wallet 3 years from now, except for the risk of 'conversion'
14:36 < sipa> just in case that isn't clear: if you currently use addwitnessaddress, you'll accept both p2sh and native-witness outputs to that address
14:37 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 252 seconds]     
14:37 < morcos> and if you don't you'll accept neither?
14:37 < sipa> yes     
14:38 < morcos> well i do think it makes sense to think about this comprehensively in the context of legacy -> hd -> hd-split -> p2shsegwit -> bech32 -> future witness versions
14:38 < morcos> there are different issues for each of those
14:39 < morcos> but i think we want the design to be something where people don't get confused understanding how it works
14:41 < gmaxwell> we really cannot do legacy and segwit doppleganging due to the uncompressed key issue.
14:41 < morcos> Imagine that each of those is considered a different path or whatever, and we introduced some concept of whether a path is active or not (meaning we are still potentially giving out addresses on it)  and once it's not active we don't need to maintain keypools anymore, we just have the historical keys
14:41 < sipa> gmaxwell: easy enough with a bit in the metadata
14:41 < gmaxwell> I think we can realistically do native + embedded doppleganging and support it forever.
14:41 < sipa> or just the addwitness approach
14:42 < gmaxwell> bit in the metadata is a backup disaster.
14:42 < morcos> When you upgrade you need to specify which ones you are still active on..  And there is a way to deactivate old types
14:42 < sipa> gmaxwell: it would also be added during hd topup
14:42 < gmaxwell> sipa: I don't understand how that works.
14:42 < gmaxwell> I mean where do the bits come from
14:43 < sipa> gmaxwell: once your wallet is segwit-enabled, you add it for every newly generated key (including auto topup)
14:43 < sipa> it means you can't recover with an old version anymore, but that's inevitable
14:44 < gmaxwell> but then you recover an old backup with a new wallet... will it then set the bit for everything
14:44 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 246 seconds]     
14:44 < sipa> ah, i see
14:44 < gmaxwell> I'm sorry, I think this is all confused; or I am all confused.  Esp since we don't even really know if we are recovering or not at any point in time.
14:47 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
14:48 < morcos> gmaxwell: I think when you said "that's a more keypools solution", I took that as a negative, but i'm not sure why it has to be a negative.   Have a keypool for every path / type of address.  Who cares?
14:50 < morcos> I don't think it causes any wallet bloat if you're comparing it to importing your keys to a new wallet as you upgrade.  It it causes in-memory bloat, that seems easy enough to optimize away, by leaving most of unlikely to be used keypools on disk.
14:51 < gmaxwell> two keypools, technically.  ends up being a megabyte of keypool for each or whatever with our current inefficient storage... 
14:53 < gmaxwell> (change and not change, is the two pools)
14:53 -!- Giszmo [~leo@ip-227-233.219.201.nextelmovil.cl] has quit [Ping timeout: 252 seconds]     
14:54 -!- btcdrak [uid239175@gateway/web/irccloud.com/x-enajpllkbwdrsyii] has quit [Quit: Connection closed for inactivity]     
14:54 < morcos> Yes, but don't you get that anyway, if you import to each version in turn as you're importing all the prior keypool keys
14:54 < gmaxwell> We could do that.  Also slower accepting blocks, because you now have a lot more keys to scan... but thats something that generally may need to be optimized.
14:55 < gmaxwell> morcos: if you do that, but most users eventually will have just started eventually with vXX and won't have any old ones
14:55 < morcos> yes, and so then you don't create the old ones
14:55 < gmaxwell> so then there is key metadata which says the oldest kind to build, and we build all later ones.
15:00 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has quit [Quit: Lost terminal]     
15:17 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-wssvnuqmqebjaqhg] has quit [Quit: Connection closed for inactivity]     
15:20 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has joined #bitcoin-core-dev     
15:23 -!- tloriato [bb203c01@gateway/web/freenode/ip.187.32.60.1] has joined #bitcoin-core-dev     
15:23 -!- Giszmo [~leo@ip-227-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev     
15:26 < tloriato> Hello. I was testing the development of some ideas using the BitcoinCore wallet and the CLI's commands, and I came across the move command. Unfortunately the Docs states that "move will be removed in a later version of Bitcoin Core. " Does another command fulfils its duty? I've read the documentation on the official webpage and came out with empty hands. I don't want to develop an architecture around a command that will be e
15:28 < sipa> tloriato: the whole accounts subsystem is deprecated
15:28 < sipa> there won't be a replacement for move, as there would be nothing to observe its effect
15:29 < sipa> addresses will be able to have labels, and you'll be able to query for payments to specific labels, but labels don't have their own balance
15:30 < tloriato> i see it
15:30 < tloriato> well, thanks for the answer and clarification
15:31 < tloriato> i'd assume that the parameter to GetNewAddress would be the label instead of account when that happens?
15:31 < sipa> indeed
15:32 < tloriato> that's alright then! thank you
15:32 -!- tloriato [bb203c01@gateway/web/freenode/ip.187.32.60.1] has quit [Quit: Page closed]     
15:38 -!- Giszmo [~leo@ip-227-233.219.201.nextelmovil.cl] has quit [Ping timeout: 240 seconds]     
15:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
16:05 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has joined #bitcoin-core-dev     
16:07 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Ping timeout: 252 seconds]     
16:15 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
16:16 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Max SendQ exceeded]     
16:16 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
16:17 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Remote host closed the connection]     
16:17 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
16:25 -!- Deadhand [~deadhand@2607:fea8:e380:10f::3] has quit [Ping timeout: 258 seconds]     
16:26 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds]     
16:30 -!- Deadhand [~deadhand@2607:fea8:e380:10f::7] has joined #bitcoin-core-dev     
16:45 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has quit [Ping timeout: 240 seconds]     
16:51 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
16:52 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
16:57 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
16:59 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
17:02 -!- Gunnie [~kamk@109.202.82.2] has joined #bitcoin-core-dev     
17:03 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has joined #bitcoin-core-dev     
17:07 -!- Gunnie [~kamk@109.202.82.2] has quit [Quit: My computer has gone to sleep. ZZZzzz…]     
17:08 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Read error: Connection timed out]     
17:09 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
17:09 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Max SendQ exceeded]     
17:10 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
17:12 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
17:13 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Max SendQ exceeded]     
17:13 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
17:13 -!- dabura667 [~dabura667@KD111103034253.ppp-bb.dion.ne.jp] has joined #bitcoin-core-dev     
17:17 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Max SendQ exceeded]     
17:20 < sipa> achow101: i overlooked it before; i've locked the comments on the first commit
17:21 < achow101> yay     
17:21 < achow101> less spam
17:21 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
17:22 < gmaxwell> oh thats why achow was asking. :P
17:26 < jtimon> review beg https://github.com/bitcoin/bitcoin/pull/8994 now there's no exception for testing segwit.py and I left the loading of the parameters from aseparated file for later
17:33 < achow101> I think I am close to figuring out what happened with #11171, and it is not related to the off screen thing
17:37 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]     
17:40 -!- Aaronvan_ is now known as AaronvanW     
17:40 -!- unholymachine [~quassel@2601:8c:c003:9f16:b5c2:f701:9fb:1fb2] has quit [Remote host closed the connection]     
17:41 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
17:46 -!- dabura667 [~dabura667@KD111103034253.ppp-bb.dion.ne.jp] has quit [Remote host closed the connection]     
17:46 < achow101> well while trying to debug that thing, I found a different bug :/
17:47 -!- unholymachine [~quassel@2601:8c:c003:9f16:240a:f81f:1dc:a9b2] has joined #bitcoin-core-dev     
18:05 < sipa> achow101: you're on a roll
18:06 < achow101> sipa: can you help? This is as far as I got: https://github.com/bitcoin/bitcoin/issues/11171#issuecomment-326457725
18:06 < achow101> I'm not sure if I've gone down the wrong rabbit hole or if I am just not seeing something
18:11 < sipa> achow101: calling a virtual method on a null pointer will cause a segfault, but this is not true for normal methods (though it's undefined behaviour, in practice the method just gets called with a this == nullptr)
18:12 < sipa> of course, if the called method tries to access any class fields, a segfault will occur
18:14 -!- jonasschnelli [~jonasschn@bitcoinsrv.jonasschnelli.ch] has quit [Changing host]     
18:14 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev     
18:14 < achow101> is there a virtual method here?
18:14 < sipa> i don't know - i know almost nothing about the GUI code
18:20 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
18:22 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
18:28 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
18:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []     
18:56 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
18:57 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
19:38 -!- dabura667 [~dabura667@KD182251112124.au-net.ne.jp] has joined #bitcoin-core-dev     
19:40 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
19:40 -!- dabura667 [~dabura667@KD182251112124.au-net.ne.jp] has quit [Client Quit]     
19:51 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
20:11 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
20:12 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Ping timeout: 255 seconds]     
20:14 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
20:38 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has quit [Ping timeout: 258 seconds]     
20:42 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has joined #bitcoin-core-dev     
21:07 < kallewoof> Ugh... I didn't realize the mempool propagated quite as slowly as it does. I have 3 public nodes (one has been up for months, one for a week or two, and one was started up yesterday). The mempools on each is quite different. 4827 entries for the longest running one, 2848 for the second and 802 for the third.
21:08 < sipa> that's not necessarily due to propagation
21:08 < kallewoof> What else could be causing it?
21:09 < sipa> if the differences are in transactions that (directly or indirectly) depend on unconfirmed transactions that were in the older running nodes but not in the newer ones, that's expected
21:09 < sipa> there is no mempool reconciliation
21:09 < kallewoof> So most of the extra cruft would be for low fee txs that are not making it into blocks for a long time?
21:10 < kallewoof> Oh wait, I see what you're saying
21:11 < kallewoof> Node gets a tx with an input that is unconfirmed and unknown and the node discards it. Or wait, it puts it in orphanTx vector, right? Maybe I can use that to get a better picture..
21:14 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
21:17 < kallewoof> sipa: Weird. It looks like a node will ask for parent txs if it runs into a tx with unknown inputs, presuming it hasn't rejected any of its parents before. Doesn't that address what you said?
21:18 < kallewoof> for loop over vin that does `if (!AlreadyHave(_inv)) pfrom->AskFor(_inv);` (net_processing.cpp somewhere around line 1900 or so)
21:18 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
21:21 < sipa> kallewoof: perhaps they already have a conflict for the parent?
21:22 < kallewoof> I could see that be the case for a couple of transactions (having a double spent parent I guess? where one node sees one and the other sees the other), but the old node has 4x the # of txs compared to the 1 day old one. seems high.
21:24 < kallewoof> Connection counts are 63, 17, 14 which might mean that some txs simply don't get very far (need lots of peers to see them), but maybe there's another reason.
21:24 < kallewoof> s/which might mean/which might indicate/
21:25 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
21:44 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
21:51 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Ping timeout: 252 seconds]     
21:59 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
22:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving]     
22:08 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
22:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
22:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
22:23 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
22:23 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
22:38 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-odvbssjbtqzjvzap] has joined #bitcoin-core-dev     
22:47 -!- Deadhand [~deadhand@2607:fea8:e380:10f::7] has quit [Ping timeout: 252 seconds]     
22:50 -!- Deadhand [~deadhand@2607:fea8:e380:10f::7] has joined #bitcoin-core-dev     
23:00 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
23:04 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has quit [Quit: leaving]     
23:04 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has joined #bitcoin-core-dev     
23:07 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds]     
23:08 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has quit [Client Quit]     
23:13 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has joined #bitcoin-core-dev     
23:14 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has quit [Client Quit]     
23:14 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has joined #bitcoin-core-dev     
23:16 -!- Giszmo [~leo@pc-93-17-46-190.cm.vtr.net] has quit [Ping timeout: 240 seconds]     
23:18 -!- sam_c [~sam_c@gateway/tor-sasl/stanley] has quit [Remote host closed the connection]     
23:19 -!- sam_c [~sam_c@gateway/tor-sasl/stanley] has joined #bitcoin-core-dev     
23:22 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has quit [Ping timeout: 240 seconds]     
23:26 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has quit [Quit: leaving]     
23:27 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has joined #bitcoin-core-dev     
23:31 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has joined #bitcoin-core-dev     
23:33 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 268 seconds]     
23:34 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has quit [Client Quit]     
23:34 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has joined #bitcoin-core-dev     
23:37 < meshcollider> Since #11171 is being used to discuss the GUI bug could someone please reopen it :) 
23:38 -!- Gunnie [~kamk@109.202.82.2] has joined #bitcoin-core-dev     
23:41 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has quit [Ping timeout: 258 seconds]     
23:45 < meshcollider> Thanks sipa 
23:45 < sipa> yw!     
23:47 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has joined #bitcoin-core-dev     
23:50 < gmaxwell> kallewoof: it will fetch parents but its pretty limited in doing that. It won't fetch things that it just wasn't online to see.
23:50 < gmaxwell> unless a child shows up.
23:51 < gmaxwell> in my expirence it normally takes about 24 hours of operation before compact blocks reaches its full hitrate.
23:52 < gmaxwell> and right now with a flood of very low fee txn you won't pick those up.
23:53 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
23:56 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Ping timeout: 255 seconds]     
23:57 < jimpo> kallewoof: Do you mind dumping the mempools and sharing if you have RPC enabled? I'd be interested in taking a look.