< meshcollider>
should doc/files.md reflect what would be created on a clean install, or should it take into account legacy locations in use for compatibility?
< meshcollider>
Specifically, for #11466, should I only mentioned wallets/database/*, wallets/db.log and wallets/wallet.dat ? Or does it need a node that they might be in the root dir instead?
< luke-jr>
meshcollider: see the existing entries..
< luke-jr>
there's separate section for old files
< meshcollider>
luke-jr: Oh true, thanks
< meshcollider>
luke-jr: but I'm unsure, because if you upgrade an existing node to, say, 0.16.0 when it is released, it will still use the old file location. This change only effects new installs
< meshcollider>
Should that still just be in its own section at the bottom?
< luke-jr>
not sure
< luke-jr>
IMO do what makes sense to you, and see if anyone complains on the PR
< meshcollider>
Alright sure :)
< jonasschnelli>
sipa: how can you leak specific data in ECDSA's r and s through nonce generation? Try and error until you have a couple of desired bytes at the end of r or s?
< gmaxwell>
no.
< jonasschnelli>
gmaxwell: does it require to generate a bunch of signatures?
< gmaxwell>
jonasschnelli: for a very dumb example, set the nonce to be k = H(message hash || constant the attacker knows). Now the attacker sees any transaction signed by this device, he instantly knows the nonce, and can determine the private key. That was is kinda boring because other people could learn the value and steal those too.
< gmaxwell>
jonasschnelli: so we can do better, k = H( xQ || message) where x is the user's private key, Q is some attacker public key. now only the attacker can derrive the nonce and steal the users private key.
< gmaxwell>
To send a message, do any of the above schemes, but steal some bits of the nonce (like 16 bits) have the attacker try all of them and you send 16 bits of additional data per signature, while also giving the attacker each private key you signed with. For example the additional data could leak the chaining code, so the attacker could derrive all past and future keys as well.
< jonasschnelli>
gmaxwell: but how does one extract the nonce from the signature?
< gmaxwell>
in the first example the attacker just does the same computation the wallet did to generate it. In the second example, the attacker takes his private key x' and multiplies it by the users public key that is signing. k = H( x'P || message).
< gmaxwell>
x'P == xQ because Q = x'G and P = xG so both of them are x'xG.
< gmaxwell>
(thats just ECDH)
< gmaxwell>
so user and attacker compute the same shared secret, hash it with the message being signed.. and use that as the nonce.
< gmaxwell>
so the attacker knows the nonce, and with the nonce can just derrive the secret key.
< * jonasschnelli>
reading and thinking...
< jonasschnelli>
gmaxwell: first Q. Why is H( xQ || message) better then H( attacker-constant || message)? Is there a difference if one learns the constant versus attackers pubkey Q?
< jonasschnelli>
or is xQ ECDH?
< gmaxwell>
imagine that some third party, not the attacker, and not the victim gets their hands on a backdoored device. They disassemble it and they learn the attacker-constant... then they could steal the coins themselves.
< meshcollider>
jonasschnelli: you need the attacker's private key not the public key
< jonasschnelli>
meshcollider: okay. I see. What notation is xQ? Multiplication?
< gmaxwell>
with xQ (the users private key times the attackers public key) then a third party which only knows the users and attacker's public keys, at msot, cannot steal the coins.
< jonasschnelli>
Okay. Got that
< meshcollider>
yes EC scalar multiplication
< gmaxwell>
so use of the ECDH is better because it makes the attack exclusive for the attacker.
< jonasschnelli>
Yes. Indeed
< jonasschnelli>
gmaxwell: And with the 16 stealed nonce bits, you could export the devices 256bit master seed (requires 16 signatures)...
< jonasschnelli>
But an attacked would have to try all 16bit combinations from all public known bitcoin signatures?
< gmaxwell>
yes, so for each transaction he wants to check, he's have to do 2^16 hashes... which would take like.. a microsecond. :)
< jonasschnelli>
okay.. I see
< jonasschnelli>
gmaxwell, meshcollider: Thanks. Got it. Thumbs up for the explanation...
< gmaxwell>
given bitcoin transaction rates perhaps he could plausably steal 32 of those bits per signature instead of 16.
< jonasschnelli>
gmaxwell: More stolen bytes = longer computation time? Thats the only limit, right?
< gmaxwell>
yes, but it goes up exponentially.
< gmaxwell>
to steal 4 extra-bytes per signature the attack is doing 2^32 work ... one thing an attacker might do is steal 16 bits in the first signature of a txn, and then 32 in all subsiquent signatures... so they can identify transactions relatively fast.
< gmaxwell>
so a transaction with three inputs would leak 10 bytes of data.
< jonasschnelli>
And I guess if he got around 200bits of the HWW master seed, he can calculate the seed by deriving keys and compare against the signatures...
< gmaxwell>
also there is an extra fun trick, if the attack code picks the extra data by indexing short chaincode[16]; ... extra_data = chaincode[messagehash%16]; then he might need to see many more than 16 signatures to steal the whole chain code. But if first the chaincode is expanded up with error correction, then the stolen data is a random chunk of the much larger error correction data... then
< gmaxwell>
the attacker will almost certantly be able to recover after seeing 16 signatures. (for a 32 byte extra-secret).
< gmaxwell>
and of course in all of this, a single signature always leaks the private key of the public key it was signing for.
< gmaxwell>
so the only reason to steal extra data is to just get a master secret for other accounts, or so it can steal coins for addresses that are only used once.
< jonasschnelli>
gmaxwell: I don't understand the "pick extra data by indexing". But if a signature can leak 16 bits, wouldn't it always be sufficient to have 16 signatures to leak 256bit? Under the assumption the leak-data code does sufficient up-count of the "already-sent-index" (maybe through EEPROM usage to avoid power-loss reset)
< aj>
jonasschnelli: yeah, if you didn't have EEPROM to know which bits to leak, you could pick the data to leak based on the hash you're signing, but then you'd need >>16 sigs to leak 256 bits
< aj>
jonasschnelli: but if you do erasure coding, you could leak 256 bits in 16 sigs without needing an EEPROM
< jonasschnelli>
Ah. Now I got it (partially understand erasure coding).
< jonasschnelli>
Conclusion: Only HODL with HWW's until sipa's proposed scheme is available. :)
< jonasschnelli>
I mean the MCU on the PCB could be tempered. Could have 512kb flash instead of 256kb and could shadow the bootloader/firmware... hard to impossible to detect I guess.
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #11713: Fix for mismatched extern definition in wallet tests (master...externfix) https://github.com/bitcoin/bitcoin/pull/11713
< gmaxwell>
aj: if you use a counter to choose the data your signature is no longer determinstic, so that might be obvious.
< gmaxwell>
aj: if you use the message hash to index, your signature is determinstic, and externally indistinguishable from normal behavior.
< aj>
gmaxwell: good point
< bitcoin-git>
[bitcoin] jamesob opened pull request #11714: [tests] Test that mempool rejects coinbase transactions (master...test-mempool-rejects-coinbase) https://github.com/bitcoin/bitcoin/pull/11714
< bitcoin-git>
[bitcoin] tjps opened pull request #11722: Switched sync.{cpp,h} to std threading primitives. (master...tjps_sync_antiboost) https://github.com/bitcoin/bitcoin/pull/11722
< Lauda>
Is the "spend unconfirmed change" feature not supposed to allow you to spend unconfirmed amounts coming from elsewhere?
< Lauda>
That should probably be added as well IMO.
< sipa>
no, it's about unconfirmed *change*, meaning money coming from yourself
< Lauda>
What do you think about adding a option for all unconfirmed outputs?
< Lauda>
i.e. is there a reason why the wallet does not have this?
< sipa>
yes, you know you won't doublespend your own money
< sipa>
you don't know that about money coming from elsewhere
< Lauda>
Well as an advanced feature, I know what I am doing. :P
< Lauda>
The use cases is probably just sending money to yourself from a second wallet
< Lauda>
and then wanting to move it elsewhere quickly
< Lauda>
as is, you have to wait
< sipa>
right, as an expert option i don't object
< sipa>
you can do it anyway through raw transaction interface
< Lauda>
The wallet tab is all expert features anyways. I think this would be a decent addition. + is likely to be needed post multiwallet GUI interface
< Lauda>
needed more often*
< Lauda>
I've opened an issue requesting such a feature.
< merehap>
Hi all, I just ran "make cov" on bitcoin core, looking for low hanging fruit for writing new unit tests. I found that src/rpc/blockchain.cpp has low coverage. Are there any objections to me adding unit tests for this file? Any caveats?
< sipa>
merehap: by all means!
< merehap>
sipa: Awesome, will get started on that now then.