Skip to content

Conversation

@NicolasDorier
Copy link
Contributor

@NicolasDorier NicolasDorier commented Aug 3, 2017

Breaking CKeyStore into two parts, one being the CKeyStore, the other CWatchOnlyStore.

The future externalhd would then just have to implement a new CKeyStore.

See #9728 (comment)

@NicolasDorier NicolasDorier force-pushed the decouplewatchonly branch 2 times, most recently from 3561d90 to d838f8c Compare August 7, 2017 14:31
@NicolasDorier NicolasDorier changed the title [WIP] Decouple CKeyStore from CWatchOnlyStore [Refactor] Decouple CKeyStore from CWatchOnlyStore Aug 17, 2017
@NicolasDorier
Copy link
Contributor Author

NicolasDorier commented Aug 17, 2017

This is the first step to achieve what is described on #9728 (comment)

Ping @instagibbs

@instagibbs
Copy link
Member

Will review.

Copy link
Member

@instagibbs instagibbs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

concept ACK, needs rebase

* and provides the ability to create new transactions.
*/
class CWallet : public CCryptoKeyStore, public CValidationInterface
class CWallet : public CCryptoKeyStore, public CWatchOnlyStore, public CValidationInterface
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update description above in comments to reflect new inheritance

@jtimon
Copy link
Contributor

jtimon commented Nov 2, 2017

Concept ACK, needs rebase

@sipa
Copy link
Member

sipa commented Nov 2, 2017

Concept NACK, I think this is a step in the wrong direction. The concept of watching should be removed from the keystore entirely.

@NicolasDorier
Copy link
Contributor Author

@sipa what do you mean? this is precisely the intent of this PR: Removing WatchOnlyStore from CKeyStore. (see the CWatchOnlyStore class)

@sipa
Copy link
Member

sipa commented Nov 2, 2017

@NicolasDorier There's no need for a separate store for watch-only, watching should be determined by the wallet, not the keys or anything related to signing.

I'm working on a design doc for how to evolve the watching/signing code and segwit/HD/... support. I'll let you know when it's in a usable state.

@ryanofsky
Copy link
Contributor

ryanofsky commented Jan 9, 2018

I'm working on a design doc for how to evolve the watching/signing code and segwit/HD/... support. I'll let you know when it's in a usable state.

Doc was posted as https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2#future-design

It does make this PR look like a step in a different direction if the goal is to have unified representation and handling of watchonly and signing keys.

It also isn't obvious to me how this PR would simplify https://github.com/instagibbs/bitcoin/commits/externalhd2 or #9728. @NicolasDorier it would be good if you could explain more why this change is useful, and whether you think anything in sipa's design might make it more difficult to support external hd wallets.

@instagibbs
Copy link
Member

I've implemented hww support, and I believe the design document posted goes more in the right direction to make it sane and palatable for upstream. Obviously it will be a much larger project...

@NicolasDorier
Copy link
Contributor Author

NicolasDorier commented Jan 10, 2018

@ryanofsky this PR was an attempt to fix my immediate problem on externalhd2. I was trying to fix the mess incrementally, one PR after another.

The design doc has a different approach: Complete redesign + one time migration. I agree with the general direction it takes (I need to re read it later though), it just seems to me it will be quite hard to do incrementally.

@NicolasDorier
Copy link
Contributor Author

NicolasDorier commented Jan 10, 2018

@ryanofsky Just additional information about what I was thinking. This is long time ago so I might not remember all details...

Currently externalhd2 works fine but generate the address as "watch-only".
The problem is that core consider an address "IS_MINE" only if you can sign. (which is not the case for addresses generated by external hd)

But nevertheless, the watchonly addresses generated by externalhd2 should be considered IS_MINE even if I can't sign. Because I want Core to behave exactly as if it was a normal wallet, except without it the ability to sign with the generated keys. (Another PR related to that that I had was separating IS_MINE from IS_SIGNABLE)

My solution was to create a new implementation of CKeyStore for external hd keys.
The old CKeyStore would still be used in non-external hd mode.
And I would keep the WatchOnlyStore separately from those classes. (As the WatchOnlyStore still need to exist independently from the CKeyStore implementation use)

Because generated addresses would come from the CKeyStore, it would be considered "IS_MINE".

This PR was the first step: Separating CWatchStore from CKeyStore.

I was attempting to slowly refactor the current flawed design until it get better. The design document though takes the bulldozer approach. (which might be OK, just harder)

@NicolasDorier
Copy link
Contributor Author

closing this, my approach of slowly refactoring does not seem to get traction.

@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants