Repository navigation
Consensus: Batched extended coinbase maturity temporary softfork #404
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
Open
FlyTheElephant1
wants to merge
8
commits into
bitcoinknots:29.x-knots
Choose a base branch
from
FlyTheElephant1:prElephant
base: 29.x-knots
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
5a7bc03
test from elephant
FlyTheElephant1 969b564
Audit fixes: hoist maturity bounds, binary search, #402-aligned tests
FlyTheElephant1 ad646c9
fix: align maturity height helper and functional test with #402
FlyTheElephant1 6d6fa12
Use 2016/4032/8064 batched maturity instead of 2016/8064/26280
FlyTheElephant1 061c403
Brought comments in line with new values set in 6d6fa12
FlyTheElephant1 a0964df
Create run-ci.yml
FlyTheElephant1 e53bb04
Merge pull request #1 from FlyTheElephant1/FlyTheElephant1-patch-1
FlyTheElephant1 64bc2e8
CI tests
FlyTheElephant1 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| name: Trigger Inherited CI | ||
|
|
||
| on: | ||
| push: | ||
| branches: [ main ] | ||
| workflow_dispatch: # Allows you to trigger this manually from the Actions UI | ||
|
|
||
| jobs: | ||
| run-bitcoin-ci: | ||
| # Syntax: OWNER/REPOSITORY/PATH@BRANCH | ||
| uses: FlyTheElephant1/bitcoin/.github/workflows/ci.yml@29.x-knots | ||
|
|
||
| # Optional: Automatically passes secrets if the inherited workflow requires any | ||
| secrets: inherit |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,53 @@ | ||
| ### Batched extended coinbase maturity (temporary softfork) | ||
|
|
||
| Coinbase outputs created while this deployment is active use a longer | ||
| maturity that is attached to the creating block, not to the spend: | ||
|
|
||
| - 1/6 of window blocks (`(height - start) % 6 == 0`): 2016 confirmations | ||
| - 2/6 of window blocks (`% 6` in {1,2}): 4032 confirmations | ||
| - 1/2 of window blocks (`% 6` in {3,4,5}): 8064 confirmations | ||
|
|
||
| The assignment is by block height, so coinbase transaction size does | ||
| not change. There is no extra output and no DATUM/script change. | ||
|
|
||
| The window is the same shape as RDTS: first block whose parent MTP | ||
| reaches the start time, through the last block whose parent MTP is still | ||
| below the RDTS expiry. After expiry, **new** coinbases go back to the | ||
| ordinary 100-block maturity. Coinbases created *inside* the window keep | ||
| their 2016/8064/26280 lock until they actually mature — expiry does not | ||
| unlock them early. | ||
|
|
||
| Only outputs created inside the window are affected. A coinbase output | ||
| created before activation keeps the 100-block rule throughout, so | ||
| activating the deployment cannot lock an output that was already | ||
| spendable. The 100-block rule continues to apply to every coinbase | ||
| output at all times as a floor. | ||
|
|
||
| The start time is not yet scheduled on mainnet or testnet4 in this | ||
| release (see `src/kernel/chainparams.cpp`); the deployment does nothing | ||
| until it is. | ||
|
|
||
| Miners: block rewards mined inside the window cannot be spent until | ||
| their assigned tranche matures (or, for coins created after expiry, 100 | ||
| blocks). Pools that pay their miners directly from coinbase outputs pass | ||
| this delay through to those miners. A non-upgraded miner that spends its | ||
| own reward at 100 confirmations produces a block that upgraded nodes | ||
| reject, if that reward was created in the window. | ||
|
|
||
| Wallet: rewards subject to the rule are reported as immature (in | ||
| `getbalances` `immature`, `listtransactions` category `immature` and the | ||
| GUI) until they can be spent, and are not selected for spending before | ||
| then, so the wallet never creates a transaction the network would reject. | ||
|
|
||
| `getdeploymentinfo` reports the deployment as `extended_coinbase_maturity`, | ||
| a `flagday` entry with `start_time`, `expiry_time` (the RDTS expiry; | ||
| after this, *new* coinbases use 100), `active` (for the next block's | ||
| *creation* rule) and, once the queried chain's median-time-past has | ||
| reached the start time, `height`, the activation height on that chain. | ||
| It is omitted on chains where the deployment is not scheduled. | ||
| `getblocktemplate` lists `extended_coinbase_maturity` in `rules` while | ||
| new coinbases are still being created under the rule; no client-side | ||
| support is required. | ||
|
|
||
| On regtest the deployment is scheduled with `-extendedcoinbasematurity=<time>`, | ||
| which requires `-rdtsexpiry` and must precede it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Is batching needed here? Attaching maturity to the creating height already staggers unlocks, one coinbase per block. The single-date cliff only exists when everything unlocks at the expiry.
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.
Well if there is a very long time where no coins reach maturity, then they all of a sudden start reaching maturity, it causes a large supply shock. The purpose of bringing some small amount forward of the mean and the bulk of it after the mean is to achieve the desired result without as high of a risk of causing a stall.
Prevents single calendar events whereby people will attempt to try and gamify the market dynamics by creating 3 different calendar events whereby some amount begin maturation. Also forces miners to begin thinking about things in multiple different future timeframes instead of one timeframe.
Single event date causes instability, and could lead to a stall (the stall condition is mostly solved in #403 solution in a different way than here)
Uh oh!
There was an error while loading. Please reload this page.
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.
This is an image of the per block maturation cycle. from activation to end of rdts, and from end of rtds until it is back to baseline.
(should be noted that the chart is slightly wrong here, there would be a 100 block period where the maturation rate would be 3.125 baseline after rdts ends before the first post rdts 100 block maturation begins happening simultaneous to the backlog)
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.
It also fixes a maturation cliff present in #402 and #403 whereby 6480 blocks all mature in a single block at rdts expiry by extending the rule for grandfathered blocks only. to produce the above chart. (assuming all of the code works as intended.)
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.
I could be missing something here, but along the same lines as kwsantiago's thoughts, wouldn't the 2016 tranche be gameable? If I had huge hashrate (10-15 ph) in a stratum pool I could mine every 6th block as hard as possible and mine a lot of them. Drop off in the other tranches and the DA could go down because minimal hashrate is mining in those tranches. This hurts those not gaming the system (the ones that the system is trying to protect) because they would find mainly those blocks in the long tranches. Worse, if the attacker wanted to do this for a few epochs and then just kill hashrate all together.
One way to possibly fix the "I know what tranche this block is in" is to use something miners know only after working on a block - hash % 6. hash % 6 would be statistically distributed, not as uniform as height based.
And back to kwsantiago's point, are tranches necessary?
Uh oh!
There was an error while loading. Please reload this page.
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.
No I don't think so. This doesn't change the reward of any particular block, the divisor by 6 creates a vesting schedule. whereby 1/6th matures at 2016 blocks, 2/6ths mature at 4032 blocks, and the remaining 3/6ths matures at 8064 blocks after being mined.
The purpose of it is to smooth the network maturation rate and prevent events where the maturation in total spikes (relative to 402 and 403). 402 and 403 matures after a set number of blocks or time and then matures all at once when rdts expires. 404 matures gradually in phases over 3 set numbers of blocks and any block that was subject to the rule is always subject to the rule so there arent a huge number of blocks maturing on the block where rdts expires. This proposal is intended to reduce the number of ways for people to game things.
The tranches are neccessary to remove single events that speculators can try to pump and dump the market, and to smooth out the supply dynamic effects. (again, does not alter the reward quantity for any block)
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.
I guess one other answer to another part of this question on why batch is this: each individual block could have three maturations, but this change from my understanding would require tripling the size of the coinbase transaction for each block. Batching by modulo6blockheight keeps data allocation low while providing an almost same effect to everyone except for true solo miners.
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.
"No, I don't think so." Not sure what you mean by that. I wasn't saying that the reward is changed by your approach. I get the tranches/schedule. I'm saying as a miner I know EXACTLY what tranche the block I'm about to work on goes in BEFORE I work on it. If I know this, I think I can game it. The only way to prevent that is if the tranche is unknowable before I mine the block, which is what using hash modulo 6 accomplishes.
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 only way you could game it is by shutting off your hashrate and getting less blocks. You can game it if you want less blocks and equipment sitting dormant.
Hash modulo could work to fix that and if people want this proposal then it could be added. I wanted to try and keep it as simple as possible so that the largest number of people could understand what it does while they figure out what they want to do.
Good idea.
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.
pull 409 resolves AcesHigh70 concern. Thank you aces.
#409