--- Day changed Thu Mar 09 2017
00:04 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
00:08 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]     
00:08 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:09 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
00:10 -!- veleiro [~sleeper@fsf/member/veleiro] has quit [Ping timeout: 246 seconds]     
00:33 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]     
00:33 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
00:33 -!- Victor_sueca is now known as Victorsueca     
00:44 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
00:48 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds]     
00:51 -!- juscamarena [~justin@47.148.176.74] has quit [Remote host closed the connection]     
00:52 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev     
01:01 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8152d3fe57a9...6805c4112cfd
01:01 < bitcoin-git> bitcoin/master 54fae05 practicalswift: Remove unreachable code (g_rpcSignals.PostCommand)
01:01 < bitcoin-git> bitcoin/master 6805c41 Wladimir J. van der Laan: Merge #9575: Remove unused, non-working RPC PostCommand signal...
01:01 < bitcoin-git> [bitcoin] laanwj closed pull request #9575: Remove unused, non-working RPC PostCommand signal (master...never-executed-comment) https://github.com/bitcoin/bitcoin/pull/9575
01:02 < bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/6805c4112cfd...02bd6e9bc6de
01:02 < bitcoin-git> bitcoin/master 6d07c62 John Newbery: Return correct error codes in bumpfee()....
01:02 < bitcoin-git> bitcoin/master c119096 John Newbery: Return correct error codes in blockchain.cpp....
01:02 < bitcoin-git> bitcoin/master 960bc7f John Newbery: Return correct error codes in removeprunedfunds()....
01:03 < bitcoin-git> [bitcoin] laanwj closed pull request #9853: Fix error codes from various RPCs (master...fixerrorcodes) https://github.com/bitcoin/bitcoin/pull/9853
01:03 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/02bd6e9bc6de...b403ec5c0f2f
01:03 < bitcoin-git> bitcoin/master 292112f kobake: Fix msvc compiler error C4146 (minus operator applied to unsigned type)...
01:03 < bitcoin-git> bitcoin/master 8e0720b kobake: Fix msvc compiler error C4146 (unary minus operator applied to unsigned type)...
01:03 < bitcoin-git> bitcoin/master b403ec5 Wladimir J. van der Laan: Merge #9916: Fix msvc compiler error C4146 (minus operator applied to unsigned type)...
01:03 < bitcoin-git> [bitcoin] laanwj closed pull request #9916: Fix msvc compiler error C4146 (minus operator applied to unsigned type) (master...fix-minus-operator-target-for-msvc-c4146) https://github.com/bitcoin/bitcoin/pull/9916
01:06 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]     
01:07 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
01:12 -!- pavel_ [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
01:15 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 240 seconds]     
01:15 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
01:19 -!- dodomojo [~goksinen@2604:2000:c591:8400:9c4d:d166:d15e:f362] has joined #bitcoin-core-dev     
01:19 < bitcoin-git> [bitcoin] practicalswift opened pull request #9962: [trival] Fix typo introduced into rpc/protocol.h in commit 338bf06 (master...fix-typo-in-protocol-h) https://github.com/bitcoin/bitcoin/pull/9962
01:22 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
01:22 -!- whphhg [whphhg@gateway/vpn/mullvad/x-xiezqomlwcbqhrdi] has quit [Ping timeout: 256 seconds]     
01:23 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Ping timeout: 255 seconds]     
01:23 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]     
01:23 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
01:24 -!- dodomojo [~goksinen@2604:2000:c591:8400:9c4d:d166:d15e:f362] has quit [Ping timeout: 246 seconds]     
01:25 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]     
01:25 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
01:27 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b403ec5c0f2f...c71f0ca5f839
01:27 < bitcoin-git> bitcoin/master 3cef950 NicolasDorier: Trivial: Add const modifier to GetHDChain and IsHDEnabled
01:27 < bitcoin-git> bitcoin/master c71f0ca Wladimir J. van der Laan: Merge #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled...
01:28 < bitcoin-git> [bitcoin] laanwj closed pull request #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled (master...consthd) https://github.com/bitcoin/bitcoin/pull/9960
01:31 -!- pavel_ [~paveljani@79.98.72.176] has quit [Quit: Leaving]     
01:33 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c71f0ca5f839...e3e7db829ecd
01:33 < bitcoin-git> bitcoin/master 53a2ba3 practicalswift: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr)
01:33 < bitcoin-git> bitcoin/master e3e7db8 Wladimir J. van der Laan: Merge #9538: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr)...
01:34 < bitcoin-git> [bitcoin] laanwj closed pull request #9538: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr) (master...remove-redundant-get-on-smartptr) https://github.com/bitcoin/bitcoin/pull/9538
01:41 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
01:47 -!- whphhg [whphhg@gateway/vpn/mullvad/x-anvfdhjuwanpcuqd] has joined #bitcoin-core-dev     
01:48 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
01:57 -!- whphhg [whphhg@gateway/vpn/mullvad/x-anvfdhjuwanpcuqd] has quit [Quit: Leaving]     
02:03 -!- JackH [~laptop@79-73-184-8.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
02:14 -!- whphhg [whphhg@gateway/vpn/mullvad/x-oilwcxfnpxuuowqg] has joined #bitcoin-core-dev     
02:36 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev     
02:39 -!- BirneGetreide_ [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev     
02:40 -!- MarcoFalke [~none@198.12.116.246] has left #bitcoin-core-dev []     
02:42 < bitcoin-git> [bitcoin] laanwj opened pull request #9963: util: Properly handle errors during log message formatting (master...2017_03_handle_exception_tinyformat) https://github.com/bitcoin/bitcoin/pull/9963
02:44 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
02:47 -!- BirneGetreide_ [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]     
02:48 -!- BirneGetreide_ [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev     
02:49 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds]     
02:49 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev     
02:51 -!- BirneGetreide_ [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Client Quit]     
02:57 -!- chris200_ [~chris2000@p5DCB4EF0.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
03:01 -!- chris2000 [~chris2000@p5DCB4EF0.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]     
03:02 < jonasschnelli> I still try to understand why importing a P2PKH address into the wallet leads to ISMINE_WATCH_UNSOLVABLE (and not ISMINE_WATCH_SOLVABLE).
03:02 < jonasschnelli> The comment for ISMINE_WATCH_SOLVABLE says: "Indicates that we know how to create a scriptSig that would solve this if we were given the appropriate private keys"
03:03 < jonasschnelli> Isn't this true for P2PKH (== importaddress could identify P2PKH)?
03:06 < luke-jr> I suspect the requirement of the public key might play a part
03:06 < luke-jr> you could calculate it from the private key, but that may not count
03:08 -!- dodomojo [~goksinen@2604:2000:c591:8400:9c4d:d166:d15e:f362] has joined #bitcoin-core-dev     
03:08 -!- chris200_ [~chris2000@p5DCB4EF0.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
03:09 -!- chris2000 [~chris2000@p5DCB4EF0.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
03:12 -!- dodomojo [~goksinen@2604:2000:c591:8400:9c4d:d166:d15e:f362] has quit [Ping timeout: 246 seconds]     
03:13 < jonasschnelli> luke-jr: Yes. When I import a pubkey it will marke the P2PKH watch-only as solveble.
03:13 < jonasschnelli> But I don't see a clear reason for that. I understand that for P2SH but not for P2PKH... 
03:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:19 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
03:34 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e3e7db829ecd...5703dff0939f
03:34 < bitcoin-git> bitcoin/master 9ea2490 practicalswift: [trival] Fix typo introduced into rpc/protocol.h in commit 338bf06...
03:34 < bitcoin-git> bitcoin/master 5703dff MarcoFalke: Merge #9962: [trivial] Fix typo in rpc/protocol.h...
03:35 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9962: [trivial] Fix typo in rpc/protocol.h (master...fix-typo-in-protocol-h) https://github.com/bitcoin/bitcoin/pull/9962
04:01 < wumpus> I just had the wallet RPC test pass... on a leveldb-based wallet on top of #9951. It's a bit of a hack right now but hopefully enough to be able to run all the RPC tests against the cloudabi bitcoind at some point.
04:01 < gribble> https://github.com/bitcoin/bitcoin/issues/9951 | Wallet database handling abstractions/simplifications by laanwj · Pull Request #9951 · bitcoin/bitcoin · GitHub
04:02 -!- dodomojo [~goksinen@2604:2000:c591:8400:9c4d:d166:d15e:f362] has joined #bitcoin-core-dev     
04:06 -!- dodomojo [~goksinen@2604:2000:c591:8400:9c4d:d166:d15e:f362] has quit [Ping timeout: 246 seconds]     
04:45 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
04:47 < bitcoin-git> [bitcoin] practicalswift opened pull request #9964: Add const to methods that do not modify the object for which it is called (master...const) https://github.com/bitcoin/bitcoin/pull/9964
04:50 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds]     
05:01 -!- adiabat [~adiabat@67.205.158.84] has quit [Ping timeout: 260 seconds]     
05:17 < wumpus> shouldn't we at least be logging a warning if pwallet->GetKey() returns false in https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcdump.cpp#L639?  Or are there legitimate reasons why this could happen?
05:18 < wumpus> seems that a dump may be incomplete if it could not find all keys
05:27 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
05:30 < wumpus> (not that I've ever seen an instance of that problem, but I just wonder that seeing the code)
05:46 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.7]     
05:46 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
05:50 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
05:50 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev     
05:54 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 256 seconds]     
06:00 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9965: Allow to use unsolveable P2PKH watch-only in fundrawtransaction (master...2017/03/watch_solve) https://github.com/bitcoin/bitcoin/pull/9965
06:27 -!- bityogi [~textual@208-104-132-26.brvd.dsl.dyn.comporium.net] has joined #bitcoin-core-dev     
06:44 -!- dodomojo [~goksinen@2604:2000:c591:8400:11a:7ed7:29:e4d8] has joined #bitcoin-core-dev     
06:46 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
06:48 -!- dodomojo [~goksinen@2604:2000:c591:8400:11a:7ed7:29:e4d8] has quit [Ping timeout: 246 seconds]     
06:51 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds]     
06:54 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
07:03 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds]     
07:04 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
07:11 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
07:23 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev     
07:38 -!- dodomojo [~goksinen@2604:2000:c591:8400:11a:7ed7:29:e4d8] has joined #bitcoin-core-dev     
07:42 -!- dodomojo [~goksinen@2604:2000:c591:8400:11a:7ed7:29:e4d8] has quit [Ping timeout: 246 seconds]     
07:54 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev     
07:59 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
07:59 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Read error: Connection reset by peer]     
08:07 -!- veleiro [~sleeper@67.202.71.188] has joined #bitcoin-core-dev     
08:32 -!- dodomojo [~goksinen@2604:2000:c591:8400:11a:7ed7:29:e4d8] has joined #bitcoin-core-dev     
08:36 -!- dodomojo [~goksinen@2604:2000:c591:8400:11a:7ed7:29:e4d8] has quit [Ping timeout: 246 seconds]     
08:38 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has quit []     
08:38 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
08:49 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:09 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
09:28 -!- CubicEarth [~cubiceart@190.140.57.211] has joined #bitcoin-core-dev     
09:32 -!- adiabat [~adiabat@67.205.158.84] has joined #bitcoin-core-dev     
09:46 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:49 -!- voyager_ [~voyager@ip68-13-242-116.ok.ok.cox.net] has quit [Ping timeout: 268 seconds]     
09:58 -!- CubicEarth [~cubiceart@190.140.57.211] has quit [Remote host closed the connection]     
10:04 -!- CubicEarth [~cubiceart@190.140.57.211] has joined #bitcoin-core-dev     
10:08 -!- voyager_ [~voyager@ip68-13-242-116.ok.ok.cox.net] has joined #bitcoin-core-dev     
10:35 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
10:37 -!- veleiro [~sleeper@67.202.71.188] has quit [Remote host closed the connection]     
10:37 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
10:44 -!- CubicEarth [~cubiceart@190.140.57.211] has quit [Remote host closed the connection]     
11:00 < sipa> ploink
11:00 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
11:00 < wumpus> #startmeeting
11:00 < lightningbot> Meeting started Thu Mar  9 19:00:43 2017 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 < jonasschnelli> hi     
11:01 < sipa> short topic: great work on 0.14 all!
11:01 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt 
11:01 < wumpus> instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
11:01 < wumpus> yes! congrats all on another great release
11:01 < btcdrak> +1     
11:02  * BlueMatt has seen really great results for miners that have upgraded to 0.14 =D
11:02 < morcos> yes i feel like we did a good job getting most of the major things we wanted into it!
11:02 < BlueMatt> net seems to have really helped a lot
11:02 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
11:02 < achow101> hi     
11:03 < wumpus> proposed topic: disclosure of alert key (https://github.com/bitcoin-dot-org/bitcoin.org/pull/1534 reminded me)
11:03 < gmaxwell> Hi.     
11:03 < gmaxwell> There are DOS vulnerablities in older verions that the final alert does not block. :(
11:03 < wumpus> #topic alert key disclosure timeline
11:04 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
11:04 < sipa> gmaxwell: below what version?
11:04 < gmaxwell> (unfortunately the old code is stupid)
11:04 < achow101> what kind of DOS vulns?
11:04 < gmaxwell> All versions. They're worse in older ones.
11:04 < gmaxwell> (obviously all versions with alerts enabled)
11:04 < sipa> when was that changed?
11:04 < wumpus> yes, what kind? just a slowdown, or a crash, or potential remote code execution?
11:05 < sipa> OOM     
11:05 < gmaxwell> No RCE, just OOM.
11:05 < btcdrak> so versions <0.12.0 affected?
11:05 < wumpus> well. some versions have already been marked as "insecure" on bitcoin.org due to other bugs. Let me see what the threshold is.
11:06 < sipa> when was the alert feature disabled by default?
11:06 < achow101> 0.12.1
11:06 < btcdrak> oh     
11:06 < BlueMatt> wumpus: we have a list somewhere?
11:06 < sipa> are there any major altcoins forked before 0.12 that did not change the alaert key?
11:07 < wumpus> https://bitcoin.org/bin/insecure/
11:07 < gmaxwell> All the 0.14 nodes sending final alerts constantly is somewhat protective, but unforuntately not absoltely protective.
11:07 < gmaxwell> sipa: already looked for that, there were no major ones, but some obscure & dead ones that have been nagged.
11:07 < gmaxwell> There are also funds paid to the alert key in the network, I believe 0.01 BTC or so. :P
11:08 < wumpus> heheh
11:08 < cfields> heh     
11:08 < gmaxwell> in any case, one possibility would be to not worry too much about it, announce again that version <0.12.1 are vulnerable (there is a lot else they're vulnerable too, I think). 
11:08 < wumpus> surprised no one ever swiped that
11:08 < btcdrak> sipa: most altcoins are on <0.12 codebase, and many never changed the alter key
11:08 < gmaxwell> btcdrak: not so.
11:09 < wumpus> from what I've seen, altcoins generally do change the alert key, at least from the bitcoin one
11:09 < gmaxwell> btcdrak: (didn't change the _litecoin_ alert key, yes, but I searched extensively for this already, months ago.)
11:09 < wumpus> many have the litecoin or feathercoin key
11:09 < wumpus> yes :)
11:09 < sipa> ah     
11:09 < btcdrak> ah yes, most coins forked from litecoin (and didnt change the network magic either)
11:09 < morcos> remind me again what the advantage is of disclosing the key?
11:10 < achow101> morcos: making the alert system entirely unreliable (as if it weren't already)
11:10 < gmaxwell> to not be responsible for someone else abusing it, among other things.
11:10 < gmaxwell> we don't believe the key is actually secure right now in any case.
11:10 < sipa> there is no hurry in disclosing it either
11:11 < sipa> just a nice to have to close that chapter
11:11 < wumpus> to force people to not use it anymore
11:11 < btcdrak> they key is useless now anyway that final alert is out.
11:11 < wumpus> and also for sake of history
11:11 < paveljanik> We can make people upgrade because of the planned alert key discolsure...
11:11 < luke-jr> not sure how litecoin alerts are affects if they use a different key
11:11 < gmaxwell> we can't make anyone upgrade, and even if we could we wouldn't. :)
11:11 < morcos> yes but if there is even nuisance harm that can be done with it.. i think we should announce that its not considred secure but that we're not going to aid people doing nuisance with it by publicly disclosing it until a) we see nuisance or b) some predetermine future point
11:11 < wumpus> litecoin is not affected luke-jr - what they do is up to them
11:12 < btcdrak> wumpus: they also removed the alert system, but there's a lot on 0.10.x nodes in litecoin
11:12 < gmaxwell> morcos: well we're at the predetermined future point now, we announced.. 6 months ago we'd do this after 0.14. The issue there is on careful review of the old code I found several DOS vulnerablities.
11:12 < wumpus> yes, this was announced on a timeline
11:12 < morcos> right, so change the predetermined point to be further out...  the risk is only that someone blames us for nuisance right?
11:13 < achow101> maybe just push back the date even further until <0.12.1 nodes are even fewer?
11:13 < BlueMatt> yea, I would vote push another release given old 0.12.0 isnt otherwise insecure?
11:13 < wumpus> right, if anyone abuses the key now, they may blame us. If it is public knowledge not so much.
11:13 < gmaxwell> It's fine with me, we should emphasize that those older versions are insecure.  If someone dosses them later it's not the end of the world.
11:13 < morcos> Except of course we will be blamed if we make it public and someone creates nuisance with it!
11:14 < gmaxwell> BlueMatt: I believe it is otherwise insecure at a greater magnitude than the alert DOS attacks.
11:14 < paveljanik> gmaxwell, yes, and by emphasizing it, maybe people update...
11:14 < gmaxwell> Well anything that has alerts is displaying the hardcoded final alert now...
11:14 < achow101> what version did BU remove the alert system? If it is in their 0.12.1, people could dos them, and I don't think they would take kindly to that (drama and FUD and all that)
11:14 < btcdrak> so let's announce the vulnerability first that should motivate more people to upgrade old systems or disable the alert system.
11:14 < gmaxwell> which says something like (allcaps) warning alert key compromised! upgrade required!.
11:14 < jtimon> ACK "<sipa> there is no hurry in disclosing it either"
11:15 < luke-jr> gmaxwell: can you get a CVE assigned for one or more of the old DoS?
11:15 < gmaxwell> I think some of you are underestimating the cost of this thing... but sure, no rush required.
11:15 < wumpus> anyhow, everyone with the alert key could disclose it, even anonymously
11:16 < wumpus> don't even know who has it exactly so...
11:16 < luke-jr> yes, nobody can be blamed individually if nobody knows who disclosed it
11:16 < wumpus> anyhow, any other topics?
11:17 < luke-jr> FWIW, ignoring alert keys, I see 539 vulnerable nodes (0.94%)
11:17 < gmaxwell> Can we get a clear plan of action here? We'll CVE old versions and remind people these old things are insecure? should we review other fixes and determine if we want to set a higher bar for holy-shit-dont-run-that than 0.12.1? 
11:18 < luke-jr> updating http://luke.dashjr.org/programs/bitcoin/files/charts/security.html to consider <0.12.1 vulnerable, that goes to 2606 vulnerable nodes (4.54%)
11:18 < wumpus> you can't be entirely sure that all of them are vulnerable, they may have patched the code to remove the alert system
11:18 < luke-jr> sure, but that's unlikely
11:18 < gmaxwell> I think 5% dropping offline would be inconsequential, so avoiding the dos is just a politeness to the users to avoid disrupting other things they may have going on.
11:19 < wumpus> many are running old versions to be able to run their own (outdated) patches on top
11:19 < achow101> gmaxwell: how about CVE the dos vulns you found, post messages an all forums about vulnerable nodes, and then release the key a few weeks later?
11:19 < luke-jr> if we're really worried, we could release a 0.12.2 with just those exploits fixed
11:19 < luke-jr> or maybe simply disabling alerts
11:19 < gmaxwell> luke-jr: 0.12.1 has them disabled.
11:19 < achow101> luke-jr: 0.12.1 already disabled alrets
11:19 < morcos> if it was me, i wouldn't do any of it...  lets put our effort where it matters.. 0.15
11:19 < luke-jr> oh, duh
11:20 < luke-jr> so why wouldn't people held back by patches just rebase?
11:20 < luke-jr> to 0.12.1
11:20 < wumpus> 0.12.0 can easily upgrad to 0.12.1, 0.11.x maybe less so
11:20 < btcdrak> considering there's an alert message broadcasting to all those vulnerable nodes right now saying they should upgrade, I think we've probably done enough.
11:20 < wumpus> not going to do a new 0.11.x release though
11:21 < luke-jr> get and publish a CVE, then 2 weeks later publish the key
11:21 < luke-jr> ?     
11:22 < wumpus> I guess we could push a patch to the 0.11 branch that disables the alert system
11:22 < gmaxwell> it's a trivial patch.
11:22 < wumpus> yes     
11:22 < achow101> luke-jr: +1
11:22 -!- adiabat [~adiabat@67.205.158.84] has quit [Ping timeout: 268 seconds]     
11:23 < gmaxwell> nothing before 0.8 still works at all, and the 0.9x nodes I have looked at are all fake.
11:23 < gmaxwell> 0.10 / 0.11 are probably still running in practice.
11:23 < gmaxwell> luke-jr: okay fine with CVE and we can patch the old branch. thats enough plan for me for now.
11:24 < wumpus> it's a one-line patch, could even do a tag, just not going to build executables for them anymore
11:25 < gmaxwell> Thanks.
11:26 < sipa> sgtm
11:27 < achow101> I suppose the bitcoin.org alert page should be updated with that info then
11:27 < jtimon> I'm happy to review any backports for an alert patch, even if they're old, won't go below 0.8, sorry
11:28 < btcdrak> everything from 0.10 and below is EOL https://bitcoincore.org/en/lifecycle/#schedule
11:29 < sipa> btcdrak: 0.14 should be added to that page
11:29 < btcdrak> sipa: https://github.com/bitcoin-core/bitcoincore.org/pull/347
11:29 < gmaxwell> what other subjects?
11:30 < cfields> Is there a timeline for 0.14.1? Or just when deemed necessary?
11:31 < achow101> it seems that 0.10 is the only one that needs an alert disabling patch. 0.11 already has it, just not tagged
11:31 < wumpus> cfields: eh not really; any pressing reason you'd want one right away?
11:32 < wumpus> the more-than-8-addnode hang at shutdown problem is annoying but not enough to warrant an immediate release
11:32 < gmaxwell> I don't see a reason one couldn't wait a few weeks, though we do have material for one.
11:32 < cfields> wumpus: nope, just couldn't remember if we usually set a date or just wing it
11:32 < wumpus> no, we never set dates in advance for minor releases
11:32 < wumpus> for 0.15 I've posted the release schedule: https://github.com/bitcoin/bitcoin/issues/9961
11:33 < gmaxwell> I'm sure that some more things will show up for 0.14.1 in not too long as people start using some of the new features.
11:33 < wumpus> yes     
11:33 < achow101> I feel like those should have been caught during RCs..
11:33 < wumpus> 'should have been'
11:33 < BlueMatt> #9959 and #9955 are interesting for 0.14.1
11:33 < gribble> https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub
11:33 < gribble> https://github.com/bitcoin/bitcoin/issues/9955 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
11:34 < wumpus> there's always issues in major releases that only get found when the final is tagged, it's a fact of life
11:34 < gmaxwell> achow101: any kind of bug that requires special configuration to find is much less likely to get caught, this is why you hear groans when people propose solving problems with more config options. :)
11:34 < wumpus> no number of rcs can solve that
11:34 < luke-jr> 9955 is more of a new feature IMO, but I don't care if people want to backport it
11:34 < morcos> agreed, we should tag those for 0.14 or backport or whatever we say, but not cause for expedited minor release
11:35 < wumpus> ok tagging them
11:36 < cfields> wumpus: 0.15 schedule sgtm.
11:36 < luke-jr> note that backporting 9955 is likely a hazard since priority mining doesn't pay attention to fIncludeWitness I think
11:36 < wumpus> cfields: thanks, good to know
11:37 < luke-jr> should be a trivial thing to fix, but might not conflict
11:37 < achow101> are we going to do the release notes wiki thing again?
11:38 < wumpus> yes, at the end of the 0.15 release cycle
11:38 < achow101> ok     
11:38 < sdaftuar> priority mining did pay attention to fIncludeWitness, so i think it would be fine, but i haven't tested
11:39 -!- JackH [~laptop@79-73-184-8.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]     
11:39 < wumpus> achow101: I think it worked quite well; the only problem that came up is merging it with that is in the tree. So better to leave it until the end when people start caring about writing release notes, and until then leave it up to pulls to add something there
11:39 < luke-jr> oh, it's tested in a different place, okay
11:41 < achow101> anything else?
11:43 < sipa> seems not
11:44 < wumpus> I don't think so
11:44 < wumpus> #endmeeting
11:44 < lightningbot> Meeting ended Thu Mar  9 19:44:45 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
11:44 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.html
11:44 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.txt
11:44 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.log.html
11:44 < achow101> a reminder that daylight savings time in the US begins this weekend so next week's meeting will be an hour later local time
11:45 < jl2012> Oh ended?
11:45 < jtimon> do you have a topic?
11:45 < jl2012> #9443
11:45 < gribble> https://github.com/bitcoin/bitcoin/issues/9443 | Repairing the large-work fork warning system by jl2012 · Pull Request #9443 · bitcoin/bitcoin · GitHub
11:45 < wumpus> here starting from march 26
11:46 < jl2012> This was tagged 0.14
11:46 < jl2012> Want to see any chance for 0.15
11:47 < jtimon> for some reason I thought that needed rebase
11:48 < jl2012> Rebased already
11:48 < jtimon> yeah, I see, thanks for the heads up, will review
11:48 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
11:49 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/9cea1698132ab68b0d6b204ff5c8d154d9192b19
11:49 < bitcoin-git> bitcoin/0.10 9cea169 Wladimir J. van der Laan: net: Disable P2P alert system
11:49 < sdaftuar> jl2012: if i understand correctly, that PR would cause us to not ban peers who are on an incompatible chain?
11:50 < jl2012> It should ban
11:50 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/0bace8307995ac2911885c7c8b8dec19b864eaa3
11:50 < bitcoin-git> bitcoin/0.11 0bace83 Wladimir J. van der Laan: net: Disable P2P alert system
11:50 < sdaftuar> ah, i will re-read more carefully
11:50 < jl2012> It just stirs the header
11:50 -!- JackH [~laptop@79-73-184-8.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
11:50 < jl2012> Stores
11:50 < achow101> wumpus: coulda just set DEFAULT_ALERTS to false
11:51 < wumpus> achow101:did that exist in 0.10 and 0.11?
11:51 < achow101> yes     
11:51 < achow101> 0.11 had it false too
11:51 < achow101> (but not tagged)
11:51 < wumpus> achow101: anyhow, this is complete and clear
11:53 < achow101> indeed
11:54 < jl2012> sdaftuar: it does not ban for sending header for childs of an invalid block
11:55 < wumpus> going to tag v0.11.3 and v0.10.5
11:55 < btcdrak> wumpus: ~1
11:55 < btcdrak> +1     
11:55 < sdaftuar> jl2012: ah, ok. right now, banning peers who are on an incompatible chain is used to avoid being partitioned from the peers who share our consensus rules.
11:55 < wumpus> no RCs necessary for this, I'd say
11:55 < sdaftuar> jl2012: there's some discussion of this in #9530
11:55 < gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
11:57 < sdaftuar> jl2012: i think we can replace the banning with something else, like rotating outbound connections periodically and try dropping any outbound peers on an incompatible chain in favor of a new outbound peer, but i think we'd need to write that code first before we change the DoS banning behavior we have now
11:57 < btcdrak> wumpus: what is the EOL date for 0.12?
11:57 < kanzure> if some python-bitcoinlib users want to do some code review, here's a mock for bitcoin.rpc.Proxy-- https://github.com/petertodd/python-bitcoinlib/pull/136
11:57 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
11:58 < sdaftuar> jl2012: i am hoping to work on the topics in #9530 for 0.15 though, if possible
11:58 < gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
11:58 < wumpus> btcdrak: wouldn't that normally be the 0.14 release date?
11:59 < kanzure> oh, i assumed the meeting was over. 'scuse me.
11:59 < wumpus> yes, the meeting is closed
11:59 < wumpus> kanzure: will take a look
12:00 < kanzure> i don't think it's directly usable in bitcoin.git because the rpc tests need to actually use real rpc :) (and also we're not using petertodd/python-bitcoinlib in bitcoin rpc tests anyway)
12:00 < jl2012> sdaftuar: maybe giving a score lower than 100 for sending child of invalid block?
12:00 < jl2012> Before we have a new DoS system
12:01 < sipa> please, no more dos scoring
12:03 < jl2012> So the plan is completely removing that?
12:08 < sipa> i think so. things are either invalid and expensive, in which case we ban, or not, and we don't ban
12:09 < sipa> and independently there is a mechanism for keeping good peers around (which can use relay speed, first to relay blocks/txn, resource comsumpion, seemingly on the same chain, ...) as a low-frequency kicking (but not banning)
12:11 < morcos> sipa: that wasn't super clear 
12:12 < morcos> there is expensive to produce and expensive to consume
12:12 < morcos> both matter
12:14 < sipa> right, ratio between cost to the attacker and cost to us is what matters
12:17 < btcdrak> wumpus: yes maintenance end will be when 0.14 is released, but what about EOL.
12:18 < wumpus> btcdrak: what did we use for other releases?
12:18 < bitcoin-git> [bitcoin] MarcoFalke pushed 10 new commits to master: https://github.com/bitcoin/bitcoin/compare/5703dff0939f...8910b4717e5b
12:18 < bitcoin-git> bitcoin/master 0e6d23d John Newbery: Add logging to test_framework.py...
12:18 < bitcoin-git> bitcoin/master 553a976 John Newbery: Add logging to p2p-segwit.py
12:18 < bitcoin-git> bitcoin/master 6d0e325 John Newbery: Use logging in mininode.py...
12:18 < wumpus> I guess it's just maintenance end date + something?
12:19 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9768: [qa] Add logging to test_framework.py (master...rpctestlogging) https://github.com/bitcoin/bitcoin/pull/9768
12:19 < btcdrak> wumpus: seems to be around ~2 years.
12:21 < wumpus> btcdrak: sounds good to me
12:23 -!- JackH [~laptop@79-73-184-8.dynamic.dsl.as9105.com] has quit [Ping timeout: 256 seconds]     
12:24 < btcdrak> wumpus:https://github.com/bitcoin-core/bitcoincore.org/pull/347/files
12:25 < wumpus> btcdrak: looks good to me
12:27  * luke-jr peers at race conditions not fixed by adding atomic<>
12:27 -!- wudayoda_ [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
12:27 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]     
12:29 < gmaxwell> sipa: we can have another mechenism unrelated to DOS to make sure peers on incompatible chains aren't wasiting our slots and contributing to partioning us. Bans are a dumb way to accomplish that.
12:30 < wumpus> just kicking is usually enough
12:30 < sipa> gmaxwell: that's exactly what i said
12:30 < sipa> 12:09:44 < sipa> and independently there is a mechanism for keeping good peers around (which can use relay speed, first to relay blocks/txn, resource comsumpion, 
12:30 < sipa>                  seemingly on the same chain, ...) as a low-frequency kicking (but not banning)
12:30 < wumpus> only spy nodes are persistent enough to keep reconnecting to the same nodes
12:30 < gmaxwell> ah I missed the 'seemingly on the same chain'.
12:32 < gmaxwell> e.g. we can easily tell when a peer is on a chain we consider recently invalid. (if they advertise a block to us, we'll fetch back its headers, and eventually find it as a child of a block we rejected as invalid)
12:32 < gmaxwell> at that point he should be ranked as first to get dropped.
12:33 < sipa> right
12:34 < gmaxwell> can just be a flag, that gets set when we see he's on an invalid chain, unset if we get a valid block from him. and connection rotation could strictly prefer to punt ... all obvious.
12:43 < luke-jr> tfw you rebase something just to realise you forgot to pull master
12:48 < wumpus> 'well, that was easy!' 'oh no...'
13:11 -!- CubicEarth [~cubiceart@201.227.226.143] has joined #bitcoin-core-dev     
13:15 -!- CubicEarth [~cubiceart@201.227.226.143] has quit [Remote host closed the connection]     
13:18 -!- CubicEarth [~cubiceart@201.227.226.143] has joined #bitcoin-core-dev     
13:32 -!- CubicEarth [~cubiceart@201.227.226.143] has quit [Remote host closed the connection]     
13:35 -!- CubicEarth [~cubiceart@201.227.226.143] has joined #bitcoin-core-dev     
13:37 -!- CubicEarth [~cubiceart@201.227.226.143] has quit [Remote host closed the connection]     
13:44 -!- MarcoFalke [~none@198.12.116.246] has left #bitcoin-core-dev []     
14:18 < luke-jr> I think #8694 needs fresh re-reviews :x
14:18 < gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
14:19 -!- randy-waterhouse [~kiwigb@43.228.156.101] has joined #bitcoin-core-dev     
14:19 < bitcoin-git> [bitcoin] jnewbery opened pull request #9966: Control mempool persistence using a command line parameter (master...mempoolpersistenceoption) https://github.com/bitcoin/bitcoin/pull/9966
14:19 -!- randy-waterhouse [~kiwigb@43.228.156.101] has quit [Changing host]     
14:19 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev     
14:46 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
14:46 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]     
15:01 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection]     
15:01 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
15:29 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev     
15:30 < gmaxwell> apparently the latest electrum nags you to opt into RBF if you tell it to pay a low fee.
15:31 < dcousens_> gmaxwell: suprising,  I'd of thought CPFP would be the easier route
15:32 < dcousens_> aka, UX escape hatch
15:33 < gmaxwell> dcousens_: CPFP is not that useful.
15:33 < gmaxwell> Requires that you have change, and involves 2x the transaction data.
15:33 < gmaxwell> I mean, it's useful, but RBF is more useful.
15:33 < dcousens_> gmaxwell: true,  just remembered as you wrote that it would require the change
15:33 < gmaxwell> Think: you were trying to pay low fees and now you have to pay twice a high fee. .. and you don't even always have the option.
15:35 < BlueMatt> gmaxwell: that seems like a reasonable route
15:36 < gmaxwell> 15:34 < cbits_> gmaxwell: yep, if you slide the fee slider all the way to the left, the rbf box becomes visible and automatically checked.  :-)
15:36 < dcousens_> gmaxwell: so RBF doesn't show unless its low fee?
15:36 < luke-jr> CPFP is more useful for the recipient than the sender, really.
15:36 < luke-jr> prompting to enable RBF for fallback fee seems like a good idea for Core
15:36 < gmaxwell> dcousens_: no, you could set it to default on in the prior version, but few users did until it was too late.
15:39 -!- cbits_ [~cbits@2607:f380:a61:650:747f:aafa:126c:1258] has joined #bitcoin-core-dev     
15:43 < cbits_> Electrum uses dynamic fees by default now. The last two slider options for fee preference are within 10 blocks, or within 25 blocks. The within 25 blocks option makes the rbf box visible and sets it on.
15:43 -!- wudayoda_ [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]     
15:44 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
15:45 < luke-jr> cbits_: why isn't it always visible?
15:45 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 264 seconds]     
15:46 < cbits_> Not sure, probably to be neutral. Less boxes for users to check or figure out. You can make it always visible in settings.
15:46 < luke-jr> i c     
15:48 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]     
15:56 < achow101> luke-jr: it can be set to always be visible
15:57 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.5]     
15:59 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
16:01 -!- CubicEarth [~cubiceart@201.227.226.143] has joined #bitcoin-core-dev     
16:02 < cbits_> Yeah, and it automatically sets rbf checked when you have it set to visible
16:08 -!- CubicEarth [~cubiceart@201.227.226.143] has quit [Remote host closed the connection]     
16:19 -!- CubicEarth [~cubiceart@201.227.226.143] has joined #bitcoin-core-dev     
16:19 -!- CubicEarth [~cubiceart@201.227.226.143] has quit [Remote host closed the connection]     
16:21 -!- GriTBalL [~gritball@104.131.129.89] has joined #bitcoin-core-dev     
16:27 -!- CubicEarth [~cubiceart@201.227.226.143] has joined #bitcoin-core-dev     
16:32 -!- CubicEarth [~cubiceart@201.227.226.143] has quit [Remote host closed the connection]     
16:35 -!- cbits_ [~cbits@2607:f380:a61:650:747f:aafa:126c:1258] has quit [Ping timeout: 256 seconds]     
16:35 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving]     
16:39 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection]     
16:49 -!- GriTBalL [~gritball@104.131.129.89] has quit []     
16:58 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
16:59 -!- cbits_ [~cbits@2607:f380:a61:650:518f:5add:c1bc:956d] has joined #bitcoin-core-dev     
17:00 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
17:03 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 260 seconds]     
17:04 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev     
17:05 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 240 seconds]     
17:18 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
17:21 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
17:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []     
17:30 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
17:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Disconnected by services]     
17:31 -!- Victor_sueca is now known as Victorsueca     
17:33 -!- bityogi [~textual@208-104-132-26.brvd.dsl.dyn.comporium.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
17:38 -!- cbits_ [~cbits@2607:f380:a61:650:518f:5add:c1bc:956d] has quit [Ping timeout: 256 seconds]     
17:56 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]     
18:04 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection]     
18:26 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]     
18:34 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev     
18:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-gmfiwlfbwmbcccro] has quit [Quit: Connection closed for inactivity]     
18:44 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
18:50 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds]     
18:56 -!- dodomojo_ [~goksinen@2604:2000:c591:8400:6895:4070:4a01:5a33] has joined #bitcoin-core-dev     
18:58 < gmaxwell> wumpus: would we perhaps want to consider removing zap? we added it because we had no way to abandon transactions, but we do now. I've seen it used in a way that created a lot of damage. (user ran into the unconfirmed depth limit and couldn't make transactions. Then zapped their wallet, then stared paying again, doublspending the @#$@# out of themselves.  .. then were stuck trying to reassemble 
18:58 < gmaxwell> the pieces... figure out who they still owed, etc.
19:02 -!- CubicEarth [~cubiceart@190.219.188.141] has joined #bitcoin-core-dev     
19:02 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer]     
19:05 -!- CubicEarth [~cubiceart@190.219.188.141] has quit [Remote host closed the connection]     
19:13 -!- harrymm1 [~wayne@104.222.140.99] has joined #bitcoin-core-dev     
19:15 -!- harrymm [~wayne@104.222.140.115] has quit [Ping timeout: 258 seconds]     
19:20 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
19:23 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 260 seconds]     
19:38 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
19:47 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds]     
19:52 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 246 seconds]     
19:52 -!- CubicEarth [~cubiceart@190.219.188.141] has joined #bitcoin-core-dev     
19:53 -!- PatBoy [xyz@192.99.249.194] has quit [Ping timeout: 245 seconds]     
19:58 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving]     
19:58 -!- PatBoy [xyz@192.99.249.194] has joined #bitcoin-core-dev     
20:00 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]     
20:34 -!- chris200_ [~chris2000@p5DCB4DF6.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
20:37 -!- chris2000 [~chris2000@p5DCB4EF0.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]     
20:57 -!- dodomojo_ [~goksinen@2604:2000:c591:8400:6895:4070:4a01:5a33] has quit [Remote host closed the connection]     
21:01 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye]     
21:01 -!- juscamarena [~justin@47.148.176.74] has quit [Remote host closed the connection]     
21:09 -!- tonebox [47e7bcc7@gateway/web/freenode/ip.71.231.188.199] has joined #bitcoin-core-dev     
21:10 -!- scan_email_bot [75c4a02a@gateway/web/freenode/ip.117.196.160.42] has joined #bitcoin-core-dev     
21:11 -!- scan_email_bot [75c4a02a@gateway/web/freenode/ip.117.196.160.42] has quit [Client Quit]     
21:11 < tonebox> It seems like segwit is a temporary fix...  4M is going to be overwhelmed, just like 1mb now...  Wouldn't a better solution be to change the time-base, so now it's 10 minutes per block... Soon, 5 min, then 2.5...  It could revert to 10, and be automatically adjusted just like the difficulty.
21:13 < Lightsword> tonebox, no, that results in higher orphan rates due to latency
21:14 < tonebox> Ok...  Thanks...   Would there be any way to make segwit not fixed at 4mb so this won't be a problem that needs to be solved again in a few years?
21:17 < tonebox> Also, it would seem like a dynamic timebase and fixing the issue with orphans would be a better solution long term.
21:20 < CubicEarth> Lightsword: I always thought moving to a 5 minute block time would be perfectly fine
21:20 < gwillen> This isn't really a good channel for this kind of discussion -- better in #bitcoin probably.
21:20 < CubicEarth> a slightly higher orphan rate wouldn't hurt anything
21:23 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev     
21:28 -!- CubicEarth [~cubiceart@190.219.188.141] has quit []     
21:43 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
21:47 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds]     
21:52 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev     
21:52 -!- juscamarena_ [~justin@47.148.176.74] has joined #bitcoin-core-dev     
21:56 -!- juscamarena_ [~justin@47.148.176.74] has quit [Client Quit]     
21:57 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
21:59 < wumpus> gmaxwell: I'm fine with that...
22:01 < wumpus> gmaxwell: what I mostly don't like about it is that it requires a rescan, and is very non-selective (zap all unconfirmed)
22:02 < wumpus> gmaxwell: mostly it's useful to troubleshoot issues with wallet bugs and corruption, when a certain transaction behavres strangely.  But a tool to remove a single transaction from the database would work much better for that and be less impactful. Back in the day,though,that was hard to do for some reason
22:02 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds]     
22:03 < wumpus> I agree abandontransaction replaces all end-use servicable reasons to use zap
22:11 < gmaxwell> It might just make sense to rename it and hide it for that reason. If there is a reason to not do that, we should probably enhance abandon further.
22:12 < wumpus> me preference would be to hide it in some dangerous-sounding wallet salvage or editing tool, not have it in the main executable at least or maybe not even in the main distribution
22:13 < wumpus> I mean there's a use for low-level-ish wallet editing, but it certainly shouldn't be easily available
22:14 < gmaxwell> Salvage is also pretty raw... I've said before it should be called "savage (verb) wallet"
22:15 < wumpus> hehe
22:15 < wumpus> salvage has been actually useful to a lot of people though, it tends to be the only thing available if the rest if something is corrupted
22:16 < luke-jr> doesn't zap recover from corrupt bdbs we can't open?
22:16 < wumpus> no, zap doesn't do that
22:17 < wumpus> it assumes that records are simply readable, what it does is remove all transactions
22:17 < wumpus> with a mode to keep metadata (by default) and another to trash it
22:17 < gmaxwell> salvage does. though at least historically it would also miss data in perfectly fine wallet.dats (though I think some of that was due to bugs which have been fixed)
22:17 < luke-jr> ah, mixed them up I guess
22:17 < wumpus> I think those issues have been fixed
22:18 < wumpus> thoug there are still some weird issues with salvagewallet, for example berkeleydb can return an error when salvaging an otherwise ok wallet (but it doesn't lose records anymore IIRC)
22:18 < wumpus> then again this is the kind of thing we're asking for with not updating the backend library for years. BDB should die.
22:20 < gmaxwell> so I did some testing and later BDB now appear to be bidirectionally compatible?!
22:20 < gmaxwell> but I couldn't find any announcement of it.
22:20 < gmaxwell> it just worked.
22:21 < wumpus> it works in some cases
22:21 < wumpus> that's been the case when I tried too. But I don't trust it.
22:21 < gmaxwell> ah, I wasn't aware that it ever worked before.
22:22 < wumpus> I think the backward incompatiblity thing is just a matter of no one ever seriously researching this, and what are the edge cases of it, than a sure thing
22:22 < wumpus> it doesn't work in *all* cases that is clear
22:26 < wumpus> one thing that is not backwards compatible is the log files; so if there are still log files behind, the old version will error out
22:33 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
22:36 < wumpus> it may well be that a "clean" .dat file, like produced by backupwallet, is always backwards compatible. Though that doesn't help a user that crashes on first run with the new version then tries to go back, the wallet being in intermediate state.
22:37 < wumpus> of course it's fairly simple to work around this with a conversion tools and/or making and automatic backup at first run. But it was just never deemed worth the trouble
22:37 < wumpus> especially as newer BDBs have license issues
22:37 < wumpus> the plan was ,and should still be, to move away from it
22:39 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
22:40 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
23:06 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]     
23:07 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 240 seconds]     
23:15 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
23:33 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-apbpicssbyrkkboe] has joined #bitcoin-core-dev     
23:44 -!- tonebox [47e7bcc7@gateway/web/freenode/ip.71.231.188.199] has quit [Quit: Page closed]     
23:54 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]     
23:58 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev