Define Taproot activation parameters for Liquid #1044
Conversation
apoelstra
force-pushed
the
2021-09--taproot-activation
branch
2 times, most recently
from
0c6acb6 to
9bb0e27
Compare
apoelstra
force-pushed
the
2021-09--taproot-activation
branch
from
9bb0e27 to
5291c0d
Compare
|
I don't feel like I understand the activation machinery well enough to truly ack this without a bunch more thought, but it seems reasonable to me. |
|
utACK 5291c0d |
| consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nTimeout = Consensus::BIP9Deployment::NO_TIMEOUT; | ||
|
|
||
| consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].bit = 2; | ||
| consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nStartTime = 1554500; // November 1, 2021 |
There was a problem hiding this comment.
Isn't the current code (prior to this patch) buggy in that it leaves consensus.vDeployments[TAPROOT] uninitialised, so that it could be anything?
There was a problem hiding this comment.
Yep, oops. This has only been true on master and for a day or two (during which time we've been merging a lot of taproot-related PRs), but it shouldn't have happened nonetheless.
There was a problem hiding this comment.
BTW -- to clarify your comment on twitter, this won't cause Taproot to be enforced on the LIquid network (except in the sense that leaving these variables undefined is UB so theoretically anything could happen). It would, at worst, cause the functionaries to start signalling early. But even that won't happen, because ofc the functionaries are not running master.
|
Looks good, utACK 0df8895 |
| consensus.vDeployments[Consensus::DEPLOYMENT_DYNA_FED].nTimeout = 1230767999; // December 31, 2008 | ||
| consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].bit = 2; | ||
| consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nStartTime = Consensus::BIP9Deployment::ALWAYS_ACTIVE; | ||
| consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nStartTime = gArgs.GetArg("-con_taproot_signal_start", Consensus::BIP9Deployment::ALWAYS_ACTIVE); |
There was a problem hiding this comment.
In 5291c0d "chainparams: add undocumented regtest/testnet only -con_taproot_signal_start option"
This is entirely unnecessary as there already exists a way to set regtest activation params via -vbparams. See the function CRegTestParams::UpdateActivationParametersFromArgs.
There was a problem hiding this comment.
Thank you! I didn't know about this.
I'm going to leave it in because this code is inherently temporary and we're already using it for internal testing, but in future we can avoid these kind of hacky undocumented options.
There was a problem hiding this comment.
Eh, also didn't know that. We did the same thing for dynafed :)
apoelstra
force-pushed
the
2021-09--taproot-activation
branch
from
0df8895 to
3cb9612
Compare
|
ACK 3cb9612 |
6 participants
Sets Taproot to start signalling around noon (California time) on Nov 1, 2021, assuming 95% of blocks are produced between now and then.
Will activate after one week of 100% signalling. If we can pull this off on the first or second try, we will beat Bitcoin which currently looks like it will activate on Nov 16.
Edit: actually, even without Speedy Trial, there is one full period (week) where Taproot will be "locked in" but not "active". So it will activate on Nov 15 at the earliest.