--- Day changed Thu Jan 11 2018
00:01 < provoostenator> Rebase party time! Congrats sipa on that merge.
00:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:05 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 252 seconds]     
00:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
00:13 < jb55> will said party be... interactive?
00:15  * jb55 walks away slowly
00:18 -!- CubicEar_ [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Remote host closed the connection]     
00:19 < luke-jr> uh, not seeing the logic for wallet versioning there.. How do I configure my wallet to NOT upgrade?
00:19 -!- CubicEarths [~cubiceart@46.243.136.9] has joined #bitcoin-core-dev     
00:20  * provoostenator wonders if there is such a thing as VM rage after umpteen useless Windows 10 notifications 
00:20 < sipa> luke-jr: you mean due to bech32 addresses in your label map?
00:23 < luke-jr> well, I would have expected ImplicitlyLearnRelatedKeyScripts to be conditional on the wallet being an upgraded version
00:23 < luke-jr> I don't even see a flag for the wallet version bump
00:23 < sipa> luke-jr: that doesn't affect the wallet file
00:24 < sipa> you can downgrade down to any segwit capable version
00:24 < luke-jr> But how do I upgrade without accepting Segwit payments?
00:25 < sipa> ah, you can't
00:26 < jonasschnelli> luke-jr: why would you want that? Can you elaborate the use case?
00:26 < luke-jr> when and why was that changed?
00:26 < luke-jr> jonasschnelli: to prevent block size increases
00:26 < sipa> sigh
00:27 < jonasschnelli> luke-jr: why would "not accepting" sw payment change that?
00:27 < jonasschnelli> (not talking about "not handing our SW addresses")
00:27 < jonasschnelli> *out
00:28 < luke-jr> jonasschnelli: someone can take a normal address from this, and modify it to a Segwit one, and the user won't even know it?
00:28 < sipa> luke-jr: that's a problem, but it's inherent to the wallet design
00:28 -!- CubicEarths [~cubiceart@46.243.136.9] has quit [Read error: Connection reset by peer]     
00:28 < jonasschnelli> I see
00:28 < sipa> they can also convert p2pkh  into p2pk etc
00:29 -!- kabaum [~kalle@h-13-35.A163.priv.bahnhof.se] has joined #bitcoin-core-dev     
00:29 < luke-jr> sipa: not without this change
00:29 < sipa> ?     
00:30 < sipa> we have always accepted payments to p2pk
00:30 < luke-jr> without this change, it isn't possible to trick the user into accepting a segwit output
00:30 -!- zautomata [~zautomata@unaffiliated/zautomata] has quit [Read error: Connection reset by peer]     
00:30 -!- Amuza [~Amuza@85.159.207.5] has quit [Ping timeout: 255 seconds]     
00:30 < sipa> yes, i don't see why that is any more of a problem than accepting p2pk instead of p2pkh (which grows the utxo set morez for example)
00:31 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
00:31 < luke-jr> sipa: only segwit outputs enable block size increases
00:31 -!- zautomata [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
00:31 < sipa> i think utxo growth is a far worse problem
00:31 < luke-jr> also, without a wallet version bump, old wallets won't receive properly for segwit addresses generated by newer software, I think?
00:31 < jonasschnelli> luke-jr: if you think this is an important feature (I don't), you may want to write a PR?
00:31 < sipa> luke-jr: they will
00:31 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Remote host closed the connection]     
00:32 < sipa> (down to 0.13.1)
00:32 < luke-jr> jonasschnelli: okay, although this was what I expected already from the discussions months ago planning it
00:32 -!- CubicEarths [~cubiceart@46.243.136.16] has joined #bitcoin-core-dev     
00:32 < luke-jr> sipa: I thought the wallet didn't get the data added permanently?
00:32 < sipa> it does
00:33 < sipa> read the PR description
00:33 < luke-jr> did that change at some point?
00:33 < sipa> yes, and there is even a design doc to explain it
00:33 < jonasschnelli> luke-jr: you didn't mentioned that point in 11403
00:34 < meshcollider> this one I think sipa is referring to https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2
00:35 -!- kabaum_ [~kalle@h-13-35.A163.priv.bahnhof.se] has joined #bitcoin-core-dev     
00:37 -!- steadguy [~ruffbot@c-73-95-55-80.hsd1.co.comcast.net] has joined #bitcoin-core-dev     
00:37 -!- Amuza [~Amuza@85.159.207.5] has joined #bitcoin-core-dev     
00:39 -!- kabaum_ [~kalle@h-13-35.A163.priv.bahnhof.se] has left #bitcoin-core-dev []     
00:39 -!- kabaum [~kalle@h-13-35.A163.priv.bahnhof.se] has quit [Quit: Leaving]     
00:40 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined #bitcoin-core-dev     
00:41 -!- steadguy [~ruffbot@c-73-95-55-80.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]     
00:42 -!- tectonic [~tectonic@c-24-6-35-228.hsd1.ca.comcast.net] has quit []     
00:43 -!- Amuza [~Amuza@85.159.207.5] has quit [Ping timeout: 252 seconds]     
00:44 < luke-jr> wouldn't the implicit in-memory redeemscript adding for old keys be sufficient if only applied to the keypool/new keys?
00:46 < sipa> read the design doc, it goes through all the scenarios it is intended to work in, and how they necessitate the implemented behaviour
00:46 -!- CubicEar_ [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
00:47 -!- zautomata1 [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
00:48 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev     
00:49 -!- CubicEarths [~cubiceart@46.243.136.16] has quit [Ping timeout: 240 seconds]     
00:49 -!- zautomata [~zautomata@unaffiliated/zautomata] has quit [Ping timeout: 240 seconds]     
00:50 -!- Krellan [~Krellan@2601:640:4000:9258:51fb:322e:7ebc:3efc] has joined #bitcoin-core-dev     
00:51 < luke-jr> sipa: I read it, but it's not clear to me why 1a requires it effect ALL keys, rather than just keypool (ie, unused at the time of the backup) and future
00:52 < luke-jr> labelled keys already have a non-segwit address assigned, and should never be seen in segwit form
00:53 < sipa> you can't know that you aren't using a restored backup which had a lost future in which the same key was used in a different address type
00:55 < luke-jr> hm, so 1) user backs up, 2) user makes a new address, 3) user restores backup, 4) user upgrades, 5) user makes a new segwit address overlapping the one in 2, 6) user downgrades, 7) user restores backup again
00:55 < luke-jr> ?     
00:56 < sipa> the only way we can actually remove the ability to accept payment to a different address type than the one we know about is afaik by having separate keychains for each address type
00:56 < sipa> luke-jr: i don't think 6 and 7 are needed in that scenario
00:57 < sipa> and swap the segwit and legacy
00:57 < meshcollider> sipa: they are needed because the first address was legacy and the second was segwit i believe
00:57 < meshcollider> yeah
00:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:58 < luke-jr> sipa: I don't understand.. step 2 can't make a segwit address since it's pre-upgrade
00:58 < sipa> someone first creates a backup, then creates a segwit address, then restores the backup, creates a legacy address with the same key, restarts
00:58 -!- zautomata1 [~zautomata@unaffiliated/zautomata] has quit [Ping timeout: 240 seconds]     
00:59 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
00:59 < sipa> no old versions involved even
00:59 < luke-jr> upon restoring the backup, that key would be in the keypool, so it would get the implied script
00:59 < sipa> the result is a file with no explicit segwit script, and a label for a legacy address for a certain key
01:00 < luke-jr> oh, add a restart and the implicit script disappears!
01:00 < meshcollider> yeah the legacy address has to be created on the old version so it doesnt hit the implicit addition of segwit scripts
01:00 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
01:00 < meshcollider> oh     
01:00 < sipa> no it doesn't
01:00 < meshcollider> yeah I got it now, right
01:00 < luke-jr> I thought I got it until "no it doesn't" :x
01:01 < luke-jr> unless that was a reply to meshcollider
01:01 < sipa> the "no it doesn't" is a response to meshcollider saying it needs an old version
01:01 < meshcollider> yeah that was a reply to me
01:01 < luke-jr> ah ok
01:01 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 276 seconds]     
01:02 < sipa> i'm not sure this scenario is actually covered in thendocument though
01:02 < meshcollider> sipa: it is, just not so explicitly written out
01:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
01:03 < sipa> may be worth spelling kt out
01:03 < sipa> *it     
01:03 < meshcollider> it just stops at restoring the backup, it doesn't mention creating a new legacy address and restarting
01:03 < meshcollider> yeah
01:05 -!- anome [~anome@unaffiliated/anome] has quit []     
01:07 -!- CubicEar_ [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]     
01:08 < provoostenator> The step 1-7 scenario luke-jr describes above is somethign I'd like to try on top of #12134  
01:08 < gribble> https://github.com/bitcoin/bitcoin/issues/12134 | [WIP] Build previous releases and run functional tests by Sjors · Pull Request #12134 · bitcoin/bitcoin · GitHub
01:11 < meshcollider> provoostenator: I've only looked briefly at that but won't adding cross version testing to travis be too slow
01:12 -!- CubicEarths [~cubiceart@73.181.185.197] has joined #bitcoin-core-dev     
01:12 < provoostenator> meshcollider: the releases are cached, so it's a one-off 30 minute thing (and only for one machine).
01:12 < meshcollider> provoostenator: oh ok, that's all good then :)
01:16 -!- CubicEarths [~cubiceart@73.181.185.197] has quit [Remote host closed the connection]     
01:17 -!- CubicEarths [~cubiceart@46.243.136.23] has joined #bitcoin-core-dev     
01:18 < luke-jr> sipa: PM
01:23 -!- tectonic_ [~tectonic@c-24-6-35-228.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
01:28 < meshcollider> Does collaborators only mean members of the organization with write access to the repo? I'd previously assumed we'd be able to comment on PRs/issues even if they were locked because we were members but that doesn't appear to be the case
01:31 -!- JackH_ [~laptop@aoe110.neoplus.adsl.tpnet.pl] has quit [Quit: Leaving]     
01:32 -!- zautomata1 [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
01:34 -!- dcousens [~dcousens@CPE-101-181-24-254.lnse4.cha.bigpond.net.au] has quit [Ping timeout: 248 seconds]     
01:34 -!- tectonic_ [~tectonic@c-24-6-35-228.hsd1.ca.comcast.net] has quit []     
01:34 -!- dcousens [~dcousens@CPE-101-181-122-189.lnse5.cha.bigpond.net.au] has joined #bitcoin-core-dev     
01:37 -!- zautomata1 [~zautomata@unaffiliated/zautomata] has quit [Ping timeout: 248 seconds]     
01:38 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev     
01:38 -!- zautomata1 [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
01:39 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev     
01:41 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
01:46 -!- logicue [~logicue@p54B5F079.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
01:48 -!- logicue [~logicue@p54B5F079.dip0.t-ipconnect.de] has quit [Client Quit]     
01:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:55 -!- Krellan [~Krellan@2601:640:4000:9258:51fb:322e:7ebc:3efc] has quit [Ping timeout: 265 seconds]     
01:56 -!- tectonic_ [~tectonic@c-24-6-35-228.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
02:00 -!- Xexe [~weechat@unaffiliated/xexe] has joined #bitcoin-core-dev     
02:02 -!- zautomata1 [~zautomata@unaffiliated/zautomata] has quit [Quit: WeeChat 1.7]     
02:04 -!- indistylo [~indistylo@119.82.105.106] has joined #bitcoin-core-dev     
02:05 -!- Krellan [~Krellan@2601:640:4000:9258:51fb:322e:7ebc:3efc] has joined #bitcoin-core-dev     
02:10 -!- Krellan [~Krellan@2601:640:4000:9258:51fb:322e:7ebc:3efc] has quit [Ping timeout: 240 seconds]     
02:12 -!- tectonic_ [~tectonic@c-24-6-35-228.hsd1.ca.comcast.net] has quit []     
02:13 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
02:13 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
02:17 -!- tectonic [~tectonic@152.42.196.35.bc.googleusercontent.com] has joined #bitcoin-core-dev     
02:23 < provoostenator> Travis is in a bad mood today?
02:24 < zelest> must be Ultron
02:26 < meshcollider> provoostenator: are you referring to 11991? I restarted it for you
02:26 < meshcollider> sipa: if you're online maybe you could add Sjors to the org so he can restart travis too
02:30 < sipa> i'm just on my phone now, will do later
02:30 < provoostenator> meshcollider: 11991 and 12119
02:31 < meshcollider> provoostenator: 12119 failed 4 checks, are you sure that its travis fault not something wrong with your PR?
02:32 < provoostenator> I'm not ruling that out, but the errors seemed to be timeouts.
02:33 < meshcollider> ok we'll try it again and see :)
02:33 < provoostenator> I'll also run the full suite locally
02:39 -!- Amuza [~Amuza@85.159.207.5] has joined #bitcoin-core-dev     
02:49 < bitcoin-git> [bitcoin] luke-jr opened pull request #12146: Wallet: Support disabling implicit Segwit operation (master...opt_wallet_segwit) https://github.com/bitcoin/bitcoin/pull/12146
02:54 < meshcollider> provoostenator: seems they're all failing again, so yeah must be something to do with the PR not travis
02:56 -!- molz [~IRCIdent@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
02:56 -!- arbitrary_guy [~arbitrary@c-67-183-30-122.hsd1.wa.comcast.net] has quit [Remote host closed the connection]     
02:58 -!- mlz [~IRCIdent@unaffiliated/molly] has joined #bitcoin-core-dev     
02:59 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
03:01 -!- rzhang__ [c1befd91@gateway/web/freenode/ip.193.190.253.145] has joined #bitcoin-core-dev     
03:01 -!- rzhang__ [c1befd91@gateway/web/freenode/ip.193.190.253.145] has quit [Client Quit]     
03:08 -!- lejitz [sid205154@gateway/web/irccloud.com/x-usmblvoqfiqivkgt] has quit [Quit: Connection closed for inactivity]     
03:13 < bitcoin-git> [bitcoin] anvilcoin opened pull request #12148: Update README.md (master...master) https://github.com/bitcoin/bitcoin/pull/12148
03:14 < sturles> vi +
03:14 < sturles> Sorry..
03:15 < meshcollider> what do these people hope to achieve with PRs like that, do they honestly ever think it will get merged?
03:15 -!- eck [~eck@fsf/member/eck] has quit [Quit: we out here]     
03:16 < sipa> meshcollider: i believe they don't understand what 'pull' means in this context
03:18 < sipa> i believe many of them are just trying to make a clone or try making a simple change in their own cooy
03:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
03:18 -!- Randolf [~randolf@96.53.47.42] has quit [Quit: https://www.randolfrichardson.com/]     
03:20 < provoostenator> meshcollider: probably, but they both pass on my machine. 11991 fails with "/wallet/db.h:21:20: fatal error: db_cxx.h: No such file or directory" on one machine. I can try on a linux VM... 
03:21 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
03:22 < bitcoin-git> [bitcoin] fanquake closed pull request #12148: Update README.md (master...master) https://github.com/bitcoin/bitcoin/pull/12148
03:25 -!- eck [~eck@fsf/member/eck] has quit [Client Quit]     
03:25 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
03:25 -!- eck [~eck@fsf/member/eck] has quit [Client Quit]     
03:27 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
03:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
03:51 < bitcoin-git> [bitcoin] kashyap2690 opened pull request #12149: Unlock Wallet Implemented. (master...master) https://github.com/bitcoin/bitcoin/pull/12149
04:00 < wumpus> congrats on merging segwit wallet support jonasschnelli 
04:01 -!- sugarpuff [sid92283@gateway/web/irccloud.com/x-soqldylegbicorcj] has quit [Read error: Connection reset by peer]     
04:02 -!- sugarpuff [sid92283@gateway/web/irccloud.com/x-ppebztgkyonjqfla] has joined #bitcoin-core-dev     
04:04 < wumpus> and sipa and everyone that reviewed ofcourse
04:07 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Quit: Gone frying asparagus or my Windows had a BSOD]     
04:09 < provoostenator> luke-jr from the title and description of 12146 it's not immediatley clear what you're tying to do, but I'll study it later. If you mention the "-walletimplicitsegwit" flag explictly in the description, it's probably a bit more clear.
04:10 < provoostenator> It would also help to clarify how it's different from -addresstype=legacy, other than foot-shooting protection.
04:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
04:12 < provoostenator> I assume we'll chat during todays meeting about what the earliest possible release date is, so people know how much time is left to get more stuff in? 
04:13 < provoostenator> (particularly stuff related to SegWit)
04:13 < provoostenator> I'd say at least two weeks given some of the current discussion.
04:16 < wumpus> yes we should give some time for fixes after this merge and before the release
04:18 -!- Amuza [~Amuza@85.159.207.5] has quit [Read error: Connection reset by peer]     
04:18 < promag> there are some things to do
04:18 < provoostenator> Is there something we changed since v0.15.1 that causes newly created wallets to be incompatible with v0.15.1? If so, what compile / launch flag do I need to use for v0.15.1?  
04:18 < promag> maybe sipa is working on those follow ups?
04:19 < provoostenator> (if not, then I'm during something wrong in my regtest setup, quite possible)
04:21 < wumpus> probably the segwit change caused newly created wallets to be incompatible with 0.15.x?
04:21 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 272 seconds]     
04:23 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Remote host closed the connection]     
04:23 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev     
04:24 -!- mariorz [sid490@gateway/web/irccloud.com/x-rnoqbjutzfswyxnr] has quit [Read error: Connection reset by peer]     
04:24 -!- mariorz [sid490@gateway/web/irccloud.com/x-mikjrxnmvepgcrpr] has joined #bitcoin-core-dev     
04:25 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
04:26 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 256 seconds]     
04:26 -!- maxim89 [4df81659@gateway/web/freenode/ip.77.248.22.89] has joined #bitcoin-core-dev     
04:26 < sipa> provoostenator: what fails? it should work fine as long as you don't create bech32 addresses
04:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]     
04:27 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev     
04:27 < sipa> provoostenator: oh, or the default key thing?
04:27 -!- AndyS2 [~noname@static.74.88.9.5.clients.your-server.de] has quit [Ping timeout: 256 seconds]     
04:27 < provoostenator> After I copy the wallet over to a 0.15 node and restart, it throws "Error loading wallet.dat: Wallet requires newer version of Bitcoin Core". I only added a legacy address.
04:27 -!- AndyS2 [~noname@static.74.88.9.5.clients.your-server.de] has joined #bitcoin-core-dev     
04:27 < provoostenator> default key thing?
04:28 < sipa> yes, i don't think you can use 0.16 wallets in 0.15
04:28 < sipa> but you can create a 0.15 wallet, use it 0.16, and then downgrade
04:29 < provoostenator> Ok, I'll use that approach in my backwards compatilibity test. It's more future proof anyway.
04:30 -!- maxim89 [4df81659@gateway/web/freenode/ip.77.248.22.89] has quit [Ping timeout: 260 seconds]     
04:31 < wumpus> yes, that's the way to go
04:31 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
04:32 < provoostenator> Anything around --with-incompatible-bdb that's worth testing?
04:37 -!- hirishaway is now known as hirish     
04:38 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
04:45 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
04:46 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
04:46 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
04:47 -!- wxss [~user@31.192.111.176] has joined #bitcoin-core-dev     
05:01 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has quit [Ping timeout: 256 seconds]     
05:01 -!- CubicEarths [~cubiceart@46.243.136.23] has quit []     
05:07 < bitcoin-git> [bitcoin] ryanofsky opened pull request #12150: Fix ListCoins test failure due to unset g_address_type, g_change_type (master...pr/listg) https://github.com/bitcoin/bitcoin/pull/12150
05:12 -!- Chenpan [~Chenpan@unaffiliated/chenpan] has quit [Ping timeout: 260 seconds]     
05:16 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d889c036cd6f...3c6286873e50
05:16 < bitcoin-git> bitcoin/master 2be2b5d Jacky C: Remove the ending slashes from RPC URI format.
05:16 < bitcoin-git> bitcoin/master 3c62868 Wladimir J. van der Laan: Merge #12112: Docs: Remove the ending slashes from RPC URI format....
05:17 < bitcoin-git> [bitcoin] laanwj closed pull request #12112: Docs: Remove the ending slashes from RPC URI format. (master...docs/multi-wallet_RPC_interface_correction) https://github.com/bitcoin/bitcoin/pull/12112
05:19 -!- Chenpan [~Chenpan@unaffiliated/chenpan] has joined #bitcoin-core-dev     
05:19 < bitcoin-git> [bitcoin] promag opened pull request #12151: Remove cs_main lock from blockToJSON and blockheaderToJSON (master...2018-01-blocktojson) https://github.com/bitcoin/bitcoin/pull/12151
05:23 -!- indistylo [~indistylo@119.82.105.106] has quit [Ping timeout: 256 seconds]     
05:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
05:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
05:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]     
05:40 -!- will_ [b3eb4fe5@gateway/web/freenode/ip.179.235.79.229] has joined #bitcoin-core-dev     
05:41 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3c6286873e50...92a810d04b90
05:41 < bitcoin-git> bitcoin/master f765bb3 Russell Yanofsky: Fix ListCoins test failure due to unset g_address_type, g_change_type...
05:41 < bitcoin-git> bitcoin/master 92a810d MarcoFalke: Merge #12150: Fix ListCoins test failure due to unset g_address_type, g_change_type...
05:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
05:41 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #12150: Fix ListCoins test failure due to unset g_address_type, g_change_type (master...pr/listg) https://github.com/bitcoin/bitcoin/pull/12150
05:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
05:47 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/92a810d04b90...1d2eaba300bc
05:47 < bitcoin-git> bitcoin/master 35c2b1f Suhas Daftuar: Fix rare failure in p2p-segwit.py...
05:48 < bitcoin-git> bitcoin/master 1d2eaba Wladimir J. van der Laan: Merge #12133: [qa] Fix rare failure in p2p-segwit.py...
05:48 < bitcoin-git> [bitcoin] laanwj closed pull request #12133: [qa] Fix rare failure in p2p-segwit.py (master...2018-01-fix-p2p-segwit) https://github.com/bitcoin/bitcoin/pull/12133
05:50 -!- Xexe [~weechat@unaffiliated/xexe] has left #bitcoin-core-dev []     
06:01 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
06:01 -!- eck [~eck@fsf/member/eck] has quit [Ping timeout: 268 seconds]     
06:02 -!- voidmain13 [~voidmain@111.196.244.48] has quit [Remote host closed the connection]     
06:07 < provoostenator> sipa: what's the expected failure mode of downgrading a wallet with a bech32 address? Is it supposed to be fully recoverable when you upgrade?
06:08 < sipa> provoostenator: the failure mode is that RPCs may report weird addresses
06:08 < provoostenator> Ok, that's what I'm seeing...
06:08 < sipa> in particular one very short address that starts with a 3
06:08 < provoostenator> I'll just bake that into the test, although a more severe warning would be nice, at least after upgrade.
06:08 < sipa> it should be fixed by uograding again
06:09 < provoostenator> Nope, weird address sticks for me. But I'm trying that again now.
06:09 < provoostenator> Actually nvm, my bad.
06:09 -!- Arielle33Wilkins [~Arielle33@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 276 seconds]     
06:15 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
06:19 < bitcoin-git> [bitcoin] Sjors opened pull request #12152: [WIP] misc. backwards compatibility tests (master...previous-release-segwit-wallet-test) https://github.com/bitcoin/bitcoin/pull/12152
06:19 < provoostenator> It does recover. Any other scenarios I should add ^ ?
06:24 < sipa> provoostenator: have you seen my gist on segwit wallet?
06:24 < sipa> it explicitly lists a number of scenarios that are intended to work
06:24 < provoostenator> I read it in early December. It is still up to date? Back then it had several atlernative plans.
06:25 < provoostenator> So it's 1a and 3a now?
06:25 < sipa> yes, it is up to date
06:25 < sipa> and 5
06:26 < sipa> but the solutions don't matter for you, just the supported scenarios :)
06:26 < provoostenator> Ah yes, alright I'll see if can turn those into tests.
06:26 < bitcoin-git> [bitcoin] promag opened pull request #12153: Avoid permanent cs_main lock in getblockheader (master...2018-01-getblockheader) https://github.com/bitcoin/bitcoin/pull/12153
06:32 < provoostenator> sipa: might be a good idea to move that gist to the docs repo or some other easier to find spot? At least the current-facts part of it.
06:33 < sipa> provoostenator: perhaps, though such documents may get outfated soon
06:33 < sipa> *outdated
06:34 -!- wtabata [~wtabata@179.235.79.229] has joined #bitcoin-core-dev     
06:35 -!- Swifree [700ac30f@gateway/web/freenode/ip.112.10.195.15] has joined #bitcoin-core-dev     
06:35 < provoostenator> In case of the wallet format, any proposed change should reference that document and we could consider a PR unfinished until a corresponding doc change PR is there. Hopefully eventually the wallet will be intuitive enough that the doc can be removed.
06:35 -!- will_ [b3eb4fe5@gateway/web/freenode/ip.179.235.79.229] has quit [Quit: Page closed]     
06:36 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
06:38 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
06:39 -!- Swifree [700ac30f@gateway/web/freenode/ip.112.10.195.15] has quit [Ping timeout: 260 seconds]     
06:40 -!- wtabata [~wtabata@179.235.79.229] has quit []     
06:41 -!- wtabata [~wtabata@179.235.79.229] has joined #bitcoin-core-dev     
06:43 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
06:56 -!- dcousens [~dcousens@CPE-101-181-122-189.lnse5.cha.bigpond.net.au] has quit [Ping timeout: 248 seconds]     
06:56 -!- dcousens [~dcousens@CPE-101-181-36-49.lnse4.cha.bigpond.net.au] has joined #bitcoin-core-dev     
06:59 -!- hirish is now known as hirishaway     
07:00 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Remote host closed the connection]     
07:01 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
07:02 -!- Cogito_Ergo_Sum [~Myself@80.107.151.135] has joined #bitcoin-core-dev     
07:02 -!- Cogito_Ergo_Sum [~Myself@80.107.151.135] has quit [Changing host]     
07:02 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
07:06 -!- hirishaway is now known as hirish     
07:07 -!- wtabata is now known as wtabat     
07:07 -!- wtabat is now known as wtabata     
07:13 -!- Judah16Tillman [~Judah16Ti@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
07:16 -!- anome [~anome@unaffiliated/anome] has quit []     
07:19 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-vwcmeawglbrndtqf] has quit [Quit: Connection closed for inactivity]     
07:20 < promag> GH down?
07:21 -!- JackH [~laptop@91.189.61.70] has joined #bitcoin-core-dev     
07:24 -!- hirish is now known as hirishaway     
07:24 < instagibbs> promag, yes
07:24 -!- hirishaway is now known as hirish     
07:25 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev     
07:26 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Quit: Leaving]     
07:27 -!- wxss [~user@31.192.111.176] has quit [Ping timeout: 256 seconds]     
07:28 -!- Chenpan [~Chenpan@unaffiliated/chenpan] has quit [Quit: Leaving]     
07:30 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
07:31 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
07:32 -!- JackH [~laptop@91.189.61.70] has quit [Ping timeout: 255 seconds]     
07:33 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
07:33 -!- harrymm [~harrymm@104.207.83.58] has joined #bitcoin-core-dev     
07:44 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev     
07:45 -!- JackH [~laptop@aoe110.neoplus.adsl.tpnet.pl] has joined #bitcoin-core-dev     
07:50 -!- mrsc_ [~bantry@96-37-241-230.dhcp.leds.al.charter.com] has joined #bitcoin-core-dev     
07:53 -!- mrsc [~bantry@96-37-241-230.dhcp.leds.al.charter.com] has quit [Ping timeout: 248 seconds]     
07:56 -!- Chenpan [~Chenpan@unaffiliated/chenpan] has joined #bitcoin-core-dev     
07:57 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
07:57 -!- unholymachine [~quassel@2601:8c:c003:9f16:b999:eaa9:7d4c:ea3c] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]     
07:58 -!- unholymachine [~quassel@185.195.201.86] has joined #bitcoin-core-dev     
08:00 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
08:01 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
08:02 -!- eck [~eck@fsf/member/eck] has quit [Quit: we out here]     
08:03 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
08:04 -!- Chenpan [~Chenpan@unaffiliated/chenpan] has quit [Remote host closed the connection]     
08:05 -!- Chenpan [~Chenpan@unaffiliated/chenpan] has joined #bitcoin-core-dev     
08:09 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: Textual IRC Client: www.textualapp.com]     
08:27 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev     
08:43 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
08:43 -!- wxss [~user@109.236.91.108] has joined #bitcoin-core-dev     
08:53 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Remote host closed the connection]     
08:54 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
09:01 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
09:01 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has quit [Quit: JayBerg]     
09:02 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
09:05 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
09:25 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
09:27 -!- Krellan [~Krellan@2601:640:4000:9258:51fb:322e:7ebc:3efc] has joined #bitcoin-core-dev     
09:28 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has quit [Client Quit]     
09:29 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev     
09:29 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
09:32 -!- Krellan [~Krellan@2601:640:4000:9258:51fb:322e:7ebc:3efc] has quit [Ping timeout: 265 seconds]     
09:33 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
09:34 -!- Ephraim [c59c5f93@gateway/web/freenode/ip.197.156.95.147] has joined #bitcoin-core-dev     
09:35 < Ephraim> help
09:38 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
09:38 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]     
09:38 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
09:38 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
09:38 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Excess Flood]     
09:39 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1d2eaba300bc...0910cbe4ef31
09:39 < bitcoin-git> bitcoin/master 18be3ab Chris Stewart: Adding test case for SINGLE|ANYONECANPAY hash type in tx_valid.json
09:39 < bitcoin-git> bitcoin/master 0910cbe MarcoFalke: Merge #12082: Adding test case for SINGLE|ANYONECANPAY hash type in tx_valid.json...
09:39 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
09:40 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #12082: Adding test case for SINGLE|ANYONECANPAY hash type in tx_valid.json (master...add_tx_valid_singleanyonecanpay) https://github.com/bitcoin/bitcoin/pull/12082
09:40 -!- Ephraim [c59c5f93@gateway/web/freenode/ip.197.156.95.147] has quit [Ping timeout: 260 seconds]     
09:47 -!- indistylo [~indistylo@106.206.27.142] has joined #bitcoin-core-dev     
09:49 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
09:51 -!- anome [~anome@unaffiliated/anome] has quit []     
09:51 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds]     
09:52 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
09:53 < achow101> what's wrong with travis today?
09:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
09:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:55 < wumpus> what is it doing?
09:56 -!- rebel84 [af8ba7c1@gateway/web/freenode/ip.175.139.167.193] has joined #bitcoin-core-dev     
09:57 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:58 -!- indistylo [~indistylo@106.206.27.142] has quit [Remote host closed the connection]     
09:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]     
09:59 -!- indistylo [~indistylo@106.206.27.142] has joined #bitcoin-core-dev     
10:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
10:03 -!- rebel84 [af8ba7c1@gateway/web/freenode/ip.175.139.167.193] has quit [Ping timeout: 260 seconds]     
10:07 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
10:12 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds]     
10:14 < achow101> nvm. I was just confused as to how 8 of the most recent PRs were failing travis. thought it was a problem travis but its actually a problem with those 8 PRs :/
10:16 -!- indistylo [~indistylo@106.206.27.142] has quit [Ping timeout: 276 seconds]     
10:16 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
10:16 -!- isis [~isis@abulafia.patternsinthevoid.net] has quit [Ping timeout: 268 seconds]     
10:17 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
10:20 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
10:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
10:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
10:31 -!- m8tion [~m8tion@81-65-53-254.rev.numericable.fr] has quit [Remote host closed the connection]     
10:32 -!- m8tion [~m8tion@81-65-53-254.rev.numericable.fr] has joined #bitcoin-core-dev     
10:33 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev     
10:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]     
10:34 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
10:36 < wumpus> indeed, master is passing according to my mails
10:37 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit]     
10:38 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #bitcoin-core-dev     
10:39 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev     
10:41 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit]     
10:43 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev     
10:44 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
10:46 -!- m8tion [~m8tion@81-65-53-254.rev.numericable.fr] has quit [Quit: Leaving]     
10:48 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
10:52 -!- anome [~anome@unaffiliated/anome] has quit []     
10:53 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
10:57 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-crhodphjhtfdfcfb] has joined #bitcoin-core-dev     
10:57 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
10:59 < wumpus> meeting?
10:59 < jtimon> hi     
10:59 < jonasschnelli> yes     
11:00 < wumpus> #startmeeting
11:00 < lightningbot> Meeting started Thu Jan 11 19:00:15 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:00 < wumpus> #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 meshcollider jnewbery maaku fanquake promag
11:00 < meshcollider> hi     
11:00 < wumpus> congrats everyone on merging segwit wallet!
11:00 < meshcollider> \o/     
11:00 < achow101> hi     
11:01 < wumpus> I think we should focus this meeting on what there is to do still for 0.16
11:01 < provoostenator> hi     
11:01 < wumpus> I've just updated https://github.com/bitcoin/bitcoin/milestone/30 removing everything that isn't either a bugfix or has to do with segwit
11:01 < instagibbs> hi     
11:01 < instagibbs> \o/ so great to see
11:01 < wumpus> (well, moving it forward to 0.17)
11:02 < provoostenator> I'd like to get either #11991 or #11937 in so non-tech-savy people can actually use bech32.
11:02 < gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
11:02 < wumpus> so that is the "high priority" list for now, if there's anything that should be added let me know
11:02 < gribble> https://github.com/bitcoin/bitcoin/issues/11937 | Qt: Setting for deciding address type (legacy, p2sh or bech32) by hsjoberg · Pull Request #11937 · bitcoin/bitcoin · GitHub
11:02 < BlueMatt> #11281 needs rebase and resolution of current discussion
11:02 < gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
11:02 < jonasschnelli> Will do soon
11:02 < wumpus> provoostenator: agreed
11:02 < provoostenator> I'll try to keep them fresh based on feedback.
11:03 < instagibbs> -qt support for address types i think is a big ? still
11:03 < jonasschnelli> Yes. I also think 11991 11937 should go into 0.16
11:03 -!- Chris_St1 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
11:03 < BlueMatt> I believe there's still pending segwit wallet stuff in some rpcs that are still TODO
11:03 < BlueMatt> sipa?
11:03 < achow101> If 11281 goes in, I would like to also have #11200
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/11200 | Allow for aborting rescans and canceling showProgress dialogs by achow101 · Pull Request #11200 · bitcoin/bitcoin · GitHub
11:03 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
11:03 < cfields> hi, here
11:04 < achow101> also #12101 and #12104 are bugfix-ish
11:04 < provoostenator> bech32 change behavior is nice to have; #11991 is mostly for my own OCD and I can just run that myself
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/12101 | Clamp walletpassphrase timeout to 2^31 seconds and check its bounds by achow101 · Pull Request #12101 · bitcoin/bitcoin · GitHub
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/12104 | HTTP Error 404: Not Found
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
11:04 < achow101> s/12024/12104
11:04 < BlueMatt> do we want to fix the non-regression rpc too-many-sockets thing given its an upstream bug? cfields?
11:04 < provoostenator> (sorry, I meant #12119)
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/12119 | [wallet] use bech32 change address if any destination is bech32 by Sjors · Pull Request #12119 · bitcoin/bitcoin · GitHub
11:04 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
11:04 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
11:05 < cfields> BlueMatt: yes, I'll clean that up and PR it today. What's not clear, though, is if we should attempt to max out available fds.
11:05 < wumpus> 11200 seems more like a feature and isn't necessarily segwit related
11:05 < wumpus> more for 0.17
11:05 -!- Krellan [~Krellan@2601:640:4000:9258:51fb:322e:7ebc:3efc] has joined #bitcoin-core-dev     
11:06 < provoostenator> wumpus: when you move something to 0.17 does that mean it be merged before 0.16 is branched off, or does it not have that meaning?
11:06 < provoostenator> *it won't
11:06 < wumpus> provoostenator: yes
11:06 -!- Judah16Tillman [~Judah16Ti@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 265 seconds]     
11:07 < BlueMatt> wumpus: tend to agree re: 11200, though I'd still very much like to see #11281
11:07 < gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
11:07 < meshcollider> Will we have the signing certificates ready for the release? jonasschnelli cfields 
11:07 < cfields> wumpus: consider the maxing fd's question a topic suggestion. I'm unsure what to do there.
11:07 < wumpus> BlueMatt: isn't that one already on there?
11:08 < jonasschnelli> meshcollider: at least there is a static non distributed RSA cert now available... (OSX).
11:08 < BlueMatt> wumpus: it is, was just re-enforcing :)
11:08 < meshcollider> jonasschnelli: ok
11:08 < jonasschnelli> (but no clue about Windows) topic?
11:08 < cfields> meshcollider: yes, we didn't get the threshold key setup in time, so we have a temporary key now. Presumably for 0.16 only.
11:09 < wumpus> BlueMatt: but yes I agree keeping that, it's more of a fix I guess (but also not really)
11:09 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
11:09 < promag> o/     
11:10 < cfields> meshcollider: I've written up a few little things worth committing, I'll PR those today as well.
11:10 < wumpus> great news regarding the signing key
11:10 < wumpus> cfields: ok, topic noted
11:11 < cfields> oh, on to me then? 
11:11 < cfields> #11785 is what I'm unsure about
11:11 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
11:11 < gribble> https://github.com/bitcoin/bitcoin/issues/11785 | Raise the open fd limit to the maximum allowed by vii · Pull Request #11785 · bitcoin/bitcoin · GitHub
11:11 < wumpus> #topic maxing out fds
11:12 < wumpus> oops, accidentelly tagged #12101 0.17 while it should be 0.16
11:12 < provoostenator> As discussed earlier today: what's the minimum time before we branch of 0.16? So there's some time to test stuff and fix PR's.
11:12 < gribble> https://github.com/bitcoin/bitcoin/issues/12101 | Clamp walletpassphrase timeout to 2^31 seconds and check its bounds by achow101 · Pull Request #12101 · bitcoin/bitcoin · GitHub
11:12 < cfields> tl;dr: there was an issue where fd's could be maxed out causing crashes and weird behavior. Let's assume that we get that issue under control. Should we still attempt to bump up our fd limit?
11:12 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Client Quit]     
11:13 < wumpus> cfields: I'm not sure that should be default behavior, how much is it frowned upon if daemons do that, don't know how other software handles it?
11:13 < wumpus> cfields: I think the usual way is to leave ulimit setting to the user/sysadmin
11:13 < ryanofsky> provoostenator, i think normally there is a feature freeze on master before creating the release branch
11:14 < wumpus> yes, normally there's a feature freeze
11:14 < wumpus> I also need to open translations for 0.16
11:14 < cfields> wumpus: I tend to agree with that. IMO if we're bumping into fd issues, we want to see them rather than mask them
11:14 < cfields> but iirc gmaxwell was generally in favor of a general bump
11:15 < wumpus> cfields: indeed, we should try to be robust against them, or at least exit with a clear error if that it's not possible
11:15 -!- indistylo [~indistylo@106.206.27.142] has joined #bitcoin-core-dev     
11:15 < cfields> wumpus: ok, mind commenting there? I'll poke gmaxwell again about it too
11:15 < cfields> </topic>
11:15 < wumpus> cfields: sure
11:15 < cfields> thanks :)
11:16 < wumpus> other topics?
11:16 < jonasschnelli> I have a short disussion request for 11281
11:16 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/11281/commits/b2cc7020956cfd36925e4957493cd28d1d6f672e
11:16 < jonasschnelli> Is that a concern (see commit above)=
11:16 < jonasschnelli> ?     
11:16 < jtimon> wumpus what are these "fds" to max out?
11:16 < wumpus> #topic "Avoid permanent cs_main/cs_wallet lock during RescanFromTime" discussion (jonasschnelli)
11:16 < jonasschnelli> sipa brought up the point, but I think it's okay if we just mention that in the rpc help
11:16 < wumpus> jtimon: "file descriptors"
11:16 < jtimon> thanks
11:17 < jonasschnelli> background: you may import a key and can see it's there but the related transactions are (still) missing
11:17 < achow101> I think it's fine to mention that in the help
11:17 < jonasschnelli> since the lock is released now
11:17  * BlueMatt is fine with the documentation fix, we cant always block the world waiting on things to be consistent
11:17 < BlueMatt> but sipa is the one who brought it up and apparently is mia today
11:18 < jonasschnelli> Okay. Lets wait on his feedback
11:18 < achow101> the alternative would be to block those calls during a rescan, right?
11:18 < jonasschnelli> </topic>
11:18 < wumpus> other topics?
11:18 < promag> what happens today if you import and then it crashes?
11:18 < jnewbery> Other PRs that would be nice for 0.16 are the RPC changes in #7965 (#10583, #11415, #10579)
11:18 < gribble> https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub
11:18 < gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
11:18 < gribble> https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub
11:18 < jonasschnelli> promag: I guess the same problem
11:18 < gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
11:18 < kanzure> hi.     
11:18 < wumpus> jnewbery: those have nothing to do with segwit, so I moved them to 0.17
11:19 < jonasschnelli> Agree
11:19 < jnewbery> Shame. They deprecate the RPCs but don't remove them, so we're stuck with those wallet dependencies until v0.18
11:19 < wumpus> if we do a "theme release" at all we need to focus, sorry
11:19 < promag> jonasschnelli: should we "mark" those addresses until the rescan finishes?
11:19 < ryanofsky> 11415 maybe could be merged now
11:19 < jtimon> do #8994 and #10757 have a chance to get merged for 0.16 if I fix the nits?
11:20 < promag> jonasschnelli: future work I guess
11:20 < gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
11:20 < gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
11:20 < jonasschnelli> promag: Yes... probably... need to think about that first
11:20 < wumpus> no, we're not adding non-segwit features for 0.16
11:20 < BlueMatt> wumpus: oooo, "theme release", can we start themeing based on cocktails like openwrt?
11:20 < achow101> presumably 0.17 will be sooner than the usual 6 months?
11:20 < ryanofsky> ok so feature freeze has already started?
11:20 < wumpus> BlueMatt: lol!
11:21 < instagibbs> ryanofsky, non-segwit ff i believe so
11:21 < jonasschnelli> I think since merging SW wallet freeze is active
11:21 < wumpus> ryanofsky: for non-segwit things, yes, for segwit things it's open for sicussion
11:21 < cfields> BlueMatt: by that you mean "white russian" (or something) for ~5 years, iirc?
11:21 < instagibbs> qt stuff might still be required
11:21 < BlueMatt> yes, didnt we say feature freeze when segwit wallet got merged
11:21 < achow101> ryanofsky: I'm guessing feature freeze started last night as soon as 11403 merged
11:21 < wumpus> BlueMatt: yes
11:21 < BlueMatt> cfields: yea......
11:21 < jtimon> achow101: really? I thought 0.16 was the exception and we're getting close to its regular planned non ahead of time date
11:21 < jonasschnelli> no     
11:21 < promag> btw, 17 theme is?
11:21 < wumpus> achow101: we could do 0.17 sooner, but one thing at a time please, this is for discussion once 0.16 is out of the door :)
11:21 < BlueMatt> promag: white russian, apparently
11:22 < wumpus> no theme for 0.17, no themes again please, back to simply time based releases
11:22 < meshcollider> wumpus: you mean 17.0 ;)
11:22 < provoostenator> Given that the world demands SegWit from the Core wallet, I tend to agree about feature freeze for non-SegWit stuff.
11:22 < jtimon> BlueMatt: it seems tohe feature freeze is being done sooner than that
11:22 < provoostenator> And I guess it's about hte regular time to release anyway?
11:22 < wumpus> segwit was an exception because that was 'promised' for 0.15.1, I don't think this should become routine
11:23 < achow101> provoostenator: I think there's still 2 months left for the usual timing
11:23 < wumpus> yes, we're intentionally trying to do the release sooner than the usual planning
11:24 < wumpus> (e.g. the one in #11449 is worst-case)
11:24 < gribble> https://github.com/bitcoin/bitcoin/issues/11449 | Release schedule for 0.16.0 · Issue #11449 · bitcoin/bitcoin · GitHub
11:24 < MarcoFalke> Is #10387 a blocker for 0.16?
11:24 < gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Eventually connect to NODE_NETWORK_LIMITED peers by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
11:24 -!- jeremymbolin [42579956@gateway/web/freenode/ip.66.87.153.86] has joined #bitcoin-core-dev     
11:24 < jonasschnelli> MarcoFalke: no... can go into 0.17 IMO
11:24 < wumpus> MarcoFalke: I don't know, let's discuss
11:24 < jonasschnelli> Or why would it be?
11:24 < jtimon> I thought the only blocker for 0.16 was #11403 ?
11:25 < BlueMatt> its pending on gmaxwell, just need his ack, I think
11:25 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
11:25 < BlueMatt> but, its def a "feature"
11:25 < jonasschnelli> 10387 is independent from the BIP159 signalling.... connecting would be nice though, but includes some risks.. so no hurry with that
11:25 < BlueMatt> we're doing the bit announce on master already
11:25 < wumpus> ok moving it to 0.17
11:25 < BlueMatt> so thats ok for it to go 17
11:26 < jonasschnelli> Ah,.. did 10387 still had the 0.16 tag?, Yes. Needs a 0.17 then
11:26 < wumpus> that leaves 13 open things in https://github.com/bitcoin/bitcoin/milestone/30 
11:26 < wumpus> (including the release notes and the release schedule itself)
11:27 < sipa> oops, i'm here
11:27 < BlueMatt> lol     
11:27 < sipa> timezone confusion
11:28 < BlueMatt> sipa: plx comment on 11281
11:28 < jonasschnelli> we need a core meeting alarm/notification service
11:28 < BlueMatt> also pending segwit wallet work
11:28 < BlueMatt> whats still missing?
11:28 < meshcollider> Does anything actually need to be done for #11048
11:28 < gribble> https://github.com/bitcoin/bitcoin/issues/11048 | Weird gettransaction details on testnet with segwit · Issue #11048 · bitcoin/bitcoin · GitHub
11:28 < jonasschnelli> sipa, Bluemat refers to https://github.com/bitcoin/bitcoin/pull/11281/commits/b2cc7020956cfd36925e4957493cd28d1d6f672e
11:28 < provoostenator> How do I add myself to the fancy meeting username mention ping?
11:28 < instagibbs> gotta tip wumpus some bch
11:28 -!- jeremymbolin [42579956@gateway/web/freenode/ip.66.87.153.86] has quit [Ping timeout: 260 seconds]     
11:29 < achow101> lol     
11:29 < meshcollider> instagibbs: lol
11:29 < sipa> yeah will do, on my phone in a bar now
11:29 -!- machaans [~krish@193.29.76.167] has joined #bitcoin-core-dev     
11:29 < instagibbs> RWC?
11:29 < wumpus> instagibbs: please no, no need to threaten me, will add him :)
11:29 < sipa> instagibbs: yes
11:29 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev     
11:30 < BlueMatt> sipa: woke up in a bar?
11:30 < sipa> BlueMatt: just charged my phone  and saw your signal msg
11:30 < jonasschnelli> heh     
11:31 < cfields> so apparrently BlueMatt is the core meeting alarm service
11:31 < instagibbs> provoostenator, what's the status of -qt PR for 0.16? I'm kind of out of it but am willing to test with my branch
11:32 < wumpus> any other topics?
11:32 -!- Krellan [~Krellan@2601:640:4000:9258:51fb:322e:7ebc:3efc] has quit [Ping timeout: 246 seconds]     
11:32 < luke-jr> hi     
11:32 < provoostenator> instagibbs: #11991
11:32 < bitcoin-git> [bitcoin] kekimusmaximus opened pull request #12158: Avoid unnecessary copy of objects. (master...avoid_copies) https://github.com/bitcoin/bitcoin/pull/12158
11:32 < gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
11:32 < BlueMatt> lol, ok, everyone's here, start over now?
11:32 < luke-jr> #12146 should be tagged 0.16 too
11:32 < gribble> https://github.com/bitcoin/bitcoin/issues/12146 | Wallet: Support disabling implicit Segwit operation by luke-jr · Pull Request #12146 · bitcoin/bitcoin · GitHub
11:32 < provoostenator> Bit of discussion about the UI... but otherwise ready to go. 
11:33 < gmaxwell> ^ 11991 seems like an obvious and easy win.
11:33 < sipa> #11991
11:33 < gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
11:33 < luke-jr> indeed, I'd also suggest the bech32 change thing
11:34 < gmaxwell> yes, the "use native change if destinations are native"?  I think that makes a lot of sense.
11:34 < luke-jr> #12119
11:34 < gribble> https://github.com/bitcoin/bitcoin/issues/12119 | [wallet] use bech32 change address if any destination is bech32 by Sjors · Pull Request #12119 · bitcoin/bitcoin · GitHub
11:34 < provoostenator> bech32 change thing needs a small refactor which I'll try to do tomorrow. But also has some discussion about which circumstances should trigger bech32 use. Please weigh in...
11:34 < wumpus> both 11991 and 12119 are already in the 0.16 milestone
11:34 < gmaxwell> The whole reason we didn't _always_ use native change was privacy, but if the outputs are native, then that same argument says we should use native.
11:35 < provoostenator> What about inputs?
11:35 < sipa> arguably you could just uniformly ranomly pick the address type of 1 of the inputs, and make the change that
11:35 < gmaxwell> provoostenator: I think they're irrelevant.
11:35 < wumpus> sipa: sounds like a plan
11:35 < gmaxwell> sipa: I don't think that makes any sense.
11:35 < provoostenator> As in: if any input or any output is bech32, use bech32, unless changeaddress param says otherwise. .... ok, why intput irrelevant? 
11:35 < luke-jr> wumpus: 12146 isn't yet.
11:36  * sipa meh 12146
11:36 < wumpus> luke-jr: seems like that needs some more discussion
11:36 < gmaxwell> Why would it possibly be relevant in any way?
11:36 < instagibbs> we want to frustrate chain analysis, mimicking the payment as much as possible is ++
11:36 < promag> gmaxwell: what if someone wants 0.16 to behave like 0.15?
11:36 < luke-jr> wumpus: releasing Segwit wallet without it is a problem for people who don't want to use Segwit.
11:36 < provoostenator> We also want to reduce fees.
11:36 < gmaxwell> The only reason to not always use native, assuming you are using segwit to begin with in your wallet, is that it would make it easier to tell which of the outputs are change.
11:36 < jonasschnelli> luke-jr: define don't use?
11:37 < wumpus> luke-jr: just don't use the segwit address types then?
11:37 < gmaxwell> But that doesn't apply if the outputs (any of them, arguably) are native. 
11:37 < luke-jr> jonasschnelli: never have a Segwit UTXO despite what anyone else may do
11:37 < provoostenator> So in other words, if you're spending from a bech32 address, there's no reason _not_ to use a native address as change?
11:37 < luke-jr> wumpus: without 12146, people can malleate your address and you'll never know
11:37 < gmaxwell> provoostenator: no!
11:37 < instagibbs> provoostenator, ?? 
11:37 < wumpus> is address malleation a thing now?
11:37 < provoostenator> It saves fees and there's no privacy downside, what am I missing?
11:38 < sipa> luke-jr: they can already
11:38 < gmaxwell> Again, inputs are irrelevant-- I can't figure out why you think inputs are at all relevant.
11:38 < jonasschnelli> provoostenator: he's worried about block size increase
11:38 < sipa> and have forever
11:38 < jonasschnelli> as sipa said,.. it was also possible by p2pk -> p2pkh
11:38 < luke-jr> sipa: with 12146, you would at least notice / not accept it
11:38 < sipa> luke-jr: why not? it's cheaper!
11:38 < jonasschnelli> s/was/is
11:38 < luke-jr> sipa: what?
11:39 < wumpus> would anyone use that at all, why would it be worth maintaining?
11:39 < sipa> you're lucky if someone sends you a witness output instead anyone of p2pkh
11:39 < jonasschnelli> I think luke-jr argument are more political/philosophical then technical/economical
11:39 < wumpus> it just complicates all kinds of logic
11:39 < gmaxwell> provoostenator: the privacy downside arises when your pay to a non-segwit destination.  If you pay a non-segwit destination but make a native output as change, then which of the outputs is change is far more easily identified.
11:39 < luke-jr> wumpus: because using Segwit enables miners to increase block size, and has no benefits for the current wallet.
11:39 < instagibbs> i think this is going to be another "no one else agrees" type argument, sorry luke-jr 
11:39 < sipa> (i think it's really bad that we accept outputs to addresses we didn'√ give out)
11:39 < BlueMatt> provoostenator: its still a privacy leak, you're (probably) much, much more likely to use non-bech32 outputs as non-change, so irrespective of the inputs you'd be pretty clearly tagging your change output
11:40 < sipa> but it's not specific to segwit, and needs fixing independently
11:40 < instagibbs> simply not handing out those addresses should be enough... sender doesn't care if you want to spend more later
11:40 < BlueMatt> provoostenator: in fact, even worse, you're tagging it *because* your inputs are bech32 you're making clear that you support segwit in your wallet, so the bech32 output is *most likely* the change
11:40 < luke-jr> instagibbs: the sender can trick you into accepting Segwit without 12146
11:40 < wumpus> instagibbs: indeed
11:40 < instagibbs> luke-jr, worse, the sender *wont know* you don't implictly convert, leading to a orphaned utxo!
11:40 < wumpus> 'trick you into accepting segwit' 
11:40 < instagibbs> whatever jerk is doing that
11:40 < gmaxwell> But if the other outputs are native, then this issue doesn't exist.
11:41 < luke-jr> instagibbs: orphaned UTXO is exactly the expected outcome
11:41 < luke-jr> instagibbs: and that's his fault
11:41 < Chris_St1> so the debate is whether we are creating the change output as the same script type as the payment output in a two output scenario?
11:41 < instagibbs> .....
11:41 < wumpus> man, that sounds like it should be prosecuted as a war crime
11:41 -!- Tennis [~Tennis@unaffiliated/tennis] has joined #bitcoin-core-dev     
11:41 < provoostenator> Alright, so rule should be: ignore inputs, if any output is bech32, use bech32 for change, unless setting overrides? 
11:41 < luke-jr> Chris_St1: there's two parallel conversations going on here now :/
11:41 < provoostenator> luke-jr: yes, IRC needs threads
11:42 < wumpus> #topic when to use bech32 for change
11:42 < wumpus> ^^     
11:42 < meshcollider> provoostenator: yes that's most sensible
11:42 < BlueMatt> provoostenator: thats not a bad idea, imo
11:42 < Chris_St1> what about when there are more than two outputs? Or are we just worried about GUI? 
11:42  * jtimon thinks about what "trick you into accepting segwit" may mean...
11:42 < instagibbs> Chris_St1, privacy mostly
11:42 < gmaxwell> provoostenator: thats my belief.
11:42 < meshcollider> Was sipa suggestion of random choice serious or a joke 
11:42 < provoostenator> Chris_St1: _any_ output, not _all_
11:42 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 265 seconds]     
11:42 < instagibbs> meshcollider, serious to me, makes sense
11:43 < luke-jr> IMO any output makes sense.
11:43 < gmaxwell> provoostenator: I think someone could reasonable argue that it should be "if a majority" rather than any.
11:43 < cfields> don't you lose the change privacy if there's a mix of segwit output types, though?
11:43 < meshcollider> Yeah was unsure if there's any downside
11:43 < wumpus> meshcollider: I think he was serious, it makes sense, less deterministic the change choice the better
11:43 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
11:43 < Chris_St1> instagibbs: yes, but what if you a 3 segwit payment outputs and 2 p2pkh payment outputs, what is the change type?
11:43 < gmaxwell> I think "all" is obviously too strong.
11:43 < cfields> if there's a p2wsh output and change goes to p2wpkh, that's obvious
11:43 < instagibbs> Chris_St1, arguments to be had. Could flip weighted coin, could just pick the cheapest to mimic
11:44 < instagibbs> (native)
11:44 < gmaxwell> cfields: "segwit" here means native.
11:44 < morcos> I don't think its worth going overboard with complication.   If you are super privacy conscious you can manually do what you want, otherwise we should make the default what makes sense for the network.
11:44 < morcos> So I like provoostenator's idea
11:44 -!- mgeuirx [409ca7a0@gateway/web/freenode/ip.64.156.167.160] has joined #bitcoin-core-dev     
11:44 < provoostenator> Chris_St1: bech32 in my proposal s well as the majority proposol (which I think it's a bit complicated...)
11:44 < Chris_St1> morcos: But that erodes the privacy of *everyone*. see zcash?
11:44 < morcos> Chris_St1: i don't think that analogy applies
11:45 < gmaxwell> Any is what I proposed on the PR, though I noted that "majority" would also be defensible.  Requiring all, or worse, not using native even if all are native is bad for privacy.
11:45 < BlueMatt> yea, majority-are-native or signle-is-native are both fine with me
11:45 < luke-jr> weighed random?
11:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
11:45 < gmaxwell> I think it's okay to bias some here towards the more cost effective form.
11:45 < morcos> well maybe, but thats why we're preservign some level of privacy...  in that we only use bech32 for change if we're paying at least one bech32 address
11:45 < wumpus> yes     
11:45 < instagibbs> hiding with other segwit wallets imo is your best bet anyways...
11:45 < gmaxwell> also the difference between these things only matters for sendmany...
11:45 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has quit [Quit: JayBerg]     
11:45 < provoostenator> luke-jr: I that would be a great way for me to demonstrate my C++ incompetence :-)
11:46  * sipa is fine with (if not otherwise configured) using any bech32 -> change is bech32
11:46 -!- Chris_St1 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Quit: WeeChat 1.4]     
11:46 < jnewbery> any-output-is-native seems reasonable to me
11:46 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
11:46 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
11:46 < achow101> same
11:46 < gmaxwell> sipa: I think my suggestion was "unless configured that change should be legacy, change is native if any output is native".
11:46 < morcos> i think non-determinism in what kind of change address you have is just ick..  especially since the p2sh-wrapped kind is temporary
11:47 < provoostenator> As for luke-jr's point: having some flag to completely opt-out of SegWit seems reasonable to me.
11:47 < gmaxwell> (or if anyone felt that was too strong, change is native unless the majority is non-native; but it seems no one does)
11:47 < sipa> gmaxwell: and p2sh-p2wsh otherwise?
11:47 < gmaxwell> sipa: yes.
11:47 < sipa> makes snese
11:47 < Chris_Stewart_5> gmaxwell: by native you mean p2wpkh? 
11:47 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
11:47 < gmaxwell> sipa: so if you set yourself to be legacy, you'll stay legacy regardless, in order to respect any weird requirement to avoid creating segwit outputs.
11:48 < instagibbs> morcos, if it has native change is native is entirely determinstic, luckily
11:48 < instagibbs> sorry, has native, comma, change is native
11:48 < gmaxwell> morcos: I think you were responding to things like "weighed random change types"
11:49 < morcos> correct
11:49 < BlueMatt> more topics?
11:49 < luke-jr> back to 12146?
11:49 < gmaxwell> yea, I could go for weighed-random change types if the choice were otherwise neutral, but it's not. 
11:49  * BlueMatt notes that it really would be nice to see #12118 in 0.16, just because its really a free 5% speedup in removeForBlock which is a big chunk of block validation latency....
11:49 < gribble> https://github.com/bitcoin/bitcoin/issues/12118 | Sort mempool by min(feerate, ancestor_feerate) by sdaftuar · Pull Request #12118 · bitcoin/bitcoin · GitHub
11:49 -!- Krellan [~Krellan@2601:640:4000:9258:51fb:322e:7ebc:3efc] has joined #bitcoin-core-dev     
11:49 < instagibbs> luke-jr, Creating utxo bloat to *slightly* reduce blocksize is weird weird feature to add imo
11:49 < instagibbs> (if we've transitioned)
11:49 < luke-jr> instagibbs: it's not UTXO bloat.
11:50 < BlueMatt> luke-jr: nack, just use 0.15.1 and focus on the real fix of splitting hd chain
11:50 < instagibbs> the scenario here is that some joker pays you, and you don't want to spend it, right?
11:50 < morcos> +1 BlueMatt
11:50 < BlueMatt> alternatively, this could be accomplished by using labels/accounts
11:50 < BlueMatt> label addresses and then payments will show up without the labels
11:50 < luke-jr> instagibbs: more or less
11:50 < luke-jr> BlueMatt: NACK, to myself and many others, mandatory Segwit wallet is a regression
11:51 < BlueMatt> then dont use 0.16
11:51 < luke-jr> so 0.15 is supported forever?
11:51 < gmaxwell> luke's argument is lame but there are other arguments for the position...  But I think it's ultimately futile.  
11:51 < luke-jr> including new features?
11:51 < morcos> luke-jr: right, but thats basically the only feature, so just dont use it until we have the version that doesn't accept all variations of key encoding
11:51 < BlueMatt> if you want the option, do the real fix, not the dirty hack of working like 0.15.1
11:51 < gmaxwell> luke-jr: by anyone who cares to support it
11:51 < instagibbs> This feature doesn't make any sense to me though.
11:51 < luke-jr> BlueMatt: there isn't a better fix
11:51 < BlueMatt> (the real fix being splitting the hd chain so that we never identify as ours addresses other than the ones we gave out)
11:52 < morcos> ^ it's in sipas gist
11:52 < achow101> luke-jr: the real fix is using different hd paths
11:52 < sipa> indeed.
11:52 < BlueMatt> which sipa proposed (I believe to much agreement) as the long-term route for the wallet
11:52 < luke-jr> BlueMatt: that's more than a fix. :p
11:52 < gmaxwell> instagibbs: it's very bad that we support showing funds paid to addresses we never issued.  It invites really bad behavior that can cause irrecoverable funds loss.   But the ship has already sailed on that.
11:52 < instagibbs> gmaxwell, no I get the issue
11:52 < instagibbs> I don't get his fix, it's one-sided
11:52 < gmaxwell> ah.     
11:52 < morcos> we all agree to fixing that, what we don't care about is that we are temporarily makign it worse for the case of giving out legacy and receiving segwit
11:52 < instagibbs> sender has no clue you won't accept it!(outside of us wagging fingers to not try it)
11:53 < gmaxwell> Well thats because his motivation isn't one of the sensible ones, it's because he's discouraging people from using segwit to keep the blocksize down.
11:53 < BlueMatt> luke-jr: it is more than a fix for your specific issue, but its much nicer and isnt ridiculous from a ux/maintainability perspective
11:53 < luke-jr> that is a sensible one
11:53 < BlueMatt> we dont need more options in the wallet...
11:53 < instagibbs> anyways, all i have to say. Let's fix the wallet.
11:53 < gmaxwell> I don't share his concern, but even if I did-- his fix isn't needed for it:  anyone autoconverting an address has a serious risk of funds loss already.
11:53 < provoostenator> luke-jr: what's wrong with launching with -addresstype=legacy? 
11:53 < luke-jr> BlueMatt: 12146 is trivial
11:53 < morcos> luke-jr: would it help if we we very publicly communicated that our philosophy is to not accept payments except for addresses which have been given out?
11:53 < wumpus> certainly not options that only exist for some political goal and no one will actually use nor test
11:54 < morcos> we discussed doing that when we were making this change, b/c we knew we'd be making things worse on that front, but we'd already crossed the bridge with addwitnessaddress
11:54 < luke-jr> provoostenator: the current code will still accept Segwit payments to malleated addresses
11:54 < morcos> and other variants
11:54 -!- indistylo [~indistylo@106.206.27.142] has quit [Ping timeout: 256 seconds]     
11:54 < BlueMatt> anyway, one more review on #12118 and slipping in past feature freeze would make me very happy...good to keep the march of performance improvements in block validation latency moving :)
11:54 < gribble> https://github.com/bitcoin/bitcoin/issues/12118 | Sort mempool by min(feerate, ancestor_feerate) by sdaftuar · Pull Request #12118 · bitcoin/bitcoin · GitHub
11:54 < gmaxwell> luke-jr: your change isn't needed to prevent autoconverting. Anyone who 'autoconverts' will have casual funds loss due to converted outputs being unreconized by older software, and _unrecoverable loss_ due to uncompressed pubkeys and potentially HSMs.
11:54 < cfields> instagibbs: at best, if you wag your finger and I'm forced to re-send a non-witness tx, that's 2x the tx's for that interaction. Not doing much to reduce block size...
11:55 < provoostenator> luke-jr: oh, you mean someone sees the public key after you spend it and then figures out how to send to its SegWit equivalent? I'm not sure if that actually works, see my backwards compatibility test PR.
11:55 < gmaxwell> luke-jr: that should be ample discouragement there.
11:55 < wumpus> morcos: would make sense to document that, though I wouldn't know where!
11:55 < jnewbery> Doesn't seem to me like this needs to be discussed for v0.16 release. Luke can maintain his patch in knots and everyone is happy. And then we can reconsider 12146 for 0.16.1
11:55 < instagibbs> cfields, what we need is a way of bloating the weight without taking up serialization space lol
11:55 < luke-jr> gmaxwell: all the more reason to allow people to avoid accepting the attempts
11:55 < provoostenator> But I don't see the point in ignoring such a transaction. There's certainly no way to stop it.
11:55 < achow101> provoostenator: given a p2pkh address, you can easily make the p2wpkh output without needing to see a transaction
11:55 < morcos> We can use the @bitcoin twitter handle maybe
11:55 < meshcollider> provoostenator: you don't need the public key, segwit addresses use PKH too
11:56 < wumpus> but a warning against 'malleating' addresses would make sense, I mean it's bad form and just because bitcoin core happens to accept it doesn't mean other wallets do
11:56 < luke-jr> provoostenator: it's an invalid payment
11:56 < gmaxwell> And yes, as morocos said, we knew that our handling of segwit would increase the risk that someone falsely believed they could autoconvert.  It was a tradeoff we made, otherwise segwit support would be delayed behind a massive redesign.
11:56 < luke-jr> morcos: It would probably be good to do so, but I'm not sure it accomplishes the same thing
11:56 < luke-jr> also, you *can't* malleate right now
11:56 < morcos> yes, so lets spend our time doing the redesign and communicating our intentions
11:56 < cfields> instagibbs: heh
11:56 < morcos> you can do other forms of malleation
11:56 < BlueMatt> </topic>? It seems like everyone agrees outside of luke, and there is a *real* solution...also easy to not use 0.16 for now
11:56 < sipa> luke-jr: you can use p2pk instead of p2pkh
11:57 < wumpus> BlueMatt: yes, any other topics?
11:57 < Chris_Stewart_5> PSA: if anyone is interested in talking more about #12131 or #12132 there is a development channel that some work has been occurring in: #bitcoin-mast
11:57 < gribble> https://github.com/bitcoin/bitcoin/issues/12131 | [BIP-98 + BIP-116] MERKLEBRANCHVERIFY by kallewoof · Pull Request #12131 · bitcoin/bitcoin · GitHub
11:57 < gribble> https://github.com/bitcoin/bitcoin/issues/12132 | [BIP-117] Tail call semantics by kallewoof · Pull Request #12132 · bitcoin/bitcoin · GitHub
11:57 < wumpus> oh 3 minutes to go
11:57 < luke-jr> sipa: only if you know the key, which only the recipient does
11:57 < morcos> aren't those a bit premature for PR's?
11:57 < arubi> sipa, then I'll trick you into accepting some big bare n-of-m with a bunch of pubkeys
11:57 < achow101> luke-jr: you can malleate it to a p2sh nested p2pkh
11:57 < gmaxwell> luke-jr: I think it's adequate enough to let people know that if they do that, they _will_ lose funds, its effectively a guarentee.  some switch to willfully ignore the outputs in a recoverable way wouldn't help that message at all.
11:57 < arubi> (all of yours)
11:57 < gmaxwell> and basically no one but you would set it.
11:57 < morcos> is there any consensus at all around wanting those features?
11:57 < luke-jr> achow101: nope, pretty sure we won't accept that without adding it to the wallet explicitly
11:58 < sipa> achow101: as luke-jr says
11:58 < luke-jr> gmaxwell: I don't agree only I would set it.
11:58 < gmaxwell> luke-jr: you can malleat addresses now fwiw, this is a long term design flaw in the wallet.
11:58 < gmaxwell> oh sipa pointed that out too
11:58 < luke-jr> gmaxwell: but you can't, as I pointed out
11:58 < wumpus> there's not really incentive for anyone to set a 'ignore some payments to me' setting, real user complaints are about not receiving payments...
11:58 < Chris_Stewart_5> morcos: I would say they are premature -- but I think they are definitely worht exploring more
11:58 < instagibbs> you can send people naked multisig...
11:58 < instagibbs> lol     
11:58 < Chris_Stewart_5> if that was directed at me 
11:58 < sipa> instagibbs: indeed
11:58 < luke-jr> instagibbs: !
11:59 < gmaxwell> luke-jr: something like 80% of addresses are reused...
11:59 < arubi> and with a bunch of pubkeys
11:59 < morcos> Chris_Stewart_5: yes...  i just wasnt sure if i was behind the times...
11:59 < luke-jr> gmaxwell: unsupported use case, not relevant to the discussion, but instagibbs found an example case
11:59 < gmaxwell> as wumpus says, the incentives are against setting that knob.
11:59 < instagibbs> I guess that's another argument, there are tons of ways of malleating it, let's just fix the wallet instead.
11:59 < Chris_Stewart_5> morcos: Also why we should discuss the development in a separate channel IMO as it is a little speculative still 
11:59 < wumpus> gmaxwell: also thanks to some exchanges that have a limit on the number of deposit addresses
11:59 < sipa> instagibbs: indeed
12:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
12:00 < sipa> DING
12:00 < wumpus> #endmeeting
12:00 < lightningbot> Meeting ended Thu Jan 11 20:00:10 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-01-11-19.00.html
12:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-01-11-19.00.txt
12:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-01-11-19.00.log.html
12:00  * luke-jr glares at a certain Amazon wrapper that won't let him generate even a second address at all
12:00 < gmaxwell> Yea, thats my point: regardless of any willfully-ignore-naughty-payments-knob  other vectors exist... and if someone does segwit convert random stuff, they're going to lose funds in an unrecoverable way.
12:01 < meshcollider> Since when do all PR mentions get added to the minutes
12:01 < achow101> I don't think any wallet that people use actually does that sort of conversion. It would have to be someone either being malicious or using their own faulty software
12:02 < gmaxwell> achow101: no of course not, it will immediately cause unrecoverable funds loss.
12:02 < luke-jr> so outcome of conversation: I consider it reasonable to not have 12146 (so I won't be too upset if it doesn't get in), but not quite so reasonable to reject it for no reason (so I will be disappointed).
12:02 < gmaxwell> achow101: one of the concerns we had with the design we used here is we chose a design where it will sometimes work... and this may encourage someone to try it with the belief that it always works.
12:03 < gmaxwell> achow101: which is unfortunate, but no option was great.
12:03 < luke-jr> btw, if someone can quickly unlock #11403 for conversation, I'd like to Post-merge utACK it
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
12:03 < meshcollider> Yeah why can't all members comment on locked PRs/issues
12:04 < achow101> meshcollider: you need to have write access to the repo
12:04 < achow101> which means you could commit
12:04 < gmaxwell> achow101: and an opt out knob really doesn't educate people more:  The issue with it working at all is people incorrectly thinking that they can do it and people can collect their funds simply by upgrading.  Adding a knob would make it so that they falsely believed people could collect their funds simply by flipping the knob back.
12:04 < gmaxwell> achow101: when in reality some people are still using uncompressed keys...
12:04 < BlueMatt> luke-jr: lol no? outcome is consider it as-is unreasonable, but if you want to fix the broader issue, sounds great!
12:04 < gmaxwell> meshcollider: github sucks.
12:04 < achow101> gmaxwell: oh yeah, uncompressed keys. that would be a problem
12:04 < gmaxwell> achow101: or HSMs.
12:05 < achow101> lol, armory has that problem...
12:05 < gmaxwell> Someone could have their key potted in a hardware device where it can never be exported.. and which can't sign segwit style.
12:07 < gmaxwell> when we talked about our style of segwit support, the concern was raised that because conversion would sometimes work it might cause fools and madmen to think it always works...  Unfortunately, we didn't really have any good alternative for segwit support.  Among other reasons backwards supporting the addwitnessaddress stuff more or less required us to go this route for now.
12:09 < gmaxwell> also geesh, please don't call someone manipulating your address malleation.
12:10 < wumpus> bitcoiners like to overload words with as many as possible different meanings
12:10 < gmaxwell> We already have far too many morons out there confused due to existing reuse of the word.
12:10 < luke-jr> gmaxwell: what do we call it then?
12:11 < luke-jr> mutilation? :p
12:11 < gmaxwell> Conversion? I dunno. though the surrounding issues could also arise without any conversion.
12:12 < gmaxwell> For example, a wallet could plausably not scan for any change outputs because it knows all that it creates.  If I go find one of your prior change addresses and pay it there is no reason to think the wallet would ever see it.  ... and in existing software (e.g. bitcoin core) the payment wouldn't show up even if it did see the funds.
12:12 < meshcollider> Hmm achow101 all branches are protected so then write access still does not allow members to push to them without explicit permission right?
12:13 < wumpus> meshcollider: correct
12:13 < achow101> meshcollider: oh!
12:13 < gmaxwell> luke-jr: AFAIK there is no common term for "someone attempted to 'pay me' by digging a hole in by back yard and leaving an envelope of money in it"... because outside of bitcoin no one is that @#$@# stupid. :)
12:13 -!- Brandt13Hartmann [~Brandt13H@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
12:14 < luke-jr> gmaxwell: conversion is too innocent-sounding IMO
12:14 < achow101> write access means you can also tag things
12:14 < instagibbs> gmaxwell, IsChange logic is also kind loopy... 
12:14 < luke-jr> anyway, gotta run
12:15 < cfields> out of curiosity, how to handle this with segwit v1? enforce incompatibility with all previous witness versions?
12:15 < sipa> cfields: have split chains first
12:15 < gmaxwell> every address type should be its own chain.
12:15 < sipa> that ^
12:16 < gmaxwell> so you just wouldn't see such a payment.
12:16 < cfields> right, ok
12:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
12:16 < meshcollider> achow101: that could be a benefit :) but no I guess write access is too potent still
12:16 < gmaxwell> that would have been the prefered path for segwit wallet support, but it requires much more major changes _AND_ isn't compatible with the addwitness stuff people were already doing.
12:17 < gmaxwell> meshcollider: part of the problem with that too is that github might randomly stir what 'write access' could do at any time.
12:18 < meshcollider> gmaxwell: mhm true, the permission system doesn't seem very flexible
12:18 < cfields> petertod1: ping. Is there any canonical format for an opentimestamps proof?
12:18 < gmaxwell> github in general has a lot of anti features.
12:20 < gmaxwell> there was some thread on reddit where one group of ignorant people was screaming at another group of ignorant people with at claim that 0.16 wouldn't be out for a year because some random and usless github milestone "percentage" page said such and such.
12:20 -!- machaans [~krish@193.29.76.167] has quit [Remote host closed the connection]     
12:20 < meshcollider> Heh 
12:21 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
12:22 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 246 seconds]     
12:22 < provoostenator> gmaxwell: I really like Github's code review UI, except that it doesn't email the full thread if someone says "fixed" in response to inline comment.  
12:23 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
12:23 < gmaxwell> the code review has gotten better at least.
12:23 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev     
12:23 < provoostenator> Github also completely breaks down if a PR or issue becomes political.
12:24 < gmaxwell> not just 'political' but linked to on any part of the internet mostly populated by idiots.
12:24 < provoostenator> It was almost impossible to have a sane discussion about replay protection on the btc1 repo; you'd have 3 people making serious arguments and 100 ranting comments from others, including from people who do write code.
12:24 < gmaxwell> god help anyone who gets their repository linked in a youtube comment.
12:24 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 265 seconds]     
12:25 < provoostenator> I suppose "political" is a euphemism for  "linked to on any part of the internet mostly populated by idiots"
12:25 < Chris_Stewart_5> lol     
12:25 < gmaxwell> They're highly correlated at least. :)
12:26 < provoostenator> I sometimes tweet out PR's; haven't seen too negative results for the Core ones, but I would think twice doing that for anything contentious. 
12:28 < gmaxwell> I'm not sure about any of your tweets, but sometimes it does.
12:28 < gmaxwell> e.g. the announcements re the merge of the segwit PR inspired a half dozen really nasty comments on that PR (which people just deleted)
12:29 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev     
12:30 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
12:30 -!- Brandt13Hartmann [~Brandt13H@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
12:33 < provoostenator> I only have 1.5K followers and anyone who SegWit has probably unfollowed me by now.
12:33 -!- dcousens [~dcousens@CPE-101-181-36-49.lnse4.cha.bigpond.net.au] has quit [Ping timeout: 240 seconds]     
12:33 < provoostenator> *who hates
12:34 -!- dcousens [~dcousens@CPE-101-181-50-119.lnse4.cha.bigpond.net.au] has joined #bitcoin-core-dev     
12:37 -!- anome [~anome@unaffiliated/anome] has quit []     
12:37 < provoostenator> gmaxwell: I'm guessing from the replies it was this tweet that attracted those folks: https://twitter.com/theonevortex/status/951479475908194304
12:38 -!- hitesh8791 [6b4ddb50@gateway/web/freenode/ip.107.77.219.80] has joined #bitcoin-core-dev     
12:38 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 276 seconds]     
12:39 -!- hitesh8791_ [6b4ddb50@gateway/web/freenode/ip.107.77.219.80] has joined #bitcoin-core-dev     
12:43 -!- hitesh8791 [6b4ddb50@gateway/web/freenode/ip.107.77.219.80] has quit [Ping timeout: 260 seconds]     
12:43 < bitcoin-git> [bitcoin] kekimusmaximus opened pull request #12159: Use the character based overload for std::string::find. (master...use_char_overload_find) https://github.com/bitcoin/bitcoin/pull/12159
12:43 -!- owowo [ovovo@gateway/vpn/mullvad/x-ymeoybrkklvmwvpi] has joined #bitcoin-core-dev     
12:43 -!- owowo [ovovo@gateway/vpn/mullvad/x-ymeoybrkklvmwvpi] has quit [Changing host]     
12:43 -!- owowo [ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
12:43 -!- owowo [ovovo@unaffiliated/ovovo] has quit [Changing host]     
12:43 -!- owowo [ovovo@gateway/vpn/mullvad/x-ymeoybrkklvmwvpi] has joined #bitcoin-core-dev     
12:43 -!- hitesh8791_ [6b4ddb50@gateway/web/freenode/ip.107.77.219.80] has quit [Ping timeout: 260 seconds]     
12:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
12:49 < gmaxwell> I probably should have brought up #11739 during the meetings.
12:49 < gribble> https://github.com/bitcoin/bitcoin/issues/11739 | RFC: Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis by sdaftuar · Pull Request #11739 · bitcoin/bitcoin · GitHub
12:58 < promag> late suggestion, but how about -changetype=auto? (being that the default)
13:04 -!- flokie [~flokie@unaffiliated/flokie] has joined #bitcoin-core-dev     
13:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
13:09 -!- mrannanay [uid222022@gateway/web/irccloud.com/x-thcmmwzcvtmondyq] has quit [Quit: Connection closed for inactivity]     
13:10 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
13:13 -!- Juana5Kunde [~Juana5Kun@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
13:16 -!- Chenpan [~Chenpan@unaffiliated/chenpan] has quit [Ping timeout: 248 seconds]     
13:17 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
13:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:18 -!- CubicEarths [~cubiceart@46.243.136.7] has joined #bitcoin-core-dev     
13:22 -!- Juana5Kunde [~Juana5Kun@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 268 seconds]     
13:30 < BlueMatt> jonasschnelli: I think you broke on rebase of #11281 - you deleted the pwallet->UpdateTimeFirstKey(1); call in importprivkey
13:30 < gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
13:30 -!- mike_28 [~mike@86.84.147.160] has joined #bitcoin-core-dev     
13:35  * BlueMatt is of the opinion #12118 can be merged
13:35 < gribble> https://github.com/bitcoin/bitcoin/issues/12118 | Sort mempool by min(feerate, ancestor_feerate) by sdaftuar · Pull Request #12118 · bitcoin/bitcoin · GitHub
13:37 < instagibbs> provoostenator, I think we have different definitions of actionable, haha
13:44 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
13:48 -!- quitobro [quitobro@gateway/vpn/privateinternetaccess/quitobro] has joined #bitcoin-core-dev     
13:56 < sipa> instagibbs: is "cheaper" actionable? (just trying to understand your definition)
13:56 -!- mike_28 [~mike@86.84.147.160] has quit [Remote host closed the connection]     
13:58 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
13:59 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
14:02 -!- Krellan [~Krellan@2601:640:4000:9258:51fb:322e:7ebc:3efc] has quit [Read error: Connection reset by peer]     
14:03 -!- Krellan [~Krellan@2601:640:4000:9258:3085:4055:9d39:915e] has joined #bitcoin-core-dev     
14:03 -!- clarkmoody_ [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
14:04 < instagibbs> sipa, of course it is, but the comment was about privacy(which we agree users won't be able to act on)
14:05 < sipa> instagibbs: i'm confused
14:06 < sipa> instagibbs: how is "cheaper" actionable but "better privacy" isn't?
14:06 < instagibbs> the language says "may" or somesuch, and if the user googles, or whatever, they'll find nothing. I *guess* the could just get scared and never set it.
14:06 < instagibbs> so I take it back, whatever, it's just a super verbose message imo
14:06 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [Ping timeout: 248 seconds]     
14:07 < sipa> instagibbs: oh no disagreement that it's too verbose
14:07 < instagibbs> also if uptake is quick(doubt, but possible) that users will be confronted with the message and go the wrong direction
14:08 < instagibbs> i think release notes might be the best place
14:14 -!- Monique75Upton [~Monique75@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
14:14 < bitcoin-git> [bitcoin] jnewbery opened pull request #12166: [docs] Clarify -walletdir usage (master...clarify_walletdir_usage) https://github.com/bitcoin/bitcoin/pull/12166
14:18 -!- Monique75Upton [~Monique75@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 256 seconds]     
14:19 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has quit [Quit: Page closed]     
14:20 < sipa> instagibbs: agree
14:21 -!- quitobro [quitobro@gateway/vpn/privateinternetaccess/quitobro] has quit [Quit: quitobro]     
14:28 < promag> block index skiplist and GetAncestor don't require any lock right? it's computed before a blockindex is given out?
14:28 -!- arbitrary_guy [~arbitrary@c-67-183-30-122.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
14:29 -!- cheese_ [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
14:32 < sipa> promag: indeed
14:32 < sipa> every CBlockIndex has those permanently set
14:32 < promag> ty     
14:36 -!- unholymachine [~quassel@185.195.201.86] has quit [Ping timeout: 246 seconds]     
14:36 -!- cheese_ [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 268 seconds]     
14:36 -!- unholymachine [~quassel@2601:8c:c003:9f16:3554:18bd:6803:d014] has joined #bitcoin-core-dev     
14:37 -!- quitobro [quitobro@gateway/vpn/privateinternetaccess/quitobro] has joined #bitcoin-core-dev     
14:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
14:39 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
14:42 -!- quitobro [quitobro@gateway/vpn/privateinternetaccess/quitobro] has quit [Quit: quitobro]     
14:43 < BlueMatt> promag: re: #11041: why do you want to use LookupBlockIndex inside CChainState?
14:43 < gribble> https://github.com/bitcoin/bitcoin/issues/11041 | Add LookupBlockIndex by promag · Pull Request #11041 · bitcoin/bitcoin · GitHub
14:43 < promag> BlueMatt: hold on there
14:43 < promag> I'll make it const
14:43 < BlueMatt> please dont do that in the same pr :(
14:43 < BlueMatt> dont really want to delay it further
14:43 < promag> and in validation.cpp just use mapBlockIndex directly
14:43 < BlueMatt> unless you want to make things more scripted-diff...
14:43 < BlueMatt> no, not validation.cpp, CChainState
14:44 < BlueMatt> outside of CChainState should all be const CBlockIndex, even in validation.cpp
14:44 < BlueMatt> but that may not be trivially possible quite yet
14:45 < BlueMatt> promag: you saw my outstanding pr to constify them with scritped-diffs, right? You're welcome to replace it if you want, but no use duplicating effort wholesale...
14:45 -!- cheese_ [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
14:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
14:46 < BlueMatt> promag: also, generally, that pr is already one giant commit that does like 3 things....please try to script what you can and cut it down
14:46 < promag> +1     
14:47 -!- tknp [~tknp@unaffiliated/tknp] has joined #bitcoin-core-dev     
14:50 < promag> curiosity, an off chain block could have 0 confirmations, why -1?
14:51 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has quit [Ping timeout: 268 seconds]     
14:51 -!- niska [~niska@68.ip-149-56-14.net] has quit [Ping timeout: 260 seconds]     
14:51 -!- cheese_ [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 276 seconds]     
14:51 -!- booyah [~bb@193.25.1.157] has quit [Remote host closed the connection]     
14:52 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Read error: Connection reset by peer]     
14:52 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev     
14:52 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has joined #bitcoin-core-dev     
14:53 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
14:53 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
14:55 -!- kakobrekla [~kako@unaffiliated/kakobrekla] has quit [Ping timeout: 260 seconds]     
14:55 -!- dcousens [~dcousens@CPE-101-181-50-119.lnse4.cha.bigpond.net.au] has quit [Ping timeout: 276 seconds]     
14:57 -!- instagibbs [~instagibb@100.15.116.35] has joined #bitcoin-core-dev     
14:58 -!- kakobrekla [~kako@unaffiliated/kakobrekla] has joined #bitcoin-core-dev     
14:58 -!- wraithm [~wraithm@unaffiliated/wraithm] has quit [Quit: Textual IRC Client: www.textualapp.com]     
15:01 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
15:10 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
15:14 -!- Michaela63Kassul [~Michaela6@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
15:16 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev     
15:19 -!- JackH [~laptop@aoe110.neoplus.adsl.tpnet.pl] has quit [Remote host closed the connection]     
15:31 -!- MarcoFalke [~none@198.12.116.246] has quit [Ping timeout: 256 seconds]     
15:36 -!- esparragow [1fddf4ea@gateway/web/freenode/ip.31.221.244.234] has joined #bitcoin-core-dev     
15:37 -!- esparragow [1fddf4ea@gateway/web/freenode/ip.31.221.244.234] has quit [Client Quit]     
15:40 -!- Michaela63Kassul [~Michaela6@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 248 seconds]     
15:52 < promag> gmaxwell: "it's a mistake to say "bech32" -- there is no address involved with change"
15:53 < promag> listunspent includes changes right? what will be "address" for change utxo?
15:56 < sipa> yes, bech32
15:56 < gmaxwell> promag: you're missing my point. One can use scripts which no address can be defined.
15:56 < gmaxwell> er s/can be/is/
15:56 < sipa> but if bech32 didn't exist, there would just be no way to show an address for such outputs, but they would have been totally possible to use
15:56 < gmaxwell> And if there were no bech32 defined we still could be using p2wpkh as change.
15:57 < gmaxwell> The fact that there is an address is incidental.
15:57 < gmaxwell> There are also other address encodings for that same script, e.g. BIP142 (though hopefully no one uses them)
15:58 < sipa> for certain types of addresses there even exist no address that can be derived from the output (e.g. ECDH based constructions like stealth addresses or CT)
15:59 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Remote host closed the connection]     
15:59 < sipa> listunspent would just be unable to show an address for such outputs
16:01 < gmaxwell> So you could just as well say that the pr12119 is "use BIP142" ... I wouldn't bother clarifying it, but the fact that there is not a 1:1 relationship between scripts and addresses is pretty important for cases like sipa points out.
16:02 < promag> sipa: do you think fundrawtransaction should have changetype option?
16:02 < gmaxwell> Also things like the payment protocol allow sending funds to a specific script which may not have any address encoding.
16:02 < sipa> promag: i guess it could have, yes
16:03 < gmaxwell> yea, probably should and should work like send to does unless overridden. ... though hopefully people will be moving onto the PSBT workflow sooner rather than later and all the old rawtxn interface can be depricated.
16:03 < promag> folks using just rpc, doing manual signing, can't expect seeing fewer (usable) utxo after upgrading
16:03 -!- logicue [~logicue@p54B5F079.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
16:03 < gmaxwell> hm?     
16:04 < gmaxwell> promag: I don't understand your last comment.
16:05 < promag> suppose someone creates raw transactions with utxos
16:06 < promag> and only uses utxos with "address", because those are the ones the system knows how to sign
16:07 < sipa> promag: that's not true
16:07 < sipa> bitcoin core was able to sign P2WPKH long before an address type for it existed
16:07 < promag> the system != bitcoind
16:07 < gmaxwell> indeed, and native mulsig too.
16:07 < sipa> and pay to pubkey
16:07 < promag> suppose signing is not done with bitcoind
16:08 < sipa> ok     
16:08 < gmaxwell> There should be no need for an address encoding to exist to make a output usable... if there is such a requirement that cropped up, it's a bug.
16:08 < sipa> promag: imagine listunspent just gace the svriptPubKey instead of the address
16:08 < gmaxwell> promag: suppose signing is done by something that doesn't know anything about p2sh-p2wpkh?  it can't sign for that. But so? 
16:08 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit []     
16:09 < gmaxwell> Some things can't sign for some things, but this is unrelated to addresses.
16:09 < promag> so, if there is some fixed decision of change type, then the utxo set is useless for those folks
16:09 < sipa> promag: but the type of change is determined by that signer
16:10 < sipa> no signer would create a type of change it couldn't sign for itself
16:10 < sipa> just like no wallet would crrate an address it can't sig n for
16:10 < sipa> my typing makes me look like an idiot, it should go sleep
16:10 -!- Krellan [~Krellan@2601:640:4000:9258:3085:4055:9d39:915e] has quit [Read error: Connection reset by peer]     
16:11 < promag> ok, so if fundrawtansaction is called with a change address, no change will happen right?
16:11 -!- Krellan [~Krellan@2601:640:4000:9258:3085:4055:9d39:915e] has joined #bitcoin-core-dev     
16:11 < promag> lol me too --- ... , no change to change will happen right?
16:12 < sipa> promag: i'm confused now!
16:12 < gmaxwell> if you've called it with a change address, thats what it would use for change.
16:13 < promag> gmaxwell: right, ok
16:13 < promag> another use case:
16:13 -!- crazyprodigy [uid194503@gateway/web/irccloud.com/x-iynzvmztaplwwjgv] has joined #bitcoin-core-dev     
16:13 < promag> if a user upgrades to 0.16
16:14 < promag> and wants to run a while *but* knows that will go back to 0.15
16:14 < gmaxwell> Release notes will reflect that if you want to be able to downgrade you'll need to set the type to legacy. 
16:14 -!- Berry45Hilll [~Berry45Hi@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
16:14 < gmaxwell> thats part of my rational on the auto-native PR to not override a selection of legacy even if all outputs are segwit.
16:14 < promag> meanwhile wants to send to a bech32, but doesn't want to add 0.16 stuff to his wallet, because he will go back to 0.15. makes sense?
16:15 < gmaxwell> right, I specifically arugued that the auto use of native should not apply if the wallet has been specifically set to use legacy outputs for change for mostly that reason.
16:16 < sipa> the upgrade will be kind of hard to avoid
16:16 -!- CubicEarths [~cubiceart@46.243.136.7] has quit [Read error: Connection reset by peer]     
16:16 < sipa> if you even just send to a bech32, listtransacrions will return bogus addresses after downgrade
16:16 < promag> why?
16:16 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
16:16 < gmaxwell> if you set legacy the only way you'll end up with segwit anything would be either due to manual action or some maniac manually constructing a segwit address for you based on your non-segwit addresses (a suicidal move).
16:16 < sipa> even without evrr creating such an address yourself
16:17 < promag> sipa: but balance will be correct right?
16:17 < sipa> yes     
16:17 < gmaxwell> bogus? hm it just won't show the address. no?
16:17 < gmaxwell> We already have this case from the payment protocol which allows sending to arbritary scripts.
16:17 < sipa> gmaxwell: it will show a very weird invalid address, we've discovered
16:17 < promag> even if the change is bech32 address?
16:17 < sipa> 3Qpvllr or sethong like that
16:18 < sipa> actually, perhaps this os not the case in listtransactions
16:18 < gmaxwell> promag: you haven't given enough details, in a downgrade funds send to segwit outputs may not be there, depending on the exact operations.
16:19 < sipa> generally they will be
16:19 < gmaxwell> not if they downgrade and use a backup.
16:19 < gmaxwell> (for example)
16:19 < sipa> i think pretty much only that
16:19 < gmaxwell> sipa: or salvagewallet
16:19 < sipa> downgrading while restoring a backup
16:19 < gmaxwell> or downgrading in the presence of a reorg perhaps?
16:20 < sipa> no, that should woek
16:20 < sipa> *work
16:20 < gmaxwell> e.g. you downgrade and the txn is removed from the wallet in a reorg but not readded when it confirms?
16:20 < sipa> txn are never removed from the wallet
16:20 < sipa> they just become unconfirmed
16:20 < gmaxwell> ah, point it's just set to unconfir,ed
16:20 < sipa> i guess with abandontx they can be removed
16:21 < sipa> in ver specific cases
16:21 < gmaxwell> In any case, I don't think people should downgrade unless they've been running with legacy mode.
16:21 < gmaxwell> though indeed, it'll kinda work.
16:21 < sipa> yes, i think the downgrade after using segwit/bech32 is a best effort thing
16:21 < sipa> it's very unlikely to lose you money
16:22 < sipa> but RPC output may be weird
16:22  * sipa goes into standby
16:22 < promag> ok guys, thanks for your time
16:23 < gmaxwell> I'm generally not super comfortable with suggesting things that will have funds go missing if you do something reasonable but slightly uncommon like recover from a backup.
16:23 < gmaxwell> The "wallet forgot about my outputs" kind of funds loss is pretty creepy.
16:25 < promag> gmaxwell: btw, do you think seeing the checkbox could be considered an "expert" option?
16:26 < gmaxwell> Hm. I dunno. It's not really a thing that a user could usually hurt themself with.
16:26 < promag> do we want people to randomly check/uncheck like "what does this do?"
16:27 < gmaxwell> E.g. say they select it, get a bech32 addres... recieving site rejects it... then they can try again without it. I guess if they're really confused they might not figure out that they need to turn it off since the site will say "invalid address"...
16:28 < promag> didn't thought of that
16:29 < gmaxwell> best would probably be to have very descriptive help text that says "This will use an address that begins with BC1 instead of 1 and will result in lower transaction fees in the future. BC1 style addresses are not accepted everywhere yet. Turn off this option if the sending party says your address is invalid" or similar. 
16:32 < gmaxwell> hopefully in a year or two we can bury the option to turn off these addresses behind some advanced thing... but I think early on it will need to be accessible because people will need both.
16:39 -!- tknp [~tknp@unaffiliated/tknp] has quit [Quit: tknp]     
16:39 -!- wxss [~user@109.236.91.108] has quit [Quit: leaving]     
16:39 -!- btcdrak [uid234579@gateway/web/irccloud.com/x-hxmbgfssshirkegi] has joined #bitcoin-core-dev     
16:43 -!- instagibbs [~instagibb@100.15.116.35] has quit [Ping timeout: 256 seconds]     
16:50 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Ping timeout: 268 seconds]     
16:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []     
16:55 -!- Berry45Hilll [~Berry45Hi@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
16:58 -!- cysm [cysm@gateway/shell/elitebnc/x-tqzyikhogximxzxl] has quit [Ping timeout: 264 seconds]     
17:00 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
17:02 -!- logicue [~logicue@p54B5F079.dip0.t-ipconnect.de] has quit [Quit: logicue]     
17:04 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 268 seconds]     
17:08 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
17:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
17:15 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
17:15 -!- Allene18Dickinso [~Allene18D@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
17:17 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds]     
17:18 < ossifrage> Has anyone noticed a large uptick in "non-continuous headers sequence" from peers?
17:26 < gmaxwell> ossifrage: idiotic bitcoin gold peers.
17:28 < ossifrage> gmaxwell, ah... it takes a while for them to get banned
17:28 < gmaxwell> I thought btg changed the network magic?
17:29 < gmaxwell> I guess its from people setting that option that lets them sync from bitcoin nodes or something, should probably submit a PR to them to remove that option.
17:29 -!- cysm [cysm@gateway/shell/elitebnc/x-qakvmcbzymrkkojm] has joined #bitcoin-core-dev     
17:29 < ossifrage> It seems to take about 10 'misbehaving's to get them banned
17:30 < ossifrage> but my grep foo may be catching other stuff
17:37 -!- harrymm [~harrymm@104.207.83.58] has quit [Ping timeout: 265 seconds]     
17:43 -!- aj [aj@cerulean.erisian.com.au] has quit [Quit: .]     
17:45 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Read error: Connection reset by peer]     
17:45 -!- aj [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev     
17:46 -!- twistedline [~quassel@unaffiliated/twistedline] has quit [Ping timeout: 252 seconds]     
17:49 < CubicEarths> surprisingly, Bitcoin Gold synced quickly using its own peers
17:50 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev     
17:50 -!- harrymm [~harrymm@104.207.83.18] has joined #bitcoin-core-dev     
17:53 -!- logicue [~logicue@p54B5F079.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
18:00 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
18:01 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
18:06 -!- mgeuirx [409ca7a0@gateway/web/freenode/ip.64.156.167.160] has quit [Ping timeout: 260 seconds]     
18:11 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
18:16 -!- Tennis [~Tennis@unaffiliated/tennis] has quit [Quit: Leaving]     
18:27 -!- Krellan [~Krellan@2601:640:4000:9258:3085:4055:9d39:915e] has quit [Read error: Connection reset by peer]     
18:28 -!- Krellan [~Krellan@2601:640:4000:9258:3085:4055:9d39:915e] has joined #bitcoin-core-dev     
18:33 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
18:35 -!- Chris_St1 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
18:35 -!- Chris_St1 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Client Quit]     
18:36 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 248 seconds]     
18:37 -!- logicue [~logicue@p54B5F079.dip0.t-ipconnect.de] has quit [Quit: logicue]     
18:37 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]     
18:39 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
19:03 -!- flokie_ [~flokie@unaffiliated/flokie] has joined #bitcoin-core-dev     
19:04 -!- Krellan [~Krellan@2601:640:4000:9258:3085:4055:9d39:915e] has quit [Remote host closed the connection]     
19:05 -!- flokie_ [~flokie@unaffiliated/flokie] has quit [Client Quit]     
19:05 -!- flokie_ [~flokie@unaffiliated/flokie] has joined #bitcoin-core-dev     
19:06 -!- flokie [~flokie@unaffiliated/flokie] has quit [Disconnected by services]     
19:06 -!- flokie_ is now known as flokie     
19:10 -!- Krellan [~Krellan@2601:640:4000:9258:38ce:f8f3:715a:fef3] has joined #bitcoin-core-dev     
19:11 -!- Allene18Dickinso [~Allene18D@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 263 seconds]     
19:15 -!- Krellan [~Krellan@2601:640:4000:9258:38ce:f8f3:715a:fef3] has quit [Ping timeout: 252 seconds]     
19:16 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
19:19 -!- Demetrius4Bartol [~Demetrius@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
19:23 -!- hirish is now known as hirishaway     
19:33 -!- Demetrius4Bartol [~Demetrius@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
19:39 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
19:39 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has quit [Quit: .]     
19:41 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has joined #bitcoin-core-dev     
19:45 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
19:45 -!- Krellan [~Krellan@2601:640:4000:9258:38ce:f8f3:715a:fef3] has joined #bitcoin-core-dev     
19:47 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
19:51 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 264 seconds]     
19:56 -!- Krellan [~Krellan@2601:640:4000:9258:38ce:f8f3:715a:fef3] has quit [Ping timeout: 252 seconds]     
20:06 < achow101> how come when I enable libevent debugging I don't see any libevent stuff in the debug.log?
--- Log closed Thu Jan 11 20:11:01 2018
--- Log opened Fri Jan 12 02:31:24 2018
02:31 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #bitcoin-core-dev     
02:31 -!- Irssi: #bitcoin-core-dev: Total of 239 nicks [0 ops, 0 halfops, 0 voices, 239 normal]     
02:32 -!- CubicEarths [~cubiceart@46.243.136.55] has quit []     
02:33 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-sbrvbpjpffmqynup] has quit [Quit: Connection closed for inactivity]     
02:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:35 -!- Giovanni31Medhur [~Giovanni3@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
02:40 -!- Irssi: Join to #bitcoin-core-dev was synced in 527 secs
02:40 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev     
02:52 -!- Giovanni31Medhur [~Giovanni3@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
02:53 -!- indistylo [~indistylo@27.59.105.138] has quit [Ping timeout: 256 seconds]     
02:58 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
02:59 -!- mrannanay [uid222022@gateway/web/irccloud.com/x-udqthfdrkkgjdvfb] has quit [Quit: Connection closed for inactivity]     
03:02 -!- CubicEarths [~cubiceart@46.243.136.55] has joined #bitcoin-core-dev     
03:07 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Read error: Connection reset by peer]     
03:09 -!- indistylo [~indistylo@119.82.105.106] has joined #bitcoin-core-dev     
03:11 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
03:18 -!- hirishaway is now known as hirish     
03:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
03:22 < bitcoin-git> [bitcoin] jsarenik opened pull request #12168: Trivial: Fix #include sys/fcntl.h to just fcntl.h (without sys/) (master...jasan/fcntl.h) https://github.com/bitcoin/bitcoin/pull/12168
03:24 < bitcoin-git> [bitcoin] kekimusmaximus opened pull request #12169: Avoid temporary copies in C++11 ranged-based for loops. (master...remove_loop_implicit_casts) https://github.com/bitcoin/bitcoin/pull/12169
03:24 -!- CubicEar_ [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
03:27 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-mgwwwznlczdxreva] has joined #bitcoin-core-dev     
03:27 -!- CubicEarths [~cubiceart@46.243.136.55] has quit [Ping timeout: 256 seconds]     
03:31 -!- indistylo [~indistylo@119.82.105.106] has quit [Ping timeout: 256 seconds]     
03:32 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
03:38 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev     
03:39 -!- Aisha42Johnson [~Aisha42Jo@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
03:42 < morcos> maaku: It is possible I have been out of the loop.  As you may know a lot has been happening in the last several months.
03:42 < morcos> I though there were several MAST proposals in the works 
03:43 < morcos> I thought based on the amount of traffic that they weren't currently getting anywhere near the developer or community mindshare to be getting near adoption
03:43 < morcos> I'd seen know discussion on whetther there was any consensus to the protocol changes or not
03:44 < morcos> To be honest, I don't know if I have any concerns or objections becuase I haven't looked at it yet.  I'm in favor of the general concept, but I'm not convinced it should be a priority right now
03:45 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]     
03:45 < morcos> It would be one thing if it wasn't a consensus change, but it is, so I think before discussing PR's being ready for Core, it makes sense to discuss whether the community wants this.
03:46 < morcos> That said, having Code is always helpful, and its good for me and others to get the feedback that this is further along than I thought if thats the case
04:04 -!- indistylo [~indistylo@27.59.105.138] has joined #bitcoin-core-dev     
04:09 -!- logicue [~logicue@p54B5F683.dip0.t-ipconnect.de] has quit [Quit: logicue]     
04:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
04:14 -!- Aisha42Johnson [~Aisha42Jo@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 256 seconds]     
04:21 < provoostenator> sipa: I'm a bit confused as to how to interpret scenario 1 in your gist. At least in the test I wrote, if you restore from a backup then any addresses that were generated after that backup would only reappear if you remember the correct sequence of legacy/p2sh-segwit/bech32 choices: https://github.com/bitcoin/bitcoin/pull/12152
04:21 < provoostenator> And funds don't show up for me unless I get that sequence right.
04:21 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
04:21 < sipa> provoostenator: that's a bug!
04:21 < gmaxwell> ?!? what do you mean choices?!
04:22 < provoostenator> sipa: ok, either that or my test is wrong.
04:22 < gmaxwell> they should all appear with you doing nothing but starting the software and waiting for the rescan to complete.
04:22 < sipa> yup     
04:22 < sipa> amd it is totally plausible that it is broken
04:22 < sipa> *and
04:22 < sipa> in which case i'd very much like to know
04:22 < provoostenator> Right, but that's what the "look for related keys" logic is for, right?
04:23 < gmaxwell> I did test this at one point.
04:23 < gmaxwell> though only with native segwit outputs.
04:23 < provoostenator> Maybe it's because my tests use accounts, I don't know how that changes things.
04:24 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 272 seconds]     
04:27 < sipa> provoostenator: the account obviously won't be credited - it can't predict which label you'll give future addresses
04:27 < sipa> but the wallet balance should get uodated
04:30 < provoostenator> I didn't check the total wallet balance, so that might be it then. So after restoring from a backup a user would see random new addresses have funds?
04:31 < sipa> yes     
04:31 < provoostenator> I suppose the only way to prevent that is to disallow address creation before rescan / sync is done.
04:31 < sipa> ?     
04:32 < provoostenator> The wallet would check to see if a key already has funds and then skip it in the new address UI.
04:32 < sipa> i'm very confused :)
04:33 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
04:33 < provoostenator> Right now if you click on new address it will just pick the next key, even the corresponding address has coins on it.
04:33 < sipa> no     
04:33 < sipa> oh... if an address is seen used on the network it is removed from the keypool
04:33 < provoostenator> Which is weird for the user, because they thought they created a fresh address.
04:33 < sipa> so it won't be given out agaon
04:34 < provoostenator> "is seen used" is the operating word then, because in my test it doesn't see it in time.
04:34 < sipa> okay
04:34 < sipa> well there may be a bug!
04:34 < sipa> or maybe you didn't wait for rescan etc
04:34 < provoostenator> I did the rescan after generating the address, yes.
04:34 < sipa> s/rescan/sync/
04:35 < provoostenator> So you're saying if I do a rescan before generating an new address this won't happen?
04:35 < sipa> there shouldn't be a need for rescan
04:36 -!- shesek [~shesek@bzq-84-110-232-125.cablep.bezeqint.net] has joined #bitcoin-core-dev     
04:36 -!- shesek [~shesek@bzq-84-110-232-125.cablep.bezeqint.net] has quit [Changing host]     
04:36 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
04:37 < provoostenator> What happens when you load an outdated wallet backup where new addresses have been added and funded by the user? Does it rescan it?
04:37 < sipa> at startup, if your wallet is older than the chain, the missing part is automatically rescanned
04:38 < provoostenator> In. my test (line 206) I had to do a rescan in order for the balances to show up on generated addresses.
04:39 < provoostenator> Maybe that's because regtest behaves different in this regard and doens't do rescans automatically.
04:40 < provoostenator> The test stops the node, replaces the wallet with an older version, starts the node, generates the same addresses and then calls rescan. That's when the balance shows up for these addresses.
04:40 < provoostenator> Without rescan the address balances remain zero, though I didn't check the wallet balance.
04:40 < provoostenator> I'll try some variations once I understand the intented behavior better.
04:40 -!- blueneon [c5b848f1@gateway/web/freenode/ip.197.184.72.241] has joined #bitcoin-core-dev     
04:40 < sipa> don't look at address balance
04:40 < sipa> look at wallet balance
04:41 < sipa> listtransactions maybreport garbage
04:41 < sipa> listunspent should probably work
04:41 < provoostenator> I'm using getbalance("account name")
04:41 < sipa> ... how could that possibly work?
04:41 < sipa> the backup doesn't know what name you're going to give a future address
04:41 < provoostenator> Which I'm assuming is what QT relies on to show the balance in the receive tab, so it could be pretty confusing (but haven't tested)
04:41 < sipa> no     
04:42 < sipa> that's even a deprecated RPC
04:42 < sipa> the GUI doesn't support accounts, and never has
04:42 < blueneon> Hi there, I've made a fork/clone of the bitcoin coin in order for me to play around and get familiar. All went well after updating chainparams.cpp etc and I created new genesis and merkle etc -the code compiles and runs. However it crashes and debug.log says: ERROR: ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=8)
04:42 < provoostenator> Ah, that points to my confusion between accouts and labels then..
04:42 < blueneon> Any advise would be much appreciated.
04:43 < sipa> blueneon: ##altcoin-dev
04:43 < blueneon> Ok thanks
04:43 < sipa> provoostenator: the only thing you should be looking at is getbalance (without argument), listtransactions, listunspent
04:44 < provoostenator> How is the label that I use in QT when I create a payment reqest represented in the RPC?
04:44 < blueneon> seems ##altcoin-dev is a dead chan :/
04:44 < blueneon> Any chance someone here can shed light on my issue?
04:45 < sipa> blueneon: not here, sorry
04:45 < provoostenator> blueneon: that's not a good way to get familiar with the code in my experience. I somewhat selfishly suggest looking at random bitcoin core github issues and trying to help out in little bits.
04:45 < sipa> provoostenator: labels amd accounts are the same up to that functionality... it's a name associated with an address
04:46 < sipa> provoostenator: but labels don't have a balance
04:46 < sipa> listreceivedbyaddress would also work
04:46 < provoostenator> Ah, so a key has multiple addresses, each address can have a label. Not in the other direction?
04:46 < sipa> but inherently, when recovering fromna backup, the labels won't be there - they can't be
04:46 < gmaxwell> one of the many limitations of labels.
04:47 < sipa> provoostenator: addresses have a label; multiple addresses can have the same label
04:47 < provoostenator> I know the labels wouldn't come back. But when the user creates a payment request that address shouldn't already have money on it. But it seems I didn't actually test that, becaus eI was using accounts.
04:48 < provoostenator> Multiple address (from different keys?) can have identical label strings or do you mean they point to the same label object?
04:48 -!- Toni67Stoltenber [~Toni67Sto@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
04:48 < sipa> provoostenator: what's the difference?
04:48 < provoostenator> The difference is what happens to the label of addres A if I change the label of address B.
04:48 < provoostenator> If they were identical before.
04:48 < sipa> oh, i see
04:49 < sipa> nothing changes to A
04:49 < provoostenator> In other words, what's the SQL schema :-)
04:49 < sipa> addresses have a string lab
04:49 < sipa> el     
04:49 < gmaxwell> same label can be on many addresses (and often is)
04:49 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev     
04:49 < sipa> pro when the user requests a payment it should never give out an address associated with a key that has already been used
04:50 < sipa> *provoostenator
04:51 -!- propumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 268 seconds]     
04:51 < provoostenator> Alright, I'll take another look with that background.
04:51 < provoostenator> How are we doing on actually deprecating accounts?
04:52 < sipa> basically rename the string account label everywhere in the source code
04:52 < sipa> and then removing getbalance(account)
04:52 < sipa> and removing the ability to specify a "from" account
04:52 < sipa> when creating a tx
04:52 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]     
04:53 -!- CubicEar_ [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Remote host closed the connection]     
05:00 -!- mrannanay [uid222022@gateway/web/irccloud.com/x-yuvmmydbgvskqzhw] has joined #bitcoin-core-dev     
05:02 -!- Toni67Stoltenber [~Toni67Sto@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 264 seconds]     
05:02 < sipa> provoostenator: actually, i am pretty interested in knowing what listtransactions shows after recovery
05:03 < provoostenator> sipa: I can take a look later (you should be able to run the backwards compatibilty tests locally in the meantime).
05:05 -!- punch [~punch@8.12.28.87] has joined #bitcoin-core-dev     
05:11 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 252 seconds]     
05:13 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev     
05:18 < provoostenator> sipa: wallet balance immedidately after backup restore: 3 (missing funds and transactions from the post-backup keys)  
05:21 < provoostenator> If I add a rescan to the test, 2 coins and their transactions reappear (not associated with an account).
05:22 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
05:24 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
05:24 < provoostenator> There's a third coin that won't appear until you've called getnewaddress 3 times.
05:25 < sipa> provoostenator: after a confirmation?
05:26 < provoostenator> Yes, these were all confirmed and synced before deleting the wallet and replacing it with a backup.
05:26 < provoostenator> But I'm a bit confused myself now as to what's so special about htat 3rd ps2sh-segwit address.
05:27 < provoostenator> It appears that a rescan revealed the wallet balance for 2 out of 3 keys (p2sh-segwit, bech32, p2sh-segwit), but it took 3 calls to getnewaddress to reveal the third one. Either a bug or more likely something really weird about my test. 
05:28 < provoostenator> Or maybe these transactions are chained in a way that matters.
05:28 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
05:28 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Ping timeout: 252 seconds]     
05:28 < provoostenator> I have a node0 which mines the blocks and sprinkles coins to the test nodes.
05:30 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
05:31 < provoostenator> https://gist.github.com/Sjors/b6ad5ee7a12973ad93edd81e2beff876
05:31 < provoostenator> That's the output of listtransactions at the end. The bottom transaction didn't immedidatley show up.
05:34 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]     
05:34 < provoostenator> Here's the 5 transactions (from a different test run) where I called rescan immedidatley after recovery: https://gist.github.com/Sjors/df8a35ae3481f83546d2ec7518e0ce28  (note that the last two account names aren't know, obviously)
05:35 < provoostenator> I should probably run these with deterministic random seed for easier comparison.
05:37 < sdaftuar> gmaxwell: re #11739 -- thoughts on next steps there?  i was thinking i need to document the change somehow, perhaps an update to the relevant bips and an email to the -dev list?
05:37 < gribble> https://github.com/bitcoin/bitcoin/issues/11739 | RFC: Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis by sdaftuar · Pull Request #11739 · bitcoin/bitcoin · GitHub
05:39 < gmaxwell> sdaftuar: sounds good to me.
05:42 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
05:43 < provoostenator> I should add that these 3 transactions, of which 1 only appears later, are in the same block.
05:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
05:45 -!- Lourdes55Wilkins [~Lourdes55@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
05:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
05:53 -!- blueneon [c5b848f1@gateway/web/freenode/ip.197.184.72.241] has quit [Quit: Page closed]     
05:57 < sipa> provoostenator: cool, i'll loook into it
06:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
06:02 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 252 seconds]     
06:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
06:12 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
06:13 -!- indistylo [~indistylo@27.59.105.138] has quit [Ping timeout: 240 seconds]     
06:16 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 240 seconds]     
06:18 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev     
06:23 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-mgwwwznlczdxreva] has quit [Quit: Connection closed for inactivity]     
06:25 -!- Lourdes55Wilkins [~Lourdes55@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 268 seconds]     
06:32 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
06:50 -!- Jacquelyn14Koss [~Jacquelyn@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
06:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
06:51 -!- alfa [uid11513@gateway/web/irccloud.com/x-gtlfyscovhkkdyrx] has joined #bitcoin-core-dev     
06:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
07:00 -!- Jacquelyn14Koss [~Jacquelyn@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
07:02 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
07:02 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
07:03 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
07:05 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
07:05 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 268 seconds]     
07:19 -!- Sprh [~Sprh@12.20.48.10] has joined #bitcoin-core-dev     
07:21 -!- keks [5b4055c9@gateway/web/freenode/ip.91.64.85.201] has joined #bitcoin-core-dev     
07:22 -!- Sprh [~Sprh@12.20.48.10] has quit [Remote host closed the connection]     
07:26 < larafale> hello guys, any brave soul to help me on this. I'm learning and testing address decoding. I've got a public key (from an electrum wallet) and I'm trying to ripemd160(sha256(pubkey)), but the result I get is not the result I'm expecting. I thought the result was going to be the pubkeyhash present in the scriptpubkey in one of the output where that address was used. Am I missing something ?
07:27 < sipa> larafale: https://bitcoin.stackexchange.com
07:32 -!- maaku [~maaku@173.234.25.100] has left #bitcoin-core-dev ["http://quassel-irc.org - Chat comfortably. Anywhere."]     
07:38 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 255 seconds]     
07:54 -!- Gabrielle5Maggio [~Gabrielle@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
07:54 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
07:55 < Randolf> larafale:  This may also be helpful to you:  https://github.com/bitcoin/libbase58
08:07 -!- Eetsi123 [~Eetsi123@85-76-51-6-nat.elisa-mobile.fi] has joined #bitcoin-core-dev     
08:12 -!- Eetsi123 [~Eetsi123@85-76-51-6-nat.elisa-mobile.fi] has quit [Client Quit]     
08:15 -!- Eetsi123 [~Eetsi123@85-76-51-6-nat.elisa-mobile.fi] has joined #bitcoin-core-dev     
08:16 -!- crazyprodigy [uid194503@gateway/web/irccloud.com/x-khkykcmmbivnajrs] has joined #bitcoin-core-dev     
08:19 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
08:20 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
08:24 -!- Eetsi123 [~Eetsi123@85-76-51-6-nat.elisa-mobile.fi] has quit [Quit: Leaving]     
08:24 -!- Eetsi123 [~Eetsi123@85-76-51-6-nat.elisa-mobile.fi] has joined #bitcoin-core-dev     
08:30 -!- Eetsi123 [~Eetsi123@85-76-51-6-nat.elisa-mobile.fi] has quit [Quit: Leaving]     
08:32 -!- Gabrielle5Maggio [~Gabrielle@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 268 seconds]     
08:37 -!- Eetsi123 [~Eetsi123@2001:999:40:3121:d9fc:8f64:53d9:4498] has joined #bitcoin-core-dev     
08:37 -!- sipa [~pw@2001:19f0:ac01:2fb:5400:ff:fe5b:c3ff] has joined #bitcoin-core-dev     
08:38 -!- mturquette [sid66043@gateway/web/irccloud.com/x-lzjxfplgshvrrhpq] has joined #bitcoin-core-dev     
08:38 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-ephsimkomkbmocbv] has joined #bitcoin-core-dev     
08:38 -!- profall [sid29922@gateway/web/irccloud.com/x-aoxqdpqiuppfvsjv] has joined #bitcoin-core-dev     
08:38 -!- klow [sid213056@gateway/web/irccloud.com/x-krkqcfjnlajyjiep] has joined #bitcoin-core-dev     
08:38 -!- gmaxwell [~gmaxwell@140.211.15.28] has joined #bitcoin-core-dev     
08:38 -!- Eetsi123 [~Eetsi123@2001:999:40:3121:d9fc:8f64:53d9:4498] has quit [Client Quit]     
08:38 -!- gmaxwell [~gmaxwell@140.211.15.28] has quit [Changing host]     
08:38 -!- gmaxwell [~gmaxwell@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev     
08:38 -!- Netsplit over, joins: gijensen, fronti, chjj, thrasher`
08:39 -!- Eetsi123 [~Eetsi123@2001:999:40:3121:d9fc:8f64:53d9:4498] has joined #bitcoin-core-dev     
08:40 -!- kakobrekla [~kako@unaffiliated/kakobrekla] has quit [Ping timeout: 260 seconds]     
08:43 -!- Eetsi123 [~Eetsi123@2001:999:40:3121:d9fc:8f64:53d9:4498] has quit [Client Quit]     
08:46 -!- kakobrekla [~kako@unaffiliated/kakobrekla] has joined #bitcoin-core-dev     
08:47 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
08:48 < SopaXorzTaker> Why does "satoshi" appear in the BIP39 wordlist?
08:48 < SopaXorzTaker> I don't think that's a well-known, unique English word
08:48 < SopaXorzTaker> a tribute to Nakamoto?
08:50 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 248 seconds]     
08:52 < mlz> SopaXorzTaker, wrong channel
08:55 < SopaXorzTaker> mlz, I know, I am sorry
08:55 < SopaXorzTaker> but there's no #ask-bitcoin-devs
08:58 -!- Lyda60Hegmann [~Lyda60Heg@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
09:09 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
09:11 -!- alfa [uid11513@gateway/web/irccloud.com/x-gtlfyscovhkkdyrx] has quit [Quit: Connection closed for inactivity]     
09:13 -!- Lyda60Hegmann [~Lyda60Heg@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 276 seconds]     
09:14 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
09:15 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
09:26 -!- SevenTimes_ [SevenTimes@gateway/vpn/privateinternetaccess/seventimes] has quit [Ping timeout: 248 seconds]     
09:32 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 264 seconds]     
09:32 < jtimon> I'm not sure I understand the point of fDumpMempoolLater ...
09:33 < gmaxwell> jtimon: we don't want to dump the mempool if we haven't finished loading the last dump yet.
09:34 < jtimon> well, that code doesn't seem to be working then, https://github.com/bitcoin/bitcoin/issues/12142 
09:35 -!- arubi_ is now known as arubi     
09:35 < gmaxwell> I think thats just an issue with the rpc, it handles it fine on shutdown as far as I know.
09:36 < jtimon> shouldn't https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L682 just set it to true? why to !fRequestShutdown ?
09:37 < jtimon> no, never minf
09:41 -!- SevenTimes_ [SevenTimes@gateway/vpn/privateinternetaccess/seventimes] has joined #bitcoin-core-dev     
09:51 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
09:55 -!- zautomata [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
09:57 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 264 seconds]     
09:59 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
10:03 -!- Betty82Schaden [~Betty82Sc@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
10:07 -!- d4ve9 [d4ve@gateway/vpn/privateinternetaccess/d4ve] has joined #bitcoin-core-dev     
10:11 -!- d4ve [d4ve@gateway/vpn/privateinternetaccess/d4ve] has quit [Ping timeout: 240 seconds]     
10:15 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 252 seconds]     
10:19 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 272 seconds]     
10:23 -!- Betty82Schaden [~Betty82Sc@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
10:25 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
10:26 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
10:31 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev     
10:34 -!- ludens[m] [ludensturi@gateway/shell/matrix.org/x-cqiavybravnktolp] has joined #bitcoin-core-dev     
10:35 -!- Netsplit over, joins: cfields
10:35 -!- jnewbery [~john@100.38.11.146] has joined #bitcoin-core-dev     
10:38 < provoostenator> Call me superstitious, but Travis seems in a much better mood today.
10:39 -!- dlb76 [~dlb76@unaffiliated/dlb76] has joined #bitcoin-core-dev     
10:45 < BlueMatt> aws disk io more available cause everyone's jobs got slowed down at the cpu level for meltdown fixes? :p
10:46 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
10:47 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds]     
10:48 -!- Chenpan [~Chenpan@unaffiliated/chenpan] has joined #bitcoin-core-dev     
10:48 -!- Chenpan [~Chenpan@unaffiliated/chenpan] has quit [Max SendQ exceeded]     
10:54 -!- Arokh [~Arokh@extknot.com] has joined #bitcoin-core-dev     
10:54 -!- zautomata [~zautomata@unaffiliated/zautomata] has quit [Read error: Connection reset by peer]     
10:56 < cfields> gmaxwell: interesting side-effect from the toolchain work, you may be interested: https://gcc.gnu.org/ml/gcc/2018-01/msg00068.html
10:56 -!- zautomata [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
11:02 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
11:03 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
11:07 -!- Deborah19Pouros [~Deborah19@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
11:11 -!- Deborah19Pouros [~Deborah19@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
11:12 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Remote host closed the connection]     
11:12 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
11:16 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Ping timeout: 240 seconds]     
11:18 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
11:25 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has quit [Quit: Page closed]     
11:27 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:27 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
11:29 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
11:34 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-pejfagogffwwywog] has joined #bitcoin-core-dev     
11:47 -!- Eetsi123 [~Eetsi123@2001:999:40:28bf:946e:8a4f:1a33:e51] has joined #bitcoin-core-dev     
11:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
11:54 -!- Eetsi123 [~Eetsi123@2001:999:40:28bf:946e:8a4f:1a33:e51] has quit [Quit: Leaving]     
11:59 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
12:05 -!- Evel-Knievel [~Evel-Knie@81.82.247.68] has joined #bitcoin-core-dev     
12:05 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
12:10 -!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Read error: Connection reset by peer]     
12:11 -!- Alberto25Runolfs [~Alberto25@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
12:16 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Remote host closed the connection]     
12:17 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
12:19 -!- mrannanay [uid222022@gateway/web/irccloud.com/x-yuvmmydbgvskqzhw] has quit [Quit: Connection closed for inactivity]     
12:19 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Remote host closed the connection]     
12:20 -!- CubicEarths [~cubiceart@46.243.136.48] has joined #bitcoin-core-dev     
12:21 -!- Alberto25Runolfs [~Alberto25@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 264 seconds]     
12:21 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Ping timeout: 240 seconds]     
12:26 -!- JayBerg [~satoshi@50-0-50-4.dsl.dynamic.fusionbroadband.com] has joined #bitcoin-core-dev     
12:26 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
12:26 -!- CubicEar_ [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
12:29 -!- CubicEarths [~cubiceart@46.243.136.48] has quit [Ping timeout: 255 seconds]     
12:31 -!- crazyprodigy [uid194503@gateway/web/irccloud.com/x-khkykcmmbivnajrs] has quit [Quit: Connection closed for inactivity]     
12:37 -!- JayBerg [~satoshi@50-0-50-4.dsl.dynamic.fusionbroadband.com] has quit [Quit: JayBerg]     
12:39 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
12:41 -!- dx25 [~dx25@67-3-130-119.omah.qwest.net] has quit [Remote host closed the connection]     
12:41 -!- wtabata [~wtabata@179.235.79.229] has quit [Ping timeout: 248 seconds]     
12:41 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
12:49 -!- dx25 [~dx25@67-3-130-119.omah.qwest.net] has joined #bitcoin-core-dev     
12:56 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-ikrjyvakvdkeunlq] has joined #bitcoin-core-dev     
12:58 -!- anome [~anome@unaffiliated/anome] has quit []     
12:58 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
12:58 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
13:01 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:01 < bitcoin-git> [bitcoin] jtimon opened pull request #12172: Bugfix: RPC: savemempool: Don't save until LoadMempool() is finished (master...b16-bugfix-savemempool) https://github.com/bitcoin/bitcoin/pull/12172
13:03 < jtimon> being a bugfix, could #12172 get in for 0.16 ?
13:03 < gribble> https://github.com/bitcoin/bitcoin/issues/12172 | Bugfix: RPC: savemempool: Dont save until LoadMempool() is finished by jtimon · Pull Request #12172 · bitcoin/bitcoin · GitHub
13:06 < jtimon> btw, gmaxwell previously I was wondering if I could reuse fDumpMempoolLater instead of creating g_is_mempool_loaded, thanks for the help
13:07 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
13:10 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
13:15 -!- Taya60Johnston [~Taya60Joh@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
13:20 -!- Taya60Johnston [~Taya60Joh@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 255 seconds]     
13:23 -!- btcdrak [uid234579@gateway/web/irccloud.com/x-xvrewxlmapqblogm] has joined #bitcoin-core-dev     
13:30 -!- zautomata [~zautomata@unaffiliated/zautomata] has quit [Read error: Connection reset by peer]     
13:31 < luke-jr> jtimon: IMO savemempool shouldn't succeed until it is actually saved, so if you make it delay the save, the RPC probably needs to block, which is complex
13:31 -!- JayBerg [~satoshi@64.201.243.34] has joined #bitcoin-core-dev     
13:32 -!- zautomata [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
13:32 < jtimon> luke-jr: yeah, that's an interesting point but kind of orthogonal, no? (although definitely related)
13:35 -!- zautomata [~zautomata@unaffiliated/zautomata] has quit [Read error: Connection reset by peer]     
13:35 < jtimon> luke-jr: perhaps I can add something to the documentation while at it?
13:36 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #12173: [Qt] Use flexible font size for QRCode image address (master...2018/01/fix_qr_font) https://github.com/bitcoin/bitcoin/pull/12173
13:37 -!- zautomata [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
13:40 < jonasschnelli> sipa: mind doing a short review on #11281 (since you have raised some issues there)?
13:40 < gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
13:42 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
13:43 -!- zautomata [~zautomata@unaffiliated/zautomata] has quit [Read error: Connection reset by peer]     
13:44 -!- zautomata [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
13:49 -!- hirish is now known as hirishaway     
14:21 -!- Jared [3264b0aa@gateway/web/freenode/ip.50.100.176.170] has joined #bitcoin-core-dev     
14:21 -!- Leila75Marquardt [~Leila75Ma@5.196.64.92] has joined #bitcoin-core-dev     
14:23 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-pejfagogffwwywog] has quit [Quit: Connection closed for inactivity]     
14:26 -!- Jared [3264b0aa@gateway/web/freenode/ip.50.100.176.170] has quit [Ping timeout: 260 seconds]     
14:26 -!- Jared [3264b0aa@gateway/web/freenode/ip.50.100.176.170] has joined #bitcoin-core-dev     
14:28 < bitcoin-git> [bitcoin] MarcoFalke pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/0910cbe4ef31...b7450cdbd89a
14:28 < bitcoin-git> bitcoin/master fcfb952 Russell Yanofsky: Improve TestNodeCLI output parsing...
14:28 < bitcoin-git> bitcoin/master ca9085a Russell Yanofsky: Prevent TestNodeCLI.args mixups...
14:28 < bitcoin-git> bitcoin/master ff9a363 Russell Yanofsky: TestNodeCLI batch emulation...
14:29 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #11970: Add test coverage for bitcoin-cli multiwallet calls (master...pr/mcli) https://github.com/bitcoin/bitcoin/pull/11970
14:33 -!- LordHummus [3264b0aa@gateway/web/freenode/ip.50.100.176.170] has joined #bitcoin-core-dev     
14:34 -!- Jared [3264b0aa@gateway/web/freenode/ip.50.100.176.170] has quit [Ping timeout: 260 seconds]     
14:35 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has quit [Remote host closed the connection]     
14:36 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
14:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
14:50 -!- Dmoney [a0650005@gateway/web/freenode/ip.160.101.0.5] has joined #bitcoin-core-dev     
14:56 -!- LordHummus [3264b0aa@gateway/web/freenode/ip.50.100.176.170] has quit [Ping timeout: 260 seconds]     
15:04 -!- clarkmoody_ [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [Quit: Leaving]     
15:05 < bitcoin-git> [bitcoin] MarcoFalke reopened pull request #12089: qa: Make TestNodeCLI command optional in send_cli (master...Mf1801-qaCliOptions) https://github.com/bitcoin/bitcoin/pull/12089
15:10 -!- zautomata1 [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
15:10 -!- cheese_ [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
15:10 -!- cheese_ [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Client Quit]     
15:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
15:11 -!- zautomata [~zautomata@unaffiliated/zautomata] has quit [Ping timeout: 256 seconds]     
15:11 -!- berndj [~berndj@mail.azna.co.za] has quit [Quit: ZNC - http://znc.in]     
15:13 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev     
15:20 -!- tknp [~tknp@unaffiliated/tknp] has joined #bitcoin-core-dev     
15:22 -!- Leila75Marquardt [~Leila75Ma@5.196.64.92] has quit [Ping timeout: 256 seconds]     
15:26 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
15:26 -!- Llewellyn69Schme [~Llewellyn@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
15:27 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
15:33 -!- JayBerg [~satoshi@64.201.243.34] has quit [Quit: JayBerg]     
15:35 -!- JayBerg [~satoshi@64.201.243.34] has joined #bitcoin-core-dev     
15:35 -!- btcdrak [uid234579@gateway/web/irccloud.com/x-xvrewxlmapqblogm] has quit [Quit: Connection closed for inactivity]     
15:38 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
15:38 -!- Llewellyn69Schme [~Llewellyn@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 276 seconds]     
15:46 -!- hirishaway is now known as hirish     
15:54 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
15:54 -!- marsadm [~marsadm@172.86.120.144] has quit [Read error: Connection reset by peer]     
15:54 -!- rfree_irc [~rfree_irc@172.86.120.144] has quit [Read error: Connection reset by peer]     
15:56 -!- d4ve9 [d4ve@gateway/vpn/privateinternetaccess/d4ve] has quit [Read error: Connection reset by peer]     
15:56 -!- d4ve9 [d4ve@gateway/vpn/privateinternetaccess/d4ve] has joined #bitcoin-core-dev     
16:07 -!- Dmoney [a0650005@gateway/web/freenode/ip.160.101.0.5] has quit [Quit: Page closed]     
16:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
16:19 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 256 seconds]     
16:24 -!- keks [5b4055c9@gateway/web/freenode/ip.91.64.85.201] has quit [Ping timeout: 260 seconds]     
16:28 -!- harrymm [~harrymm@104.207.83.18] has quit [Ping timeout: 265 seconds]     
16:31 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
16:31 -!- Kraig60Wiegand [~Kraig60Wi@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
16:41 -!- harrymm [~harrymm@104.207.83.38] has joined #bitcoin-core-dev     
16:55 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 256 seconds]     
16:58 -!- Tennis [~Tennis@unaffiliated/tennis] has joined #bitcoin-core-dev     
16:58 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
16:59 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
17:04 -!- JayBerg [~satoshi@64.201.243.34] has quit [Quit: JayBerg]     
17:06 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
17:29 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Remote host closed the connection]     
17:49 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 260 seconds]     
18:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
18:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
18:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
18:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
18:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
18:13 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
18:27 -!- Randolf [~randolf@24.244.32.253] has joined #bitcoin-core-dev     
18:34 -!- Randolf [~randolf@24.244.32.253] has quit [Ping timeout: 248 seconds]     
18:49 -!- Krellan [~Krellan@c-73-223-240-52.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]     
18:49 -!- rfree_irc [~rfree_irc@172.86.120.144] has joined #bitcoin-core-dev     
18:50 -!- marsadm [~marsadm@172.86.120.144] has joined #bitcoin-core-dev     
18:58 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
18:59 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
19:00 -!- Tennis [~Tennis@unaffiliated/tennis] has quit [Quit: Leaving]     
19:00 -!- smack [42de9351@gateway/web/freenode/ip.66.222.147.81] has joined #bitcoin-core-dev     
19:01 < smack> ma     
19:01 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has quit [Quit: .]     
19:01 < smack> man     
19:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
19:01 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
19:01 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has joined #bitcoin-core-dev     
19:02 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has quit [Client Quit]     
19:04 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has joined #bitcoin-core-dev     
19:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]     
19:14 -!- Kraig60Wiegand [~Kraig60Wi@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 256 seconds]     
19:17 -!- tknp [~tknp@unaffiliated/tknp] has quit [Quit: tknp]     
19:23 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
19:25 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
19:34 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
19:40 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has quit [Read error: Connection reset by peer]     
19:41 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has quit [Quit: JayBerg]     
19:41 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
19:42 < smack> such wow
19:42 -!- smack [42de9351@gateway/web/freenode/ip.66.222.147.81] has quit [Quit: Page closed]     
19:46 -!- Krellan [~Krellan@2601:640:4000:9258:dcfc:c909:c3dc:cdf8] has joined #bitcoin-core-dev     
19:47 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has quit [Read error: Connection reset by peer]     
19:48 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
19:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
19:55 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has quit [Read error: Connection reset by peer]     
19:56 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
20:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]     
20:02 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has quit [Read error: Connection reset by peer]     
20:02 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
20:16 -!- TheRec [~toto@84-75-205-212.dclient.hispeed.ch] has joined #bitcoin-core-dev     
20:16 -!- TheRec [~toto@84-75-205-212.dclient.hispeed.ch] has quit [Changing host]     
20:16 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev     
20:18 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
20:22 -!- booyah_ [~bb@193.25.1.157] has joined #bitcoin-core-dev     
20:24 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]     
20:26 -!- TheRec [~toto@drupal.org/user/146860/view] has quit []     
20:26 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev     
20:28 -!- harrymm [~harrymm@104.207.83.38] has quit []     
20:32 -!- harrymm [~harrymm@104.207.83.32] has joined #bitcoin-core-dev     
20:37 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
20:38 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]     
20:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
20:51 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 256 seconds]     
20:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
20:56 -!- Dagmar75Thompson [~Dagmar75T@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
21:07 -!- twistedline [~quassel@unaffiliated/twistedline] has joined #bitcoin-core-dev     
21:14 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
21:17 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
21:18 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
21:20 -!- mrsc_ [~bantry@96-37-241-230.dhcp.leds.al.charter.com] has quit [Read error: Connection reset by peer]     
21:23 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
21:42 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
21:42 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 272 seconds]     
21:43 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
21:50 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
21:51 -!- Krellan [~Krellan@2601:640:4000:9258:dcfc:c909:c3dc:cdf8] has quit [Read error: Connection reset by peer]     
21:52 -!- Krellan [~Krellan@2601:640:4000:9258:dcfc:c909:c3dc:cdf8] has joined #bitcoin-core-dev     
21:59 -!- mrannanay [uid222022@gateway/web/irccloud.com/x-umvkjsnriafdrdbf] has joined #bitcoin-core-dev     
22:13 -!- indistylo [~indistylo@27.59.44.204] has joined #bitcoin-core-dev     
22:17 -!- indistylo [~indistylo@27.59.44.204] has quit [Max SendQ exceeded]     
22:17 -!- indistylo [~indistylo@27.59.44.204] has joined #bitcoin-core-dev     
22:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
22:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]     
22:49 -!- JayBerg [~satoshi@c-24-4-144-11.hsd1.ca.comcast.net] has quit [Quit: JayBerg]     
22:59 -!- indistylo [~indistylo@27.59.44.204] has quit [Ping timeout: 256 seconds]     
23:09 -!- Megumiin [~Megumiin@unaffiliated/megumiin] has joined #bitcoin-core-dev     
23:16 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
23:17 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
23:35 -!- indistylo [~indistylo@27.59.44.204] has joined #bitcoin-core-dev     
23:51 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
23:57 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Read error: Connection reset by peer]