-
Notifications
You must be signed in to change notification settings - Fork 38.7k
Can create External HD wallet with -externalhd #9728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
src/wallet/walletdb.h
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
>=?
src/wallet/wallet.cpp
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/AddKey/AddWatchOnly/
src/wallet/wallet.cpp
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think returning false in case of isWatchOnly is confusing.
IMO better set the hasSecret boolean with another check of hdChain.isWatchOnly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can replace returns bool by void, and make the client responsible to test the validity of the returned Key.
But I fear that a new user would assume that DeriveNewKey always returns a valid CKey.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I once did a PR where we separate the key/pubkey records: #9298
I guess this would be the cleaner solution... but maybe later.
|
Concept ACK (will review in detail and test soon). |
ef90ffb to
d66e33a
Compare
Instead of removing the wallet, it would also be possible to specify an alternative one with |
|
How does this work, considering that Core is exclusively hardened derivation right now? Or can it only watch non-Core wallets? O.o |
For the hd-watch-only default keypath, we should probably use Bip44. |
899e384 to
4d81253
Compare
|
Travis error not related to this PR. |
|
@NicolasDorier: I think in order to pass travis you need to add |
|
I added a commit to track P2PK as well. It would be the same behavior as normal wallet. However I am not sure it is the right approach as P2PK are obsolete. An attacker could disrupt service by sending a P2PK output, when the service does not expect it. Also, what for P2WPKH ? |
b79a3ce to
14d9a0d
Compare
e69b273 to
de5b860
Compare
|
I am replicating the behavior of normal wallets, both p2pk and p2pkh are tracked. The test is failing because I am testing wrong parameter usage, and there is no way in the test framework to assert an exception. Ping @MarcoFalke , same problem as reported by jonas on #9662 |
8ec7c56 to
fc8f811
Compare
qa/rpc-tests/test_framework/util.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this additional optional arg required? I don't think this will ever be used.
Edit: I see you are doing it for consistency, so might be fine...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is used by assert_start_raises_init_error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, right. I missed the plural s.
fc8f811 to
d8c3b37
Compare
|
I am at loss understanding why there is a permission denied on travis.... I thought I maybe did not had right to /dev/null, and tried to redirect stderr to stdout instead, but same problem. Any idea ? |
Try chmod +x qa/rpc-tests/hdwatchonly.py |
e82852f to
2d91dd4
Compare
61b180b to
1e99dae
Compare
1e99dae to
1cac7a6
Compare
| " \"unlocked_until\": ttt, (numeric) the timestamp in seconds since epoch (midnight Jan 1 1970 GMT) that the wallet is unlocked for transfers, or 0 if the wallet is locked\n" | ||
| " \"paytxfee\": x.xxxx, (numeric) the transaction fee configuration, set in " + CURRENCY_UNIT + "/kB\n" | ||
| " \"hdmasterkeyid\": \"<hash160>\" (string) the Hash160 of the HD master pubkey\n" | ||
| " \"hdmasterkeyid\": \"<hash160>\" (string) the Hash160 of the HD master pubkey\n" + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: missing two whitespaces before (string).
| } | ||
| } | ||
| else { | ||
| if (!AddWatchOnly(pubkey, metadata, nCreationTime)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: brackets
| do { | ||
| if (internal) { | ||
| chainChildKey.Derive(childKey, hdChain.nInternalChainCounter); | ||
| metadata.hdKeypath = "m/1/" + std::to_string(hdChain.nInternalChainCounter); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for other reviewers: the account key level is dropped here because it's hardened in BIP44. Maybe a source code comment would be good.
|
Re-Concept ACK. This should really be something we want in 0.16. |
|
Needs rebase. |
|
@jonasschnelli We talked about this PR at Tokyo with @instagibbs and @sipa . Basically we agreed that contrary to what this PR does, the generated keys should not be considered as WATCH_ONLY but as SPENDABLE, even if core do not have the keys, it is still signable. This mean that we need to refactor the wallet to first decouple a new class: I tried to do that in a separate PR, but this goes deep into the rabbit hole, I will need more work on it. |
|
What is the status of this? |
|
So @saleemrashid is using it for hardware support in Bitcoin Core. I am using it in prod for quite a while, so this is stable. However, this is not the best way to do, ideally we should do like I detailed here #9728 (comment) . This would need deeper review, and sadly I am out of time these days to follow through and keep rebasing. So if someone wants to take it over, it would probably be better. |
|
For those interested, I'm rebasing at https://github.com/instagibbs/bitcoin/tree/externalhd2 |
|
Rebase required... |
|
@instagibbs is maintaining a rebased version I think do you want to supersede this PR? |
|
Sure I can open a replacement PR if people are interested. I'm not actively pushing for merge at this time however. |
|
So the reason I put that back on the shelf, is that I think we want to do that after a major overall wallet refactoring that @sipa proposed on https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2#future-design This PR is creating new addresses as watch-only, this is however not what we want. We want addresses to be |
|
Closing this it seems that we need deeper wallet refactoring as specified by sipa on https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2#future-design @instagibbs is maintaining https://github.com/instagibbs/bitcoin/tree/externalhd2 for those interested to continue this work. |
The user creates a new wallet by running
./bitcoind -externalhd=[ExtPubKey base58].This make it possible to use methods like
getnewaddress,fundrawtransactionand all normal wallet operations on a HD pubkey.Software built on top of core which need to delegate signing operations to hardware wallet will have almost the same code as if signing was done by Core.
With the introduction of a standard for dealing with hardware wallet signing in the future, I expect that
signrawtransactionwill just delegate the signing to the hardware wallet.In this way, there will be no code difference between software using third party solution for signing, and those just using core for signing.
I will use it in my own projects. My HW is giving me the ExtPubKey, and I want to use bitcoin core just for coin selection and tracking. I also did not wanted to break bunch of old code. Ping @jonasschnelli
EDIT: @saleemrashid built HW support for Bitcoin Core on https://github.com/saleemrashid/bitcoin/tree/hardware-wallet based on this PR