search

stacks-network / stacks-core

The Stacks blockchain implementation
https://docs.stacks.co
GNU General Public License v3.0
3.01k stars 667 forks source link

PoX: native segwit support #2586

Closed jcnelson closed 1 year ago

jcnelson commented 3 years ago

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

raymonddurk commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

~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 commented 1 year ago

This is now merged!