< 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
< 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
< 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
< 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.
< 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)
< 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>
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)
< 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
< 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