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

add key generation type #5916

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@jonasschnelli
Member

jonasschnelli commented Mar 17, 2015

A encrypted wallet can still hold keys which where created when the wallet was unencrypted.
Could solve #3314.

This PR will add a 8bit-flags-int to the CKeyMetadata class.

listreceivedbyaddress will report whether the key was generated within a encrypted wallet or if it was imported throught importprivkey.

If this gets conceptual ACKs id like to extend this to the UI level.

@laanwj laanwj added the Wallet label Mar 18, 2015

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Mar 18, 2015

Member

Remembering where a key comes from, yeah, why not.

Member

laanwj commented Mar 18, 2015

Remembering where a key comes from, yeah, why not.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Mar 18, 2015

Member

"generationtype" may not be the best name though; we also have "generated" for wallet transactions that shows whether the coins were mined.

Member

laanwj commented Mar 18, 2015

"generationtype" may not be the best name though; we also have "generated" for wallet transactions that shows whether the coins were mined.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Mar 18, 2015

Member

What about using keyGenerationType?

Member

jonasschnelli commented Mar 18, 2015

What about using keyGenerationType?

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Mar 18, 2015

Member

key_generation_type then, we don't tend to use lowerCamelCase in RPC

Member

laanwj commented Mar 18, 2015

key_generation_type then, we don't tend to use lowerCamelCase in RPC

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Mar 18, 2015

Member

Right.
Changed and pushed.

Member

jonasschnelli commented Mar 18, 2015

Right.
Changed and pushed.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Mar 20, 2015

Member

Hm, one thought: Would the resulting wallet still be backwards compatible?
We have a versioning/upgrade system for wallets, not sure if it should be used here.

Member

laanwj commented Mar 20, 2015

Hm, one thought: Would the resulting wallet still be backwards compatible?
We have a versioning/upgrade system for wallets, not sure if it should be used here.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Mar 20, 2015

Member

Good point. I'll have to check/test the backward compatibility. I'm not sure what happens to the deserialization when there are one additional byte at the end.

Member

jonasschnelli commented Mar 20, 2015

Good point. I'll have to check/test the backward compatibility. I'm not sure what happens to the deserialization when there are one additional byte at the end.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Mar 20, 2015

Member

It's backward and forward compatible.
Tested.

The 1byte flag added at the end of the CKeyMetadata serialization stream will be ignored when running (old) master-branch. Using a "new" wallet on a "old" bitcoind will still keep the key generation data because Metadata is somehow immutable (will only be created/changes when a key gets generated).
Also testes with a full keypool generated with "key generation type".

bildschirmfoto-2015-03-20-um-10 50 30

Member

jonasschnelli commented Mar 20, 2015

It's backward and forward compatible.
Tested.

The 1byte flag added at the end of the CKeyMetadata serialization stream will be ignored when running (old) master-branch. Using a "new" wallet on a "old" bitcoind will still keep the key generation data because Metadata is somehow immutable (will only be created/changes when a key gets generated).
Also testes with a full keypool generated with "key generation type".

bildschirmfoto-2015-03-20-um-10 50 30

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Mar 24, 2015

Member

SGTM, utACK

Member

laanwj commented Mar 24, 2015

SGTM, utACK

Show outdated Hide outdated src/wallet/walletdb.h
@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Jun 2, 2015

Member

I don't understand the term "generation" in this context.

Member

luke-jr commented Jun 2, 2015

I don't understand the term "generation" in this context.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Jun 2, 2015

Member

@luke-jr: "generation" was the best i could find. What would you prefer (maybe something like "Key generation environment" or "key generation security context")?

Member

jonasschnelli commented Jun 2, 2015

@luke-jr: "generation" was the best i could find. What would you prefer (maybe something like "Key generation environment" or "key generation security context")?

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Jun 24, 2015

Member

"origin" perhaps.

Also, this is lacking -upgradewallet logic. Even if old versions can handle it, third-party software might not.

Member

luke-jr commented Jun 24, 2015

"origin" perhaps.

