PoX: native segwit support

[jcnelson]

Add support for native segwit address payouts. Two items of complexity:

• Using wtxid pervasively throughout the codebase
• Upgrading the miner to create segwit outputs and possibly consume segwit inputs

[raymonddurk]

I'd love to update this proposal one step further to include bech32m addresses (Taproot). While I also agree native segwit support of bech32 should be supported as it is harder and harder to find non-segwit wallets, it would have further impact than an increase in user experience.

1. The savings on Bitcoin fees would increase the decentralization as it has a direct relationship with the minimum number of Stacks needed for stacking to be above the dust limit and or run profitably.
2. It is an irresponsible use of chain space which would increase the bitcoin fee market and be a centralising force as the inverse of the first point.
3. If anyone is paying out from a multisig, Schnorr would provide more of the rewards payouts to stackers
4. Moving to Taproot could open the door for new engineering opportunities to take advantage of things being built with those three new BIPs and the subsequent development that comes in the next few years.

[zone117x]

Do we anticipate function signatures changes for PoX-2 (e.g. stack-stx, delegate-stack-stx, etc) in order to support segwit & taproot? Or perhaps new functions like stack-stx-segwit?

Or is the only anticipated change for Stacking clients that we cannot expect to always be able to convert between Stacks Address <-> (tuple (hashbytes (buff 20)) (version (buff 1)))?

[jcnelson]

The new type signature for a PoX address will be { (hashbytes (buff 32)) (version (buff 1)) }. New version values will be added to represent p2wpkh, p2wsh, and p2tr, and the hashbytes field will be checked at runtime to ensure that it is either 20 bytes or 32 bytes depending on version.

[janniks]

Does a stacks-node need to know about the witness version of a bech32 native segwit address pox-address when converting the address to a scriptPubkey? — i.e. OP_n (OP_0 through OP_16) etc.

The witness version is not part of the (hashbytes (buff 32)). Will this be "hardcoded" into / discerned from the (version (buff 1))?

EDIT:
I believe this is the correct deduction for native addresses: v0 + 20 bytes → P2WPKH, v0 + 32 bytes → P2WSH, v1 + 32 bytes → P2TR encoded into the (version (buff 1)) via the changes in this PR https://github.com/stacks-network/stacks-blockchain/pull/3283/files

[jcnelson]

This is now merged!