Skip to content

Conversation

@instagibbs
Copy link
Member

@instagibbs instagibbs commented Feb 20, 2019

The current usage seems to be an overloading of meanings. CScriptID is used in the wallet as a lookup key, as well as a destination, and CKeyID likewise. Instead, have all destinations be dedicated types.

New types:
CScriptID->ScriptHash
CKeyID->PKHash

@DrahtBot
Copy link
Contributor

DrahtBot commented Feb 20, 2019

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #15093 (rpc: Change importwallet to return additional errors by marcinja)
  • #12578 (gui: Add transaction record type Fee by promag)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@sipa
Copy link
Member

sipa commented Feb 22, 2019

Concept ACK. I believe @ryanofsky suggested something like this before.

@instagibbs
Copy link
Member Author

Not sure how to read appveyor error tbh

@maflcko
Copy link
Member

maflcko commented Feb 26, 2019

The appveyor sync failure was fixed earlier this week

@Sjors
Copy link
Member

Sjors commented Feb 27, 2019

Concept ACK. Maybe enumerate the new types in the PR description?

Shouldn't CKeyID GetID() in pubkey.h also return a PKHash ? That breaks a few other things from the looks of it, but otherwise it seems inconsistent. (no actually that's the point :-)

{
PKHash() : uint160() {}
explicit PKHash(const uint160& hash) : uint160(hash) {}
explicit PKHash(const CPubKey& pubkey);
Copy link
Member

Choose a reason for hiding this comment

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

Inline definition might be more clear but I don't want to upset any strong c++ preferences out there.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's a mixed bag here(definition for other constructors are in .cpp), I'll leave as-is unless someone else chimes in

@stevenroose
Copy link
Contributor

utACK 3330398

@instagibbs
Copy link
Member Author

rebased

@instagibbs
Copy link
Member Author

rebased and added description of new destination types in OP @Sjors

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

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

Conditional utACK 5148213 if fixes are added for travis failures. I'm guessing this will just require rebasing and adding some more CKeyID/CScriptID replacements.

This change was also suggested a while ago in: #11403 (comment) and I think it could be simplified a little by taking the other suggestion in that comment and making ScriptHash inherit from CScriptID and PKHash inherit from CKeyID. This would avoid the need to add explicit conversions several places in this PR. I think it's important for conversions from CScriptID to ScriptHash and CKeyID to PKHash to be explicit, but it seems fine for conversions in the opposite direction to be implicit.

for (const auto& entry : mapKeyMetadata) {
if (entry.second.nCreateTime) {
mapKeyBirth[entry.first] = entry.second.nCreateTime;
mapKeyBirth[PKHash(entry.first)] = entry.second.nCreateTime;
Copy link
Contributor

Choose a reason for hiding this comment

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

This change and the 2 changes below will work but don't really make sense logically. Would suggest reverting these and just changing the map key type to:

boost::variant<CKeyID, CScriptID>

or maybe

CKeyID

if you wanted to drop the "TODO: include scripts in GetKeyBirthTimes() output instead of separate" comment.

Copy link
Member Author

Choose a reason for hiding this comment

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

done

@instagibbs
Copy link
Member Author

fixed a single dangling test case that was expecting a PKHash, and added a commit to change GetKeyBirthTimes to returning CKeyID instead of CTxDestination.

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

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

utACK ddc21f2. Changes since last review are fixing test case and switching GetKeyBirthTimes away from CTxDestination.

@Sjors
Copy link
Member

Sjors commented Apr 24, 2019

tACK ddc21f2. Compiled, opened a wallet and ran test suite and bench on macOS 10.14.4. Not sure what else to test here.

@instagibbs
Copy link
Member Author

all comments addressed

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

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

utACK 78e407a. Only changes are removing extra CScriptID()s and fixing the test case.

@fanquake fanquake requested review from Sjors and meshcollider May 8, 2019 13:51
Copy link
Member

@Sjors Sjors left a comment

Choose a reason for hiding this comment

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

utACK 78e407a

Copy link
Contributor

@meshcollider meshcollider left a comment

Choose a reason for hiding this comment

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

utACK 78e407a

By removal of the // TODO: include scripts in GetKeyBirthTimes() output instead of separate comment, I assume you think that shouldn't be done, rather than because you implemented it.

@laanwj laanwj merged commit 78e407a into bitcoin:master May 9, 2019
laanwj added a commit that referenced this pull request May 9, 2019
…icated types

78e407a GetKeyBirthTimes should return key ids, not destinations (Gregory Sanders)
70946e7 Replace CScriptID and CKeyID in CTxDestination with dedicated types (Gregory Sanders)

Pull request description:

  The current usage seems to be an overloading of meanings. `CScriptID` is used in the wallet as a lookup key, as well as a destination, and `CKeyID` likewise. Instead, have all destinations be dedicated types.

  New types:
  `CScriptID`->`ScriptHash`
  `CKeyID`->`PKHash`

ACKs for commit 78e407:
  ryanofsky:
    utACK 78e407a. Only changes are removing extra CScriptID()s and fixing the test case.
  Sjors:
    utACK 78e407a
  meshcollider:
    utACK 78e407a

Tree-SHA512: 437f59fc3afb83a40540da3351507aef5aed44e3a7f15b01ddad6226854edeee762ff0b0ef336fe3654c4cd99a205cef175211de8b639abe1130c8a6313337b9
@instagibbs
Copy link
Member Author

@meshcollider payoff was very low, and descriptor wallets would have changed whatever someone was going to do

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request May 10, 2019
…ith dedicated types

78e407a GetKeyBirthTimes should return key ids, not destinations (Gregory Sanders)
70946e7 Replace CScriptID and CKeyID in CTxDestination with dedicated types (Gregory Sanders)

Pull request description:

  The current usage seems to be an overloading of meanings. `CScriptID` is used in the wallet as a lookup key, as well as a destination, and `CKeyID` likewise. Instead, have all destinations be dedicated types.

  New types:
  `CScriptID`->`ScriptHash`
  `CKeyID`->`PKHash`

ACKs for commit 78e407:
  ryanofsky:
    utACK 78e407a. Only changes are removing extra CScriptID()s and fixing the test case.
  Sjors:
    utACK 78e407a
  meshcollider:
    utACK bitcoin@78e407a

Tree-SHA512: 437f59fc3afb83a40540da3351507aef5aed44e3a7f15b01ddad6226854edeee762ff0b0ef336fe3654c4cd99a205cef175211de8b639abe1130c8a6313337b9
domob1812 added a commit to domob1812/namecoin-core that referenced this pull request May 13, 2019
Update chainActive to ::ChainActive() in Namecoin code.

Changed the Namecoin code for the upstream refactoring of CKeyID
and CScriptID in the wallet (bitcoin/bitcoin#15452).

Explicitly serialise block without witness, so that we do not have to
activate segwit at height 432 first in name_multiupdate.py.
domob1812 added a commit to xaya/xaya that referenced this pull request May 13, 2019
Update chainActive to ::ChainActive() in Xaya code.

Changed the Xaya code (esp. the modified verifymessage) for the upstream
refactoring of CKeyID and CScriptID in the wallet
(bitcoin/bitcoin#15452).

Explicitly serialise block without witness, so that we do not have to
activate segwit at height 432 first in xaya_gameblocks.py.
deadalnix pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Jun 6, 2020
…dedicated types

Summary:
bitcoin/bitcoin@70946e7

---

Depends on D6402

Partial backport of Core [[bitcoin/bitcoin#15452 | PR15452]]

Test Plan:
  ninja check-all

Reviewers: #bitcoin_abc, deadalnix

Reviewed By: #bitcoin_abc, deadalnix

Differential Revision: https://reviews.bitcoinabc.org/D6403
deadalnix pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Jun 6, 2020
…ions

Summary:
bitcoin/bitcoin@78e407a

---

Depends on D6403

Concludes backport of Core [[bitcoin/bitcoin#15452 | PR15452]]

Test Plan:
  ninja check-all

Reviewers: #bitcoin_abc, deadalnix

Reviewed By: #bitcoin_abc, deadalnix

Differential Revision: https://reviews.bitcoinabc.org/D6404
dzutto pushed a commit to dzutto/dash that referenced this pull request Dec 10, 2021
…ith dedicated types

78e407a GetKeyBirthTimes should return key ids, not destinations (Gregory Sanders)
70946e7 Replace CScriptID and CKeyID in CTxDestination with dedicated types (Gregory Sanders)

Pull request description:

  The current usage seems to be an overloading of meanings. `CScriptID` is used in the wallet as a lookup key, as well as a destination, and `CKeyID` likewise. Instead, have all destinations be dedicated types.

  New types:
  `CScriptID`->`ScriptHash`
  `CKeyID`->`PKHash`

ACKs for commit 78e407:
  ryanofsky:
    utACK 78e407a. Only changes are removing extra CScriptID()s and fixing the test case.
  Sjors:
    utACK 78e407a
  meshcollider:
    utACK bitcoin@78e407a

Tree-SHA512: 437f59fc3afb83a40540da3351507aef5aed44e3a7f15b01ddad6226854edeee762ff0b0ef336fe3654c4cd99a205cef175211de8b639abe1130c8a6313337b9
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Dec 16, 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.

10 participants