Also, this is lacking -upgradewallet logic. Even if old versions can handle it, third-party software might not.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Jun 24, 2015

Member

@luke-jr: right, it missed the -upgradewallet approach. I aim for including the key origin/generation type in the new wallet.

Member

jonasschnelli commented Jun 24, 2015

@luke-jr: right, it missed the -upgradewallet approach. I aim for including the key origin/generation type in the new wallet.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Jun 24, 2015

Member

Renamed to key origin and added wallet new wallet feature level 70000

Member

jonasschnelli commented Jun 24, 2015

Renamed to key origin and added wallet new wallet feature level 70000

keyFlags = pwalletMain->mapKeyMetadata[keyID].keyFlags;
std::string keyOrigin;
if (keyFlags & CKeyMetadata::KEY_ORIGIN_UNKNOWN)

This comment has been minimized.

@luke-jr

luke-jr Jul 11, 2015

Member

Shouldn't this be used for actually unknown origins (eg, 0 or no-known-bits-set)?

@luke-jr

luke-jr Jul 11, 2015

Member

Shouldn't this be used for actually unknown origins (eg, 0 or no-known-bits-set)?

This comment has been minimized.

@jonasschnelli

jonasschnelli Jul 11, 2015

Member

Yes. Agree with you. I will change this to not only holding KEY_ORIGIN within the flags... update is on the way.

@jonasschnelli

jonasschnelli Jul 11, 2015

Member

Yes. Agree with you. I will change this to not only holding KEY_ORIGIN within the flags... update is on the way.

@laanwj

View changes

Show outdated Hide outdated src/wallet/walletdb.h
@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Sep 15, 2015

Contributor

concept and code review ACK

Contributor

jgarzik commented Sep 15, 2015

concept and code review ACK

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Sep 16, 2015

Contributor

NACK on the bit flag, concept ACK on the general idea (tracking private key origin).
An enumeration sounds fine.

Contributor

dcousens commented Sep 16, 2015

NACK on the bit flag, concept ACK on the general idea (tracking private key origin).
An enumeration sounds fine.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Sep 16, 2015

Member

@dcousens: i really like the idea of bit flags. IMO it is flexible, it could indicate different things like if a key was generated deterministic after bip32, etc. What are the downsides of the bit flags compared to a enum/int?

Member

jonasschnelli commented Sep 16, 2015

@dcousens: i really like the idea of bit flags. IMO it is flexible, it could indicate different things like if a key was generated deterministic after bip32, etc. What are the downsides of the bit flags compared to a enum/int?

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Sep 16, 2015

Contributor

@jonasschnelli I'd go so far to say that this could be user defined, as even a string type might be suitable.
The bit flag idea seems very isolated and only useful for very specific applications.

I don't really have a strong opinion either way on this, did you have a use case in mind?

edit: in terms of #3314, a bit flag would make sense.

Contributor

dcousens commented Sep 16, 2015

@jonasschnelli I'd go so far to say that this could be user defined, as even a string type might be suitable.
The bit flag idea seems very isolated and only useful for very specific applications.

I don't really have a strong opinion either way on this, did you have a use case in mind?

edit: in terms of #3314, a bit flag would make sense.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Sep 24, 2015

Member

I'd disagree with using a string type. It uses more memory and disk space (this is per key!), and is also worst for anything machine-understandable.

Member

laanwj commented Sep 24, 2015

I'd disagree with using a string type. It uses more memory and disk space (this is per key!), and is also worst for anything machine-understandable.

jonasschnelli added some commits Mar 17, 2015

add key generation type
A encrypted wallet can still hold keys which where created when the wallet was unencrypted.

This PR will add a 8bit-flags-int to the CKeyMetadata class.

`listreceivedbyaddress` will report whether the key was generated within a enctypted wallet or if it was imported throught `importprivkey`
@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Sep 24, 2015

Member

Rebased and replace the 8bit bitfield with a 32bit bitfield, also removed the "unset" keyflag.

Member

jonasschnelli commented Sep 24, 2015

Rebased and replace the 8bit bitfield with a 32bit bitfield, also removed the "unset" keyflag.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Oct 23, 2015

