--- 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 " 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