4 deleted 36 characters in body
source | link

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version are expected to produce a valid Schnorr signatures.

ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. Also since this is a soft-fork you cannot removeAll outputs having the OP_CHECKSIG opcode will continue to use the legacy ECDSA signing algorithm as it will not be compatible with non-upgraded nodes resulting in a hard forkand verification.

So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not native v1 SegWit. According to P2SH.info only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version are expected to produce a valid Schnorr signatures.

ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. Also since this is a soft-fork you cannot remove ECDSA signing algorithm as it will not be compatible with non-upgraded nodes resulting in a hard fork.

So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not native v1 SegWit. According to P2SH.info only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version are expected to produce a valid Schnorr signatures.

ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. All outputs having the OP_CHECKSIG opcode will continue to use the legacy ECDSA signing algorithm and verification.

So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not native v1 SegWit. According to P2SH.info only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

3 P2SH wrapped v1 is not supported according to the latest update
source | link

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version or P2SH wrapped v1 outputs are expected to produce a valid Schnorr signatures.

ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. Also since this is a soft-fork you cannot remove ECDSA signing algorithm as it will not be compatible with non-upgraded nodes resulting in a hard fork.

So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not native v1 SegWit (or P2SH wrapped v1). According to P2SH.info only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version or P2SH wrapped v1 outputs are expected to produce a valid Schnorr signatures.

ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. Also since this is a soft-fork you cannot remove ECDSA signing algorithm as it will not be compatible with non-upgraded nodes resulting in a hard fork.

So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not v1 SegWit (or P2SH wrapped v1). According to P2SH.info only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version are expected to produce a valid Schnorr signatures.

ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. Also since this is a soft-fork you cannot remove ECDSA signing algorithm as it will not be compatible with non-upgraded nodes resulting in a hard fork.

So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not native v1 SegWit. According to P2SH.info only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

2 added 48 characters in body
source | link

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version or P2SH wrapped v1 outputs are expected to produce a valid Schnorr signatures.

ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. Also since this is a soft-fork you cannot remove ECDSA signing algorithm as it will not be compatible with non-upgraded nodes resulting in a hard fork.

So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not v1 SegWit (or P2SH wrapped v1). According to P2SH.info only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version are expected to produce a valid Schnorr signatures.

ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. Also since this is a soft-fork you cannot remove ECDSA signing algorithm as it will not be compatible with non-upgraded nodes resulting in a hard fork.

So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not v1 SegWit. According to P2SH.info only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version or P2SH wrapped v1 outputs are expected to produce a valid Schnorr signatures.

ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. Also since this is a soft-fork you cannot remove ECDSA signing algorithm as it will not be compatible with non-upgraded nodes resulting in a hard fork.

So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not v1 SegWit (or P2SH wrapped v1). According to P2SH.info only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

1
source | link