Bitcoin Forum

Segwit was in 2017 but why Bitcoin community did not reach a consensus for Native Segwit?

There is Nested Segwit that is worse than Native Segwit but why community wanted to try with Nested Segwit?

Two words: backward compatibility.

SegWit was a soft-fork and soft-forks need to be backward compatible. Meaning your old node that didn't upgrade needs to be able to send bitcoin to a SegWit address too which is where nested SegWit addresses come in. They wrap the witness in a P2SH script so that the corresponding address is looking like the same old P2SH addresses and can be used by old clients that don't recognize Bech32 addresses.

Nested segwit addresses are similar to multisig addresses and I think were in case people were wary of segwit or didn't want to accept it (it might've been a way to force some to use it too as a soft push).

Now, native segwit is the best for fees, and any site that doesn't accept deposits and withdrawals on it is probably not very secure.

Thank you!

It means Nested Segwit is not a plan initially but because of flaw to make transactions between Legacy and Native Segwit wallets when there was little adoption for Native Segwit. Nested Segwit was created and used like this.

Or it was planned initially for Segwit with both Nested and Native?

and if Nested Segwit is a transition in between Legacy and Native Segwit, will it be used less and less in future?

I know for Nested address created, they will not disappear or erase.

I think it is similar to software. We can use newest version of same software to read file from past versions but if we use old versions, we can not read files created by later and newest versions.

Not a flaw, but laziness or maliciousness of some services like exchanges that refused to adopt SegWit for a long time so that their users needed a way to still receive their funds when they were withdrawing coins from exchanges to a SegWit address.

It is more like a workaround but yes it is being used less and less.

Yes, P2SH-P2WPKH and P2SH-P2WSH are parts of the protocol now and they can not be removed.

Thank you! Now I understood why we have Nested Segwit.

If exchanges are lazy again, will we have Nested Taproot just like why we have Nested Segwit?

While SegWit was a huge leap (completely new address type), taproot is just a baby step forward (let's say SegWit v2). Also iirc Nested SegWit came alive when SegWit did, not later. And Taproot is alive already.

Exchanges' laziness today means they don't support LN yet... but that's another, more complicated story.

To add to this, in order to add Nested Taproot we would need to perform another soft-fork because unlike the previous soft-fork in 2017, the rules to spend a Nested Taproot output are not defined in the protocol. This is why I don't think we would ever add such feature.

Nested Taproot as in P2SH-P2TR? It's unlikely it'll happen due to security concern[1].


To be precise, Taproot use Bech32m[2] address (similar with Bech32, except it use 0x2bc830a3 as constant).

[1] https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-3 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-3)
[2] https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki (https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)

Thanks but I am confusing.

Was Nested Segwit is part of Segwit Protocol at beginning for vote from Bitcoin community? I mean developers well planned and integrated two things in Segwit protocol: Nested Segwit as a transition (backward compatability solution) and Native Segwit is ultimate Segwit after the transition is done.

Legacy > Nested Segwit > Native Segwit.  Two Segwit types were written in Protocol for 2017 Segwit

Taproot Protocol was written for Taproot only, no Nested Taproot or Native Taproot. If they want to have it, they must writr and submit a new protocol for community vote to reach a new consensus.

Yes. These are like "special scripts", when the interpreter sees one of these scripts it goes through a different route for the rest of the evaluation. Each new rule requires a soft-fork.

For example when the interpreter sees a P2SH output (OP_HASH160 <20 bytes> OP_EQUAL) it looks on the stack for the redeem script, after evaluating the redeem script if it is a legacy type, it follows the legacy rules to evaluate the rest but if it is a SegWit type (OP_0 <20/32 bytes>) it's considered as a program version 0 and requires witnesses according to version 0. This was added with the SegWit soft-fork. If the redeem script is any other program version (eg. OP_1 <32 bytes>) there is no rules defined. So it simply returns true. If we want to add that, there has to be a proposal then voting and reaching consensus followed by the soft-fork locking it in.

No, because Taproot uses the same address format (bech32) as native segwit, so in order to support Taproot addresses, you already have to be supporting native segwit addresses in the first place.

Taproot is actually using a slightly different version of Bech32 encoding (Bech32m) so in order to support Taproot addresses these services would have to upgrade their backend so that it can verify these addresses using the new rules.