< bitcoin-git> [bitcoin] promag opened pull request #10885: Prevent duplicate wallets (master...2017-07-prevent-duplicate-wallets) https://github.com/bitcoin/bitcoin/pull/10885
< promag> sipa: there you go
< Chris_Stewart_5> The CScript constructor in the python testing framework will add push ops for constants right? Or do I need to add them manually
< Chris_Stewart_5> nvm, dynamic typing got me..
< bitcoin-git> [bitcoin] MeshCollider opened pull request #10886: Remove unused #define in sync.h (master...remove-unused-define) https://github.com/bitcoin/bitcoin/pull/10886
< bitcoin-git> [bitcoin] MeshCollider closed pull request #10886: Remove unused #define in sync.h (master...remove-unused-define) https://github.com/bitcoin/bitcoin/pull/10886
< wumpus> a user on transifex is misbehaving (vandalizing the German translations), anyone have experience with how to handle this? I don't see any ban controls etc in their interface
< jonasschnelli> hmm...can we revert his changes?
< wumpus> e.g. nearly all of these are nonsense https://www.transifex.com/bitcoin/bitcoin/translate/#de/$/104570304?user=pehotinec, sometimes he copies slightly similar messages to make it look ok, sometimes he just copies the English message, in any cast this seems deliberate
< jonasschnelli> I'll write transiflex support to ban that user
< wumpus> thank you
< jonasschnelli> But is there a way to revert all his changes?
< wumpus> not in one go - there's a revert button on messages, but usually it seems to be disabled; I think that means these messages have no previous translation, it's only noticed now
< jonasschnelli> Okay. I'll check the german part (and eventually write in the correct transaltion)
< wumpus> they should be reveted back to untranslated
< wumpus> yes, or that
< Victorsueca> I don't know a way to block a user from a project that doesn't go through making people request to join the translation team
< jonasschnelli> wumpus: do we also need to take care of <0.15 translations (do these get pulled again?)?
< wumpus> only 0.14, the others are closed. Those get pulled again when there is a minor release.
< jonasschnelli> wumpus: although users pehotinec did also correct translations...
< wumpus> there are a few that seem to be correct, some look very convincing but seem copies of related messages, and others are complete nonsense
< wumpus> it's quite sneaky which is why it took months to discover, unlike if he just wrote 'poop' everywhere. seone has sent him a message asking about his motivation but I have the feeling he's not going to respond normally to that
< jonasschnelli> Yes. I guess he filled in english translations into the missing german ones
< wumpus> he also has some english to english messages in de_DE https://www.transifex.com/bitcoin/bitcoin/translate/#de_DE/$/65093519?user=pehotinec
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/df0793f324e3...bf3b742e2852
< bitcoin-git> bitcoin/master 2264236 Alex Morcos: Rename -usewallet to -rpcwallet
< bitcoin-git> bitcoin/master bf3b742 Wladimir J. van der Laan: Merge #10883: Rename -usewallet to -rpcwallet...
< bitcoin-git> [bitcoin] laanwj closed pull request #10883: Rename -usewallet to -rpcwallet (master...rpcwallet) https://github.com/bitcoin/bitcoin/pull/10883
< bitcoin-git> [bitcoin] benma opened pull request #10888: range-based loops and const qualifications in net.cpp (master...netcpp_cosmetics2) https://github.com/bitcoin/bitcoin/pull/10888
< bitcoin-git> [bitcoin] jnewbery closed pull request #10868: Remove -usewallet (master...remove_use_wallet) https://github.com/bitcoin/bitcoin/pull/10868
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bf3b742e2852...adf170daf90f
< bitcoin-git> bitcoin/master 6b4f231 Andrew Chow: Move transaction combining from signrawtransaction to new RPC...
< bitcoin-git> bitcoin/master adf170d Wladimir J. van der Laan: Merge #10571: [RPC]Move transaction combining from signrawtransaction to new RPC...
< bitcoin-git> [bitcoin] laanwj closed pull request #10571: [RPC]Move transaction combining from signrawtransaction to new RPC (master...combineraw-rpc) https://github.com/bitcoin/bitcoin/pull/10571
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/adf170daf90f...fd2814ef1182
< bitcoin-git> bitcoin/master 35aff43 practicalswift: Remove unused variable int64_t nEnd...
< bitcoin-git> bitcoin/master 5a6671c practicalswift: Fix typo: "conditon" → "condition"...
< bitcoin-git> bitcoin/master fd2814e Wladimir J. van der Laan: Merge #10862: Remove unused variable int64_t nEnd. Fix typo: "conditon" → "condition"....
< bitcoin-git> [bitcoin] laanwj closed pull request #10862: Remove unused variable int64_t nEnd. Fix typo: "conditon" → "condition". (master...nEnd) https://github.com/bitcoin/bitcoin/pull/10862
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd2814ef1182...041dad94b047
< bitcoin-git> bitcoin/master a70d025 Gregory Sanders: fixup some rpc param counting for rpc help
< bitcoin-git> bitcoin/master 999ef20 Gregory Sanders: importmulti options are optional
< bitcoin-git> bitcoin/master 4dc1915 Gregory Sanders: check for null values in rpc args and handle appropriately
< bitcoin-git> [bitcoin] laanwj closed pull request #10783: [RPC] Various rpc argument fixes (master...rpcargfixes) https://github.com/bitcoin/bitcoin/pull/10783
< jnewbery> sipa gmaxwell: you were asking for #10882 . It should be review-ready now.
< gribble> https://github.com/bitcoin/bitcoin/issues/10882 | [WIP] Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
< sipa> jnewbery: thanks!
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/041dad94b047...7c2400cb8ab7
< bitcoin-git> bitcoin/master d9d1bd3 romanornr: nCheckDepth chain height fix
< bitcoin-git> bitcoin/master 7c2400c Wladimir J. van der Laan: Merge #10775: nCheckDepth chain height fix...
< bitcoin-git> [bitcoin] laanwj closed pull request #10775: nCheckDepth chain height fix (master...master) https://github.com/bitcoin/bitcoin/pull/10775
< instagibbs> jnewbery, could you squash?
< jnewbery> sure - I'll do that now
< instagibbs> \o/
< sipa> meeting?
< instagibbs> in an hour?
< sipa> oops, in an hour
< instagibbs> :) thanks for reminder though, completely forgot
< sipa> yes, i didn't actually think it was meeting time, just wanted to give a veiled reminder </yeahright>
< instagibbs> so humble
< gmaxwell> do we have a editable web doc for release notes again?
< sipa> unsure
< jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/10870#discussion_r128546723, .. what do you think about not doing the URL encode
< jonasschnelli> The allowed wallet characters would not require an urlencode...
< wumpus> jonasschnelli: well you do an URL decode at the other side, so I think that'd potentially result in problems
< jonasschnelli> wumpus: look at SAFE_CHARS_FILENAME
< wumpus> better to keep it symmetrical just in case, even if not strictly needed for what we see now
< jonasschnelli> I though because its a temp fix and the URI encode/decode (atm) do nothing-.
< sipa> it may do something later
< sipa> i don't think it hurts to have it
< wumpus> I have some terrible experiences with escaping if not very carefully taking care of on both sides
< jonasschnelli> Yes. Okay. Then lets keep it.
< jonasschnelli> https://github.com/bitcoin/bitcoin/pull/10870#discussion_r128546723 must be removed (replaced) once 0.15 is fixed.
< jonasschnelli> whats the long term solution for wallet arguments like -usehd in conjunction with multiwallet?
< jonasschnelli> A createwallet RPC?
< sipa> i think so
< wumpus> yes - dynamically loading/unloading and creating wallets should be possible at some point
< jonasschnelli> but if you would create a wallet, would it be automatically loaded next start? (== have wallet>s<.dat file somewhere that keeps track of wallets to load)?
< wumpus> I don't thikn so
< jonasschnelli> Assume you use Qt and create a wallet.
< jonasschnelli> You don't want to add a -wallet= to your config file
< jonasschnelli> But Qt may be different
< jonasschnelli> (QSettings)
< wumpus> well, just add a menu option "load wallet"
< sipa> i guess qt can have modifiable settings that include the wallets to load
< wumpus> but yes, qt has a dynamic settings mechanism
< wumpus> it could use that
< jonasschnelli> Not auto-loading RPC created wallets can be cumbersome if one uses pruning.
< wumpus> yes, maybe, I think it's something to worry about later
< wumpus> there's no reason bitcoind couldn't have a dynamic settings mechanism, with some configuration that automatically gets re-loaded on next run, for example the bitcoin-rw.conf idea
< bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c2400cb8ab7...16240f43a550
< bitcoin-git> bitcoin/master 4d50f38 Pieter Wuille: Support multi-block SHA256 transforms...
< bitcoin-git> bitcoin/master 2991c91 Pieter Wuille: Add SHA256 dispatcher
< bitcoin-git> bitcoin/master c1ccb15 Pieter Wuille: Add SSE4 based SHA256
< bitcoin-git> [bitcoin] laanwj closed pull request #10821: Add SSE4 optimized SHA256 (master...20170713_shasse) https://github.com/bitcoin/bitcoin/pull/10821
< sipa> \o/
< instagibbs> jnewbery, gmaxwell re:unlock of wallet, one issue I see is that we have no way(?) of unlocking the wallet as bitcoind startup argument, so if the user hits the minimum they will be stuck aside from heroically fast fingers
< gmaxwell> (so bystanders aren't confused, thats defaulted to off, enabled with a configure flag, in master)
< gmaxwell> instagibbs: yea, it's ugly.
< sipa> instagibbs: it's annoying... we effectively have no means of recovery
< instagibbs> at a minimum, should the wallet.dat get copied and backed up temporarily?
< instagibbs> upon any rescan
< sipa> but i do think that it's better than the alternative (which is making the state even harder to recover from, with also no means of recovery)
< instagibbs> at least allow the user to take the older wallet.dat to some other software
< instagibbs> sipa, im sorry what's the worse idea of the two?
< instagibbs> not scanning forward and missing funds?
< gmaxwell> sipa: if it just won't start syncing with the wallet emptied and locked.. then you could unlock at your leasure.
< sipa> instagibbs: well if you don't stop, it means your wallet will go further out of sync with the chain, which may force you to do a full reindex later (if you're pruning)
< sipa> gmaxwell: yes, if we had support for stopping sync without shutdown, absolutely
< instagibbs> oh, stop syncing wallet but not chain, didn't know what you were talking about
< instagibbs> agreed
< gmaxwell> sipa: I mean it could shut down still but on restart just not start again.
< gmaxwell> It's easier to not start than it is to stop it, I think.
< sipa> gmaxwell: i see, that may be the case yes
< sipa> instagibbs: no, i mean that's what we're currently doing
< sipa> instagibbs: the keypool would go out of sync, and you'd keep syncing, making the wallet go out of sync (while not even being aware of it)
< sipa> so i think stopping when running out is a strict improvement
< sipa> but it's far from a complete solution
< instagibbs> wait it's already doing that?
< instagibbs> :(
< instagibbs> ok then
< BlueMatt> sipa: do you know offhand what the performance difference between the sse4 sha256 and the avx1 sha256 impls are?
< sipa> BlueMatt: small
< sipa> instagibbs: that's the problem we're trying to solve, no?
< instagibbs> sipa, I thought it was adding a "min" level
< gmaxwell> BlueMatt: AVX1 is a performance disaster on AMD and hardly faster on intel.
< instagibbs> which is separate from the "total"
< sipa> instagibbs: i'm confused
< BlueMatt> gmaxwell: hmm, ok, i was just trying to figure if i should remove the avx1 patch i have in fibre or leave it
< instagibbs> < 500 of 1000, topup vs 1000 of 1000 topup
< wumpus> BlueMatt: https://github.com/laanwj/bitcoin/tree/2016_05_sha256_accel readme.md has some benchmarks
< instagibbs> sipa, I'm probably just horribly confused about how the wallet currently operates
< wumpus> but yes, on most cpus there's hardly or no difference
< wumpus> and when there is a big difference it's SLOW
< BlueMatt> wumpus: ok, so, unless i get some rorx CPUs, just use sse4 and wait till there's shani
< sipa> shani is awesome
< instagibbs> sipa, right now the PR makes it shut down when you are below a new argument, default of 500
< sipa> it's 5.5x faster than sse4 here
< BlueMatt> lol, nice
< sipa> sorry, 4.5x
< wumpus> the rorx implementations are a little bit faster
< BlueMatt> so, fibre servers will use that in....5 years?
< wumpus> but yes, -ni is definitely what to go for
< BlueMatt> yea, I'm just limited by what random cheap hosting providers have available
< gmaxwell> BlueMatt: broadwell-ep
< gmaxwell> +Impl | avg | speed%
< gmaxwell> +------------ | ---------- | --------
< gmaxwell> +basic |0.00599851 | 100
< gmaxwell> +sse4 |0.00396052 | 151
< gmaxwell> +avx |0.00397483 | 151
< gmaxwell> +rorx |0.00334802 | 179
< sipa> BlueMatt: shani makes my reindex to 450k time go from 4900s to 4200s
< gmaxwell> +rorx_x8ms | 0.00328667 | 183
< gmaxwell> sipa: do you have a table like that for your system with shani on it?
< sipa> i had, somewhere
< sipa> it's probably in your PM history with me
< sipa> SHA256_32b_avx,4,0.464040040969849,0.464066028594971,0.464053034782410,1670543604,1670636664,1670590134
< sipa> SHA256_32b_basic,4,0.298919439315796,0.298947453498840,0.298933446407318,1076109714,1076210442,1076160078
< sipa> SHA256_32b_rorx,6,0.215215563774109,0.216080069541931,0.215623021125793,774776664,777886704,776242368
< sipa> SHA256_32b_rorx8,4,0.460553050041199,0.460564017295837,0.460558533668518,1657989792,1658029986,1658009889
< sipa> SHA256_32b_shani,16,0.064792513847351,0.065104484558105,0.064978063106537,233253936,234375822,233920892
< sipa> SHA256_32b_sse4,6,0.230213999748230,0.230278015136719,0.230246663093567,828768096,829000080,828886758
< gmaxwell> Thanks.
< gmaxwell> BlueMatt: I assume we'll add rorx and sha-ni right after branching...
< BlueMatt> gmaxwell: yea, would be cool to not carry patches for that on fibre
< sipa> that's already with a patch to make the rorx cases use larger CSHA256 buffers, because they process multiple blocks at once faster
< sipa> that patch doesn't affect the performance of others (in fact, it seems to slightly improve it...)
< gmaxwell> BlueMatt: ISTM you'd be better off with what we have in master than what you have now. (IIRC you're using just the AVX not the rorx one)
< BlueMatt> gmaxwell: that is correct, yes
< sipa> i'm afraid we'll need to startup benchmark to determine what sha256 implementation to use :(
< gmaxwell> I don't see why.
< sipa> because rorx8 is presumably faster than sse4 on intel, but slower on amd
< gmaxwell> sipa: well we need to try with the multiblock changes, it wasn't a big change before, but good point.
< gmaxwell> sipa: though we could simply check for intel and only use it on intel.
< wumpus> doing a sha256 benchmark at every start seems excessive to me
< gmaxwell> I doubt we'll have reason to do so. even if rorx8 is faster only on intel, and enough faster to include, fine.. we'll just check the vendor string.
< sipa> fair
< achow101> meeting?
< gmaxwell> #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
< jonasschnelli> hi
< instagibbs> hi
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Jul 20 19:00:49 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< cfields> hi
< achow101> hi
< wumpus> #topic high priority for review
< sipa> #10882 needs 0.15 tag?
< gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 has pretty much been cleaned out (only #10652 left), anything new?
< sipa> otherwise, the things with current 0.15 tag?
< gribble> https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt · Pull Request #10652 · bitcoin/bitcoin · GitHub
< gmaxwell> ACK for 10882 0.15 tag
< BlueMatt> 10652 can lose its 15 tag
< BlueMatt> #10758 really wants review sooner rather than later
< gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
< cfields> i'd say #10821 needs high prio review if it's going in for 0.15, though it's got a bunch of ACKs already
< gribble> https://github.com/bitcoin/bitcoin/issues/10821 | Add SSE4 optimized SHA256 by sipa · Pull Request #10821 · bitcoin/bitcoin · GitHub
< instagibbs> cfields, it got merged..
< jonasschnelli> cfields: it's merged
< wumpus> 10821 is merged
< cfields> hah
< wumpus> there's virtually no regression risk as it's disabled by default
< kanzure> hi.
< * cfields> refreshes
< wumpus> ok, added #10758 to project 8, and #10882 to 0.15
< gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
< wumpus> #10652 was already untagged for 0.15 2 days ago
< gribble> https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt · Pull Request #10652 · bitcoin/bitcoin · GitHub
< BlueMatt> good :)
< wumpus> other topics?
< BlueMatt> Make 0.15 Great Again!
< achow101> forks! forks! forks!
< instagibbs> 10882 halting condition
< gmaxwell> 10882 halting problem.
< instagibbs> so, there's gotta be something better than "load your wallet in an older bitcoin instance"
< sipa> i'd like to bring up #10526
< gribble> https://github.com/bitcoin/bitcoin/issues/10526 | Force on-the-fly compaction during pertxout upgrade by sipa · Pull Request #10526 · bitcoin/bitcoin · GitHub
< btcdrak> hi
< instagibbs> oh sorry il lwait for topic
< wumpus> about 2.5 weeks to go before projected 0.15 split-off
< wumpus> #topic Force on-the-fly compaction during pertxout upgrade
< gmaxwell> master is too reliable.
< sipa> so, the 0.15 per-txout database needs conversion on first startup
< sipa> this has the risk of leveldb leaving the old tables around
< sipa> leaving you with a 4.something GB chainstate rather than 2.something
< wumpus> did anyone see any difference with that merged?
< sipa> i did - i don't know if anyone else tried
< sipa> but it's pretty worrying if it doesn't work deterministically
< wumpus> did it make a difference for you? any idea what happened in my case?
< sipa> wumpus: no...
< sipa> it did make a difference for me, yes, as far as i remember
< sipa> i'll investigate again and rebase
< sipa> probably not much else to say
< wumpus> can anyone else try, please? I think it makes a lot of sense to have it in 0.15, *if* it works :)
< sipa> agree.
< sipa> will rebase
< wumpus> will tag it
< wumpus> #action test #10526
< gribble> https://github.com/bitcoin/bitcoin/issues/10526 | Force on-the-fly compaction during pertxout upgrade by sipa · Pull Request #10526 · bitcoin/bitcoin · GitHub
< gmaxwell> wumpus: I thought there might have been something weird about your test; hardlinked database directories or something
< wumpus> gmaxwell: not hard-linked directories, just individual files
< wumpus> e.g. I use https://gist.github.com/laanwj/3c4614a23e072cbb3d39090da1834a68 to make copies - but not sure how it could cause the problem
< sipa> i don't see that either
< wumpus> but sure I could copy the ldb files instead and retry
< gmaxwell> Unrelated, does anyone have a point of contact with '1Hash' (or whomever was the author of block 476670)
< gmaxwell> ?
< wumpus> no, no idea
< btcdrak> gmaxwell: I do
< gmaxwell> btcdrak: thanks.
< wumpus> #topic 10882 halting condition
< jnewbery> instagibbs ?
< instagibbs> I think users need some sane way of recovering from their wallet hitting topup
< instagibbs> and their node shutting down, since the user cannot recover using the current software
< instagibbs> sorry, don't have great solutions, just bringing it up because I'd like it merged
< instagibbs> (for encrypted wallets, obviously)
< gmaxwell> My suggestion is the although stoping the sync was hard, preventing it from starting may be easy.
< gmaxwell> so if you start with a locked tip-behind wallet, that doesn't have enough keys, it could just not start the sync until unlocked.
< gmaxwell> but I haven't investigated.
< wumpus> sounds good to me
< gmaxwell> instagibbs: Sipa's point was that an unrecoverable always shuts down state is STILL better than what we do now.
< gmaxwell> because you at least won't end up with a silently screwed up wallet.
< jnewbery> There are a couple of solutions that I hope we could get into v0.15.1 : dynamic loading of wallets with the option to unlock on load (#10740) and a standalone wallet tool with option to topup (#8745)
< gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [WIP] [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/8745 | [PoC] Add wallet inspection and modification tool "bitcoin-wallet-tool" by jonasschnelli · Pull Request #8745 · bitcoin/bitcoin · GitHub
< instagibbs> gmaxwell, mmm sure, conveying actionable info is still a requirement, though this may be off topic for meeting
< wumpus> dynamic loading is a feature, that won't make it into 0.15.1
< wumpus> (but will to 0.16, ofc)
< instagibbs> jnewbery, oh optional unlock on load, nice, will look
< jnewbery> it's not in 10740 yet, but hopefully not too difficult to add
< instagibbs> ok, well if it's not super pressing to anyone else, whatever. I don't run crypted anyways :)
< wumpus> suddeny crashing on startup w/ the wallet effectively being unusable is unacceptable at least
< gmaxwell> I think it's preferable to current behavior where the wallet is effectively silently corrupted.
< BlueMatt> well its fixable with rescan
< sipa> BlueMatt: no
< sipa> it'll fail to load
< instagibbs> sipa, ?
< BlueMatt> i was responding to greg's "silently corrupted" comment
< sipa> oh, ok
< wumpus> forcing a rescan would be somewhat better
< wumpus> but just crashing will lead people to do things like salvagewallet and worse
< instagibbs> nvm
< gmaxwell> BlueMatt: fixable somehow doesn't mean not silently corrupted though. since it's silent you won't know to rescan.
< gmaxwell> wumpus good point.
< gmaxwell> in any case, lets see what we can do with the PR.
< BlueMatt> fair
< gmaxwell> (there were people running salvage wallet in response to the 50/100 warning... :( :( )
< BlueMatt> holy what the fuck
< gmaxwell> Humans.
< wumpus> yes, at least if it crashes it should tell something actionable to do, not just leave the user to dry
< jnewbery> Yes, the current error message is "Error: Keypool is too small. Shutting down"
< jnewbery> which isn't helpful enough
< instagibbs> startingly vague
< wumpus> not helpful at all
< instagibbs> salvagewallet may seem reasonable in response
< wumpus> they'll try providing a larger -keypool
< wumpus> which doesn't help
< instagibbs> "my keys disappeared!"
< gmaxwell> Any time we create a warning or an error condition that a user can't suppress a few people will do increasingly insane things to try to get it to go away.
< jnewbery> suggested action for user could be: set "-keypoolmin to 0 and then rescan"?
< wumpus> yes, 'core nuked my wallet!'
< sipa> jnewbery: and unlock beforehand
< gmaxwell> jnewbery: no, that'll just corrupt their wallet. (they'll end up scanning past the end)
< gmaxwell> they need to unlock before.
< wumpus> ideally this would just be automated
< wumpus> if there is a course of recovery
< jnewbery> ok: "set -keypoolmin to 0, unlock wallet, rescan"
< jtimon> my keypool is too small? isn't this just a warning because I resuse addresses and they want me to create more new ones?
< gmaxwell> I guess you can keypoolmin, restart, unlock, and restart with rescan.
< jtimon> sorry, bad joke
< gmaxwell> or we find out if we can just suppress the scanstart until unlock, then it just needs to nag you to unlock.
< wumpus> would be nice
< instagibbs> if error messages are more helpful, and there is a manual method of recovery, I'm fine with it for now
< wumpus> sure
< wumpus> if this is a rare condition, and explaining what to do is easier than automating it, that would be acceptable for 0.15
< jnewbery> ok, I'll improve the error message. PR could still do with lots of review
< instagibbs> Great!
< sipa> note that all of this can only ever occur when restoring a wallet backup in the first place
< wumpus> #action review #10882
< gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
< wumpus> the more important not to scare people with unrecoverable errors
< gmaxwell> if people can't tell what to do in order to get rid of the error, they'll do something dangerous eventually, after trying a few safe but unsuccessful things.
< gmaxwell> I wonder how many people have died due to blinking 12 on VCRs.
< wumpus> they'll escalate to worse and worse things
< wumpus> heh
< sipa> well improving the error message at least would be a start
< wumpus> yes, that would be good
< sipa> but i agree more is needed
< jnewbery> It's a shame all the wallet initialization stuff is so coupled to node initialization. Hopefully we can make some good progress with that in 0.16. That'd make issues like this a lot easier to deal with.
< sipa> jnewbery: yeah
< wumpus> it is a shame indeed
< wumpus> although it's better than it used to be
< wumpus> but both multiwallet and this are good reasons to make further progress with it in 0.16
< wumpus> any other topics?
< wumpus> ... I guess not, we can end the meeting early
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Jul 20 19:44:01 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< instagibbs> "activate segwit" maybe not so much of a joke this time :)
< sipa> may be the fork be with you
< sipa> always
< wumpus> it was never a joke :)
< cfields> instagibbs: whew, good thing we don't have to talk about a UASF to activate BIP91 :p
< instagibbs> we still have time!
< kanzure> should there be a reorgs warning about bip91 and possible partial activation
< kanzure> ?
< instagibbs> bitcoincore.org could have something like bitcoin.org's warning
< instagibbs> btcdrak, ?
< Chris_Stewart_5> kanzure: that is what I was wondering too
< kanzure> the bitcoin.org warning was about aug1?
< instagibbs> oh right
< kanzure> well i don't know.
< gmaxwell> premature.
< gmaxwell> we should look again a day after 91 lockin.
< kanzure> is there signalling during the lock in period?
< gmaxwell> it may be at that point ~100% hashrate is setting bit 1 and there will be little reason to warn more.
< sipa> bip9 specifies that there should
< kanzure> well okay then.
< jtimon> sipa: but it is not required, is it?
< gmaxwell> if its still 50% hashrate setting bit1 at that point, there will need to be a warning.
< sipa> jtimon: it is not consensus enforced
< btcdrak> instagibbs: sorry battery died
< jtimon> I don't see why specify that then, it doesn't make any difference, does it? not even the warnings need it, do they?
< sipa> jtimon: it's helpful to be able to observe how the adoption goes
< jtimon> oh, I see
< instagibbs> how do I trigger a rescan inside -cli?(outside of importing a key/addr...)
< instagibbs> sorry for #bitcoin level q, testing
< jonasschnelli> instagibbs: impossibke
< sipa> isn't there a rescanchain RPC?
< sipa> or was that in an unmerged PR?
< instagibbs> so... I have to import a junk key to recover? oh boi
< jonasschnelli> But unmerged
< sipa> oh
< jonasschnelli> I think RPC makes much more sense then -argument
< jonasschnelli> Will rebase soon
< instagibbs> ah! walletpassphrase calls topup, and rescan works. Ok.
< Guest19525> shouldnt there be a better warning for "“unknown block versions being mine”
< Guest19525> ?
< jnewbery> wumpus: Any chance of #10604 being tagged 0.15?
< gribble> https://github.com/bitcoin/bitcoin/issues/10604 | [wallet] [tests] Add listwallets RPC, include wallet name in `getwalletinfo` and add multiwallet test by jnewbery · Pull Request #10604 · bitcoin/bitcoin · GitHub
< wumpus> jnewbery: tagged
< wumpus> (don't know if it's going to be controversial because it adds RPC stuff after the feature freeze, but it seems pretty simple straightforward)
< wumpus> ...and doesn't add translation messages
< jnewbery> thanks. It had plenty of ACKs while we were settling on the multiwallet API. Trivial rebase
< jnewbery> speaking of translations, #10882 has some translations strings. Is that going to be an issue?
< gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
< wumpus> jnewbery: it's increasingly unlikely that they're going to be translated before the 0.15 release
< jnewbery> ok, but that doesn't block the PR from going in?
< wumpus> blah according to the release schedule it should, it's too late to change messages, but anyhow having the functionality untranslated is better than not having it at all in this case I guess?
< wumpus> that's the consideration that needs to be made, the message freeze is there to give the translators time, and thus increase the quality of the translations, but that might not matter for last-minute fixes
< wumpus> would be stupid to leave the walllet in a broken state just because we can't add a translation emssage
< jnewbery> ok good. 10882 is now mostly waiting on review. So far I have comments from instagibbs and ryanofsky
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/6adc3a37324caa07015368bfe8529e1964366eef
< bitcoin-git> bitcoin/master 6adc3a3 Wladimir J. van der Laan: qt: Periodic translations update...