-
Notifications
You must be signed in to change notification settings - Fork 810
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
Wallet: require public key for watchonly #639
Conversation
Codecov Report
@@ Coverage Diff @@
## master #639 +/- ##
=========================================
+ Coverage 53.18% 53.2% +0.02%
=========================================
Files 104 104
Lines 27724 27724
Branches 4752 4752
=========================================
+ Hits 14745 14751 +6
+ Misses 12979 12973 -6
Continue to review full report at Codecov.
|
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.
OK. Needs a deprecation warning and API docs documenting this backward-incompatible change.
Added note in changelog, will update API docs after merge |
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.
LGTM +1
Wallet: require public key for watchonly
Merged in 375965c |
Addresses #636 in which a user creates private keys they could never access due to a wallet being watch-only.
This PR goes along with #637 and bcoin-org/bclient#15, maybe we can decide if we need all three safeties in place or which ones we do or don't need.
In this pull request, we prevent a watch-only wallet from ever generating a master (private) key which could lead to a user seeing addresses they can not spend from.
I think
watchOnly
should always require anaccountKey
. The reverse isn't necessarily required, for example inbclient
, creating a wallet withaccountKey
automatically setswatchOnly
totrue
. In bcoinwallet._createAccount()
,accountKey
is just ignored ifwatchOnly
is false, but at least that doesn't lead to unrecoverable keys!