Feat/native segwit #3283
Merged
Feat/native segwit #3283
Conversation
This file contains 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
…gwit variant, and implement the segwit variant to represent p2wpkh, p2wsh, and p2tr scriptPubKey outputs
…we parse the former, but do not parse the latter. This is used to support segwit witness scripts and tapscripts, which do not have readily-identifiable public keys or a fixed required number of signers
…at and after epoch 2.1, parse transactions with native segwit outputs and witness-bearing inputs
…parseable) input or a raw input (for segwit and taproot)
…'s just an opaque string that gets logged and reported to prometheus (as had always been the case, but is now made explicit by the type). Also, leader key register txs no longer need to store an identifying address
…ion, since with segwit this is no longer really doable
… txs don't have addresses
…output from the miner (which must be the input to the next block-commit from this miner). Also, API sync on the tests with the new bitcoin address types and BurnchainSigner
…s not used at all
…and also update the tests to use new types)
…which represent p2wpkh, p2sh, and p2tr
…sh, and p2tr natively (in addition to p2wpkh-p2sh and p2wsh-p2sh)
…k/stacks-blockchain into feat/native-segwit
|
Testing PR #3357 |
donpdonp
approved these changes
Nov 4, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR adds support for both stacking and mining with native segwit addresses. The
feat/pox-2-unlockbranch is merged into this branch, so let's get that reviewed and merged before doing this one.Highlights:
PoX 2
The
pox-2contract will now accept a{ version: (buff 1), hashbytes: (buff 32) }tuple for a PoX reward address, which may represent any of the following scriptPubKeys:The
PoxAddresstype, which represents committed PoX payouts in aLeaderBlockCommitOp, can now represent all legacy address types as well as p2wpkh, p2wsh, and p2tr addresses, as well as their Clarity tuple representations forpox-2.Burnchain Parser
The Bitcoin block downloader and transaction parser are epoch-gated so that at Epoch 2.1, transactions that contain native segwit inputs and outputs will be considered.
The Bitcoin address parser can now decode p2wpkh, p2sh, and p2tr scriptPubKeys
The vendored Bitcoin transaction parsing library has been patched to generate segwit sighashes for the purposes of mining with segwit.
Burn Operations Processing
We no longer care about the contents of a Bitcoin transaction's scriptSig or witness. We never did at the consensus level, but now
BurnchainSignerno longer represents this information, and all the code that inadvertently depended on this has been updated to not to so.LeaderKeyRegisterOpno longer has anaddressfield. It was never checked by the consensus rules, and it was only used by the node for matching up aLeaderKeyRegisterOpto the keychain'sBurnchainSigner(which has been removed).StackStxOpandTransferStxOpdo not support segwit, since the recipient address must decode to a Stacks address (and only legacy Bitcoin addresses do this).Node
Using segwit is a configuration option now, which must be turned on explicitly. It will only take effect in Epoch 2.1.
If configured to do so, the miner will spend and create segwit p2wpkh UTXOs instead of legacy UTXOs when mining and registering VRF keys. If a miner has UTXOs for both the legacy and p2wpkh addresses derived from the miner's seed, then the legacy ones will be used prior to Epoch 2.1 and the segwit ones will be used at and after Epoch 2.1. This will permit miners to seamlessly transition to using native segwit at the Epoch 2.1 boundary without a node restart.
Leader key registration considers the Bitcoin txid, not the
BurnchainSignerorLeaderKeyRegisterOpaddressfield when processing tenures.Vendored Code
The directory
stacks-common/src/deps_common/bech32was vendored from https://github.com/rust-bitcoin/rust-bech32. It was created by the same folks who created our vendored Bitcoin block and transaction parsing library.