If exchanges are lazy again, will we have Nested Taproot just like why we have Nested Segwit?
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.
Topic: Why do we have Nested Segwit and Native Segwit? (Read 194 times)
If exchanges are lazy again, will we have Nested Taproot just like why we have Nested Segwit?
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.
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.
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.
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.
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.
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.
If exchanges are lazy again, will we have Nested Taproot just like why we have Nested Segwit?
Nested Taproot as in P2SH-P2TR? It's unlikely it'll happen due to security concern[1].
While SegWit was a huge leap (completely new address type), taproot is just a baby step forward (let's say SegWit v2).
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
[2] https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki
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.
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.
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.
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?
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.
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.Quote
and if Nested Segwit is a transition in between Legacy and Native Segwit, will it be used less and less in future?
It is more like a workaround but yes it is being used less and less.Quote
I know for Nested address created, they will not disappear or erase.
Yes, P2SH-P2WPKH and P2SH-P2WSH are parts of the protocol now and they can not be removed. 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.
Thank you!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.
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.
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.
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.
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.
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.
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?
There is Nested Segwit that is worse than Native Segwit but why community wanted to try with Nested Segwit?
Jump to: