1 2017-11-18 03:37:00 0|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?
2 2017-11-18 03:38:03 0|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?
3 2017-11-18 03:38:06 0|gribble|https://github.com/bitcoin/bitcoin/issues/11466 | Specify custom wallet directory with -walletdir param by MeshCollider ÷ Pull Request #11466 ÷ bitcoin/bitcoin ÷ GitHub
4 2017-11-18 03:38:17 0|meshcollider|s/node/note/
5 2017-11-18 03:55:33 0|sipa|noded.
6 2017-11-18 03:57:10 0|luke-jr|meshcollider: see the existing entries..
7 2017-11-18 03:57:18 0|luke-jr|there's separate section for old files
8 2017-11-18 03:58:08 0|meshcollider|luke-jr: Oh true, thanks
9 2017-11-18 04:00:20 0|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
10 2017-11-18 04:00:41 0|meshcollider|Should that still just be in its own section at the bottom?
11 2017-11-18 04:00:44 0|luke-jr|not sure
12 2017-11-18 04:01:16 0|luke-jr|IMO do what makes sense to you, and see if anyone complains on the PR
13 2017-11-18 04:01:36 0|meshcollider|Alright sure :)
14 2017-11-18 06:24:20 0|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?
15 2017-11-18 06:25:44 0|gmaxwell|no.
16 2017-11-18 06:26:54 0|jonasschnelli|gmaxwell: does it require to generate a bunch of signatures?
17 2017-11-18 06:27:08 0|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.
18 2017-11-18 06:28:02 0|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.
19 2017-11-18 06:29:16 0|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.
20 2017-11-18 06:30:21 0|jonasschnelli|gmaxwell: but how does one extract the nonce from the signature?
21 2017-11-18 06:32:00 0|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).
22 2017-11-18 06:32:38 0|gmaxwell|x'P == xQ because Q = x'G and P = xG so both of them are x'xG.
23 2017-11-18 06:32:47 0|gmaxwell|(thats just ECDH)
24 2017-11-18 06:33:19 0|gmaxwell|so user and attacker compute the same shared secret, hash it with the message being signed.. and use that as the nonce.
25 2017-11-18 06:33:43 0|gmaxwell|so the attacker knows the nonce, and with the nonce can just derrive the secret key.
26 2017-11-18 06:38:19 0|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?
27 2017-11-18 06:38:58 0|jonasschnelli|or is xQ ECDH?
28 2017-11-18 06:39:06 0|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.
29 2017-11-18 06:39:15 0|meshcollider|jonasschnelli: you need the attacker's private key not the public key
30 2017-11-18 06:39:37 0|jonasschnelli|meshcollider: okay. I see. What notation is xQ? Multiplication?
31 2017-11-18 06:40:14 0|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.
32 2017-11-18 06:40:27 0|jonasschnelli|Okay. Got that
33 2017-11-18 06:40:29 0|meshcollider|yes EC scalar multiplication
34 2017-11-18 06:40:55 0|gmaxwell|so use of the ECDH is better because it makes the attack exclusive for the attacker.
35 2017-11-18 06:41:11 0|jonasschnelli|Yes. Indeed
36 2017-11-18 06:42:20 0|jonasschnelli|gmaxwell: And with the 16 stealed nonce bits, you could export the devices 256bit master seed (requires 16 signatures)...
37 2017-11-18 06:42:56 0|jonasschnelli|But an attacked would have to try all 16bit combinations from all public known bitcoin signatures?
38 2017-11-18 06:43:59 0|gmaxwell|yes, so for each transaction he wants to check, he's have to do 2^16 hashes... which would take like.. a microsecond. :)
39 2017-11-18 06:44:09 0|jonasschnelli|okay.. I see
40 2017-11-18 06:45:04 0|jonasschnelli|gmaxwell, meshcollider: Thanks. Got it. Thumbs up for the explanation...
41 2017-11-18 06:45:15 0|gmaxwell|given bitcoin transaction rates perhaps he could plausably steal 32 of those bits per signature instead of 16.
42 2017-11-18 06:46:19 0|jonasschnelli|gmaxwell: More stolen bytes = longer computation time? Thats the only limit, right?
43 2017-11-18 06:48:05 0|gmaxwell|yes, but it goes up exponentially.
44 2017-11-18 06:49:14 0|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.
45 2017-11-18 06:49:41 0|gmaxwell|so a transaction with three inputs would leak 10 bytes of data.
46 2017-11-18 06:51:37 0|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...
47 2017-11-18 06:52:41 0|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
48 2017-11-18 06:52:48 0|gmaxwell|the attacker will almost certantly be able to recover after seeing 16 signatures. (for a 32 byte extra-secret).
49 2017-11-18 06:53:00 0|gmaxwell|and of course in all of this, a single signature always leaks the private key of the public key it was signing for.
50 2017-11-18 06:53:27 0|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.
51 2017-11-18 06:57:23 0|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)
52 2017-11-18 07:02:48 0|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
53 2017-11-18 07:03:12 0|aj|jonasschnelli: but if you do erasure coding, you could leak 256 bits in 16 sigs without needing an EEPROM
54 2017-11-18 07:04:06 0|jonasschnelli|Ah. Now I got it (partially understand erasure coding).
55 2017-11-18 07:06:32 0|jonasschnelli|Conclusion: Only HODL with HWW's until sipa's proposed scheme is available. :)
56 2017-11-18 07:07:58 0|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.
57 2017-11-18 08:00:22 0|bitcoin-git|[13bitcoin] 15sipsorcery opened pull request #11713: Fix for mismatched extern definition in wallet tests (06master...06externfix) 02 https://github.com/bitcoin/bitcoin/pull/11713
58 2017-11-18 08:06:15 0|gmaxwell|aj: if you use a counter to choose the data your signature is no longer determinstic, so that might be obvious.
59 2017-11-18 08:07:02 0|gmaxwell|aj: if you use the message hash to index, your signature is determinstic, and externally indistinguishable from normal behavior.
60 2017-11-18 08:11:23 0|aj|gmaxwell: good point
61 2017-11-18 08:57:24 0|bitcoin-git|[13bitcoin] 15jamesob opened pull request #11714: [tests] Test that mempool rejects coinbase transactions (06master...06test-mempool-rejects-coinbase) 02 https://github.com/bitcoin/bitcoin/pull/11714
62 2017-11-18 11:06:40 0|bitcoin-git|13bitcoin/06master 14dcfef27 15Wladimir J. van der Laan: cli: Reject arguments to -getinfo...
63 2017-11-18 11:06:40 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/142913296f00...938863965f14
64 2017-11-18 11:06:41 0|bitcoin-git|13bitcoin/06master 149388639 15Wladimir J. van der Laan: Merge #11710: cli: Reject arguments to -getinfo...
65 2017-11-18 11:07:15 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11710: cli: Reject arguments to -getinfo (06master...062017_11_getinfo_args) 02 https://github.com/bitcoin/bitcoin/pull/11710
66 2017-11-18 13:03:53 0|bitcoin-git|13bitcoin/06master 1449667a7 15Wladimir J. van der Laan: Merge #11713: Fix for mismatched extern definition in wallet tests...
67 2017-11-18 13:03:53 0|bitcoin-git|13bitcoin/06master 14f94c2ec 15Aaron Clauson: Fix for mismatched extern definition in wallet test classes which was breaking msvc linking.
68 2017-11-18 13:03:53 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/938863965f14...49667a77e76a
69 2017-11-18 13:04:23 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11713: Fix for mismatched extern definition in wallet tests (06master...06externfix) 02 https://github.com/bitcoin/bitcoin/pull/11713
70 2017-11-18 13:15:02 0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #11718: tests: move pwalletMain to wallet test fixture (06master...062017_11_wallet_test_fixture) 02 https://github.com/bitcoin/bitcoin/pull/11718
71 2017-11-18 13:41:55 0|bitcoin-git|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/49667a77e76a...d080a7d5030e
72 2017-11-18 13:41:56 0|bitcoin-git|13bitcoin/06master 140530ba0 15MeshCollider: Add -walletdir parameter to specify custom wallet dir
73 2017-11-18 13:41:57 0|bitcoin-git|13bitcoin/06master 1480c5cbc 15MeshCollider: Add test for -walletdir
74 2017-11-18 13:41:57 0|bitcoin-git|13bitcoin/06master 14d987889 15MeshCollider: Add release notes for -walletdir and wallets/ dir
75 2017-11-18 13:42:19 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11466: Specify custom wallet directory with -walletdir param (06master...06201710_walletdir) 02 https://github.com/bitcoin/bitcoin/pull/11466
76 2017-11-18 19:39:03 0|bitcoin-git|[13bitcoin] 15tjps opened pull request #11722: Switched sync.{cpp,h} to std threading primitives. (06master...06tjps_sync_antiboost) 02 https://github.com/bitcoin/bitcoin/pull/11722
77 2017-11-18 19:57:22 0|Lauda|Is the "spend unconfirmed change" feature not supposed to allow you to spend unconfirmed amounts coming from elsewhere?
78 2017-11-18 19:57:35 0|Lauda|That should probably be added as well IMO.
79 2017-11-18 19:58:29 0|sipa|no, it's about unconfirmed *change*, meaning money coming from yourself
80 2017-11-18 19:59:22 0|Lauda|What do you think about adding a option for all unconfirmed outputs?
81 2017-11-18 19:59:37 0|Lauda|i.e. is there a reason why the wallet does not have this?
82 2017-11-18 19:59:52 0|sipa|yes, you know you won't doublespend your own money
83 2017-11-18 20:00:11 0|sipa|you don't know that about money coming from elsewhere
84 2017-11-18 20:00:24 0|Lauda|The use cases is probably just sending money to yourself from a second wallet
85 2017-11-18 20:00:24 0|Lauda|Well as an advanced feature, I know what I am doing. :P
86 2017-11-18 20:00:29 0|Lauda|and then wanting to move it elsewhere quickly
87 2017-11-18 20:00:34 0|Lauda|as is, you have to wait
88 2017-11-18 20:00:47 0|sipa|right, as an expert option i don't object
89 2017-11-18 20:00:57 0|sipa|you can do it anyway through raw transaction interface
90 2017-11-18 20:01:27 0|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
91 2017-11-18 20:01:51 0|Lauda|needed more often*
92 2017-11-18 20:08:26 0|Lauda|I've opened an issue requesting such a feature.
93 2017-11-18 22:15:59 0|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?
94 2017-11-18 22:29:48 0|sipa|merehap: by all means!
95 2017-11-18 22:31:30 0|merehap|sipa: Awesome, will get started on that now then.
96 2017-11-18 22:32:33 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 6 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/d080a7d5030e...0d89fa087793
97 2017-11-18 22:32:34 0|bitcoin-git|13bitcoin/06master 142613c54 15John Newbery: [tests] fix flake8 warnings in sendheaders.py
98 2017-11-18 22:32:34 0|bitcoin-git|13bitcoin/06master 14f39d4bb 15John Newbery: [tests] tidy up BaseNode in sendheaders.py
99 2017-11-18 22:32:35 0|bitcoin-git|13bitcoin/06master 1425fd6e2 15John Newbery: [tests] refactor check_last_announcement() in sendheaders.py...
100 2017-11-18 22:33:09 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11707: [tests] Fix sendheaders (06master...06fix_sendheaders) 02 https://github.com/bitcoin/bitcoin/pull/11707