--- Day changed Thu Jan 05 2017 00:09 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 00:11 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.cablep.bezeqint.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 00:13 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:14 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-sknvalniwtzxvxmv] has joined #bitcoin-core-dev 00:17 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 248 seconds] 00:20 < gmaxwell> morcos: I agree that we need to focus on small improvements that make things simply better at the moment, and that a big redesign is out of scope at the moment. 00:32 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev 00:33 -!- juscamarena [~justin@47.148.176.74] has quit [Client Quit] 00:33 < jonasschnelli> We had 15208 github comments in 2016, from 517 users. That's an avg of ~41.5 comments per day. 00:35 -!- juscamarena__ [~justin@47.148.176.74] has joined #bitcoin-core-dev 00:35 -!- juscamarena_ [~justin@47.148.176.74] has joined #bitcoin-core-dev 00:35 -!- juscamarena__ [~justin@47.148.176.74] has quit [Client Quit] 00:36 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 248 seconds] 00:44 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-core-dev 00:57 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 01:12 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 01:29 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7dac1e5e9e88...70145064153a 01:29 < bitcoin-git> bitcoin/master 0388afe Luke Dashjr: Let autoconf detect presence of EVP_MD_CTX_new... 01:29 < bitcoin-git> bitcoin/master 7014506 Wladimir J. van der Laan: Merge #9475: Let autoconf detect presence of EVP_MD_CTX_new... 01:29 < bitcoin-git> [bitcoin] laanwj closed pull request #9475: Let autoconf detect presence of EVP_MD_CTX_new (master...EVP_MD_CTX_new) https://github.com/bitcoin/bitcoin/pull/9475 01:29 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70145064153a...48d7e0d5e463 01:29 < bitcoin-git> bitcoin/master ce370c1 Pieter Wuille: Mark the minconf parameter to move as ignored 01:29 < bitcoin-git> bitcoin/master 48d7e0d Wladimir J. van der Laan: Merge #9474: Mark the minconf parameter to move as ignored... 01:30 < bitcoin-git> [bitcoin] laanwj closed pull request #9474: Mark the minconf parameter to move as ignored (master...stale_minconf_parameter) https://github.com/bitcoin/bitcoin/pull/9474 01:30 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 272 seconds] 01:37 -!- Alina-malina [~Alina-mal@37.157.216.139] has joined #bitcoin-core-dev 01:43 < wumpus> jonasschnelli: wow 01:49 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/48d7e0d5e463...c4b7d4f79c85 01:49 < bitcoin-git> bitcoin/master 407cdd6 Pieter Wuille: Do not evaluate hidden LogPrint arguments 01:49 < bitcoin-git> bitcoin/master c4b7d4f Wladimir J. van der Laan: Merge #9417: Do not evaluate hidden LogPrint arguments... 01:49 < bitcoin-git> [bitcoin] laanwj closed pull request #9417: Do not evaluate hidden LogPrint arguments (master...bypass_debug) https://github.com/bitcoin/bitcoin/pull/9417 01:51 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:00 < jonasschnelli> Currently verifying my data.. 02:01 < jonasschnelli> But I guess we had 1563 PRs opened in 2016. 02:01 < jonasschnelli> 1032 merged (66%) 02:01 < jonasschnelli> 146 still open (~9%) 02:02 < jonasschnelli> 385 closed (~24.6%) 02:02 < jonasschnelli> (though the last one may have some false-positives [manual closed merges]) 02:02 < wumpus> it at least feels like it was a really busy year in that regard 02:11 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev 02:11 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/c4b7d4f79c85...cfe41d7a6034 02:11 < bitcoin-git> bitcoin/master e5534d2 Karl-Johan Alm: Added std::unique_ptr<> wrappers with deleters for libevent modules. 02:11 < bitcoin-git> bitcoin/master 7f7f102 Karl-Johan Alm: Switched bitcoin-cli.cpp to use RAII unique pointers with deleters. 02:11 < bitcoin-git> bitcoin/master 280a559 Karl-Johan Alm: Added some simple tests for the RAII-style events. 02:12 < bitcoin-git> [bitcoin] laanwj closed pull request #9387: [Refactor] RAII of libevent stuff using unique ptrs with deleters (master...raii-libevents) https://github.com/bitcoin/bitcoin/pull/9387 02:17 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 02:19 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cfe41d7a6034...406f35d99d0f 02:19 < bitcoin-git> bitcoin/master d5aa198 Doug: Allow linearization scripts to support hash byte reversal... 02:19 < bitcoin-git> bitcoin/master 3c8f63b Doug: Make linearize scripts Python 3-compatible. 02:20 < bitcoin-git> bitcoin/master 406f35d Wladimir J. van der Laan: Merge #9373: Linearize script update (hash byte reversal and Python 3 support)... 02:20 < bitcoin-git> [bitcoin] laanwj closed pull request #9373: Linearize script update (hash byte reversal and Python 3 support) (master...linearize-update) https://github.com/bitcoin/bitcoin/pull/9373 02:23 < kallewoof> I am noticing that listsinceblock is sometimes including and sometimes not including a transaction that was double-spent and discarded by the network. Is this expected? 02:24 -!- Alina-malina [~Alina-mal@37.157.216.139] has quit [Ping timeout: 272 seconds] 02:25 < kallewoof> Should've asked on #bitcoin-dev. Migrating, sorry. 02:27 -!- Alina-malina [~Alina-mal@37.157.216.129] has joined #bitcoin-core-dev 02:33 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/406f35d99d0f...4cfd57d2e382 02:33 < bitcoin-git> bitcoin/master 73f4119 Karl-Johan Alm: Refactoring: Removed using namespace from bench/ and test/ source files. 02:33 < bitcoin-git> bitcoin/master 4cfd57d MarcoFalke: Merge #9281: Refactor: Remove using namespace from bench/ & test/ sources... 02:33 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9281: Refactor: Remove using namespace from bench/ & test/ sources (master...no-using-namespace-bench-test) https://github.com/bitcoin/bitcoin/pull/9281 02:33 < wumpus> kallewoof: depends on the reason for 'sometimes' I suppose :) 02:36 < wumpus> I'd say random non-deterministic behavior is never intended 02:37 < bitcoin-git> [bitcoin] kallewoof opened pull request #9476: Refactor: Remove using namespace from rpc/ & script/ sources (master...no-using-namespace-rpc-script) https://github.com/bitcoin/bitcoin/pull/9476 02:39 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 02:41 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 02:42 < kallewoof> @wumpus: http://pastebin.com/EqupZuFM (missing case) vs http://pastebin.com/Phy6mN3G (present case). 02:46 < kallewoof> It is an automated test. Only thing I can think of is some weird timing, but I'm being very generous with letting things sync so not sure what's going on. 02:47 < wumpus> I wonder, does listing transactions not in blocks make sense at all for "listsinceblock" 02:47 < wumpus> apparently it's a difference with regard to what unconfirmed/conflicted transactions are listed 02:48 < kallewoof> My assumption was that it would list anything affecting me given the last state of the block chain from the hash I give. I.e. if a tx was dropped it would be present. 02:48 -!- Alina-malina [~Alina-mal@37.157.216.129] has quit [Changing host] 02:48 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 02:48 < kallewoof> Specifically an invoice system would do listsinceblock periodically to ensure payments did not get double spent or similar. As it is, you have to do extra work to detect those. 02:50 < wumpus> in that case not showing "orphaned" transactions would be better 02:50 < wumpus> but a difference like that could indeed be due to a timing or race condition, e.g. block not yet processed by the wallet 02:50 < kallewoof> What is the proper way to detect a double spend, in that case? I thought listsinceblock seemed ideal. And it is, at least sometimes. 02:51 < fanquake> wumpus Spoke with theuni about some depends changes yesterday, so waiting on some feedback from him about most of those prs. 02:52 < fanquake> re libevent, I think potential code improvements should be in a followup PR? Such as removing work arounds, any no-longer needed version checks etc? 02:52 < wumpus> fanquake: I think the libevent change is ok, not sure about the remark about that the hash is potentially not stable 02:52 < wumpus> fanquake: well we're far from being able to remove those workaround 02:52 < wumpus> fanquake: it should stil support building with stable libevent :) 02:52 < wumpus> just with new libevent it can use the new features 02:53 < wumpus> (which it already does, in some places) 02:53 < fanquake> wumpus Yea I would have thought it would be stable also. However, there could be a "more stable" URL before 0.14.0 02:53 < fanquake> Might even be a proper release! 02:54 < wumpus> the only option for us I see there would be to copy the file somewhere and host it there 02:54 < fanquake> Yes we can do that also, we already host some files as a backup on bitcoincore.org. 02:54 < fanquake> I'd like to put Boost on there so we can remove our last use of SourceForge. 02:55 < wumpus> should ask cfields for that though, I don't have access to that server AFAIK 02:56 < fanquake> Yes I'll bring it up with him later on. 02:57 < fanquake> Does #9475 mean a 0.13.3 release quite soon? Or waiting a while longer for more bug reports. 02:57 < gribble> https://github.com/bitcoin/bitcoin/issues/9475 | Let autoconf detect presence of EVP_MD_CTX_new by luke-jr · Pull Request #9475 · bitcoin/bitcoin · GitHub 02:58 < wumpus> fanquake: if you ask me, I don't think a build system issue necessitates an urgent release 02:58 < wumpus> we should focus on 0.14.0 now 03:01 < wumpus> #9475 should just go on the stack of things to include when a 0.13.3 is released 03:01 < gribble> https://github.com/bitcoin/bitcoin/issues/9475 | Let autoconf detect presence of EVP_MD_CTX_new by luke-jr · Pull Request #9475 · bitcoin/bitcoin · GitHub 03:07 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4cfd57d2e382...ce43630d1e97 03:07 < bitcoin-git> bitcoin/master d29505d jonnynewbs: Fix transaction size comments. Size now refers to virtual size as defined in BIP141. 03:07 < bitcoin-git> bitcoin/master ce43630 Wladimir J. van der Laan: Merge #8747: [rpc] Fix transaction size comments and RPC help text.... 03:07 < bitcoin-git> [bitcoin] laanwj closed pull request #8747: [rpc] Fix transaction size comments and RPC help text. (master...rpc_comments) https://github.com/bitcoin/bitcoin/pull/8747 03:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 245 seconds] 03:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 03:22 -!- jtimon [~quassel@197.red-88-0-200.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 03:25 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9473: doc: Parameterize rpcauth help text for translation (master...Mf1701-transPara) https://github.com/bitcoin/bitcoin/pull/9473 03:28 < MarcoFalke> wumpus: The rpcauth still needs a `make translate` to show up properly for translators in transifex. 03:28 < MarcoFalke> Not super important, but letting you know. 03:29 < MarcoFalke> Would you mind to create a pull request for `make translate` updates whenever this hasn't been done in months? 03:29 < MarcoFalke> Thus, we could catch failures early 03:29 < MarcoFalke> (Not after they have been propagated to transifex) 03:39 -!- Alsazia [5ffa401d@gateway/web/freenode/ip.95.250.64.29] has joined #bitcoin-core-dev 03:39 < Alsazia> Premium link generator (30+ host supported) ---> www.galileo.pw 03:39 -!- Alsazia [5ffa401d@gateway/web/freenode/ip.95.250.64.29] has quit [Client Quit] 03:43 < phantomcircuit> wumpus, listsinceblock should almost certainly not list things which aren't actually in a block 03:55 -!- Netsplit *.net <-> *.split quits: thokon00, adam3us, baldur, phantomcircuit, da2ce7, sdaftuar, Evel-Knievel, gluytium, crescendo, bad_duck, (+3 more, use /NETSPLIT to show all of them) 03:55 -!- Netsplit over, joins: bad_duck 03:55 -!- Netsplit over, joins: pigeons 03:55 -!- Netsplit over, joins: gluytium 03:55 -!- thokon00 [~thokon00@gw.linuxit.at] has joined #bitcoin-core-dev 03:55 -!- crescendo [~mozart@173.203.100.20] has joined #bitcoin-core-dev 03:55 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 03:56 -!- Netsplit over, joins: Evel-Knievel 03:56 -!- Netsplit over, joins: baldur 03:56 -!- Netsplit over, joins: d9b4bef9 03:56 -!- crescendo [~mozart@173.203.100.20] has quit [Changing host] 03:56 -!- crescendo [~mozart@unaffiliated/crescendo] has joined #bitcoin-core-dev 03:56 -!- Netsplit over, joins: phantomcircuit 03:56 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Changing host] 03:56 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev 03:56 -!- pigeons is now known as Guest73955 03:57 -!- Netsplit over, joins: adam3us 03:57 -!- Netsplit over, joins: da2ce7 03:58 -!- BlueMatt [~BlueMatt@mail.bluematt.me] has joined #bitcoin-core-dev 03:58 -!- BlueMatt [~BlueMatt@mail.bluematt.me] has quit [Changing host] 03:58 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev 04:01 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Quit: Page closed] 04:04 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 245 seconds] 04:12 < wumpus> MarcoFalke: the reason for having only a relatively small translation window is that it doesn't matter whether "make translate" is before that in the meantime 04:12 < wumpus> MarcoFalke: during the translation window (e.g. starting this month for 0.14) we have to make sure it is up to date though 04:29 < wumpus> (well that's one of the reasons; the other is to prevent translators from wasting time translating messages in the meantime that go away before the release anyway) 04:39 < fanquake> Pretty sure theuni has a patch to fix the weird 9472 error. However he's on a plane I think. 05:04 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 05:05 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 05:19 -!- gielbier is now known as gielbier-irc 05:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 05:33 < sipa> kallewoof: is it about double spends tgat your node has seen? they're not usually relayed by the network 05:35 < sipa> fanquake: he's in NY 05:36 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 05:45 -!- jtimon [~quassel@197.red-88-0-200.dynamicip.rima-tde.net] has quit [Ping timeout: 246 seconds] 05:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:50 < fanquake> Just chased that code in 9451 back to "First commit" 06:05 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:11 < wumpus> fanquake: hah, nice catch 06:14 -!- BCBot_ [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 06:15 -!- LeMiner [~LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer] 06:15 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 260 seconds] 06:15 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 06:15 -!- BCBot [~BCBot@46.101.246.115] has quit [Remote host closed the connection] 06:15 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Changing host] 06:15 -!- LeMiner [~LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev 06:15 -!- TD--Linux [~Thomas@2604:a880:1:20::173:1001] has joined #bitcoin-core-dev 06:16 < phantomcircuit> fanquake, i believe i was right there? 06:16 < phantomcircuit> seems to be about multi byte op codes 06:17 < sipa> even then it was redundant 06:17 < sipa> but it did make more sense 06:19 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #bitcoin-core-dev 06:30 -!- chris2000 [~chris2000@p5DCB4C6E.dip0.t-ipconnect.de] has quit [] 06:34 < bitcoin-git> [bitcoin] kallewoof opened pull request #9478: Trivial refactor: BOOST_FOREACH(a, b) -> for (a : b) (master...replace-boostforeach) https://github.com/bitcoin/bitcoin/pull/9478 06:36 < phantomcircuit> i can fuzz test 9451 but not at the moment 06:42 < fanquake> kallewoof See the discussion in #8718 re bulk BOOST_FOREACH changes. Have a feel opinion may still be as it was a few months ago. 06:42 < gribble> https://github.com/bitcoin/bitcoin/issues/8718 | An error has occurred and has been logged. Please contact this bot's administrator for more information. 06:44 < fanquake> Although your changeset seems to be smaller than the previous attempt. 59 files now vs 75 previous. 07:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds] 07:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 07:21 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 07:22 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 07:26 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 07:33 -!- kinlo [~peter@unaffiliated/kinlo] has quit [Quit: !] 07:38 -!- kinlo [~peter@unaffiliated/kinlo] has joined #bitcoin-core-dev 07:46 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 07:46 -!- roidster [~chatzilla@47-41-33-247.dhcp.mtpk.ca.charter.com] has joined #bitcoin-core-dev 07:46 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 07:47 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 07:50 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection] 07:51 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev 08:05 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.] 08:21 -!- gielbier-irc is now known as gielbier 08:34 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has left #bitcoin-core-dev [] 08:39 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 08:52 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:05 -!- LeMiner2 [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 09:08 -!- LeMiner [~LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds] 09:08 -!- LeMiner2 is now known as LeMiner 09:22 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 09:29 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has quit [Quit: Whatever] 09:35 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 09:35 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 09:40 -!- TD--Linux is now known as TD-Linux 09:40 -!- TD-Linux [~Thomas@2604:a880:1:20::173:1001] has quit [Changing host] 09:40 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #bitcoin-core-dev 09:40 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 272 seconds] 09:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 09:43 < gmaxwell> sipa: 09:43 < gmaxwell> ./.bitcoin/debug.log.reindex1 11670.622538 09:43 < gmaxwell> ./.bitcoin/debug.log.reindex2 12182.296543 09:45 < gmaxwell> These are reindex times on a dbcache=2000 host from the time it hit block one till it hit tip, the first is normal, the second is with all signature checks enabled. 09:46 < gmaxwell> so it took eight and a half minutes longer, or a 4% slowdown. 09:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:08 -!- jtimon [~quassel@197.red-88-0-200.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 10:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 10:17 < sipa> gmaxwell: i made a graph of progress (according to my pr) vs time 10:17 < sipa> on my laptoo 10:17 < sipa> *laptoo 10:17 < sipa> *laptoP 10:18 < sipa> and it shows a very clear change in slope at 295000 10:19 -!- Guest73955 is now known as pigeons 10:19 < gmaxwell> I'm doing a par4 run, to get more figures, in case verification parallelism beyond 4 actually works now. :P 10:19 < gmaxwell> But there being a change in slope doesn't refute my figures. sync is very fast at 295k and the utxo set is small. 10:20 < gmaxwell> so it makes a difference there, sure.. but it's only a small part of the chain. 10:22 -!- LeMiner2 [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 10:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:25 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds] 10:25 -!- LeMiner2 is now known as LeMiner 10:39 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 10:47 < morcos> gmaxwell: it works! at least to 16 10:47 < morcos> and beyond with some minor'ish tweaks that might be overfitting to checkqueue 10:50 < BlueMatt> note: meeting in 10 minutes...obviously a major point of discussion will be the huge volume of outstanding things for 0.14 10:50 < gmaxwell> morcos: even without the checkqueue changes? 10:50 < BlueMatt> if y'all get the time prior to the meeting, please think a bit about what you want for 0.14, and what you dont think needs to make it 10:51 < gmaxwell> BlueMatt: you mean the huge volume of things that are going to miss 0.14? :( 10:51 < BlueMatt> gmaxwell: yea, probably :( 10:51 < morcos> yeah the cuckoocache was the immediate bottle neck, so with that, we've definitely got improvement , but from 8 -> 16 isn't that great 10:51 < BlueMatt> need to be able to prioritize review for what can make it in a week, and what wouldnt without an extra week :/ 10:51 < gmaxwell> morcos: if it really was we could have gotten a similar speedup by bypassing the cache in IBD. :P oh well. :) 10:53 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 10:53 < morcos> gmaxwell: ah yes i guess i wasn't talking about IBD... well i don't remember now what my IBD results were, but i'd be surprised if you couldn't go past 4 previously... actually having to do the signtures makes the parrellism more valuable 10:53 < sipa> gmaxwell: rebase #9319 ? 10:53 < gribble> https://github.com/bitcoin/bitcoin/issues/9319 | Break addnode out from the outbound connection limits. by gmaxwell · Pull Request #9319 · bitcoin/bitcoin · GitHub 10:54 < BlueMatt> yea, super want that one for 0.14, and should be an easy target 10:54 < BlueMatt> already has some acks, too 10:55 < sipa> can i have a few more acks on #8610? i think the rewrite invalidated prior review 10:55 < gribble> https://github.com/bitcoin/bitcoin/issues/8610 | Share unused mempool memory with coincache by sipa · Pull Request #8610 · bitcoin/bitcoin · GitHub 10:56 < gmaxwell> sipa: oh I didn't know one was needed there. 10:56 < morcos> sipa: you didn't specify what you changed the last time, i looked and it seemed just the lock inversion fix? 10:56 -!- LiberalSquash [~LiberalSq@kol-kvintus.cust.fsknet.dk] has joined #bitcoin-core-dev 10:56 -!- LiberalSquash [~LiberalSq@kol-kvintus.cust.fsknet.dk] has left #bitcoin-core-dev [] 10:56 < sipa> morcos: yes, just that 10:56 < sipa> morcos: i mean compared to before implementing your approach 10:56 < gmaxwell> oh now I kinda wish I didn't load that PR... 10:57 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 10:58 < BlueMatt> sipa: done (I recalled that I had already reviewed half of it yesterday...) 10:59 < morcos> if you guys trust my rebases, just merge #9138 already... please? (next time in exchange for more willing reviewers of fee estimation, i will break into smaller PR's) 10:59 < sipa> BLING 10:59 < gribble> https://github.com/bitcoin/bitcoin/issues/9138 | Improve fee estimation by morcos · Pull Request #9138 · bitcoin/bitcoin · GitHub 10:59 < BlueMatt> meeting 11:00 < sipa> morcos: i was waiting for acks 11:00 < wumpus> #startmeeting 11:00 < lightningbot> Meeting started Thu Jan 5 19:00:15 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 < jl2012> may I propose a topic first? need to sleep 11:00 < petertodd> hi 11:00 < BlueMatt> jl2012: go 11:00 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs 11:00 < jonasschnelli> Hi 11:00 < jl2012> proposed topic: repair the fork warning system: https://github.com/bitcoin/bitcoin/pull/9443 11:01 < wumpus> #topic repair the fork warning system 11:01 < sipa> concept ack on fixing it if it's broken! 11:01 -!- instagibbs_ [640f7203@gateway/web/freenode/ip.100.15.114.3] has joined #bitcoin-core-dev 11:01 < BlueMatt> concept ack 100% 11:01 < wumpus> haha yes concept ack. Haven't looked at the code yet. 11:01 < sipa> i haven't had time to look at the details... 0.14 is getting close 11:01 < jl2012> but this is more than just fixing it 11:01 < BlueMatt> but we've fucked that up several times already, so needs careful review, I think 11:01 < instagibbs_> here 11:01 < sipa> jl2012: elaborate? 11:02 < jl2012> it also stores invalid headers 11:02 < morcos> jl2012: are you trying to say you think it NEEDS to be in 0.14 11:02 < phantomcircuit> huh what 11:02 < jtimon> oh, meeting, wasn't planning on attending today, but really nothing to do until one hour from now... 11:02 < phantomcircuit> oh 11:02 < jl2012> specifically, it stores valid headers under an invalid block 11:02 < kanzure> hi. 11:03 < jl2012> also, headers with invalid nVersion are stored 11:03 < sipa> jl2012: but those do have valid PoW? 11:03 < jl2012> yes 11:03 < jl2012> and valid nTime 11:03 < sipa> iirc that is our only invariant for the storage of headers 11:03 < BlueMatt> jl2012: do we need to store them or can we just store them in memory? 11:03 < BlueMatt> but, I'm fine either way 11:04 < BlueMatt> looking at invalid headers with valid pow for user-warnings sounds good to me 11:04 < wumpus> stored headers are forever, both on disk and in memory, unfortunately 11:04 < sipa> there may be some DoS avenues that open up due to it, if they get accepted for chains that fork off early on 11:04 < luke-jr> jl2012: does this do anything to address that nodes sending us such chains will be DoS banned 11:04 < luke-jr> ? 11:04 < jl2012> won't be banned 11:04 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has joined #bitcoin-core-dev 11:04 < sipa> (but i shouldn't comment on that before looking at code) 11:04 < gmaxwell> I feel pretty blah about the utlity of that warning system, and warnings in general. I think we've burned people out with false warnings, and they weren't used usefully by most to begin with. :( 11:04 < wumpus> the alternative to fixing it would be to just disable the system, at least for 0.14 11:05 < BlueMatt> gmaxwell: having reliable warning messages is the first step towards fixing that trust :) 11:05 < luke-jr> jl2012: so this removes the DoS banning for invalid blocks? 11:05 < jl2012> luke-jr: just for valid header 11:05 < wumpus> shipping it broken, especially with risk of false positives, indeed isn't going to do anything good 11:05 < jl2012> if the block content is invalid (e.g. invalid script), still banned 11:06 < gmaxwell> There is currently no false positive risk from it AFAIK. 11:06 < luke-jr> jl2012: which will lead to you not getting future headers 11:06 < petertodd> jl2012: to be clear, if the block is too large it will be banned as well? 11:06 < wumpus> having to store more data forever just to be able to warn seems a bit inefficient to me though 11:06 < jtimon> mhmm, the block is still invalid here, no? https://github.com/bitcoin/bitcoin/pull/9443/files#diff-24efdb00bfbe56b140fb006b562cc70bR3038 11:06 < wumpus> the block headers are never pruned, and all loaded into memory at start 11:06 < BlueMatt> petertodd: i dont think it changes anything wrt consensus code? the way I read it 11:06 < gmaxwell> petertodd: we can't even deseralize it if its too large so how would we even know if the contet were invalid. 11:06 < jl2012> petertodd: should be, I don't change that part 11:06 < BlueMatt> petertodd: /any/ consensus logic 11:06 < sipa> i wonder if we need a detection of internal consensus errors (database corruption, CPU overheating, ...) 11:06 < petertodd> gmaxwell: we can deserialize if it's only a little bit too large though IIRC 11:06 < sipa> because 99.999% of all fork warning that are seen in practice as just broken nodes 11:07 < gmaxwell> An invarient we have right now is that we depnd on banning to make sure all our connection slots are not consumed by peers that are on an incompatible blockchain. 11:07 < gmaxwell> sipa: I think we do. 11:07 < gmaxwell> sipa: which ultimately should be used to trigger recovery from chainstate backup automatically. (I think) 11:07 < sipa> but i don't know how without having a thread in the background that computes Pi or so :p 11:08 < morcos> jl2012: i'd like to understand the context of the discussion, is that about the change in general or whether it shoudl be in 0.14. Is the current status of master somehow worse than 13.1/2? 11:08 < wumpus> detecting database corruption on disk is pretty easy as everything is CRC-ed, CPU overheating or memory corruption on the other hand... 11:08 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 11:09 < jl2012> morcos: I think that has broken for a few versions 11:09 < gmaxwell> Broken just means that it won't trigger in all cases it might trigger, right? 11:09 < wumpus> good to know, yes, if it's been broken for a few versions there's no hurry to fix it for 0.14 11:09 < jl2012> so you may consider it as a new feature 11:09 < jl2012> gmaxwell: yes 11:09 < sipa> well it can be considered for 0.14.1 or so 11:09 < sipa> if it's a bugfix (which i think it is) 11:10 < wumpus> I wonder if it can be done without storing more headers though 11:10 < luke-jr> but it doesn't sounds like this PR will actually fix it, and fixing it may be more complicated than it seems due to the point gmaxwell raised 11:10 < gmaxwell> My understanding is that there are cases where invalid blocks make us ignore later headers (normally a good thing) which will prevent them from triggering the warning. 11:10 < wumpus> I really don't like storing otherwise unnecessary data forever 11:10 < BlueMatt> wumpus: store only headers required to prove to yourself upon restart that you should display a warning, and prune the (separate) storage for that? 11:10 < sipa> we could prune old header chains 11:10 < sipa> (both from disk and memory) 11:10 < BlueMatt> or that 11:11 < BlueMatt> from memory....sounds hard 11:11 < wumpus> we could, sure, but right now we don't, so should be careful not to store more than necessary 11:11 < BlueMatt> on-disk/restart-only sounds doable 11:11 < petertodd> wumpus: provided theres a reasonable minimum PoW to storing it, it'll never be all *that* much extra data given it's just headers 11:11 < jtimon> re: invariant for storage of headers: remind you that matt moved the nTime check from CheckBlockHeader() to ContextualCheckBlockHeader() 11:11 < sipa> yeah, on restart it trivial 11:11 < wumpus> yes on startup would be good enough 11:11 < morcos> I think it would be wise to use our limited time to concentrate on things people think are really important for 0.14, it doesn't sound like anyone is making that argument about this change? 11:11 < sipa> agree 11:11 < jl2012> ok, please move on 11:11 < gmaxwell> I'd like improvements here, but I don't think it's 0.14 critical. 11:12 < wumpus> other proposed topics? 11:12 < BlueMatt> 0.14 prs-to-review... 11:12 < luke-jr> morcos: this change is mostly useful to plan for a future hardfork, but I don't think it's critical it's in 0.14 11:12 < wumpus> BlueMatt: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0 11:12 < BlueMatt> wumpus: many of those are almost certainly not gonna make it 11:12 < morcos> luke-jr: heh, ok, i'll put tha ton my hard-fork planning list, i have it handy right here 11:12 < wumpus> BlueMatt: that's a chicken-egg problem though as it depends on who reviews it 11:13 < BlueMatt> true 11:13 < sipa> so the topic here for the discussion should be what to prioritize for review 11:13 < wumpus> I agree, though 11:13 < BlueMatt> well if we're short for topics parallel processmessages...if folks think they will not have time to review it, then I'll skip it, but I have one based on cory's current net pr at https://github.com/theuni/bitcoin/compare/connman-locks...TheBlueMatt:2017-01-parallel-processmessages?expand=1 11:13 < cfields> agree with sipa 11:13 < BlueMatt> and think it would be a huge improvement for some use-cases 11:13 < wumpus> I just meant that the lis is already very long, so let's at least try not to add much more 11:13 < sipa> so open question: what would people like to see in 0.14, if review effort wasn't a bottleneck 11:14 < wumpus> named arguments 11:14 < BlueMatt> or, what is the priority 11:14 < gmaxwell> I really feel uncomfortable with last minute concurrency changes. 11:14 < jtimon> proposed topic: custom blockchains for 0.14 (ie how realistic it is to hope to get https://github.com/bitcoin/bitcoin/pull/8994 merged for 0.14 ? ) 11:14 < luke-jr> there was some desire for #8775 #8694 #7533 in 0.14, but they're not tagged as such 11:14 < gribble> https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub 11:14 < gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub 11:14 < gribble> https://github.com/bitcoin/bitcoin/issues/7533 | RPC: sendrawtransaction: Allow the user to ignore/override specific rejections by luke-jr · Pull Request #7533 · bitcoin/bitcoin · GitHub 11:14 < jtimon> custom chainparams really 11:14 < BlueMatt> gmaxwell: it tries very hard to limit concurrency changes - its whitelisted on messages, plus other things 11:14 < wumpus> gmaxwell: same 11:14 < morcos> i'd like to see the improvements to block relay #9375, #9441, #9447 and possibly parallel ProcessMessages 11:14 < BlueMatt> gmaxwell: no open prs of mine make any significant concurrency changes 11:14 < gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub 11:14 < gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub 11:15 < gribble> https://github.com/bitcoin/bitcoin/issues/9447 | Allow 2 simultaneous block downloads by morcos · Pull Request #9447 · bitcoin/bitcoin · GitHub 11:15 < BlueMatt> gmaxwell: or at least they try hard not to 11:15 < BlueMatt> s/not// 11:15 < cfields> wumpus: +1 for named arguments. Will re-review. 11:15 < gmaxwell> BlueMatt: we really have inadequate testing there, as cfield's version assert has shown us. 11:15 < morcos> +1 on named arguments as well... will amke future PR's easier/better 11:15 < BlueMatt> gmaxwell: helgrind works well, it turns out :), but, agreed 11:16 < gmaxwell> BlueMatt: only if you actually execute the codepaths. 11:16 < BlueMatt> sure 11:16 < gmaxwell> Where are we with the multiwallet support? 11:16 < cfields> BlueMatt: maybe you could briefly describe what you're hoping to immediately improve? 11:16 < instagibbs_> gmaxwell: there's one refactor outsanding I believe 11:16 < luke-jr> gmaxwell: 3 PRs left, 9375 and 9441 11:17 < sipa> 9441? sure? 11:17 < luke-jr> err 11:17 < instagibbs_> 8775 11:17 < luke-jr> 8775 8694* 11:17 < gmaxwell> I had been hoping for that and the utxo scriptpubkey index (#8660) in 0.14, but it looks like the latter has been abandoned by its requester. 11:17 < gribble> https://github.com/bitcoin/bitcoin/issues/8660 | txoutsbyaddress index (take 2) by djpnewton · Pull Request #8660 · bitcoin/bitcoin · GitHub 11:18 < wumpus> gmaxwell: yes, that's unfortunate 11:18 < sipa> i'd like to see #9441 in to get the performance benefit 11:18 < BlueMatt> cfields: specifically, because many miners rely on bitcoind submitblock -> p2p network latency to relay their blocks out, this ends up being pretty important for miners in several ways, so speeding up the relay (hopefully without introducing a ton of new concurrency outside of cmpctblock/getblocktxn/blocktxn message processing) would be a massive win for many miners 11:18 < gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub 11:18 < jtimon> for efficiency, maybe https://github.com/bitcoin/bitcoin/pull/8498 helps, but nobody has found the time to benchmark that in years... 11:19 < BlueMatt> yes, so multiwallet and at least the currently-open net prs are review focus 11:19 < gmaxwell> wumpus: I think it's suffered less attention than it would have recieved because it's poorly labled and people keep thinking its a blockchain index. 11:19 < morcos> ok well if i had to pick one, i think 9375 makes a huge difference 11:19 < wumpus> gmaxwell: looks like droark might pick it up 11:20 < gmaxwell> BlueMatt: well I had a PR that removed the biggest source of submitblock latency-- it's a couple lines changes, I assume its functionality has been duplicated in one of cfields overlapping PRs that I closed that one in favor of. 11:20 < morcos> if nothing else the caching of the block/cmpctblock that you are about to send to all your peers reduces the time per per from 25ms to <1ms 11:20 < BlueMatt> gmaxwell: yes, its in the "Net: Massive speedup" one, but the validation time cost (which the parallel getblocktxn/processmessages stuff + the fast relay stuff fixes) 11:21 < BlueMatt> gmaxwell: for current-tip you really want both, but the net stuff you're referring to isnt the only thing here 11:21 < gmaxwell> I am going to be irritated if 9441 misses 0.14. I had an alternative PR that resulted in the same speedup which I think was much less invasive, but I closed it because cfields prefered the other change because it serviced his overall refactor planning. 11:22 < BlueMatt> I think that one is pretty far along, its gotten a lot of eyes even if not so much acks 11:22 < BlueMatt> yes, so multiwallet and at least the currently-open net prs are review focus <-- any other things to add to that list 11:22 < BlueMatt> ? 11:22 < wumpus> gmaxwell: let's focus on making that one get in then (I do think there's some regression risk, as it's a pretty invasive change to do last minute) 11:22 < sipa> i'll focus on the net locks overhault, named args, early compact block relay 11:23 < morcos> gmaxwell: so 9441 doesn't count as concurrency changes you are worried about merging now 11:23 < gmaxwell> wumpus: that was my feeling too but yea. 11:23 < morcos> +1 sipa's list 11:23 < gmaxwell> morcos: right, I think it's invasive but it shouldn't be meaningfully creating new concurrency. 11:23 < wumpus> sgtm 11:23 < wumpus> #action focus on the net locks overhault, named args, early compact block relay 11:23 < BlueMatt> sip, ok, named args it is, also multi-wallet? 11:24 < BlueMatt> a 11:24 < gmaxwell> The caching improvements as part of early compact block are nice. One option is if we feel uncomfortable about early compact blocks is that we disable that part and just take the caching. 11:24 < BlueMatt> sipa 11:24 < instagibbs_> luke-jr: might make sense to split out QT stuff for time 11:24 < luke-jr> instagibbs_: planning to do so, once 8775 is merged 11:24 < wumpus> multi-wallet may be still too many PRs away for 0.14 , dunno how realistic it is to get that in, though we certainly can make progress with the refactors 11:24 < jtimon> which pr is named args? 11:24 < sipa> jtimon: #8811 11:24 < gribble> https://github.com/bitcoin/bitcoin/issues/8811 | rpc: Add support for JSON-RPC named arguments by laanwj · Pull Request #8811 · bitcoin/bitcoin · GitHub 11:24 < morcos> Obviously I think 9138 (improve fee estimation) needs to be merged, but i think its ACK'ed enough (excpet it had some rebases) 11:24 < BlueMatt> gmaxwell: the fast-relay stuff there has been /super/ scaled back...at this point its only a) if its the first thing you're annoucing at that height, and b) if its built directly on your tip 11:25 < BlueMatt> gmaxwell: so hopefully its easier to be comfortable with it 11:25 < gmaxwell> On the remaining multiwallet, I felt one of the outstanding refactor PRs introduced a fair amount of not very C++ish code, but who am I to judge? and I didn't know what to recommend instead, so I asked sipa to look at it but I doubt he's had a chance yet. 11:25 < luke-jr> instagibbs_: although Qt stuff ties in with RPC stuff for the debug window 11:25 < wumpus> morcos: if something is ready for merge you should let me know :) 11:25 < morcos> well at this point, my judgement isn't to be trusted.. :) 11:25 < gmaxwell> BlueMatt: remaining concerns are things like "are we going to accidentally DOS attack our peers by announcing something and then reorging" and things like that. 11:26 < jonasschnelli> Multiwallet: I think need to rebase this one: #8764 11:26 < gribble> https://github.com/bitcoin/bitcoin/issues/8764 | [Wallet] get rid of pwalletMain, add simple CWallets infrastructure by jonasschnelli · Pull Request #8764 · bitcoin/bitcoin · GitHub 11:26 < BlueMatt> gmaxwell: yes, hence scaling it back...been discussing it a bunch with folks in the past few days 11:26 < luke-jr> jonasschnelli: that kinda conflicts with the current multiwallet stuff 11:26 < jonasschnelli> Maybe https://github.com/bitcoin/bitcoin/projects/2 needs update 11:27 < jtimon> maybe https://github.com/bitcoin/bitcoin/projects/6 needs to be...closed? 11:27 < luke-jr> might be more efficient to do 8764 after the basic parts are in 11:28 < gmaxwell> For 0.14 I really want to see the second pass through createtransaction change from morcos in... fixes some concerning fee overpayment corner case. 11:29 < gmaxwell> I don't know why #9312 isn't merged yet. 11:29 < gribble> https://github.com/bitcoin/bitcoin/issues/9312 | Increase mempool expiry time to 2 weeks by morcos · Pull Request #9312 · bitcoin/bitcoin · GitHub 11:29 < morcos> #9404 is super easy now, although needs rebase after #9465 is merged 11:29 < gribble> https://github.com/bitcoin/bitcoin/issues/9404 | Smarter coordination of change and fee in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub 11:29 < gribble> https://github.com/bitcoin/bitcoin/issues/9465 | [Wallet] Do not perform ECDSA signing in the fee calculation inner loop. by gmaxwell · Pull Request #9465 · bitcoin/bitcoin · GitHub 11:29 < sipa> i read a few things about accidental extreme fee 11:30 < jtimon> maybe related to estimate fee for the very next block now disabled? (no idea, just thinking out loud) 11:30 < sipa> is that related to 9138 ? 11:30 < wumpus> gmaxwell: same holds for you, if something is ready for merging you should let me know 11:30 < sipa> or 9404? 11:31 < gmaxwell> #9404 though I really want it in, I haven't actually reviewed the code becuase I know it'll be simpler after 9465. (the story there is a user reported an issue that might be that fee bug, I went go fix it, realized it would be easier to fix after factoring out the signing.. did that.. then realized your preexisting patch was already the fix I wanted. :P ) 11:31 < gribble> https://github.com/bitcoin/bitcoin/issues/9404 | Smarter coordination of change and fee in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub 11:31 < wumpus> 9312 clearly is 11:31 < morcos> sipa: both, well disabling fee estimates for 1 already went in, not part of 9138 11:31 < luke-jr> jtimon: https://www.reddit.com/r/Bitcoin/comments/5ltw5n/bitcoin_core_v0131_sends_enormously_high_fee/ 11:31 < luke-jr> perhaps ^ should be our next topic 11:31 < morcos> but both could cause high fees 11:31 < wumpus> I think I stopped paying attention there when a certain person started trolling then lost track of it. 11:31 < sipa> can someone explain what causes this? 11:31 < sipa> (i don't visit reddit) 11:31 < morcos> yes 11:31 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has joined #bitcoin-core-dev 11:31 < BlueMatt> ^ that 11:31 < kanzure> luke-jr: see 9404, i think 11:32 < gmaxwell> luke-jr: I believe its fixed by 9404. Of course, I can't know for sure, not enough info. 11:32 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 11:32 < sipa> oh, is it change unnecessarily converted to fee? 11:32 < instagibbs_> gmaxwell: so it's wallet-related code, not estimation 11:32 < morcos> the 9404 case is caused when you select coins to pay for a tx, calculate fee and realize you dont' have enough, so you have to go and reselect coins. you end up selecting many fewer for whatever reason, and now you have enough fee of course, and you end up paying the fee you calculated for the prior iteration 11:32 < luke-jr> gmaxwell: well, OP's post there said he's using estimatefee :/ 11:32 < morcos> gmaxwell: 9404 is already rebased on 9465 as of this morning, so easy peasy to review now 11:32 < gmaxwell> But the user seemed to be reporting that it payed several times the fee estimator figures (at least thats my read on it), which supports 9404 over 9138 though 9138 needs to go in too. 11:33 < gmaxwell> morcos: oh missed that, will review. 11:33 < jonasschnelli> #9294 should also go into 0.14 (needs overhaul, my turn) and some form of a HD rescan would be great. 11:33 < gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub 11:33 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ce43630d1e97...a72f76ca3d5d 11:33 < bitcoin-git> bitcoin/master 5f0e27f Alex Morcos: Increase mempool expiry time to 2 weeks 11:33 < bitcoin-git> bitcoin/master a72f76c Wladimir J. van der Laan: Merge #9312: Increase mempool expiry time to 2 weeks... 11:33 < luke-jr> gmaxwell: he sent you the debug log, did that indicate anything useful? 11:33 < bitcoin-git> [bitcoin] laanwj closed pull request #9312: Increase mempool expiry time to 2 weeks (master...longerexpiry) https://github.com/bitcoin/bitcoin/pull/9312 11:34 < gmaxwell> jonasschnelli: do we still have nothing that removes key from the keypool when they show up in transactions out of order, so that a rescan while unlocked would successfully find everything? 11:34 < gmaxwell> luke-jr: no. unfortunately. 11:34 < gmaxwell> well it didn't suggest that the known ways that estimatefee could be high weren't being hit. 11:34 < jonasschnelli> gmaxwell: we don't. But I'm working on it. Got distracted with SPV/BFD and 2016 visualisation. 11:35 < gmaxwell> jonasschnelli: okay, I'll do it if you don't have time; I just figured you are much more recently familar with that code than I. Sorry to nag. 11:35 < morcos> sipa: its also possible that fee estimation could temporarily be very high.. was MUCH more likely for estimatefee 1 though, which has already been disabled 11:35 < sipa> morcos: ok 11:35 < jonasschnelli> gmaxwell: I'm happy if you do it. 11:35 < sipa> let's get those fixes in 11:36 < jonasschnelli> gmaxwell: maybe use some prework form https://github.com/bitcoin/bitcoin/pull/9370 11:36 < gmaxwell> TBH I knew about the issue fied by 9404 long ago, but I thought it had since been fixed... :( 11:37 < gmaxwell> jonasschnelli: oh I thought I'd acked the fundraw reuse fix.. will review. 11:37 < jonasschnelli> The correct one is: https://github.com/bitcoin/bitcoin/pull/9377 11:38 < jonasschnelli> The one above is an older try that could be useful for hd restore. 11:38 < jonasschnelli> Fun topic: 2016 Git Visualisation: I'd created a draft video, need feedback to overhaul it and place it on the bitcoincore.org website. 11:38 < jonasschnelli> https://vimeo.com/198242328 11:38 < jonasschnelli> Password coredev 11:38 < jonasschnelli> (will be there for a couple of mins) 11:39 < jonasschnelli> (sorry to spam the meeting) 11:39 < gmaxwell> okay I concept acked, well I'll complete the review. 11:40 < luke-jr> jonasschnelli: why password protect it and post the password in public? :P 11:40 < jonasschnelli> Security by obscurity. 11:40 < petertodd> luke-jr: MILITARY LEVEL BLOCKCHAIN SECURITY 11:40 < jonasschnelli> heh 11:40 < wumpus> hehe 11:41 < petertodd> anyway, I think that constitutes an "effective access control" under the DMCA... 11:41 < gmaxwell> Who called this meeting? 11:41 < sipa> jonasschnelli: short comment: overuse of capitalization (why are Day and Commit capitalized) and dashes (Code-contributors should be written with a space in between) 11:41 < jonasschnelli> sipa: Thanks, will adapt 11:41 < instagibbs_> any other topics? 11:42 < wumpus> apparently not! 11:42 < instagibbs_> everyone's watching the video 11:43 < kanzure> chainparams? 11:43 < wumpus> looks like we'll close the first meeting of 2017 early 11:43 < kanzure> 8994 11:43 < wumpus> what is there to discuss about chainparams? 11:43 < kanzure> for 0.14, i think. 11:43 < BlueMatt> final list of things to focus for review? multi-wallet, currently-open net prs, fee ones, what else? 11:44 < BlueMatt> oh, and multiargs 11:44 < BlueMatt> rpcarg thing 11:44 < jonasschnelli> and hd chain-split/rstore 11:44 < jtimon> wumpus, on my part #8994 11:44 < gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub 11:44 < gmaxwell> I think that is really a lot less important than everything else listed. 11:44 < gmaxwell> (as people using that are also probably using git master) 11:44 < morcos> are we really trying to get all these wallet changes in? 11:45 < wumpus> yes it doesn't seem to make a lot of sense to focus last-minute review attention on that 11:45 < jtimon> sure, feedback is still welcomed though 11:45 < morcos> should we focus on some over others? 11:45 < BlueMatt> morcos: yea, I think thats more than will make it, but that was the list 11:45 < gmaxwell> (so merging it after 14 means just weeks of delay for someone who wants to use it) 11:45 < gmaxwell> jtimon: fair enough. 11:45 < wumpus> morcos: the fee fixes obviously have priority 11:45 < jtimon> I doubt it will get to 0.14 that's why I asked "how realistic..." 11:45 < wumpus> anything that can cause users to spend unnecessary coins should be first priority 11:45 < morcos> well i guess i meant between hd-chain/split and multiwallet 11:45 < BlueMatt> i think maybe multi-wallet is less likely so maybe less priority, but maybe others disagree since that would be a super nice user-facing feature 11:46 < instagibbs_> I think multiwallet would be great... lots of demand for something like that 11:46 < gmaxwell> I would prioritize fee fixes, net/relay things, hd/rescan improvements, multiwallet, the thousand other open PRs. 11:46 < instagibbs_> but yes bigger changes 11:46 < morcos> gmaxwell: in order? 11:46 < gmaxwell> There is a lot of demand for multiwallet and I feel like if we don't get it done it'll continue to slip. 11:46 < morcos> don't forget named args? 11:46 < gmaxwell> morcos: yes that was an order. 11:46 < instagibbs_> >thousand other open PRs 11:46 < jonasschnelli> gmaxwell: Would multiwallet in 0.14 include the GUI? 11:47 < wumpus> I think 0.14 multiwallet is too late - better to merge it as first thing for 0.15, then improve it in master 11:47 < jonasschnelli> Have we already discussed how to select the wallet over RPC? 11:47 < luke-jr> multiwallet is in Knots already, so may be less important in that sense (since users who want it can get it); stuff like HD split can't really go in Knots without being more final 11:47 < wumpus> it will need a lot of last-minute fixes Im sure 11:47 < luke-jr> jonasschnelli: a number of times :p 11:47 < wumpus> a big feature like that is not done once it's merged 11:47 < luke-jr> wumpus: it's not actually that big at this point 11:48 < gmaxwell> At least on my earlier review it seemed like most of it was the refactors. 11:48 < gmaxwell> Which helps. 11:48 < luke-jr> 99% of it is renaming pwalletMain to pwallet in rpc files 11:48 < jonasschnelli> But we need to be careful. Running with many wallets needs some testing. 11:48 < morcos> sorry i'm not trying to be a downer, but both 9375 (fast compact block relay) and 9441 (net speedup) are big heavy review changes, so we shouldn't spread ourselves too thin if we realyl want those in 11:48 < wumpus> in any case there are plenty of PRs to focus on, as said before they can't make it all in 11:48 < jonasschnelli> Even if it's code-wise trivial 11:49 < luke-jr> overall, I think multiwallet can be delayed in Core if other things need time 11:49 < wumpus> if we can't make any choices to postpone things, either 0.13 will slip incredibly (I'd hate that) or we'll have to randomly drop things last minute 11:49 < wumpus> agree with morcos 11:49 < sipa> 0.13 slipping now would indeed be terrible! 11:49 < luke-jr> heh 11:49 < sipa> ;) 11:49 < gmaxwell> hah 11:50 < wumpus> lol 11:50 < gmaxwell> wumpus: if we slip it we slip it, but if people are active on review and testing I think we don't need to. I really wish the net changes were less invasive but thats water under the bridge now. 11:51 < gmaxwell> I do believe the release will be delayed from fixes for just the things we already have in now. 11:51 < luke-jr> am I likely to be of any help reviewing the net stuff if I'm not up to speed on the net refactoring so far? 11:51 < wumpus> gmaxwell: I don't want to let it slip on features in any case, on bugfixes is more acceptable 11:51 < BlueMatt> note: we have at least 4 regressions in master which are 0.14-blocking which do not yet have prs open to fix them 11:51 < wumpus> so it's clear what to focus on then 11:51 < BlueMatt> so....thats a thing 11:51 < gmaxwell> wumpus: right, well ... you could just merge everything outstanding and then all slips are bugfix related! :P 11:51 < instagibbs_> BlueMatt: there a list? 11:51 < BlueMatt> oh, sorry, 1 has an open pr 11:52 < wumpus> BlueMatt: are the issues tagged appropriately? 11:52 < BlueMatt> yes, tagged 0.14, i believe 11:52 < wumpus> ok 11:52 < gmaxwell> AFAIK we are not actually waiting on the competion of any feature changes. (except perhaps some rescan improvements).. E.g. almost everything I think we might have in 0.14 has a PR already open. 11:52 < cfields> to reviewers, don't let the amount of commits in 9441 scare you. Almost all of them are very tiny, explicitly to make review easier 11:52 < BlueMatt> at least #9479, #9027, #9148 and #9212 11:52 < gribble> https://github.com/bitcoin/bitcoin/issues/9479 | An error has occurred and has been logged. Please contact this bot's administrator for more information. 11:52 < BlueMatt> maybe others 11:52 < gribble> https://github.com/bitcoin/bitcoin/issues/9027 | Unbounded reorg memory usage · Issue #9027 · bitcoin/bitcoin · GitHub 11:52 < sipa> confirming what cfields said 11:52 < gribble> https://github.com/bitcoin/bitcoin/issues/9148 | Wallet RPCs can return stale info due to ProcessNewBlock Race · Issue #9148 · bitcoin/bitcoin · GitHub 11:52 < gribble> https://github.com/bitcoin/bitcoin/issues/9212 | Assertion failed: (nSendVersion != 0), function GetSendVersion, file ./net.h, line 775. · Issue #9212 · bitcoin/bitcoin · GitHub 11:52 < morcos> oh shit, yeah sorry, one is mine.. , lets quickly decide which direction we want to take on that. Do we revert #9240 or do we not care about the notifications? I think #9371 is too late for 0.14 11:52 < gmaxwell> completion* 11:52 < gribble> https://github.com/bitcoin/bitcoin/issues/9240 | Remove txConflicted by morcos · Pull Request #9240 · bitcoin/bitcoin · GitHub 11:52 < gribble> https://github.com/bitcoin/bitcoin/issues/9371 | Notify on removal by morcos · Pull Request #9371 · bitcoin/bitcoin · GitHub 11:53 < sipa> morcos: if 9371 is too late, we need to revert 9240... but maybe that is not something we need to know now? 11:53 < sipa> a revert can be do at the last minute 11:53 < sipa> *done 11:53 < morcos> If we're reverting #9240, it'll conflict, definitely with 9138 and probably already, so let me know and I'll make a revert PR 11:53 < BlueMatt> yea, we can revert on the 0.14 branch at that point? 11:53 < gribble> https://github.com/bitcoin/bitcoin/issues/9240 | Remove txConflicted by morcos · Pull Request #9240 · bitcoin/bitcoin · GitHub 11:53 * jtimon reiterates his dissapointment on not having removed checkpoints for everything except progress estimation, that doesn't have a PR... 11:54 < sipa> jtimon: 9472 removes checkpoints for the purpose of progress estimation 11:54 < morcos> sipa: well i like 9371, but it overlaps a lot with #8549 and we haven't resolved direction 11:54 < sipa> :) 11:54 < jtimon> I mean gmaxwell you had that practically done already 11:54 < gribble> https://github.com/bitcoin/bitcoin/issues/8549 | zmq: mempool notifications by jmcorgan · Pull Request #8549 · bitcoin/bitcoin · GitHub 11:54 < jtimon> sipa: oh, nice, will have a look 11:54 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has quit [Ping timeout: 248 seconds] 11:55 < gmaxwell> jtimon: not going to have one either, not any time soon (1) it requires a consensus change; and I don't have the appetite to carry forward in the adversarial climate of the mailing list (which I am not on for a long time now), and (2) Sipa disagrees with my one strategy for removing the signature checking dependency, and petertodd disagrees with the other. 11:55 < wumpus> Madars: what I don't like about 9371 is that is that it keeps the list of removed transactions on mempool, instead of an external object listening for signals 11:55 < wumpus> sorry s/Madars/Morcos 11:56 < wumpus> morcos: this means it can only support one client listening for removals at most 11:56 < gmaxwell> (sipa disagrees that we can just check all signatures; petertodd disagrees with the proposal that we use burried by 30 days of work+other conditions) 11:56 < jtimon> gmaxwell: mhmm, I didn't remember a consensus change, must be missing something, but sure, if it needs it, definitely no time to do it for 0.14 11:56 < wumpus> morcos: for the rest I'm ok with it, and it doesn't conflict with 8549 too much 11:56 < sipa> gmaxwell: what about the idea of once crossing a certain amount of work, requiring a higher minimum difficulty? 11:57 < gmaxwell> jtimon: the part of it that didn't either need a consensus change (uppping the minimum difficulty) and didn't change the signature checking, has already been merged. 11:57 < morcos> wumpus: i was trying to keep notifications from happening while we were locked in reorg.. couldn't we later make it so the mempoolremovaltracker could interface with multiple clients or something 11:57 < sipa> ah, right, consensus change 11:57 < gmaxwell> sipa: it's a consensus change, and I implemented it, and asked for review which jtimon gave some, but... consensus change. 11:57 < wumpus> morcos: I just don't like making a notification mechanism stateful, but that may be a personal thing 11:58 < jtimon> thanks for the info, wasn't up to date on the subject 11:58 < wumpus> morcos: but ok maybe this is the only way to handle reorgs sanely 11:58 < gmaxwell> but I really have no interest in writing a bit and getting treated like shit by zander and voskull or whatever other trolls inhabit the list today. 11:58 < morcos> but isn't that what we've just done on purpose with ConnectTrace? 11:58 < morcos> i guess not quite the same thing... but accomplishes same goal 11:58 < jtimon> maybe in this 2 minutes...should I rebase the super-trivial #9279 ? 11:58 < gribble> https://github.com/bitcoin/bitcoin/issues/9279 | Consensus: Move CFeeRate out of libconsensus by jtimon · Pull Request #9279 · bitcoin/bitcoin · GitHub 11:59 * luke-jr ponders if it would make sense to increase min difficulty to 50% of current difficulty. 11:59 < wumpus> morcos: well at least that's an external object passed in 11:59 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has left #bitcoin-core-dev ["Ex-Chat"] 11:59 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev 11:59 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 11:59 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has joined #bitcoin-core-dev 11:59 < sipa> gmaxwell: maybe you should explain your idea to luke-jr 11:59 < morcos> i know... but so many layers.. anyway, ok we'll see what happens.. i'll make the revert later if i need to 12:00 < gmaxwell> sipa: https://github.com/gmaxwell/bitcoin/commit/2db190b183c5204da23191ca642c7f6cad412ae3 12:00 < instagibbs_> time of meeting has ended 12:00 < wumpus> #endmeeting 12:00 < lightningbot> Meeting ended Thu Jan 5 20:00:11 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-05-19.00.html 12:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-05-19.00.txt 12:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-05-19.00.log.html 12:00 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a72f76ca3d5d...fd7d8c7b35ae 12:00 < bitcoin-git> bitcoin/master 54f8026 Jonas Schnelli: [CoinControl] Allow non-wallet owned change addresses 12:00 < bitcoin-git> bitcoin/master fd7d8c7 Jonas Schnelli: Merge #9413: [CoinControl] Allow non-wallet owned change addresses... 12:00 < jtimon> #9279 would make libconsensus lighter :p 12:00 < gribble> https://github.com/bitcoin/bitcoin/issues/9279 | Consensus: Move CFeeRate out of libconsensus by jtimon · Pull Request #9279 · bitcoin/bitcoin · GitHub 12:00 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #9413: [CoinControl] Allow non-wallet owned change addresses (master...2016/12/qt_cc_change) https://github.com/bitcoin/bitcoin/pull/9413 12:01 < gmaxwell> sipa: presumably that explains the idea precisely enough. :) 12:01 < wumpus> morcos: I guess your mechanism could be extended to multiple clients if the start/stop timespans for storing mempool removals are not determined by the client 12:01 < wumpus> morcos: then the whole list of removed transactions could be passed to all listeners 12:01 < morcos> yes i think thats what i meant 12:01 < wumpus> morcos: and it's listener-agnostic without calling a signal for every transaction 12:02 < jtimon> what about fetching the minimum difficulty from the 6 biggest mining pools? 12:02 * jtimon hides 12:02 < gmaxwell> /kb jtimon 12:02 < wumpus> morcos: not sure what the batching granularity should be in that case though 12:02 < petertodd> jtimon: so long as we have a service that defines which those 6 pools are 12:02 < wumpus> morcos: per block, per reorg? 12:02 < jtimon> kb ? 12:02 < kanzure> kickban 12:03 < BlueMatt> jtimon: lol 12:03 < jonasschnelli> jtimon: heh. Read this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013432.html 12:03 < luke-jr> gmaxwell: sounds reasonable 12:03 < morcos> wumpus: well i batched it per lock of cs_main i think 12:03 < BlueMatt> jonasschnelli: lol, I hope that was a joke too 12:03 < morcos> which basically is ActivateBestChain(or Step can't remember) and per AcceptToMemoryPool 12:04 < jtimon> jonasschnelli: right, sorry, should have said 5, didn't remember correctly :p 12:04 < jonasschnelli> haha 12:04 < gmaxwell> luke-jr: A bip for it would probably want to specify how the timestamps must be distorted if difficulty gets down to the limit x 4. 12:04 < gmaxwell> luke-jr: which I've not bothered thinking through. 12:04 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 12:05 < luke-jr> gmaxwell: I'd be inclined to suggest if we ever got to that point, a PoW change may be necessary just to avoid attacks from the ex-miners? 12:05 < jtimon> anyway, should go back to vacations, we spaniards give the christmas presents tomorrow and stuff (yeah we like doing things late) 12:06 < gmaxwell> luke-jr: I fully agree. but it would be a little crazy if the software just ... breaks. on its own (e.g. picks a difficulty whos blocks they won't accept). 12:06 < luke-jr> jtimon: not just spaniards! 12:06 < jtimon> who else? 12:06 < luke-jr> gmaxwell: throw a JSON exception? ☺ 12:06 < luke-jr> jtimon: we also do gifts on the Epiphany here 12:07 < jtimon> interesting, will ask more next time we meet, sorry everyone else for the offtopic 12:07 < gmaxwell> luke-jr: it should be as simple as (if difficulty < 4 * limit, there is a maximum timestamp for exach block). 12:07 < luke-jr> gmaxwell: yes, if it makes sense to continue that chain 12:08 < gmaxwell> maybe four lines of code, just would take a little thinking to figure out the right four lines. doesn't even have to be a consensus rule, just a thing that createnetblock does. 12:08 * luke-jr shrugs 12:08 < adiabat> luke-jr: but what about if the hashrate is actually down 5X "naturally"; e.g. global thermonuclear war? :) 12:09 < gmaxwell> adiabat: we're not talking about 5x. We're talking about 1/20000th. 12:09 < luke-jr> ^ 12:09 < adiabat> luke-jr: ahh, you mean 4X on min-difficulty 12:09 < gmaxwell> luke-jr: it probably doesn't make sense to continue the chain, but it would be goofy if in tests the system fails on its own because of the rule. 12:10 < adiabat> luke-jr: yeah not even thermonuclear war acheives that. 12:10 < gmaxwell> maybe it does, but then who cares? y'all be dead in those cases. 12:11 < luke-jr> XD 12:12 < kanzure> death is merely a temporary inconvenience for thermonuclear scaling 12:12 < gmaxwell> in any case, raising the minimum difficulty was one of the two remaining issues for checkpoint removal. 12:12 < gmaxwell> The other is the signature checking bypass. 12:12 < luke-jr> kanzure: I'm not sure it's scaling to decrease demand. 12:13 < gmaxwell> I have two proposals for that: (1) we just get rid of it, sipa doesn't like this. (2) we replace it with a non-checkpoint based bypass but instead a proof of work based one, and petertodd opposed the best proposal thus far (and I assume otherws would too) 12:14 < gmaxwell> https://github.com/bitcoin/bitcoin/pull/9180 12:15 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev 12:16 < luke-jr> would it be so terrible to keep a single "checkpoint" just for sigcheck bypass? 12:16 -!- instagibbs_ [640f7203@gateway/web/freenode/ip.100.15.114.3] has quit [Quit: Page closed] 12:17 -!- jtimon [~quassel@197.red-88-0-200.dynamicip.rima-tde.net] has quit [Ping timeout: 272 seconds] 12:17 < gmaxwell> luke-jr: for the purpose of people misunderstanding the security model I think thats just as bad as what we have now. 12:17 < luke-jr> what if it's a param the user can specify? 12:18 < luke-jr> (with a sane default) 12:18 < gmaxwell> luke-jr: the fact that you can -checkpoints=0 now doesn't prevent people from mistaking that for the origin of the security of the history. 12:19 < luke-jr> :< 12:19 < gmaxwell> I have been thinking that maybe a configurable known good value ANDed with the 9180 process might be good enough. But I'm not sure. 12:20 < gmaxwell> and the continued obession with checkpoints by people (esp. academics) makes me want to not work on bitcoin anymore, so I might not be thinking about it objectively. 12:20 < luke-jr> what if we have multiple such values, all but one of which are bogus valid chains? ☺ 12:20 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 12:21 < gmaxwell> from a security perspective if I was happy with PR9180 on its own, then I'd be happy with it anded with a restriction on what chain(s) it applies to. So I think thats fine, but the problem is that people focus on the freeking hardcoded value, so what I hoped to do was just eliminate it. 12:24 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 12:26 < gmaxwell> luke-jr: in any case we are in an optimally bad situation now. 12:28 < gmaxwell> because these hardcoded values pin the consensus we won't move them forward, and won't find out if making them do less would resolve the people confusing them for the security model, but because they (maybe) make a meaningful impact on IBD speed we won't take them out. 12:29 < gmaxwell> and the alternative of using POW can be argued to give more control of the system to miners, so thats opposed too. 12:29 < gmaxwell> (I don't share that belief because the threshold is so large that miners that could do that could simply confiscate all the coins anyways by replacing the chain back to 295k) 12:30 < gmaxwell> (but I don't think the position is an absurd one) 12:32 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 12:32 < gmaxwell> luke-jr: perhaps we can do this in the short term. Introduce a "all prior signatures known good" blockhash which is used for script checking but doesn't pin the chain. Ancestors of that block get scriptchecked.. and then we can set that to a current height. Then the chain pining checkpoints can be eliminated once we've done something about the header flooding... but regardless we can leave the 12:33 < gmaxwell> m alone for now. 12:33 < sdaftuar> gmaxwell: +1, seems reasonable to me. 12:34 < luke-jr> Ancestors of that block get scriptchecked..? 12:34 < gmaxwell> er don't get scriptchecked. :) 12:35 < luke-jr> ok, that sounds pretty much like what I thought the near-term goal already was ☺ 12:37 < gmaxwell> okay, well I'll go PR the scriptcheck skipping change I guess. 12:40 -!- wvr [~wvr@215.red-83-59-62.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 12:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds] 12:49 < gmaxwell> I guess I'll open this question up to more than sipa: 12:49 < gmaxwell> 22:48 I'm not impressed by the bare pointer twizzling in this commit: https://github.com/bitcoin/bitcoin/pull/8775/files#diff-ad6efdc354b57bd1fa29fc3abb6e2872R233 esp with the type punning can you suggest to luke a more C++ way to do this? 12:49 < gmaxwell> 22:49 (thats also the code I would have written, but I'd feel I was probably doing it wrong while doing it.) 12:50 < BlueMatt> are we staunchly against having a "class CWallet" in !define WALLET? 12:51 < BlueMatt> forward declaration, that is 12:59 < luke-jr> that would make things so much simpler XD 13:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 13:07 < gmaxwell> I think the problem is that it may not compile since disabling the wallet at compile time changes our dependencies. 13:07 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye] 13:07 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Quit: DeepSpace took me hostage.] 13:07 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev 13:07 < gmaxwell> I suppose it could be a dummy class CWallet that exists in that case though. 13:08 < gmaxwell> e.g. has no methods or fields. 13:08 < BlueMatt> gmaxwell: not dummy, forward declartion 13:09 < BlueMatt> gmaxwell: i think in this case it will still compile 13:09 < BlueMatt> since there are no actual uses of it, just a pointer to it 13:09 < BlueMatt> which the compiler knows how to do, even without knowing shit about the class 13:11 < gmaxwell> Makes sense. Even to my C loving eyes, the code in 8775 struck me as pretty yucky. If it's forward declared and you try to use it when you shouldn't the result will fail to compile or link. So.. seems fine to me. 13:12 < gmaxwell> but I'm not the person likely to have useful opinions on that. 13:12 < BlueMatt> I kinda agree, i /think/ forward decl will work, easy to test at least 13:12 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 13:13 < sipa> if it compiles with just a forward declaration, it should be fine 13:13 < sipa> and i guess it should 13:13 < sipa> i wouldn't want that in a longer-term solution, but that code will be in flux for a while 13:14 < luke-jr> so I can use a fwd decl? 13:14 < BlueMatt> luke-jr: try it, if it compiles, yes :) 13:14 < luke-jr> pretty sure it will 13:14 * sipa is strongly against code that does not compile 13:15 < gmaxwell> If it works and someone thinks its somehow worse than functions with void pointers in their typedefs and typecasting all over the place I will argue with them. :P 13:15 < luke-jr> sipa: but..! 13:16 < sipa> luke-jr: i know, i know. bitcoin would be much more secure if it didn't compile 13:16 < gmaxwell> sipa: code that does not compile never crashes. 13:16 < luke-jr> lol 13:17 < BlueMatt> it also doesn't have bugs 13:17 < BlueMatt> (for some definition of bugs) 13:17 < BlueMatt> then again nothing has bugs for some definition of bugs 13:18 < luke-jr> but also everything has bugs for some definition of bugs <.< 13:19 < luke-jr> btw, this doesn't look like it's going to change more than a few lines of code in this particular PR 13:19 < luke-jr> and may have to still use the ugly cast in Qt code to pass through signals/slots, dunno 13:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 13:32 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 13:37 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd7d8c7b35ae...a7d55c933853 13:37 < bitcoin-git> bitcoin/master b3d7b1c Gregory Maxwell: Wallet: Do not perform ECDSA in the fee calculation inner loop.... 13:37 < bitcoin-git> bitcoin/master a7d55c9 Pieter Wuille: Merge #9465: [Wallet] Do not perform ECDSA signing in the fee calculation inner loop.... 13:37 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has quit [Ping timeout: 255 seconds] 13:37 < bitcoin-git> [bitcoin] sipa closed pull request #9465: [Wallet] Do not perform ECDSA signing in the fee calculation inner loop. (master...no_signing_in_inner_loop) https://github.com/bitcoin/bitcoin/pull/9465 13:52 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a7d55c933853...c252685aa586 13:52 < bitcoin-git> bitcoin/master ba3cecf Pieter Wuille: Share unused mempool memory with coincache... 13:52 < bitcoin-git> bitcoin/master c252685 Pieter Wuille: Merge #8610: Share unused mempool memory with coincache... 14:22 < bitcoin-git> [bitcoin] sipa pushed 11 new commits to master: https://github.com/bitcoin/bitcoin/compare/c252685aa586...f646275b90b1 14:22 < bitcoin-git> bitcoin/master 4df4479 Alex Morcos: Remove extraneous LogPrint from fee estimation... 14:22 < bitcoin-git> bitcoin/master 60ac00d Alex Morcos: Don't track transactions at all during IBD.... 14:22 < bitcoin-git> bitcoin/master 84f7ab0 Alex Morcos: Remove member variable hadNoDependencies from CTxMemPoolEntry... 14:22 < bitcoin-git> [bitcoin] sipa closed pull request #9138: Improve fee estimation (master...refactorFeeEstimation) https://github.com/bitcoin/bitcoin/pull/9138 14:33 < instagibbs> BlueMatt, if it doesn't compile there is no unexpected behavior :) 14:36 < gmaxwell> luke-jr: fking signals/slots. 14:49 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 14:59 < gmaxwell> morcos: do you think it would be reasonable for CreateTransaction or its kin to log the feerate its using for its construction? So that if there is further concern about strange fees there is log evidence if the strange fee was a result of the estimator vs something else? 15:00 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 15:34 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 15:37 < luke-jr> a bigger concern I think is that logging is not enabled until it's too late 15:37 < luke-jr> so unless you log it by default (which may be reasonable for manual activity?), it won't be there when you want it 15:38 < luke-jr> maybe log it by default ASAP and we can quiet it in a few releases after things have been sufficiently resolved? 15:58 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has quit [Read error: No route to host] 15:59 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has joined #bitcoin-core-dev 16:00 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 16:02 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Read error: Connection reset by peer] 16:11 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has quit [Quit: brg444] 16:31 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has quit [Ping timeout: 256 seconds] 16:36 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]] 16:39 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has joined #bitcoin-core-dev 16:42 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 16:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-sknvalniwtzxvxmv] has quit [Quit: Connection closed for inactivity] 16:57 < luke-jr> sipa: I see your point. paveljanik: are you already working on a PR, or shall I? 16:57 < gmaxwell> 16:53 < Michail1> gmaxwell - Mental note: bitcoin-0.13.2-win64-setup.exe is detected by Norton (File Insight) as not safe and automatically removes it. (Not that you can do anything about it, just letting you know.) I am confirming the prior versions are not auto deleted. 16:58 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 16:58 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 17:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 17:13 -!- Netsplit *.net <-> *.split quits: Eliel, belcher, michagogo, rubensayshi, midnightmagic, sipa, owowo, Lightsword, ryan-c, PatBoy, (+5 more, use /NETSPLIT to show all of them) 17:14 -!- Netsplit *.net <-> *.split quits: [b__b], nsh, GreenIsMyPepper, gwillen, wallet42, eragmus, gielbier, Bootvis, Soligor, nickler, (+5 more, use /NETSPLIT to show all of them) 17:14 -!- Eliel_ [~jojkaart@104-250-47-212.rev.cloud.scaleway.com] has joined #bitcoin-core-dev 17:14 -!- Netsplit over, joins: ryan-c 17:14 -!- owowo [ovovo@gateway/vpn/mullvad/x-sutgtiqxmxirkvkc] has joined #bitcoin-core-dev 17:14 -!- Netsplit over, joins: PatBoy 17:14 -!- Netsplit over, joins: ill 17:14 -!- Bootvis [bob@baltar.lan.endoria.net] has joined #bitcoin-core-dev 17:14 -!- gwollon [~gwillen@unaffiliated/gwillen] has joined #bitcoin-core-dev 17:14 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev 17:14 -!- Netsplit over, joins: nickler 17:14 -!- sipa [~pw@vps64477.public.cloudvps.com] has joined #bitcoin-core-dev 17:14 -!- gielbier [~michiel@2001:981:9573:1:5428:c047:3a2f:e262] has joined #bitcoin-core-dev 17:14 -!- owowo [ovovo@gateway/vpn/mullvad/x-sutgtiqxmxirkvkc] has quit [Changing host] 17:14 -!- owowo [ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 17:14 -!- owowo [ovovo@unaffiliated/ovovo] has quit [Changing host] 17:14 -!- owowo [ovovo@gateway/vpn/mullvad/x-sutgtiqxmxirkvkc] has joined #bitcoin-core-dev 17:14 -!- jyap [~jyap@server1.getjumbucks.com] has joined #bitcoin-core-dev 17:14 -!- Netsplit over, joins: GreenIsMyPepper 17:15 -!- nsh- [~lol@wikipedia/nsh] has joined #bitcoin-core-dev 17:15 -!- Netsplit over, joins: musalbas 17:15 < bitcoin-git> [bitcoin] JeremyRubin opened pull request #9480: [trivial] De-duplicate SignatureCacheHasher (master...refactor-signaturecachehasher-visibility) https://github.com/bitcoin/bitcoin/pull/9480 17:16 -!- jyap is now known as Guest26441 17:16 -!- Guest26441 [~jyap@server1.getjumbucks.com] has quit [Changing host] 17:16 -!- Guest26441 [~jyap@unaffiliated/jyap] has joined #bitcoin-core-dev 17:16 -!- Netsplit over, joins: [b__b] 17:16 -!- Netsplit over, joins: paracyst 17:16 -!- Netsplit over, joins: belcher 17:16 -!- Netsplit over, joins: Lightsword 17:16 -!- Netsplit over, joins: Soligor 17:17 -!- Netsplit over, joins: midnightmagic 17:17 -!- limpkin [sid20909@gateway/web/irccloud.com/x-iljunpguwpwmshbs] has quit [Ping timeout: 245 seconds] 17:17 -!- Netsplit over, joins: lightningbot 17:18 -!- rubensayshi [uid201751@gateway/web/irccloud.com/x-ghpvbmrwzmbsxzkq] has joined #bitcoin-core-dev 17:21 -!- Netsplit over, joins: michagogo 17:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 17:22 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev 17:22 -!- gwollon is now known as gwillen 17:24 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-nexidsjonumbkijr] has joined #bitcoin-core-dev 17:24 -!- limpkin [sid20909@gateway/web/irccloud.com/x-vgkarszzflsuywsd] has joined #bitcoin-core-dev 17:25 < bitcoin-git> [bitcoin] kallewoof closed pull request #9478: Trivial refactor: BOOST_FOREACH(a, b) -> for (a : b) (master...replace-boostforeach) https://github.com/bitcoin/bitcoin/pull/9478 17:26 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-eybphxocnajhfdjv] has joined #bitcoin-core-dev 17:33 -!- aspect_ [sid151486@gateway/web/irccloud.com/x-rodisjcrbevhmfhy] has joined #bitcoin-core-dev 17:40 -!- eragmus [sid136308@gateway/web/irccloud.com/x-dxtwomjijaanfbnz] has joined #bitcoin-core-dev 17:41 -!- mappum [sid43795@gateway/web/irccloud.com/x-dovkbenqddonujgf] has joined #bitcoin-core-dev 17:49 -!- abpa [~abpa@2602:306:b837:dbf0:78ef:2885:f4c2:2077] has joined #bitcoin-core-dev 18:20 < kallewoof> sipa: i have 4 nodes (n1-n4) partitioned into two nets (n12 n34). n2 and n3 both spend the same UTXO, then 6 blocks are generated on each side after which the nets are merged and an additional block is generated on n4 causing the n3 transaction to take precedence, knocking the n1 transaction out. this is sometimes listed in listsinceblock and sometimes not. 18:21 < kallewoof> sipa: I tried putting a 1 sec delay after the generate to see if there was some wallet fiddling that did not finish in time but this did not change the outcome. 18:31 < gmaxwell> listed in listsinceblock on which side? 18:31 < gmaxwell> and which block are you listing since? 18:34 < kallewoof> I am calling listsinceblock from n1 18:36 < kallewoof> What's fascinating is that, for the MISSING case (i.e. when it doesn't list the now-orphaned transaction originating from n2), n1 has this in the debug.log file, and for the present case it does not have this: 18:36 < kallewoof> 2017-01-05 11:04:46 Transaction efd9e5d4daf8d47a2cc07db0e153513b2d02da2e031d3f2398f804b2a3d7ba03 (in block 2fd09b11259689722ec38873aeedc7e27753a587f66a542bb2ae64546b17943f) conflicts with wallet transaction 5c717b80ee4e4909e9f4a15bfacd728c3be8c1e75d6eed83a3e9324f6b9ea38c (both spend f72d9d38468c40777640e5b7731dab76cd961ee60cc93198b2ec706c21fb1801:0) 18:40 < kallewoof> I guess since the transaction was overridden by another one, 'orphaned' is probably not the right term. 'Invalidated'? 'Betrayed'? Anyway, the tx that lost the UTXO race. 18:42 < kallewoof> A bit verbose but you can compare the two cases here: http://pastebin.com/EqupZuFM (missing) and here: http://pastebin.com/Phy6mN3G (present) 18:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 18:46 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Quit: Leaving.] 19:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 19:14 -!- abpa [~abpa@2602:306:b837:dbf0:78ef:2885:f4c2:2077] has quit [Quit: Textual IRC Client: www.textualapp.com] 19:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds] 19:43 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 20:02 < phantomcircuit> kallewoof, conflicted 21:01 -!- roidster [~chatzilla@47-41-33-247.dhcp.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]] 21:06 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 21:10 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 21:15 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has quit [] 21:35 < paveljanik> luke-jr, I'm not (I was sleeping ;-) 22:32 < gmaxwell> morcos: par=4 synctime of 24453.715550 (all signatures checked), and par=max (24 actual core host) 12182.296543... so yea, I suppose it's scaling better than it used to. 22:33 < gmaxwell> (these figures with dbcache=2000) 22:52 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zflodhdpeelpsnrl] has joined #bitcoin-core-dev 22:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:00 -!- dermoth [~thomas@dsl-66-36-158-182.mtl.aei.ca] has quit [Read error: Connection reset by peer] 23:01 -!- dermoth [~thomas@dsl-66-36-158-182.mtl.aei.ca] has joined #bitcoin-core-dev 23:09 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has quit [Quit: brg444] 23:59 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]