-
Notifications
You must be signed in to change notification settings - Fork 38.7k
mining: getCoinbase() returns struct instead of raw tx #33819
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
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33819. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please copy-paste ConflictsReviewers, this pull request conflicts with the following ones:
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. |
|
Working on a matching sv2-tp pull request. It will first try |
79e73b0 to
0dfe602
Compare
|
It's ready for testing with: I also pushed a small change that switches |
|
@plebhash can you try to see if it's easy for you to support both |
|
There is no direct C++ unit test for |
0dfe602 to
d926d31
Compare
No strong opinion on whether we need one. |
src/interfaces/mining.h
Outdated
| /** | ||
| * Return scriptPubKey with SegWit OP_RETURN. | ||
| * | ||
| * @note deprecated: use the output field from getCoinbase() |
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.
getCoinbase() returns a CoinbaseTemplate struct which has an outputs field, which itself is an array with zero or more elements.
(I'll rename output to outputs)
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.
As a progression towards getCoinbase & deprecation, this implementation could internally also do what is suggested in the deprecation node:
invoke ExtractCoinbaseTemplate, scan outputs for the SegWit marker, and return the index.
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.
re: #33819 (comment)
As a progression towards
getCoinbase& deprecation, this implementation could internally also do what is suggested in the deprecation node: invokeExtractCoinbaseTemplate, scan outputs for the SegWit marker, and return the index.
I don't see a clean way to get the index from ExtractCoinbaseTemplate, but even if there were, calling GetWitnessCommitmentIndex seems like the simplest implementation of this method. Changing this might make more sense if the GetWitnessCommitmentIndex function was only called this one place and could be eliminated, but this isn't the case.
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.
The latest push dropped ExtractCoinbaseTemplate entirely.
|
Concept ACK (d926d31603316a10e3210f10480dd02bb34f667a) The added new method makes sense. The deprecating methods are only being marked in the header comments, they are kept, there is no formal plan for deprecation. But there is a fair plan for switching users, and keeping them is not an extra burden. |
d926d31 to
0528e06
Compare
|
🚧 At least one of the CI tasks failed. HintsTry to run the tests locally, according to the documentation. However, a CI failure may still
Leave a comment here, if you need help tracking down a confusing failure. |
60f74dd to
5761dac
Compare
|
Applied both suggestions from @ryanofsky: #33819 (review) |
ryanofsky
left a comment
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.
Code review ACK 5761dac2f5481c27550483279a007c2b850bc990, with the two suggestions applied since last review.
5761dac to
1bd6cae
Compare
|
Trivial rebase after #29641. |
ryanofsky
left a comment
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.
Code review ACK 1bd6cae. Just rebased with no changes, to avoid trivial merge conflict.
ryanofsky
left a comment
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.
Code review ACK 1bd6cae. Just rebasing again since last review to avoid minor conflict
This frees up the name getCoinbaseTx() for the next commit. Changing a function name does not impact IPC clients, as they only consider the function signature and sequence number.
1bd6cae to
979805b
Compare
|
Rebased after #34003. |
ismaelsadeeq
left a comment
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.
ACK 979805b
The commit message is helpful for my review.
I still prefer that deprecated methods be removed once we have a replacement for them, for 1. better hygiene for the codebase. 2 Ensures we only maintain what should be used and our perceived valid approach for IPC clients. 3. Will prevent naive users from using deprecated method.
However, others seem to prefer deprecating them first, then batch-removing them later.
#33819 (review) Option 2 is my second preferred option. The method names and numbering are kept, but we return an error when someone tries to use them
It would allow us to remove the implementation code and tests while maintaining the methods and numbering for the transition period (can even be kept indefinitely since no implementation and test to maintain, could also be deleted in batch).
| * Currently there are no non-zero required_outputs, so block_reward_remaining | ||
| * is the entire block reward. See also required_outputs. | ||
| */ | ||
| CAmount block_reward_remaining; | ||
| /* | ||
| * To be included as the last outputs in the coinbase transaction. | ||
| * Currently this is only the witness commitment OP_RETURN, but future | ||
| * softforks or a custom mining patch could add more. | ||
| * | ||
| * The dummy output that spends the full reward is excluded. | ||
| */ |
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.
In 979805b "mining: add new getCoinbaseTx() returning a struct"
nit: Current comment is a bit speculative. I think we should just document existing rules and requirements.
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.
The reason it's a bit more elaborate is that otherwise people will be confused why this is an array.
The part about merged mining is not speculative, only the part about future soft-forks. But from the point of view of a client implementer this speculation is very important to keep in mind. They should not be lazy and only take the first element from the array. And by "they" I mean myself :-) stratum-mining/sv2-tp#55
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.
re: #33819 (comment)
nit: Current comment is a bit speculative. I think we should just document existing rules and requirements.
Agree with sjors it is important to document things that may be required in the future even if they are not required now. But in case this is updated, it would be good to make the "Currently..." sentence a separate final paragraph. This way, all the fields would be documented in a consistent way with descriptions & requirements first, and information about specific values they currently contain last.
Introduce a new method intended to replace getCoinbaseRawTx(), which provides a struct with everything clients need to construct a coinbase. This is safer than providing a raw dummy coinbase that clients then have to manipulate. The CoinbaseTx data is populated during the dummy transaction generation and stored in struct CBlockTemplate. Expand the interface_ipc.py functional test to document its usage and ensure equivalence.
979805b to
48f57bb
Compare
ryanofsky
left a comment
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.
Code review ACK 48f57bb. Just rebased and addressed comments and dropped coinbase tx "template" suffix, which is a nice change
| * Currently there are no non-zero required_outputs, so block_reward_remaining | ||
| * is the entire block reward. See also required_outputs. | ||
| */ | ||
| CAmount block_reward_remaining; | ||
| /* | ||
| * To be included as the last outputs in the coinbase transaction. | ||
| * Currently this is only the witness commitment OP_RETURN, but future | ||
| * softforks or a custom mining patch could add more. | ||
| * | ||
| * The dummy output that spends the full reward is excluded. | ||
| */ |
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.
re: #33819 (comment)
nit: Current comment is a bit speculative. I think we should just document existing rules and requirements.
Agree with sjors it is important to document things that may be required in the future even if they are not required now. But in case this is updated, it would be good to make the "Currently..." sentence a separate final paragraph. This way, all the fields would be documented in a consistent way with descriptions & requirements first, and information about specific values they currently contain last.
ismaelsadeeq
left a comment
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.
code review ACK 48f57bb
vasild
left a comment
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.
ACK 48f57bb
| coinbaseTx.vout[0].nValue = block_reward; | ||
| coinbase_tx.block_reward_remaining = block_reward; |
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.
Looks messy to have two variables named coinbaseTx and coinbase_tx. I do not have a better suggestion though. Feel free to ignore.
| /* nVersion */ | ||
| uint32_t version; | ||
| /* nSequence for the only coinbase transaction input */ | ||
| uint32_t sequence; | ||
| /** |
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.
Change /* to /** in order to get doxygen link the comment with the variable that follows it, like the comments for the subsequent members. Same for the required_outputs member.
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.
Will do if I need to retouch.
The first commit renames
getCoinbaseTx()togetCoinbaseRawTx()to reflect that it returns a serialised transaction. This does not impact IPC clients, because they do not use the function name.The second commit then introduces a replacement
getCoinbase()that provides a struct with everything clients need to construct a coinbase. This avoids clients having to parse and manipulate our dummy transaction.Deprecate but don't remove
getCoinbaseRawTx(),getCoinbaseCommitment()andgetWitnessCommitmentIndex().After this change we can drop these deprecated methods, which in turn would allow us to clear the dummy transaction from the
getBlock()result. But that is left for a followup to keep this PR focussed. See Sjors#106 for an approach.Expand the
interface_ipc.pyfunctional test to document its usage.Can be tested using: