--- Day changed Thu Jan 12 2017 00:01 < jonasschnelli> <*highlight> [02:02:36] jonasschnelli: did you ever get to producing the change that removes keys from the keypool when they're seen used on the network? 00:01 < jonasschnelli> gmaxwell: No. Didn't started. I had in mind that you said you want to start with that... but I can try something... 00:03 < jonasschnelli> Oh. Github down? 00:08 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:08 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:08 < whphhg> Yup, seems so 00:09 < rabidus> yup 00:09 * jonasschnelli doesn't like the unicorn... 00:13 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 00:25 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev 00:26 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 00:26 -!- goregrin1 is now known as goregrind 00:28 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer] 00:37 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:39 -!- xinxi [~xinxi@116.87.187.139] has quit [Read error: Connection reset by peer] 00:57 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 01:03 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 255 seconds] 01:04 -!- michiel_ [~michiel@unaffiliated/gielbier] has joined #bitcoin-core-dev 01:13 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 01:19 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:34 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 01:41 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev 01:47 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 01:47 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 01:54 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9ec1330b455c...2456a835f0bc 01:54 < bitcoin-git> bitcoin/master db904db Pieter Wuille: Deprecate non-txindex getrawtransaction and better warning 01:54 < bitcoin-git> bitcoin/master 2456a83 MarcoFalke: Merge #9520: Deprecate non-txindex getrawtransaction and better warning... 01:54 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9520: Deprecate non-txindex getrawtransaction and better warning (master...warntxindex) https://github.com/bitcoin/bitcoin/pull/9520 02:16 < MarcoFalke> Thanks for fixing doxygen, wumpus! 02:38 < MarcoFalke> What is the desired behavior of pruneblockchain(0)? 02:41 -!- AaronVW [~aaronvw@207pc74.sshunet.nl] has joined #bitcoin-core-dev 02:49 -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 256 seconds] 02:51 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2456a835f0bc...a65ced1a6657 02:51 < bitcoin-git> bitcoin/master 918d1fb Russell Yanofsky: Return height of last block pruned by pruneblockchain RPC... 02:51 < bitcoin-git> bitcoin/master a65ced1 MarcoFalke: Merge #9518: Return height of last block pruned by pruneblockchain RPC... 02:52 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9518: Return height of last block pruned by pruneblockchain RPC (master...pr/prune-height) https://github.com/bitcoin/bitcoin/pull/9518 03:02 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9524: qa/rpc: Fix pruneblockchain edge cases (master...Mf1701-qaPruning) https://github.com/bitcoin/bitcoin/pull/9524 03:02 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 03:03 < MarcoFalke> We should probably just only allow a single code style with all known bad practices eliminated. 03:06 < MarcoFalke> python should stop interpreting when it sees smelly code and gcc should fail to compile. 03:13 < bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/a65ced1a6657...fac0f30482d5 03:13 < bitcoin-git> bitcoin/master a4bac66 Pieter Wuille: [MOVEONLY] Move progress estimation out of checkpoints 03:13 < bitcoin-git> bitcoin/master 3641141 Pieter Wuille: Move tx estimation data out of CCheckPointData 03:13 < bitcoin-git> bitcoin/master 6dd8116 Pieter Wuille: Remove SIGCHECK_VERIFICATION_FACTOR 03:13 < bitcoin-git> [bitcoin] laanwj closed pull request #9472: Disentangle progress estimation from checkpoints and update it (master...update_tx_estimation) https://github.com/bitcoin/bitcoin/pull/9472 03:18 < wumpus> MarcoFalke: continuing without crashing :-) 03:24 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/fac0f30482d5...d5d4ad87afbf 03:25 < bitcoin-git> bitcoin/master 1814b08 Stanislas Marion: add p2sh and segwit options to bitcoin-tx outscript command 03:25 < bitcoin-git> bitcoin/master 61a1534 jnewbery: Add all transaction output types to bitcoin-tx.... 03:25 < bitcoin-git> bitcoin/master b7e144b jnewbery: Add test cases to test new bitcoin-tx functionality... 03:35 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d5d4ad87afbf...2742568a008e 03:35 < bitcoin-git> bitcoin/master dfbe0d5 Alex Morcos: Add unstored orphans with rejected parents to recentRejects 03:35 < bitcoin-git> bitcoin/master 2742568 Wladimir J. van der Laan: Merge #9261: Add unstored orphans with rejected parents to recentRejects... 03:36 < bitcoin-git> [bitcoin] laanwj closed pull request #9261: Add unstored orphans with rejected parents to recentRejects (master...orphanRejects) https://github.com/bitcoin/bitcoin/pull/9261 03:46 < bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/2742568a008e...f9117f204756 03:46 < bitcoin-git> bitcoin/master 8ac1830 fanquake: [depends] Latest config.guess and config.sub 03:46 < bitcoin-git> bitcoin/master 4ed6faf fanquake: [depends] Boost 1.63.0 03:46 < bitcoin-git> bitcoin/master 6019d21 fanquake: [depends] FreeType 2.7.1 03:47 < bitcoin-git> [bitcoin] laanwj closed pull request #9468: [Depends] Dependency updates for 0.14.0 (master...depends-update-014) https://github.com/bitcoin/bitcoin/pull/9468 03:47 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has quit [Quit: Leaving] 03:49 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f9117f204756...7cb024eba68b 03:49 < bitcoin-git> bitcoin/master 453bda6 Chris Moore: Add 'subtractFeeFromOutputs' option to 'fundrawtransaction'. 03:49 < bitcoin-git> bitcoin/master 7cb024e Wladimir J. van der Laan: Merge #9222: Add 'subtractFeeFromAmount' option to 'fundrawtransaction'.... 04:15 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9525: test: Include tx data in EXTRA_DIST (master...Mf1701-testINCLUDE) https://github.com/bitcoin/bitcoin/pull/9525 04:15 < MarcoFalke> going to cancel all travis instances 04:23 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 04:24 < fanquake> Let's get a few ACKs on #9525 04:24 < gribble> https://github.com/bitcoin/bitcoin/issues/9525 | test: Include tx data in EXTRA_DIST by MarcoFalke · Pull Request #9525 · bitcoin/bitcoin · GitHub 04:43 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7cb024eba68b...02e5308c1b9f 04:43 < bitcoin-git> bitcoin/master fa29736 MarcoFalke: test: Include tx data in EXTRA_DIST 04:43 < bitcoin-git> bitcoin/master 02e5308 MarcoFalke: Merge #9525: test: Include tx data in EXTRA_DIST... 04:43 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9525: test: Include tx data in EXTRA_DIST (master...Mf1701-testINCLUDE) https://github.com/bitcoin/bitcoin/pull/9525 04:58 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection] 04:59 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 05:01 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Ping timeout: 260 seconds] 05:02 < da2ce7> Just tested 'make deploy' from git-head on latest mac. Works without problem :) 05:05 < wumpus> great! 05:09 < fanquake> wumpus any objection to closing 7149 ? 05:12 < wumpus> fanquake: yeah I don't think it's going to be merged as it is 05:14 -!- pavel_ [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 05:17 < fanquake> wumpus yea, open for > 1yr with only 2 comments. 05:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Read error: Connection reset by peer] 05:17 < fanquake> I might close a few older/inactive pull requests. Mentioning that they are of course free to reopen if they wish to restart/continue the work. 05:18 -!- pavel_ [~paveljani@79.98.72.176] has quit [Client Quit] 05:19 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection] 05:19 < bitcoin-git> [bitcoin] fanquake closed pull request #8339: Consensuslib: Block Verify / Transaction Verify [Do not merge, work in progress] (master...blkconsensus) https://github.com/bitcoin/bitcoin/pull/8339 05:23 < bitcoin-git> [bitcoin] fanquake closed pull request #7149: Bugfix: Correctly calculate priority when inputs are mined after dependent transactions enter the memory pool (master...bugfix_priority) https://github.com/bitcoin/bitcoin/pull/7149 05:25 < bitcoin-git> [bitcoin] fanquake closed pull request #8488: Add deleteprivkey and forgetaddress RPC calls (master...forgetaddress-1) https://github.com/bitcoin/bitcoin/pull/8488 05:27 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 05:29 < bitcoin-git> [bitcoin] fanquake closed pull request #8849: print P2WSH redeemScript in getrawtransaction if it s not a pubkey (master...print-p2wsh-redeemscript-in-getrawtransaction) https://github.com/bitcoin/bitcoin/pull/8849 05:35 < bitcoin-git> [bitcoin] fanquake closed pull request #9116: Allow getblocktemlate for not connected regtest node (master...master) https://github.com/bitcoin/bitcoin/pull/9116 05:38 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 05:42 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 260 seconds] 05:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:43 < morcos> wumpus: is your concern with changing -walletrbf this close to 0.14 from a technical safety standpoint or more from a user/community awareness standpoint? 05:44 < wumpus> morcos: both, though mostly the latter 05:44 < wumpus> mostly that people get confused that they're suddenly creating a different kind of transactions with different properties 05:44 < wumpus> without having asked for it 05:45 < wumpus> of course it could be included in the release notes, but the planned release notes for 0.14 will already be huge :) 05:45 < morcos> ok, i agree that maybe it needs more forewarning... but i do think that the problem we'll run into as is, is that people won't have changed the default, they'll have some "stuck" tx and want to bumpfee it and realize they can't 05:45 < fanquake> Yes I'm sure a few things are going to get lost in there already. 05:46 < morcos> so perhaps we should at least make it very clear in the release notes that if you're using a core to send your txs, that you need to change this default in order for bumpfee to be of any use to you 05:46 < wumpus> I think at least in the UI it would e.g. make sense to add a question on the first transaction send after upgrade 05:46 < wumpus> yes 05:47 < bitcoin-git> [bitcoin] fanquake closed pull request #9064: unify capitalization of "bitcoin address" (master...changeCaps) https://github.com/bitcoin/bitcoin/pull/9064 05:47 < wumpus> anywhere bumpfee is mentioned it should be made clear 05:48 < wumpus> also in the RPC help for the funcition, thinking of it 05:50 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 05:54 < wumpus> in any case let's not make merging that functionality dependent on the defaults discussion 05:54 < morcos> sure agreed 05:55 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 240 seconds] 06:07 < morcos> wumpus: suppose i want to add a new option such as rbfflag to an rpc call like sendtoaddress... what is the right way to do that now we have named arguments? 1) add support for holes in sendtoaddress and 2) add a new argument in the last position for rbfflag ? 06:08 < wumpus> morcos: yes, that sounds like the right approach to me 06:08 < morcos> i guess i'm just trying to reconcile some rpc calls having an options argument like bumpfee and some not, so for bumpfee i wouldn't worry about and just add the rbfflag inside the options object? 06:09 < sipa> we should also make the rpc example code use named rgs 06:09 < sipa> *args 06:09 < sipa> and i wonder if we shouldn't first start converting some methods to natively accept names 06:09 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 06:12 < fanquake> Do we really need a nearly 1100 line script to check/maintain copyright headers 06:17 < wumpus> well right now named arugments are completely backwards compatible, and supporting holes also helps people that use positional arguments. It means they can specify 'null' to use the default. 06:17 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 06:17 < wumpus> so adding holes support to a RPC call is good in every way 06:18 < wumpus> fanquake: well as long as the guy maintains it it's fine I guess 06:18 < instagibbs> morcos, I'm up to 20% RTT saved now, syncing with your number 06:20 < fanquake> wumpus I guess. It just seems like something set to degrade. Checking sub-trees also seems like overkill. 06:20 < wumpus> fanquake: checking sub-trees is absolutely overkill 06:20 < fanquake> I'm not sure what the point of that is, as it's not like we're going to modify them also. 06:20 < wumpus> we don't merge any changes to those 06:20 < wumpus> right 06:21 < wumpus> but I suppose that comes by default - it's *avoiding* subtrees that requires extra logic. Or maybe I'm thinking of it wrong. 06:21 < fanquake> I thought you'd be able to just exclude all the files in the subtree dirs. 06:21 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 240 seconds] 06:22 < wumpus> very possible - I don't know what he uses to query the list of files from git 06:24 < fanquake> I am starting to like the idea of adding other types of checking to Travis though. Some discussion in 9452 06:24 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 06:26 < fanquake> Just got to find the balance between not failing on every code change to the point that Travis is never green again, and picking up things like 9487. 06:27 < gmaxwell> Re walletrbf: I could see it going either way. We could write the release note for the bumpfee that just said you have to set walletrbf in advance for it to be useful. 06:28 < gmaxwell> Though I think we can't default to walletrbf unless we have a way to bump to non-rbf. Though I think that would be a trivial change to bumpfee. 06:29 < morcos> gmaxwell: what i said yesterday about using the default in bumpfee doesn't make sense 06:29 < morcos> i don't think you want to be changing the sequence numbers on the tx which may have other meaning unless you specifically indicate that you want to 06:30 < morcos> ryanofsky is going to add an option to bumpfee, and the only time you ever modify the sequence numbers is if the option tells you to specifically change it to not be rbf any more 06:30 < gmaxwell> thats okay with me. 06:31 < morcos> even that though sounds a bit risky to me 06:32 < morcos> what happens when you bump some transaction that was only valid because of its sequence numbers and CSV 06:32 < gmaxwell> well considering we can't sign for such a transaction currently... 06:32 < morcos> we can't? 06:32 < gmaxwell> no, if there is a OP_CSV signrawtransaction won't work, you'd need to be running modified software. 06:33 < Chris_Stewart_5> requires standardness? 06:34 < gmaxwell> jonasschnelli: sorry, darn, must have been a miscommunication. I was nagging before because I was saying I'd start on it if you weren't going to; but if you told me you weren't going to I either didn't get the message or forgot. 06:34 < jonasschnelli> gmaxwell: deadlock. :) 06:35 < jonasschnelli> Should I start to do something or do you want to work on the HD-keypool auto-jump? 06:35 < sipa> Chris_Stewart_5: no, the signing code just doesn't know how to produce a scriptSig for that 06:35 < gmaxwell> jonasschnelli: you should start because I'm going to be travling most of the day and don't know if I'll be productive (e.g. have power). 06:35 < gmaxwell> jonasschnelli: I think it will be simple (famous last words). 06:36 < jonasschnelli> gmaxwell: Okay. Let me try... but I can't start before tomorrow / friday. Not sure if I get something done before the freeze. 06:36 < jonasschnelli> gmaxwell: heh. Okay. 06:37 < Chris_Stewart_5> gotcha. Thanks. 06:39 < morcos> gmaxwell: damn.. i should have known that since i wrote the rpc test... i put the stupid OP_CSV in the scriptSig to test it instead 06:46 < wumpus> fanquake: I'm not against adding checks to travis if they're strongly useful in preventing immediate problems. The only thing I'm sure about is that I don't want copyright header checks in there. 06:47 < fanquake> wumpus agreed. 06:48 < bitcoin-git> [bitcoin] fanquake closed pull request #7823: Add index to wallet UTXO (master...enhancement/cache-unspent-outputs) https://github.com/bitcoin/bitcoin/pull/7823 06:48 < wumpus> the problem really is that travis only has two states (or three?) in any case it has no support for severity levels. This means that someone whose tests fails has to skip through screenfuls of logs to get to the place where the error happened. I wish it had a way to produce a summary instead 06:49 < fanquake> wumpus Yea I wish it just posted the error/log output in the GitHub comment bit. 06:49 < wumpus> well please not the entire thing 06:49 < wumpus> just a summary of points, say e.g. what build step failed and the error message 06:50 < fanquake> Yes not the whole lot, just the last 10 lines or so. 06:50 -!- michiel_ is now known as gielbier_ 06:50 < fanquake> I should be minimized by default too. 06:51 < wumpus> any way to put a custom message in the comment bit would be great, we can handle the rest 06:51 < fanquake> Anything to save looking at 6 different sets of logs. 06:55 < fanquake> Also, are we still manually starting the builds of 7148 06:55 < fanquake> Just noticed Travis now has a Cron Job feature (beta), so maybe we could setup a branch for the extended test suite and have it run by the cron rather than manual trigger. 06:59 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 07:01 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 07:02 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev 07:03 -!- AaronVW [~aaronvw@207pc74.sshunet.nl] has quit [Read error: Connection reset by peer] 07:03 -!- AaronVW [~aaronvw@207pc74.sshunet.nl] has joined #bitcoin-core-dev 07:18 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.] 07:31 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9527: Enable RBF transactions in wallet by default (master...pr/walletrbf) https://github.com/bitcoin/bitcoin/pull/9527 07:49 < bitcoin-git> [bitcoin] practicalswift opened pull request #9528: [trivial] Rename formateNiceTimeOffset(qint64) to formatNiceTimeOffset(qint64) (master...rename-formateNiceTimeOffset) https://github.com/bitcoin/bitcoin/pull/9528 07:50 < gmaxwell> does the github api that travis uses allow comments or something? because the error being able to pass up a comment would be great. 07:55 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 07:56 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 07:57 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection] 08:03 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 08:10 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 08:23 < bitcoin-git> [bitcoin] practicalswift opened pull request #9529: Bug fix: Update the instance variable self.lastDate (not the locally scoped variable lastDate) (master...fix-bug-in-BlockDataCopier) https://github.com/bitcoin/bitcoin/pull/9529 08:37 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 08:41 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:43 -!- Guest53948 is now known as haakonn 08:43 -!- haakonn is now known as Guest46061 08:48 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection] 08:50 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:51 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 08:56 -!- afk11 [~user@unaffiliated/afk11] has joined #bitcoin-core-dev 09:10 < luke-jr> any objections to rebasing #9422 ? 09:10 < gribble> https://github.com/bitcoin/bitcoin/issues/9422 | Refactor mempool.dat to be extensible, and store missing info by luke-jr · Pull Request #9422 · bitcoin/bitcoin · GitHub 09:27 < bitcoin-git> [bitcoin] morcos opened pull request #9531: Release notes for estimation changes (master...relnotes) https://github.com/bitcoin/bitcoin/pull/9531 09:35 -!- arubi [~ese168@gateway/tor-sasl/ese168] has left #bitcoin-core-dev ["Leaving"] 09:35 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 09:38 < bitcoin-git> [bitcoin] practicalswift opened pull request #9532: [trivial] Remove unused variables (master...remove-unused-variables) https://github.com/bitcoin/bitcoin/pull/9532 09:51 -!- drbolardus [8fb00c79@gateway/web/freenode/ip.143.176.12.121] has joined #bitcoin-core-dev 09:55 < btcdrak> luke-jr: go ahead 10:06 -!- cbits [~cbits@47.148.176.74] has joined #bitcoin-core-dev 10:11 -!- cbits [~cbits@47.148.176.74] has quit [Ping timeout: 240 seconds] 10:17 < sipa> i'll be travelling during part of the meeting 10:22 < bitcoin-git> [bitcoin] sipa opened pull request #9533: Allow non-power-of-2 signature cache sizes (master...anysigcachesize) https://github.com/bitcoin/bitcoin/pull/9533 10:36 -!- MarcoFalke [~marco@host63-2.natpool.mwn.de] has joined #bitcoin-core-dev 10:50 -!- Guest46061 is now known as haakonn 10:51 -!- haakonn [~haakonn@146.185.155.218] has quit [Changing host] 10:51 -!- haakonn [~haakonn@pdpc/supporter/active/haakonn] has joined #bitcoin-core-dev 10:56 < BlueMatt> cfields: yea, dunno what to say, then, about your comment on #9375 - personally I like using ABC to be a barrier for best-chain-activated 10:57 < 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 10:58 < cfields> BlueMatt: i'm reasonably convinced that it's harmless as-is, my only fear is that it leads to bugs in the future. Any thoughts on preventing future side-effects there? 10:58 < BlueMatt> I mean I tend to air on the side of it-shouldnt-have-side-effects just because thats how that function /should/ work 10:58 < BlueMatt> :/ 11:00 < wumpus> #startmeeting 11:00 < lightningbot> Meeting started Thu Jan 12 19:00:08 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: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 < kanzure> hi. 11:01 < wumpus> proposed topics? 11:01 < btcdrak> hi 11:01 < michagogo> o/ 11:01 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 11:01 < BlueMatt> 0.14 freeze monday, so lock in prs that will go in now and finalize PR/issue tags for 0.14? 11:01 < jonasschnelli> gmaxwell mentioned yesterday that he's traveling. 11:01 < BlueMatt> feature freeze, of course 11:01 < jtimon> here 11:01 < wumpus> anyone working really hard on getting something in before the feature freeze? 11:02 < BlueMatt> my #9499 and #9375 plus cfields' #9441 are massive 11:02 < gribble> https://github.com/bitcoin/bitcoin/issues/9499 | Use recent-rejects, orphans, and recently-replaced txn for compact-block-reconstruction by TheBlueMatt · Pull Request #9499 · bitcoin/bitcoin · GitHub 11:02 < 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:02 < BlueMatt> and probably close enough to make it 11:02 < gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub 11:02 < luke-jr> would be nice to get multiwallet in, but it's mostly just waiting on review at this point. if we think we can get it in, I will rebase the final PR(s) as soon as the last pre-MW refactor is merged 11:02 < morcos> +1 BlueMatt's list 11:02 < luke-jr> (but IIRC from last meeting, there were more important things than MW that take precedence) 11:02 -!- e4xit [~e4xit@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Quit: Right I'm out!] 11:02 < cfields> wumpus: there's qt 5.7 which is probably worth having in. 11:03 < jonasschnelli> cfields: +1... whats missing? Can I help? 11:03 < wumpus> cfields: I don't understand the blocker there 11:03 < BlueMatt> luke-jr's multiwallet would have been nice, but we're at least two prs away...#8775 could probably be merged easily, but the one thereafter hasnt really gotten any review yet :( 11:03 < 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:04 < wumpus> yes #9441 should be ready for merge really 11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub 11:04 < btcdrak> +1 on multiwallet 11:04 < cfields> wumpus: i did some work on a bump+restructure a while back, and fanquake recently bumped but it's a bit broken. We just need to pull the fixes out of mine and into his. Should be quick/easy, it's just the building that takes a while 11:04 < BlueMatt> btcdrak: my point was I dont think thats gonna make it 11:04 < cfields> (re qt 7.1) 11:04 < cfields> er, 5.7. heh. 11:05 < BlueMatt> would have to turn out to get acks without any comments on the final multiwallet pr, I think 11:05 < BlueMatt> unless we decide we super want it and are willing to let it go in post-feature-freeze 11:05 < wumpus> forget about multwallet for 0.14 11:05 < jonasschnelli> Yes. It's probably to late 11:05 < BlueMatt> yup 11:05 < wumpus> it's a pity but let's just merge that stuff after the 0.14 split 11:05 < jonasschnelli> Yes. No hurry. 11:06 < wumpus> then it has ample time to be tested in master, which it needs 11:06 < cfields> jonasschnelli: happy to have help, sure. Let's discuss after meeting. 11:06 < jonasschnelli> ok 11:06 < wumpus> it's not something that is safe to merge last minute before a release and let people figure it out in a rc :) 11:06 < BlueMatt> havent looked at the diff, but I'd call #9519 a bugfix, so should go in post-monday 11:06 < gribble> https://github.com/bitcoin/bitcoin/issues/9519 | Exclude RBF replacement txs from fee estimation by morcos · Pull Request #9519 · bitcoin/bitcoin · GitHub 11:06 < BlueMatt> morcos: should we tag that 0.14? 11:06 < luke-jr> ACK not doing MW in 0.14 11:06 < morcos> Yes I talked about it a while this morning with sdaftuar. We should do it for 0.14 11:07 < morcos> It's a very minor change 11:07 < wumpus> yes bugfixes can be merged after the feature freeze, will tag it 11:07 < BlueMatt> #9512 is probably a 0.14 bugfix that should be tagged 11:07 < gribble> https://github.com/bitcoin/bitcoin/issues/9512 | Fix various things -fsanitize complains about by sipa · Pull Request #9512 · bitcoin/bitcoin · GitHub 11:07 < achow101> there's also the final alert stuff that's supposed to go in 0.14 11:08 < wumpus> #9512 a bugfix? 11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9512 | Fix various things -fsanitize complains about by sipa · Pull Request #9512 · bitcoin/bitcoin · GitHub 11:08 < morcos> I think we should merge #9380 for 0.14 as well, or at least the part that breaks out the -dustrelayfee 11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9380 | Separate different uses of minimum fees by morcos · Pull Request #9380 · bitcoin/bitcoin · GitHub 11:08 < BlueMatt> wumpus: I mean I'd call code correctness bugfixes even if there are no bugs 11:08 < wumpus> I don't really like the perf hit 11:08 < BlueMatt> wumpus: assuming we can fix the performance hit? 11:08 < wumpus> normally I woudln't mind but hashing is very important to bitcoind performance 11:09 < sdaftuar> regarding 9512, sipa just told me (he's walking out the door) that he can make it a very slight performance improvement... but i guess he hasn't pushed that yet 11:09 < BlueMatt> I know gmaxwell wanted #9484 for 0.14, which I think it should be 11:09 < gribble> https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub 11:09 < wumpus> I had hoped to work on platform specific implementations for sha256, but anyhow, that won't make 0.14 and we shouldn't make the default implementation slower than necessary either 11:09 < BlueMatt> wumpus: ok, lets punt on 9512 for now, then 11:09 < BlueMatt> can decide later 11:10 < morcos> Can we discuss briefly the concept of dust being tied to minrelaytxfee 11:10 < wumpus> BlueMatt: yeah unless there's something that introduces an actual bug (I don't even understand all the change in it - e.g. asked about the change from LONG_MAX to 1<<40) 11:10 < BlueMatt> so things that need review before monday: 9484, 9499, 9375, 9441 11:10 < wumpus> morcos: sure, next topic 11:10 < sipa> wumpus: i'm running to catch a bus, but i believe i have a slightly faster-than-master but sanitize-correct version of ReadLE32 etc 11:10 < wumpus> #action review before monday : 9484, 9499, 9375, 9441 11:10 < wumpus> sipa: great! 11:11 -!- str4d [~str4d@cable-185.30.54.182.coditel.net] has joined #bitcoin-core-dev 11:11 < sipa> and by faster i mean 0.025% 11:11 < BlueMatt> heh 11:11 < morcos> I want to motivate why its important to consider #9380 as well. At least one of the commits there has translation strings.. do we translate debug help? 11:11 < gribble> https://github.com/bitcoin/bitcoin/issues/9380 | Separate different uses of minimum fees by morcos · Pull Request #9380 · bitcoin/bitcoin · GitHub 11:11 < wumpus> well "not slower" would be the goal so anything faster is doubly awesome 11:11 < BlueMatt> wumpus: wait, which PR was the LONG_MAX comment in reference to? 11:12 < wumpus> BlueMatt: #9512 IIRC 11:12 < gribble> https://github.com/bitcoin/bitcoin/issues/9512 | Fix various things -fsanitize complains about by sipa · Pull Request #9512 · bitcoin/bitcoin · GitHub 11:12 < BlueMatt> wumpus: ahh, yea, admittedly I havent read the code there yet, beyond very brief skimming 11:12 < BlueMatt> morcos: go ahead? 11:12 < cfields> yes, it's in the CScriptNum tests 11:13 < morcos> Sorry I was confused as to whether I was waiting for "topic:" or not.. Anyway. The point is that right now if a miner changes the -minrelaytxfee, this already automatically changes their definition of dust. This occasionally leads to txs with high feerates not being minable by some portion of miners 11:13 < wumpus> yes https://github.com/bitcoin/bitcoin/pull/9512/files#diff-2513c35abb5ab245137423db2d803628R17 11:14 < MarcoFalke> wumpus: Set topic for morcos? 11:14 < wumpus> morcos: oh yes forgot that - current topic is still what to do before the feature freeze 11:14 < wumpus> #topic the concept of dust being tied to minrelaytxfee 11:14 < BlueMatt> morcos: ahh, ok, I'd call that a bugfix that we can do post-feature-freeze? but sounds like something that should be fixed 11:14 < BlueMatt> (I assume code is realatively trivial) 11:14 < morcos> BlueMatt: what about the transaltion strings 11:15 < BlueMatt> wumpus: ? 11:15 < MarcoFalke> morcos: Those are "hidden" features? So no translation string 11:15 < MarcoFalke> I'd recommend against exposing -dustfeerate 11:15 < MarcoFalke> to every user 11:16 < MarcoFalke> Maybe not even at all. Just make it a const in the code. 11:16 < wumpus> yes, translation freeze is at the same time as feature freeze 11:16 < morcos> MarcoFalke: ok, in that PR, -blockmintxfee was not hidden, specifically intended to be used by miners... But yes -dustrelayfee is hidden. And I agree, it shouldn't be changed by anyone. 11:16 < wumpus> but if it's a debug feature it won't have translation strings, ofc 11:16 < morcos> I suppose if we merge it too late, we can start with all features hidden and expose them next version 11:16 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection] 11:17 < BlueMatt> ehh, I'd say the diff is pretty trivial, lets just target it for monday? 11:17 < BlueMatt> (at the risk of piling on top of the other 4) 11:17 < morcos> Anyhway there are 2 potential problems: 1, a users txs are stuck for reasons they don't understand, but potentially more seriously it hurts fee estimation... 11:17 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 11:18 < morcos> I actually do agree with luke-jr that ideally fee estimation will be more robust to this... but considering we dont' see much value in having different nodes have different definitions of dust. It seems a no-brainer to fix that so it doesn't change anytime someone is trying to avoid spammy low-fee txs 11:19 < luke-jr> morcos: eh, is it based on your own fee, or the relay min fee? I thought the latter 11:19 < morcos> luke-jr: dust is based on minrelayfee, but people change minrelayfee to avoid spam or limit their mempool and inadvently change dust in teh process 11:20 < luke-jr> ah 11:20 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:21 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 11:21 < morcos> OK, I'm done.. Just wanted to be sure this was flagged before it was too late... seems like we could merge some version after feature freeze if we had to.. , anyway, someone please tag 9380 for 0.14 as well 11:22 < wumpus> ok 11:22 < BlueMatt> lets add it to the list for monday and if it slips thats ok 11:22 < BlueMatt> wumpus/sdaftuar/morcos should #8456 be un-tagged for 0.14? probably #8501 should be. I dont think we're gonna make #8654 or #8723 or #8755 either 11:22 < gribble> https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub 11:22 < gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub 11:22 < gribble> https://github.com/bitcoin/bitcoin/issues/8654 | Reuse sighash computations across evaluation (rebase of #4562) by jl2012 · Pull Request #8654 · bitcoin/bitcoin · GitHub 11:22 < gribble> https://github.com/bitcoin/bitcoin/issues/8723 | [Wallet] Add support for flexible BIP32/HD keypath-scheme by jonasschnelli · Pull Request #8723 · bitcoin/bitcoin · GitHub 11:22 < gribble> https://github.com/bitcoin/bitcoin/issues/8755 | Implement excessive sighashing protection policy with tight sighash estimation by jl2012 · Pull Request #8755 · bitcoin/bitcoin · GitHub 11:22 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 11:23 < jonasschnelli> Yes. We should 11:23 < jl2012> yes, leave 8654 and 8755 for later 11:23 < BlueMatt> jonasschnelli: do you have a strong desire for #9294? 11:23 < 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:23 < morcos> I think 8456 can make it... The others maybe not 11:23 < jonasschnelli> Yes. 9294 must go in! 11:23 < BlueMatt> morcos: its kinda light on ACKs to get merged this weekend, no? 11:23 < jonasschnelli> Needs review. Has only a single utACK 11:23 < BlueMatt> jonasschnelli: looks like it needs rebase? 11:23 < jonasschnelli> We should also tag #9377 11:23 < gribble> https://github.com/bitcoin/bitcoin/issues/9377 | fundrawtransaction: Keep change-output keys by default, make it optional by jonasschnelli · Pull Request #9377 · bitcoin/bitcoin · GitHub 11:24 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:48f3:61a8:9c35:5348] has quit [Quit: .] 11:24 < BlueMatt> grrr, this list is a bit long for 4 days incl a weekend... 11:24 < jonasschnelli> Oh. Yes. Needs rebase (since today) 11:24 < wumpus> agree on 8456 may still make it, I think the only discussion there is about the default value for walletrbf and that's unnecessary to decide there 11:24 < luke-jr> maybe we should split up the list between different people? 11:24 < wumpus> yes, it's not going to all make it 11:24 < luke-jr> we don't all have to review the same stuff 11:24 < wumpus> as I've said last week we should really make a choice 11:24 < wumpus> instead of trying to cram everything in 11:24 -!- drbolardus [8fb00c79@gateway/web/freenode/ip.143.176.12.121] has quit [Quit: Page closed] 11:25 < BlueMatt> luke-jr: we dont have enough reviewers for that to work well enough :( 11:25 < jonasschnelli> 9377 is a bugfix and can go in later 11:25 < jonasschnelli> But please review 9294,.. is a sensitive wallet thing 11:25 < BlueMatt> and I think gmaxwell and sipa are on the road, plus I'm avoiding review at least until my cold is a bit better and I can think straight 11:25 < luke-jr> :< 11:25 < wumpus> especiall for the wallet it seems getting reviewers is really hard 11:25 < BlueMatt> yes :( 11:25 < bitcoin-git> [bitcoin] losh11 opened pull request #9534: Statoshi (master...master) https://github.com/bitcoin/bitcoin/pull/9534 11:26 < bitcoin-git> [bitcoin] losh11 closed pull request #9534: Statoshi (master...master) https://github.com/bitcoin/bitcoin/pull/9534 11:26 < cfields> that one's done! 11:26 < jtimon> I'm afraid I will prioritize the ones that are easier for me to review either way 11:26 < jonasschnelli> sure 11:26 < luke-jr> wallet needs the most review after consensus-critical changes, too 11:27 < jtimon> jonasschnelli: is the fact that 9377 is a bugfix a good reason to delay it? 11:27 < jonasschnelli> jtimon: delay,.. more priorize because of the freeze. 11:27 < BlueMatt> 9377 needs rebase 11:27 < jonasschnelli> But 9377 fixes a address reuse problem ans should be in 0.14 11:28 < luke-jr> jonasschnelli: how important is it to get 9294 in 0.14 as opposed to 0.15? should I prioritise it over the other reviews? 11:28 < jonasschnelli> It somehow feels that all my PR needs rebase since today. 11:28 < BlueMatt> ok, 9377 looks like a bugfix that can go in after monday...looks like an easy diff too 11:28 < BlueMatt> can someone tag it? 11:28 < luke-jr> jonasschnelli: heh, I rebased something yesterday and had to re-rebase it again today XD 11:28 < jonasschnelli> 9294 should be in 0.14 because we should avoid creating more single-chain HD wallets 11:28 < sipa> made it to the bus! 11:29 < luke-jr> jonasschnelli: can it upgrade single-chain HD wallets? 11:29 < jonasschnelli> No 11:29 < jonasschnelli> That's why it should be in 0.14 11:29 < luke-jr> is there a reason it cannot? 11:29 < jonasschnelli> You can't split the hd chains once you have created change outputs on the external chain... 11:29 < wumpus> jonasschnelli: that's a good point 11:29 < jonasschnelli> well... not with consequences. 11:29 < BlueMatt> sipa: yay! 11:29 < jonasschnelli> like re-seed 11:29 < morcos> and HD isn't released yet? 11:30 < jonasschnelli> it is. 11:30 < instagibbs> HD is already in 0.13 11:30 < wumpus> so from the wallet features we should focus on getting #9294 in 11:30 < jonasschnelli> Since 0.13 11:30 < 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:30 < luke-jr> jonasschnelli: I don't understand why not. Maybe we should discuss this further after the meeting? 11:30 < morcos> Ok so its a matter of not makign it worse then 11:30 < wumpus> yes it is, but uses a single chain, which is inconvenient for reconstruction from a seed 11:30 < jonasschnelli> Yes. 11:30 < sipa> luke-jr: recovery from a seed won't correctly identify change 11:30 < sipa> that's all 11:30 < jonasschnelli> The change is not complex, but also not trivial 11:31 < sipa> are there other wallet related changes we want to see in 0.14 11:31 < sipa> ? 11:31 < sipa> jonasschnelli: ? 11:31 < jonasschnelli> gmaxwell and I like to have the keypool detecting in 0.14 11:31 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:65d7:c8cb:dd71:37b7] has joined #bitcoin-core-dev 11:31 < jonasschnelli> But not sure if its too late 11:31 < luke-jr> what happens if I try to recover from a seed generated from a current HD wallet? ;) 11:31 < sipa> i think that is too laye 11:31 < jonasschnelli> Yes. It feels like 11:31 < jtimon> jonasschnelli: how #9294 works with #8723 ? 11:31 < 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:31 < gribble> https://github.com/bitcoin/bitcoin/issues/8723 | [Wallet] Add support for flexible BIP32/HD keypath-scheme by jonasschnelli · Pull Request #8723 · bitcoin/bitcoin · GitHub 11:32 < luke-jr> jonasschnelli: that's a bugfix IMO 11:32 < luke-jr> or potentially a bugfix, at least 11:32 < jonasschnelli> 8723 has no reviews. 11:32 < jonasschnelli> To late for 0.14 IMO 11:32 < sdaftuar> jonasschnelli: can you remind us what keypool detecting is? 11:32 < jtimon> but have you thought about how they would combine? 11:32 < instagibbs> luke-jr, we have no direct recovery tools from seed AFAIK 11:32 < sipa> sdaftuar: the wallet marking keys as used once they are seen in a transaction 11:32 < jtimon> independently of which one goes first 11:32 < instagibbs> current flow is ~same as before 11:32 < luke-jr> instagibbs: but presumably we will be adding one 11:32 < jonasschnelli> sdaftuar: if you use an old backup... you want to autodetect keys already been used. 11:33 < instagibbs> luke-jr, indeed, which is why split will be important, right? 11:33 < sdaftuar> got it, thanks 11:33 < jonasschnelli> We need to check the keypool keys during SyncTransaction (each input/output) and mark the key as used when we have a match 11:33 < jonasschnelli> Otherwise you re-use keys. 11:34 < jonasschnelli> (if you don't topup your keypool +1000 and do a rescan before you use your old backup) 11:34 < luke-jr> instagibbs: perhaps. but nothing stops someone from recovering from a pre-split seed? 11:35 < jonasschnelli> luke-jr: yes. But we should at least stop creating wallets with change and normal-addresses on the same chain. 11:35 < luke-jr> jonasschnelli: not disputing that. 11:35 < jonasschnelli> Flexible keypath is nice.. but too late for 0.14. 11:36 < jonasschnelli> The sad thing is, it will be another feature that is not downward compatible. 11:36 < jonasschnelli> 0.13 HD, 0.14 HD/split, 0.15 flex-keypath 11:36 < jonasschnelli> All not backward comp. 11:36 < sipa> meh. 11:36 < jonasschnelli> Yes. Meh. 11:36 < jonasschnelli> That's why I'd like combining the HD split with other stuff. 11:36 < luke-jr> surely at least HD/split can be upgraded to flex-keypath⁇ 11:36 < sipa> breaking backward compatibility in major releases is fine 11:37 < instagibbs> Yeah why can't we upgrade to keypath? 11:37 < jonasschnelli> Okay. 11:37 < jonasschnelli> You can upgrade to keypath, but not downgrade 11:37 * instagibbs should have actually reviewed, my bad 11:37 < jonasschnelli> Use a 0.15 wallet in 0.14 as an example 11:37 < jonasschnelli> But maybe its not so bad. 11:37 < luke-jr> upgrade-only is okay. we have -walletupgrade for that 11:38 < wumpus> don't you mean forwards compatible? backwards compatible means that it can use old wallets, which should always be possible 11:38 < jonasschnelli> wumpus: right. My fault. 11:38 < sipa> backward compatible means that old software can use new wallets 11:38 < wumpus> but being able to use a new wallet with an old major version is not 11:38 < wumpus> huh? 11:38 < jonasschnelli> perspetive thing. :) 11:38 < wumpus> I thought the other way around. 11:38 < jonasschnelli> *perspective 11:39 < sipa> forward compatible is what you normally always have 11:39 < wumpus> I don't understand it anymore then 11:39 < instagibbs> wallet.dat vs Core wallet relativity... 11:39 < sipa> oopz 11:39 < CodeShark> Walllet format vs. Wallet app 11:39 < luke-jr> I think we have more cases than normal 11:39 < sipa> maybe i am wrong too 11:39 < jonasschnelli> Looking at the git history tells me, that we took good care about the fact that you can run a newer wallet on an older bitcoin-core version 11:39 < sipa> i will shut up 11:39 < jonasschnelli> And now we break that in 0.13, 0.14 and probably 0.15. 11:40 < jonasschnelli> But fine for me. 11:40 < instagibbs> jonasschnelli, OTOH, these are the kind of upgrades people desperately want... 11:40 < instagibbs> for future work 11:40 < wumpus> jonasschnelli: well in my opinion that doesn't matter too much. What is important is that if you open a wallet once with the new version you should still be able to downgrade 11:40 < luke-jr> jonasschnelli: there have been cases where -walletupgrade is needed, and then the wallet ceases to work in old versions 11:40 < CodeShark> wallet format is forward compatible, wallet app is backward compatible 11:40 < wumpus> jonasschnelli: however, new wallets created with new versions don't need to be open-able with old versions 11:40 < jonasschnelli> Okay. Seems that we all agree. Good. 11:40 < morcos> wumpus: +1 for those standards 11:41 < wumpus> we're just trying to avoid that *touching* a wallet with a new version automatically makes it incompatible, which would happen when upgrading berkeleydb for example 11:41 < jonasschnelli> Flexible keypath is nice. But we don't want to support BIP44 anyways thats why it's not urgent 11:41 < jtimon> all these backards and forwards compatibility is confusing, softfork and hardforks are much more clear :p 11:41 < petertodd> jtimon: +1 11:41 < luke-jr> we should also avoid making it incompatible unintentionally; only if -walletupgrade is enabled should we bump the feature requirements of a wallet 11:41 < luke-jr> jtimon: lol 11:42 < luke-jr> eg, if someone tries to use the flex-keypath, throw an error instead of upgrading the wallet (unless option is enabled0 11:45 < BlueMatt> ok, list for monday: 9380 (if it slips that ok, but prefer monday), net-related: 9441, 9375, 9499 (can someone tag 9499), 9486. wallet related: 9294, 8456 (are you sure that can make it sdaftuar/morcos?) 11:45 < BlueMatt> well, ok, 9486 is whatever, its trivial 11:45 < sdaftuar> BlueMatt: i think 8456 ought to be done, though it is true that gmaxwell keeps finding small issues 11:45 < CodeShark> Please no use of the terms "evil compatibility" or "backward-forward compatibility" 11:45 < BlueMatt> everything else tagged looks like a bugfix (#9490 is, right?) 11:45 < gribble> https://github.com/bitcoin/bitcoin/issues/9490 | Replace FindLatestBefore used by importmuti with FindEarliestAtLeast. by gmaxwell · Pull Request #9490 · bitcoin/bitcoin · GitHub 11:46 -!- afk11 [~user@unaffiliated/afk11] has quit [Ping timeout: 240 seconds] 11:46 < sdaftuar> yes that is a bugfix 11:46 < sipa> is #9484 on the list? 11:46 < gribble> https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub 11:46 < BlueMatt> jonasschnelli: whats up with #9461? 11:46 < gribble> https://github.com/bitcoin/bitcoin/issues/9461 | [Qt] Improve progress display during headers-sync and peer-finding by jonasschnelli · Pull Request #9461 · bitcoin/bitcoin · GitHub 11:46 < jtimon> lol evil compatibility 11:46 < BlueMatt> sipa: oops, yes, add that to the list 11:46 < jonasschnelli> BlueMatt: simple change. Hope we can get it into 0.14 11:46 < jonasschnelli> Needs review 11:46 < BlueMatt> ok, list for monday: 9380 (if it slips that ok, but prefer monday), 9484, net-related: 9441, 9375, 9499 (can someone tag 9499), 9486. wallet related: 9294, 8456 (are you sure that can make it sdaftuar/morcos?) 11:46 < luke-jr> BlueMatt: do an `action` thing with the final list? 11:46 < instagibbs> someone with the meeting hammer has to do that i think 11:47 < luke-jr> O.o 11:47 < BlueMatt> that list is much too long :( 11:47 < wumpus> I've tagged 9499. Though we should stop tagging more stuff for monday. 11:47 < morcos> BlueMatt: nah... we can do all those 11:47 < BlueMatt> lol 11:47 < wumpus> we're not going to make the current list 11:47 < morcos> I think they are almost all ready for merge except perhaps 9294 11:47 < luke-jr> maybe we should sort the list by priority 11:47 < luke-jr> otherwise we're liable to work on opposite ones first and get none done 11:47 < BlueMatt> i dont think 8456 is gonna make that, either 11:48 < morcos> in 2 hours it'll have 2 ACK's, but if it doesn't make it, thats fine 11:48 < cfields> BlueMatt: what do you think about pulling out your net lock change from #9419 for inclusion? I've been assuming that would make it in in one way or another 11:48 < gribble> https://github.com/bitcoin/bitcoin/issues/9419 | Stop Using cs_main for CNodeState/State() by TheBlueMatt · Pull Request #9419 · bitcoin/bitcoin · GitHub 11:48 * sipa imagines creating a few sockpuppet accounts on github now 11:48 < sipa> *morcos 11:48 < jonasschnelli> heh 11:48 < BlueMatt> wumpus: 9499 was deliberately written to be as easy to review as possible (for 0.14)...there are tons of things to make it better, but they were all left 11:48 < luke-jr> sipa: that'd violate github tos :P 11:48 < cfields> (it belongs in 9441, i just left it out because you already had one) 11:49 < jonasschnelli> luke-jr: depends how many kids you have 11:49 < BlueMatt> cfields: oh fuck I forgot about the cs_vSend split there 11:49 < jtimon> 9380 seems easy to review, more about deciding what to expose now and what to leave for later 11:49 < BlueMatt> argh, well I can open it in its own pr, but that one's gonna be a rush if we want it 11:49 < BlueMatt> it is a huge win, though :/ 11:49 < luke-jr> jonasschnelli: account terms #1 You must be 13 years or older to use this Service. 11:49 < gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub 11:49 < luke-jr> … 11:50 < sipa> hah 11:50 < jonasschnelli> heh 11:50 < cfields> BlueMatt: indeed. I think it's quite simple, though 11:51 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 11:51 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 11:51 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 11:51 < jtimon> any other topics? 11:51 < jtimon> 10 min 11:52 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9535: Split CNode::cs_vSend: message processing and message sending (master...2017-01-cs-vsend-split) https://github.com/bitcoin/bitcoin/pull/9535 11:52 < cfields> BlueMatt: thanks. Will scrutinize. 11:53 < BlueMatt> wumpus: dont kill me, but ^ is kinda worth doing for monday :( 11:54 < wumpus> they're all worth doing, that's not the question 11:54 < luke-jr> it's not the end of the world if we don't have all optimisations in for 0.14 >_ true 11:54 < wumpus> agree luke-jr 11:55 < wumpus> let's leave something for 0.15 11:55 < BlueMatt> oh I've got lots for 0.15 already :p 11:55 < wumpus> of which at least half will probably miss 0.15 and only make it to 0.16 :) 11:55 < BlueMatt> oh yea 11:55 < BlueMatt> always do 11:55 < luke-jr> XD 11:56 < luke-jr> it's not like we have 3 years between releases ☺ 11:56 < wumpus> that's how it goes, there's no other way if you have time based releases 11:56 < BlueMatt> anyway, so lets call the meeting? 11:56 < wumpus> and without a deadline we'd never agree what to put in a release and never again do a release 11:56 < luke-jr> what's the phone number? 11:56 < BlueMatt> wumpus: ooo, I vote for that one 11:56 < luke-jr> lol 11:56 < wumpus> yes, I think we're out of topics 11:56 < wumpus> #endmeeting 11:56 < lightningbot> Meeting ended Thu Jan 12 19:56:56 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 11:56 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-12-19.00.html 11:56 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-12-19.00.txt 11:56 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-12-19.00.log.html 11:57 < BlueMatt> no more releases, just keep putting things in :) 11:57 < luke-jr> nobody did a #action with the PR list 11:57 < luke-jr> did anyone sort it? 11:57 < BlueMatt> ehh, whatever 11:57 < luke-jr> if nobody sorts it for me, I'm just going to review them in random order <.< 11:58 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 11:58 < jtimon> luke-jr: they're ordered by appearence in the link above ^ 11:59 < BlueMatt> cfields: to finish our discussion from pre-meeting: I'm not sure what to do here...I dont think having a WaitForSync() barrier is sufficient, I can add lots of comments everywhere noting potential issues for reviewers to see on future prs? 12:00 < cfields> BlueMatt: deal. 12:00 < cfields> it'll get solved as part of parallel processing 12:01 < BlueMatt> not really? 12:01 < BlueMatt> i mean its not going away 12:02 < cfields> BlueMatt: i mean as part of SendMessages dissolving into more event-based sends 12:03 < BlueMatt> how does that fix this? 12:04 -!- cbits [~cbits@2607:f380:a61:650:ed85:f0b8:3d4a:ac1c] has joined #bitcoin-core-dev 12:04 < cfields> BlueMatt: for ex, BlockChecked could unblock all sends waiting on full verification 12:04 < luke-jr> (FWIW, my prioritised list I will be using is: 9294, 8456, 9499, 9375, 8441, 9486, 9484, 9380) 12:05 < cfields> (not thought through, just an off-the-cuff approach) 12:07 -!- cbits [~cbits@2607:f380:a61:650:ed85:f0b8:3d4a:ac1c] has quit [Read error: Connection reset by peer] 12:10 < BlueMatt> cfields: yes, possibly 12:12 < instagibbs> luke-jr, 8441 is some merged thing from august.. 12:12 < luke-jr> oops *goes to find what he meant to put there* 12:13 < cfields> luke-jr: 9441 i assume 12:13 < luke-jr> yep 12:13 < instagibbs> crisis averted 12:15 * luke-jr wishes 9294 was multiple commits :x oh well 12:15 < BlueMatt> cfields: is that sufficient for #9375? 12:15 < 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 12:17 < BlueMatt> sipa: want to ack #9375? 12:17 < 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 12:17 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 12:19 < cfields> BlueMatt: that works, thanks 12:20 < sipa> wumpus: i wonder if you should choose randomized feature freeze dates, and not announce them in advance 12:21 < BlueMatt> lol 12:21 < BlueMatt> probably 12:21 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 255 seconds] 12:21 < sipa> BlueMatt: going to look over 9375 again soon 12:40 -!- str4d [~str4d@cable-185.30.54.182.coditel.net] has quit [Ping timeout: 240 seconds] 12:50 < luke-jr> it kinda scares me that some failure cases of ReserveKeyFromKeyPool are non-obvious and requires explicit checking. would anyone mind if I made it throw an exception instead? jonasschnelli BlueMatt 12:51 < bitcoin-git> [bitcoin] practicalswift opened pull request #9536: [trivial] Remove unused int64_t nSinceLastSeen (master...remove-unused-variable-nSinceLastSeen) https://github.com/bitcoin/bitcoin/pull/9536 12:52 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 13:00 < bitcoin-git> [bitcoin] practicalswift closed pull request #9536: [trivial] Remove unused int64_t nSinceLastSeen (master...remove-unused-variable-nSinceLastSeen) https://github.com/bitcoin/bitcoin/pull/9536 13:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 13:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 13:09 -!- [Author] [~Author]@2401:a400:3200:5600:bad:d09:15:90d] has quit [Read error: Connection reset by peer] 13:11 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds] 13:11 < BlueMatt> luke-jr: i havent looked at that code in a long time, happy to review a pr, though :; 13:11 < BlueMatt> :p 13:18 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 13:20 < bitcoin-git> [bitcoin] luke-jr opened pull request #9537: Wallet: Refactor ReserveKeyFromKeyPool for safety (master...refactor_wallet_RKFKP) https://github.com/bitcoin/bitcoin/pull/9537 13:23 < bitcoin-git> [bitcoin] practicalswift opened pull request #9538: [trivial] Remove redundant call to get() on smart pointer (thread_specific_ptr) (master...remove-redundant-get-on-smartptr) https://github.com/bitcoin/bitcoin/pull/9538 13:27 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 255 seconds] 13:30 < BlueMatt> cfields: sorry, found two more issues in 9441 13:30 < BlueMatt> :( 13:30 < cfields> BlueMatt: yep, looking them over now 13:32 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: leaving] 13:32 < cfields> BlueMatt: iirc i was unhappy about the placement of setting fPauseSend, but left it alone for the sake of not being a moving target. happy to fix that. 13:33 < BlueMatt> well right now its technically wrong 13:33 < BlueMatt> soooo 13:33 < BlueMatt> if someone set a stupid low nSendBufferMaxSize it might actually be triggerable, though maybe not 13:34 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 255 seconds] 13:34 < jeremyru1in> is there a good reason why validation.h should not include consensus/consensus.h? 13:34 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 13:34 < BlueMatt> no? 13:35 < jeremyru1in> (ok, was making some derived constants that belong in validation.h) 13:41 < instagibbs> morcos, what kind of performance boost does the caching give? (asking the obvious re:relay cmpct) 13:42 < morcos> the act of looping through your peers and announcing blocks to them is now much faster that the block is cached, as well as responding to getdata's for the cmpctblock or blocktxn messages 13:42 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 13:42 < morcos> it greatly decreases the processing time for relay 13:43 < BlueMatt> massively so, in fact 13:44 < BlueMatt> luckily sipa's last round on 9375 was all pretty minor stuff 13:44 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 13:46 -!- AaronVW is now known as AaronvanW 13:47 -!- AaronvanW [~aaronvw@207pc74.sshunet.nl] has quit [Changing host] 13:47 -!- AaronvanW [~aaronvw@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 13:47 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 13:52 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 240 seconds] 13:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 13:56 < bitcoin-git> [bitcoin] practicalswift opened pull request #9539: [trivial] Avoid initialization to a value that is never read (master...avoid-initialization-to-a-value-that-is-never-read) https://github.com/bitcoin/bitcoin/pull/9539 13:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 14:00 < cfields> BlueMatt: yep, you're right. 14:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 14:03 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 14:04 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 14:06 < cfields> lol, "git commit --amen" worked 14:06 < cfields> praise be. 14:06 < BlueMatt> wut 14:06 < cfields> typo'd 'git commit --amend' 14:07 < BlueMatt> lol, someone left that in as a easteregg 14:07 < BlueMatt> not in man-page 14:07 < gmaxwell> yep, git commit --amen works. 14:07 < BlueMatt> someone go file a bug and ruin their fun :P 14:07 < BlueMatt> confirmed: easter egg works here too 14:07 < gmaxwell> I don't know if its an easter egg or just 'shortest unambigious prefix is accepted for maximum forward incompatiblity' 14:08 < sdaftuar> cfields: in CConnMan::Interrupt(), why is there a lock protecting flagInterruptMsgProc? it's an atmoic that doesn't seem to be protected by a lock anywhere else (unless i'm just badly confused about how all this works) 14:08 < cfields> seems to be that. --ame works too. 14:08 < BlueMatt> i could totally see git pulling shit like that :( 14:08 < BlueMatt> ffs 14:09 < sipa> BlueMatt, gmaxwell: pretty sure any unambiguous prefix is intentionally accepted 14:09 < sipa> sdaftuar: you need a lock for the condition variable anyway 14:10 < cfields> right, it's for the condvar 14:11 < cfields> sdaftuar: I was thinking the same thing as you. BlueMatt and i debated that. I lost hard. 14:11 < sdaftuar> but we release the lock before calling condMsgProc.notifyAll(), don't we? 14:11 < BlueMatt> sdaftuar: you cannot use a condvar without a lock. 14:12 < cfields> sdaftuar: need to lock regardless, may as well stick the wake condition in it. Notifying while locked would be a pessimism, though. 14:13 < BlueMatt> said lock has to be released after updating the wakeup condition, and either held during, or released before the wakeup call. (it can, optionally, be taken entirely after updating the wakeup condition) 14:13 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 14:14 < sdaftuar> if i understand right, we acquire lock, set the variable, release the lock, then do the notify_all() (which internally is acquiring and releasing as well)? 14:15 < sdaftuar> is that correct? 14:15 < BlueMatt> gmaxwell: my reasoning for requesting a month timeout on 9484 instead of a week was that if software were to be shipped with a bad hash I'd feel much better if it required the attacker create a month of blocks on top of the invalid one and stay ahead of the longest chain than only a week 14:15 < BlueMatt> sdaftuar: notify_all does not acquire or release a lock, or, it does not need to per the spec, it might very well internally 14:15 < BlueMatt> std::condition_variable_any definitely does 14:16 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 14:17 < sipa> sdaftuar: *waiting* on a condvar requires a lock 14:17 < sdaftuar> ok, i remain deeply puzzled, but i will worry about this when i'm at my desk again 14:17 < sipa> signalling can happen by anyone, anytime 14:18 < BlueMatt> sdaftuar: specifically, whie technically implementing the "unlock+wait is a single atomic action" will require a lock, it will require a lock that is intimately connected with the kernel's thread_waiting stuff in order to not have weird corner cases that are really non-performant 14:19 < gmaxwell> BlueMatt: anyone who can create more than a day of bad blocks is already reversing third party transations and stealing coins from arbritary people. 14:19 < BlueMatt> gmaxwell: I absolutely am confident you could easily get a massive chunk of the network hashpower for a day or two 14:20 < BlueMatt> I am much less confident you could hold it for a week...and if you give it time to reorg back to a valid chain a month makes me feel better :p 14:20 < gmaxwell> BlueMatt: great 7 days is 7 times a day. 14:21 < BlueMatt> if you have like 75% for two days, then it trails off for a few days as folks recover, you may end up staying ahead for a week or so 14:22 < gmaxwell> keep in mind this also requires the vendor to ship a bad hash, seriously, you're arguing against removing the feature. 14:22 < gmaxwell> the argument PT gave is that its harmless because the hash is much easier to audit/review than virtually any of the other code. 14:22 < BlueMatt> huh? I mean if a month is a massive sync-time feature then I'm fine with leaving it, but I dont think it is? 14:23 < BlueMatt> I could absolutely see the hash getting changed in the middle of an rc, everyone saying "meh, i guess thats ok", building happening, and then it getting discovered mid-gitian-phase 14:24 < BlueMatt> belt-and-suspenders, yo 14:24 < BlueMatt> s/massive sync-time feature/massive sync-time difference/ 14:24 < gmaxwell> on my laptop a month of blocks takes 2.25 hours to validate. 14:25 < gmaxwell> 2017-01-12 13:15:11 UpdateTip: new best=000000000000000000733f6623fd1d5e1a227cb5bd4c66a08714847d0a3267b1 height=436828 version=0x20000000 log2_work=85.483019 tx=167130980 date='2016-11-01 00:30:58' progress=0.969406 cache=2810.3MiB(3802921tx) 14:25 < gmaxwell> 2017-01-12 15:36:08 UpdateTip: new best=00000000000000000037811542c2ca670af372dd43555c4d2dcb69744ab899be height=441341 version=0x20000000 log2_work=85.614254 tx=175220623 date='2016-12-01 00:07:06' progress=0.982775 cache=2773.7MiB(3915896tx) 14:25 < BlueMatt> how long with -assumevalid? 14:25 < BlueMatt> (ie how much of that is non-sig-checking) 14:26 < BlueMatt> I mean even with -assumevalid we're gonna take an hour or five to sync on some machines like that...doing the spv-initial sync (especially with -assumevalid) is gonna be the savior if you want lightning-fast sync...I'm ok eating an extra 30 minutes or hour, especially if its not something thats gonna grow ad infinitum forever 14:27 < gmaxwell> ^ thats with a 3GB db cache.. I think it's about 30 minutes for the same span with assume valid. 14:27 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 258 seconds] 14:28 < gmaxwell> you're missing my point. If you earnestly believe that auditing the hash is harder then the software then you should believe that we MUST NOT ship this feature at all. 14:28 < BlueMatt> hilariously, setting it to a month is gonna mean constant performance for a month after release, as the chain grows on top of the assumevalid setting, whereas setting it to a week means it'll start growing again after a week :p 14:30 < luke-jr> auditing the hash is as trivial as running without it, no? 14:30 < BlueMatt> no, i get your point, but I also dont think we have enough people looking at code, plus there are how many instructions for "how to run a node" that people might figure out if it said "download from my server" but might not catch if it says "set assumevalid to this hash, it makes sync happen instantly" 14:30 < gmaxwell> luke-jr: yes and checking if that block is in your chain. 14:30 < BlueMatt> i mean the recommended method to audit the hash takes a day for many folks :p 14:31 < BlueMatt> while the recommended way to set the hash is right before release 14:31 < sipa> i'm fine with either a week or a month. 14:31 < gmaxwell> BlueMatt: no, it's part of the procedure that happens at the start of RCs. 14:31 * instagibbs re-opens 14:32 < gmaxwell> BlueMatt: the procedure is actually checking two things: that the release didn't introduce any consensus reguressions in previously validated blocks, and that the new hash is acceptable. To only check the latter you need simply check that it's in your chain from a node not yet running that value. 2 seconds, and thats it. 14:33 < gmaxwell> The longer procedure is an omission in our current process that we should already be addressing due to the checkpoint skipping. (though I do a checkpointless resync of every release myself) 14:33 < BlueMatt> gmaxwell: look at it this way - shipping a massive footgun which we think might plausibly trigger without considering the entire bitcoin network worthless seems questionable, shipping a massive footgun which would likely only ever trigger if someone had persistent control of 60% of hashpower....maybe less so 14:33 < gmaxwell> If it is a massive footgun it must not be shipped. 14:33 < BlueMatt> if its a massive footgun that cant go off without bitcoin being completely broken I think thats fine :p 14:34 < BlueMatt> gmaxwell: how long does your sync take on your laptop start-to-finish with -assumevalid set to a week? 14:34 < sipa> i think the footgun (wth is that?) is minimal 14:34 < luke-jr> sipa: footgun is a gun designed for shooting one's own foot 14:34 < cfields> sipa: a device one uses to shoot one's self in the foot. 14:34 < TD-Linux> it's a footgun that only triggers when you've already lost your legs. 14:34 < sipa> to exploit it, the attacker would need to have an invalid majority branch already mined at the time of software relwase 14:35 < BlueMatt> (if this were being proposed with zero additional checks I would be arguing against it wholesale, fwiw) 14:35 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 14:35 < sipa> or is the issue not the hardcoded value, but people convincing others to run with a certain settings value? 14:35 < gmaxwell> BlueMatt: with my large db cache, about 5 hours in a chainstate reindex. I can do more recent numbers later this week. 14:36 < luke-jr> sipa: or trick the user into configuring a majority invalid branch 14:36 < BlueMatt> so its 5 hours -> 7.5 hours if we set it to a month? 14:36 < BlueMatt> or 5 -> 7.25 14:36 < sipa> luke-jr: but they'd need to already have that invalid branch mined, and ahead by a week? 14:36 < gmaxwell> If I never stuck that check in none of you would have suggested it. 14:37 < BlueMatt> or, i guess 5 + (2.25/4) = 5.5 -> 7.25 14:37 < BlueMatt> gmaxwell: (if this were being proposed with zero additional checks I would be arguing against it wholesale, fwiw) 14:37 < jtimon> luke-jr: right, that's much better justification for the one week thing than the "artificially setting it 'too earlly' in releases" IMO 14:37 < gmaxwell> I think you're wrong. 14:37 < luke-jr> sipa: not necessarily 14:37 < BlueMatt> I'm not sure I would have suggested said check, but if weren't there I'd be saying uhhh, lets not 14:37 < luke-jr> ahead by a week, yes, but not already-mined 14:37 < sipa> BlueMatt: what specific attack scenario are you worried about? 14:38 < sipa> (honest question) 14:38 < gmaxwell> BlueMatt: (my blunt assumption is based on that you haven't been contributing to removing the existing checkpoints, no insult intended) 14:39 < BlueMatt> sipa: no, eg you start mining an invalid chain with your small hashpower, tell people to set the assumevalid setting in some blog post in russian that none of us see, when you find one guy who is gonna be your target, pwn a bunch of hahspower for a few days (I'm pretty confident you could get 75% for a few days, at least, if not more), and stay ahead for a week 14:39 < BlueMatt> its kinda weird, but definitely not impossible 14:39 -!- str4d [~str4d@cable-185.30.54.182.coditel.net] has joined #bitcoin-core-dev 14:40 < BlueMatt> gmaxwell: so, to confirm, it would take chain sync on your laptop from roughly 5.5 hours to 7.25 hours to set it to a month? 14:40 < sipa> BlueMatt: but the assumevalid setting value is only known after creating that branch 14:40 < gmaxwell> BlueMatt: I believe so. 14:40 < BlueMatt> gmaxwell: if thats the case, I might be convinced that a month is too long and we should go with 2 weeks 14:40 < BlueMatt> sipa: creating the start of the branch, not actually having to actively keep it up to sync all that well 14:40 < luke-jr> sipa: you'd make the transactions after your assumevalid all be valid 14:40 < BlueMatt> luke-jr: huh? no, you wouldnt 14:41 < luke-jr> BlueMatt: why not? 14:41 < BlueMatt> you would make all the txn before your assumevalid be valid 14:41 < BlueMatt> not after 14:41 < BlueMatt> well, and including, i think 14:41 < luke-jr> before it, they won't check if it's valid 14:41 * gmaxwell flies 14:41 < jtimon> BlueMatt: he means as an attacker 14:41 < luke-jr> so that's where you'd want to hide the invalid stuff 14:41 < sipa> BlueMatt: if at any point your attacker branch is overtaken by the honest branch, assumevalid has no more effect 14:41 < BlueMatt> oh, i see your point, ok 14:42 < BlueMatt> sipa: I'm aware, and I'm pretty confident you could manage to get an attack chain longer than the honest chain for a week 14:42 < BlueMatt> but maybe only like 5/6 days, and probably not much longer 14:42 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 14:42 < BlueMatt> eg start by pwning 75% of the network for 2 full days, then a tail while folks take a while to fix their shit 14:43 < BlueMatt> if you're really clever you'll pwn the pool servers, have some knowledge of where they'll fall back to, and be prepared to do a bgp attack against their (hopefully-less-bw-flood-intensive) fallback asn 14:44 < luke-jr> anyhow, this all requires getting the user to manually set the block hash 14:44 < luke-jr> IMO just hide it as a debug option and we're fixed 14:44 < BlueMatt> luke-jr: I think you missed part, above 14:44 < luke-jr> ? 14:46 < BlueMatt> eg you're an attacker, you maintain a russian-language (or some other language none of us would find) blog on "how to set up a bitcoin node"...you keep some small amount of hashpower mining invalid chains based on the best chain all the time, so you always have some hash in your page that isnt too far back from the tip, maybe a few hours, you very actively monitor users and try to find when someone who is a real target uses it 14:46 < BlueMatt> then you reveal that you've pwned all the pool servers and start mining invalid garbage for a few days 14:46 < BlueMatt> its kinda a strange scenario, and seems pretty highly unlikely, but I do not believe it is impossible 14:47 < luke-jr> BlueMatt: how will your invalid chain get accepted? 14:47 < BlueMatt> it wont be accepted by anyone except your target? 14:47 < luke-jr> why would it be accepted by your target, though? 14:47 < luke-jr> he'd need to set the config option to your malicious block hash 14:47 < jtimon> huhm, what does mining invalid garbage on top of your fake invalid assumevalid give you? 14:47 < BlueMatt> because you got them to set the assumevalid setting? 14:47 < BlueMatt> luke-jr: yes, did you miss the part where they set up their bitcoin node based on your instructions? 14:48 < jtimon> right, the ate the invalid stuff belowe your fake assumevalid, but not above it 14:48 < jtimon> s/the/they s/belowe/below 14:48 < luke-jr> ok, so the user is an idiot who will set the option without investigating what it does 14:49 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 14:49 < BlueMatt> as luke pointed out, you could print (by stealing) on the assumevalid block, and then spend it to your victim in a later bnlock 14:49 < BlueMatt> luke-jr: most users do shit like that.... 14:49 < luke-jr> what if we rename it to assumevalid_this_can_compromise_your_node? 14:49 < BlueMatt> luke-jr: fuck, many users use the ppa 14:50 < jtimon> Ok, so precisely this attack is what the 1 week thing serves for, no? 14:50 < luke-jr> can't blame them. using the PPA makes a lot of sense considering they already trust Canonical. 14:50 < BlueMatt> jtimon: my claim is that I'm not at all convinced you could not have a longer chain than the honest one for a week 14:51 < jtimon> BlueMatt: thus you propose to change it to 2 weeks ? (sorry, I should have read all the logs before intervening) 14:51 < BlueMatt> gmaxwell: does 2 weeks meet your performance target? its more like an extra half hour 14:51 < BlueMatt> jtimon: yes, I prefer a mont but gmaxwell pointed out that that increases sync time on his laptop with massive dbcache by something like 1.5 hours 14:52 < BlueMatt> which does seem like a big cost to pay 14:52 < jtimon> regarding the 5.5 vs 7.5 h benchmark, that's only for fresh releases or people setting the arg manually right before the limit, right? 14:52 < BlueMatt> yes 14:52 < BlueMatt> thats only if you sync within the first week of the release 14:52 < BlueMatt> well, first week after the hash was selected/set 14:53 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 260 seconds] 14:54 < jtimon> I don't oppose changing it to 2 weeks, it's performance vs a more cautious protection against a possible attack 14:56 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 14:57 < jtimon> I mean, even with a month it's a great improvement over the checkpoint way 14:58 < BlueMatt> oh, totally I think we should do this, just prefer a tiny inch more conservatism 14:58 < cfields> BlueMatt: it seems a bit unrealistic to argue what time-period to pick in that scenario. Assuming I'm an attacker in the above conditions, I'd send the victim an "optimized binary that syncs the chain faster" (and it would, the wrong one :P) rather than trying to get them to fiddle with config settings. 14:59 < jtimon> and I'm happy with both 2 or 1 week, so I don't have anything to convince you about 14:59 < BlueMatt> cfields: given an assumevalid setting, I'm pretty sure it'll become common-enough practice to tell people to set it to make chainsync faster 14:59 < BlueMatt> whereas "download from this random site" might be a bit more alarming to folks 15:00 < jtimon> cfields: well, if you can send them an "evil binary" the whole assumevalid thing is irrelevant: you can change the rules! 15:00 < cfields> jtimon: that was exactly my point. 15:00 < jtimon> a bad bitcoin.conf seems more realistic 15:00 < BlueMatt> as for why a month instead of a week, well its about human-scale response to attacks....how long would it take for pools to escalate a large-scale hack against their infrastructure up to their hosting provider...what about if there's a bgp-based attack? how long for global NOCs to respond? etc 15:01 < jtimon> "here's my bitcoin.conf, copy it, it syncs super-fast" 15:01 < BlueMatt> then double because the honest chain has to catch back up 15:03 < cfields> jtimon: given the example above, undermining the majority of hashpower, surely getting them to run my binary is trivial in comparison 15:04 < BlueMatt> cfields: you massively underestimate how trivial it is to pwn most pool servers' hosting providers 15:04 < BlueMatt> also, remember that there is no auth on stratum 15:05 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.] 15:05 < BlueMatt> so even those who get off big centralized providers and host themselves for security will possibly get fucked due to mitm/bgp/etc/etc 15:05 < jtimon> cfields: maybe it's that I underestimate the loss of using 1 month instead of 1 week... 15:08 < cfields> BlueMatt: i'm not arguing with you about that. I'm arguing the relative ease of undermining your victim (who is already gullible enough to set assumevalid) 15:09 < BlueMatt> ehh, I'm not sure about that, though I absolutely agree the example attack given above is not the most robust example 15:16 < cfields> BlueMatt: updated 9441. Now going over 9375 one last time. 15:23 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 256 seconds] 15:31 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:65d7:c8cb:dd71:37b7] has quit [Quit: .] 15:37 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 15:42 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:cd2b:f49d:fe68:cdf9] has joined #bitcoin-core-dev 15:50 -!- str4d [~str4d@cable-185.30.54.182.coditel.net] has quit [Ping timeout: 245 seconds] 15:57 -!- wvr [~wvr@215.red-83-59-62.dynamicip.rima-tde.net] has quit [Quit: Leaving] 16:31 < BlueMatt> cfields: want to review #9535 as well? 16:31 < gribble> https://github.com/bitcoin/bitcoin/issues/9535 | Split CNode::cs_vSend: message processing and message sending by TheBlueMatt · Pull Request #9535 · bitcoin/bitcoin · GitHub 16:44 < jtimon> #9535 seems easy to review for those familiar with the network code 16:44 < gribble> https://github.com/bitcoin/bitcoin/issues/9535 | Split CNode::cs_vSend: message processing and message sending by TheBlueMatt · Pull Request #9535 · bitcoin/bitcoin · GitHub 16:44 < BlueMatt> (its also a big performance bump) 16:45 < BlueMatt> or, well, easy to review for anyone who can read a list of variable names and trace their usage :p 16:47 < jtimon> yeah, I wish I could review that, but never paid much attention to the network code above processMessages and I wasn't able to keep up with the recent changes (I still greatly appreciate the separation and look forward studying it better after all these improvements) 16:49 < BlueMatt> well #9535 is just a lock split, so just going through each variable that is accessed in one side and making sure its not accessed on the other is a pretty good (though admittedly not 100% sufficient) review 16:49 < gribble> https://github.com/bitcoin/bitcoin/issues/9535 | Split CNode::cs_vSend: message processing and message sending by TheBlueMatt · Pull Request #9535 · bitcoin/bitcoin · GitHub 16:50 < BlueMatt> and one one of the sides in this case there are relatively few variables accessed, so its not so hard 16:50 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 16:50 < jtimon> I just meant the code changes are small 16:52 < jtimon> I guess I could do a mechanical review like what you propose 16:52 < cfields> BlueMatt: yep, will do after dinner 16:54 < cfields> jtimon: yea, it's sane, just needs manual review of what's accessed under the locks before/after 16:59 < cfields> (note that you can treat it as non-recursive, so very simple) 16:59 < jtimon> yeah, I considered it as the network-related PR I was more likely to be able to review, but then I tried to estimate how much would it take to do that and my answer was "no idea, let's move to another PR for now", if you say it's easy, thanks, I'll gladly do that (maybe not today, was hoping to at least utACK some individual commits in #9512) 16:59 < gribble> https://github.com/bitcoin/bitcoin/issues/9512 | Fix various things -fsanitize complains about by sipa · Pull Request #9512 · bitcoin/bitcoin · GitHub 17:01 < cfields> jtimon: np. no obligation, was just echoing what matt said 17:06 < jtimon> cfields: sure, it's a good tip, if you guys tell me it shouldn't take long to do that manual review I think it's a good use of my time, hey, it's dividing an important lock into 2! I guess I cs_main got me too scared about reviewing concurrency unless it was cs_args, cs_mempool (encapsulated in its class), or maybe even a 10-line singleton for libsecp's context or something 17:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-uubzupkvraxrslps] has quit [Quit: Connection closed for inactivity] 17:07 < jtimon> will review #9535 17:07 < gribble> https://github.com/bitcoin/bitcoin/issues/9535 | Split CNode::cs_vSend: message processing and message sending by TheBlueMatt · Pull Request #9535 · bitcoin/bitcoin · GitHub 17:14 -!- AaronvanW [~aaronvw@unaffiliated/aaronvanw] has quit [] 17:23 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 245 seconds] 17:46 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 18:00 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 18:05 -!- juscamarena [~justin@47.148.176.74] has quit [Ping timeout: 240 seconds] 18:06 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev 18:14 < jtimon> in case someone gets bored among so many things to review somehow...#8855 has been needing review for so long... 18:14 < gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub 18:18 < jtimon> about a previous version of it gmaxwell once said "This adds news without frees", and I believe I removed all the non-frees many rebases ago... 18:23 < jtimon> also, how should I benchmark #8498 to make it attractive? 18:23 < gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub 18:24 < BlueMatt> jtimon: do a few reindexes with and without it on a relatively unused machine 18:29 < jtimon> BlueMatt: that will show some improvement (since connectblock is still calculating the tx fee twice), but the most interesting effect should be with acceptToMemoryPool...oh,wait, now that's only calculating it twice per tx too (it used to be much more), yeah, thanks, can try that (probably after 0.14) 18:32 < jtimon> should probably have a look at src/bench and maybe try to do the reindex from there 18:36 < BlueMatt> luke-jr: re: FlexVer...talos failed to get the (crazy high) funding they were trying to raise, so thats not gonna happen 18:36 < luke-jr> BlueMatt: no, FlexVer survives beyond Talos 18:36 < luke-jr> without more funding 18:36 < BlueMatt> oh? are they putting it in something else? 18:37 < BlueMatt> (my understanding was the raptor folks were essentially saying "ok, well we didnt get the funding, so if you want any pieces of talos you have to come pay us for them") 18:37 < luke-jr> non-workstation/servers 18:37 < BlueMatt> well, ok, technically they have another 48 hours to raise the missing 3.something million USD..... 18:38 < luke-jr> FlexVer-based VPS is their fallback after Talos failing 18:38 < midnightmagic> that funding target was pretty nuts. :-( 18:38 < BlueMatt> oh? link? 18:38 < BlueMatt> midnightmagic: yea...real shame, too 18:39 < BlueMatt> they should have done the shit the ORWL folks did - raise a modest amount and assume you can sell more of the hardware later to make up the missing costs 18:39 < BlueMatt> of course its a big risk, but at least we'd get cool stuff out of it :) 18:39 < midnightmagic> Perhaps they just didn't have the money to do it to begin with. 18:39 < luke-jr> BlueMatt: #talos-workstation discussion 18:39 < BlueMatt> luke-jr: oh? link? 18:40 < midnightmagic> Similar failures have happened many times in the past e.g. phase5's attempt to resurrect the Amiga with the A\Box 18:40 < BlueMatt> ooo, didnt know about that 19:01 * sipa googles 19:03 < gmaxwell> BlueMatt: I dunno, maybe, will have to think; but if you're concerned about security here there are many better things to do that would harden it that wouldn't change performance. 19:04 < gmaxwell> BlueMatt: e.g. make it so that it can't skip signatures in a reorg. 19:04 < cfields> BlueMatt: thanks for fixing up the const. I think my gripe wasn't really justified. The const rules for pointers/references still trip me up sometimes. 19:04 < BlueMatt> gmaxwell: hadnt thought about that one...came up with a few things which addressed the specific scenario I described above, though figured that would be very scenario-specific :/ 19:05 < BlueMatt> cfields: I agree it was super hard to read what was going on there, and why it wasnt some crazy const_cast unsafe bullshit the way it read 19:05 < gmaxwell> BlueMatt: another one is to not skip signatures when there is a long fork that doesn't cointain this block. 19:06 < gmaxwell> (both of these were security features I recommended for the hashpower only decision-- but I didn't think their complexity was worthwhile with a static hash.) 19:06 < cfields> BlueMatt: right, that. const_cast usually just sets off alarms to me that something's fishy. The change makes it easy to reason about. 19:06 < BlueMatt> gmaxwell: yea, I wanted to avoid suggesting adding twenty ways it could be hardened and risk it slipping for 0.14 19:07 < gmaxwell> I think both are more powerful than just burriedness, I even only did the burriedness because it was ~1 LOC. 19:09 < BlueMatt> gmaxwell: both assume you actually see the other branch, which isnt a crazy assumption, but is different from burriedness 19:10 < BlueMatt> well, reorg less so 19:10 < BlueMatt> but either way, I'm happy if 2 weeks meets your performance goals 19:10 < BlueMatt> if we come up with fun ways to strengthen it in the future (eg when jl2012's fork warning stuff gets fixed it would be easy to combine that), then we can do that 19:10 < luke-jr> sipa: essentially DRM that allows selling encrypted VPSs that the physical-access/datacentre/host-manager cannot see into or control (beyond poweroff/delete) 19:11 < cfields> jonasschnelli: I'm going through #9294, though I'm afraid I don't know the code well enough to give any helpful review. So nits is the best I can do :( 19:11 < 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 19:12 < gmaxwell> BlueMatt: the forkwarning stuff 'brokenness' actually wouldn't effect that. 19:12 < gmaxwell> because in that case you'd be on the attack chain, which is best header, but there would be a long valid fork that doesn't contain your block. 19:14 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 19:16 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 252 seconds] 19:17 < cfields> sipa: am I going to throw you off if I go ahead and squash 9441? Not sure if you want to have another look after the last few cleanups 19:17 < BlueMatt> gmaxwell: ok, so do you want to add that? I do not think it is a replacement for setting the time to 2 weeks, plus setting the time to 2 weeks avoids the need to get re-reviews when we're already not gonna make our goals 19:17 < gmaxwell> 14:52 < jtimon> regarding the 5.5 vs 7.5 h benchmark, that's only for fresh releases or people setting the arg manually right before the limit, right? 19:17 < gmaxwell> 14:52 < BlueMatt> yes 19:17 < gmaxwell> no increasing the offset increases the total sync time for that software forever. 19:18 < BlueMatt> huh? 19:18 < BlueMatt> did i misread the code? 19:19 < gmaxwell> oh no I'm being momentarily stupid. 19:19 < BlueMatt> the software is updated with some assumevalid....at that time all blocks a week before that assumevalid arent validated...one week later all blocks up to that assumevalid are validated 19:19 < BlueMatt> ok, phew 19:19 < jtimon> huh? +1 (I bet the answer is in GetBlockProofEquivalentTime which is the part I didn't fully read because it wasn't being changed in that PR) 19:20 < gmaxwell> BlueMatt: I'm referring to the case where the user updates it. Which I expect people to do on low power devices. 19:20 < BlueMatt> ahh, yes, ok 19:20 < gmaxwell> it basically says you can't sync without processing N-back no matter what you set. So if you're on a low power device where a month of blocks takes hours, thats what you're left with. 19:22 < BlueMatt> how long does it take to sync a week's blocks on an rpi? 19:22 < BlueMatt> or, cdecker you were complaining about stuff on the cheapest digitalocean thing 19:22 < BlueMatt> how slow was that? 19:23 < jtimon> but the user doesn't have to do anything right? just wait for the program to fully the N last blocks, right? 19:23 < jtimon> s/fully the/fully verify the/ 19:23 < gmaxwell> BlueMatt: a lot of people just copy the chain from another system; instead they could copy the assume block. 19:24 < BlueMatt> on the flip side, a lot of setup guides will tell you to copy blockchain.info's latest hash as the assumeblock the day after release :p 19:25 -!- guetta610 [499a835d@gateway/web/freenode/ip.73.154.131.93] has joined #bitcoin-core-dev 19:25 < gmaxwell> I also worry that making this too slow increases the occurance of people copying the state. E.g. there is someone on reddit that responds to every thread about slow sync with a download for a synced node. 19:25 < BlueMatt> oh, agreed, but there is a line to walk there 19:25 < gmaxwell> BlueMatt: thats better than taking a whole download of the state which people are already being told to do. 19:25 < jtimon> re N blocks vs time: I definitely like height more, for everything related to time in consensus 19:26 < BlueMatt> (I'd tend to agree that a week is sufficient to keep stupidity of random block explorers from creeping into consensus) 19:26 < BlueMatt> just prefer > 1 week for other reasons 19:26 < BlueMatt> I'm open to being convinced if it really is prohibitively slow (compared to the rest of chainsync w/o sig-checks) 19:28 < jtimon> To reiterate, I don't see the danger with doing a month either: advanced users that look for top performance can compile the code changing the month to a week or 2 blocks 19:28 < BlueMatt> I dont think thats a realistic request 19:29 -!- guetta610 [499a835d@gateway/web/freenode/ip.73.154.131.93] has quit [Ping timeout: 260 seconds] 19:32 < gmaxwell> jtimon: none of this should involve time or height. 19:32 < gmaxwell> __sigh__ both are trivially controlled by miners. 19:32 < gmaxwell> the test in the code involves work. 19:33 < jtimon> I guess my point is that "I want to resync faster than the assumevalid by default in the last release" use case is not very compeling 19:33 < gmaxwell> jtimon: it is very compelling when it's taking days to sync and can be fixed. 19:34 < jtimon> gmaxwell: the week sounds like time, but sorry, I admited I don't fully understand GetBlockProofEquivalentTime so I shouldn't have made the time vs height comment and I bet you're right it was irrelevant 20:06 < BlueMatt> uhhh, wut....just fetched from github and compared my local branch between my two machines as always....except this time they're different 20:06 < MarcoFalke> huh? 20:06 < MarcoFalke> same commit hashes? 20:06 < BlueMatt> different commit hash, same tree 20:07 * BlueMatt goes to read git-log to see if github is fucking with shit or if I'm confused 20:07 < BlueMatt> oh, nvm, false alarm 20:07 * BlueMatt was testing git commit --amen and forgot that i changed the commithash on the top commit 20:16 -!- chris200_ [~chris2000@p5082ABC7.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 20:18 -!- chris2000 [~chris2000@p5082AE70.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 20:22 < cfields> BlueMatt: I suppose you just added cs_sendProcessing for general correctness? afaik, with the current single-threaded processing, there's no actual need for it? 20:23 < BlueMatt> https://github.com/bitcoin/bitcoin/pull/9535/commits/11290734ca7261f732c9f43f152c69de3a42546c 20:23 < BlueMatt> see commit body :p 20:23 < BlueMatt> "Technically cs_sendProcessing is entirely useless now because it 20:23 < BlueMatt> is only ever taken on the one MessageHandler thread, but because 20:23 < BlueMatt> there may be multiple of those in the future, it is left in place" 20:23 < BlueMatt> but, yea, its for correctness 20:23 < cfields> haha 20:23 < cfields> at least we agree :) 20:23 < BlueMatt> true 20:23 < cfields> serves me right for not reading. thanks. 20:23 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 20:25 < cfields> it'd be nice if github emphasized the display of full individual commit messages better. I'm well aware that I put much more effort into writing them than reviewers put into reading them. And I'm equally guilty in my own reviews. 20:26 * BlueMatt generally tries to avoid reading too much author-written text during review 20:26 < BlueMatt> too easy to see what the author intended instead of what it actually does 20:26 < BlueMatt> I tend to read the commit message if I'm confused to see if it helps me understand, but only if I have an idea that it might be broken 20:27 < cfields> fair point 20:27 < BlueMatt> ok, I'm down to 4 prs to review tomorrow...should be fun 20:30 < cfields> heh 20:30 < cfields> feeling better, i hope? 20:30 < BlueMatt> yea, well enough to review, at least 20:30 < BlueMatt> taking a day off to lie in bed helped a ton 20:35 < cfields> good 20:35 < cfields> those days are helpful even when you're not sick :) 20:36 < cfields> maybe not in bed all day, but disconnected enough to make you crave code again 20:36 < BlueMatt> oh, didnt mean to imply I didnt have email to respond to all day :p 20:37 < cfields> oh, heh 20:53 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection] 21:08 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 21:19 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds] 21:19 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:39 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection] 22:31 -!- MarcoFalke [~marco@host63-2.natpool.mwn.de] has quit [Quit: MarcoFalke] 22:35 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev 22:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-klitxyrlpvkxrtqa] has joined #bitcoin-core-dev 23:24 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection] 23:26 -!- ClockCat [~CattieCat@75-109-228-219.stjocmtk01.res.dyn.suddenlink.net] has quit [Read error: Connection reset by peer] 23:26 -!- ClockCat [~CattieCat@75-109-228-219.stjocmtk01.res.dyn.suddenlink.net] has joined #bitcoin-core-dev 23:28 -!- pindarhk [sid105966@gateway/web/irccloud.com/x-vzxmdttmkznzfgwx] has quit [Ping timeout: 255 seconds] 23:29 -!- eragmus [sid136308@gateway/web/irccloud.com/x-dxtwomjijaanfbnz] has quit [Ping timeout: 255 seconds] 23:30 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Ping timeout: 255 seconds] 23:31 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev 23:33 -!- eragmus [sid136308@gateway/web/irccloud.com/x-qcdumxgyfhmcrcbj] has joined #bitcoin-core-dev 23:35 -!- pindarhk [sid105966@gateway/web/irccloud.com/x-mkbqitomwdnwffow] has joined #bitcoin-core-dev 23:35 < jonasschnelli> sipa: is this (https://github.com/sipa/bitcoin-seeder/pull/42) related to the seeder silent crash we recently encountered? 23:50 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 23:54 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 23:57 < fanquake> Has anyone running master noticed sync/reindex stalling just prior to getting a connection refused message in the debug.log? 23:58 < fanquake> Have just had one instance of the GUI freezing/lagging, and no debug output for ~10 seconds. Then a few UpdateTip messages followed by a Connection refused. 23:59 < fanquake> Testing 9484 btw, I think I'll get a full sync in just less than 2 hours. 23:59 < fanquake> 1hr40m to block 424'000