Member

How will this top commit affect wallets with top-minus-one keyFlags? Bitcoin LJR includes the previous semantics, and it would be nice not to break loading such wallets. Maybe the wallet version can be bumped one to handle that case?

Member

luke-jr commented Oct 23, 2015

How will this top commit affect wallets with top-minus-one keyFlags? Bitcoin LJR includes the previous semantics, and it would be nice not to break loading such wallets. Maybe the wallet version can be bumped one to handle that case?

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Oct 23, 2015

Member

@luke-jr: hmm.. yes. This would be required unless we want to break LJR 0.11 wallets. I have plans to update this PR, but it will take some weeks (this PR has low prio). If anyone likes to take this over: go ahead.

Member

jonasschnelli commented Oct 23, 2015

@luke-jr: hmm.. yes. This would be required unless we want to break LJR 0.11 wallets. I have plans to update this PR, but it will take some weeks (this PR has low prio). If anyone likes to take this over: go ahead.

@pstratem

This comment has been minimized.

Show comment
Hide comment
@pstratem

pstratem Dec 8, 2015

This doesn't look like it would handle multiple flags being set very well.

pstratem commented on src/wallet/rpcwallet.cpp in f1fef04 Dec 8, 2015

This doesn't look like it would handle multiple flags being set very well.

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Feb 10, 2016

Collaborator

Yea, if a non-sensible combination of bits is set, it should probably report it as 'unknown'.

Edit: or better, simply return a list of strings here.

Collaborator

laanwj replied Feb 10, 2016

Yea, if a non-sensible combination of bits is set, it should probably report it as 'unknown'.

Edit: or better, simply return a list of strings here.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Feb 10, 2016

Member

Rebased and replace the 8bit bitfield with a 32bit bitfield, also removed the "unset" keyflag.

That's better.
Concept ACK.

Member

laanwj commented Feb 10, 2016

Rebased and replace the 8bit bitfield with a 32bit bitfield, also removed the "unset" keyflag.

That's better.
Concept ACK.

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Apr 5, 2016

Member

Concept ACK.

Member

btcdrak commented Apr 5, 2016

Concept ACK.

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 27, 2016

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Jul 20, 2016

Member

Do we really need a minVersionBump for this change?
This PRs minVersionBump to 70000 is kinda senseless.

What about just detecting the change in the deserialization code?
I guess every useable deserialization code (assume third party apps) can handle this.

Member

jonasschnelli commented Jul 20, 2016

Do we really need a minVersionBump for this change?
This PRs minVersionBump to 70000 is kinda senseless.

What about just detecting the change in the deserialization code?
I guess every useable deserialization code (assume third party apps) can handle this.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Jul 20, 2016

Member

Well, we don't want to add data unless the user upgrades their wallet explicitly (or makes a new one) either.

Member

luke-jr commented Jul 20, 2016

Well, we don't want to add data unless the user upgrades their wallet explicitly (or makes a new one) either.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Jul 20, 2016

Member

Well, we don't want to add data unless the user upgrades their wallet explicitly (or makes a new one) either.

But this would make the upgraded wallet no longer work with older versions of bitcoin-core (<0.13 if we would merge this for 0.13) even with the fact that older version are capable of handling the changed/new CKeyMetadata format. This sounds inefficient to me.

Member

jonasschnelli commented Jul 20, 2016

Well, we don't want to add data unless the user upgrades their wallet explicitly (or makes a new one) either.

But this would make the upgraded wallet no longer work with older versions of bitcoin-core (<0.13 if we would merge this for 0.13) even with the fact that older version are capable of handling the changed/new CKeyMetadata format. This sounds inefficient to me.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Jul 20, 2016

Member

Won't old versions currently strip off the key origin data, even if they load the wallet itself okay?

Member

luke-jr commented Jul 20, 2016

Won't old versions currently strip off the key origin data, even if they load the wallet itself okay?

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Aug 9, 2016

Member

Closing in favor of #8471

Member

jonasschnelli commented Aug 9, 2016

Closing in favor of #8471

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment