Skip to main content
added 21 characters in body
Source Link
user103136
user103136

This does not address your main question but response to some of the wrong assumptions in the question:

  1. Bitcoin blocksize is not 1 MB: What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?

Blocksize

  1. A major problem with simple approaches to increasing the Bitcoin blocksize is that for certain transactions, signature-hashing scales quadratically rather than linearly.

https://bitcoincore.org/en/2016/01/26/segwit-benefits/

  1. Increasing the blocksize every few months or increasing it by more than 1000x will most probably increase the blockchain size unexpectedly/rapidly, cost to run full nodes and other issue so decrease decentralization.

blocksize-decentralizations

  1. 1 Bitcoin transaction can be done for more than 1 real world payment so transactions per second when comparing with few other systems is a wrong metric in my opinion and explained here: https://bitcoin.stackexchange.com/a/100829/

  2. Bitcoin scaling works in layers: https://bitcoinkpis.com/layer2 and this does not mean on-chain development has stopped or will not focus on scaling. Example:

Compared to ECDSA signatures, Schnorr signatures are between 6 and 9 byte shorter. These savings stem from the removed encoding overhead and the default SigHash flag. With a Schnorr signature adoption of 20%, and assuming all of the 800.000 inputs spent per day contain only a single signature, more than 1MB of blockchain space is saved per day.

https://web.archive.org/web/20201214095704/https://www.advancingbitcoin.com/blog/evolution-signature-size-bitcoin/

This does not address your main question but response to some of the wrong assumptions in the question:

  1. Bitcoin blocksize is not 1 MB: What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?

Blocksize

  1. A major problem with simple approaches to increasing the Bitcoin blocksize is that for certain transactions, signature-hashing scales quadratically rather than linearly.

https://bitcoincore.org/en/2016/01/26/segwit-benefits/

  1. Increasing the blocksize every few months or increasing it by more than 1000x will most probably increase the blockchain size, cost to run full nodes and other issue so decrease decentralization.

blocksize-decentralizations

  1. 1 Bitcoin transaction can be done for more than 1 real world payment so transactions per second when comparing with few other systems is a wrong metric in my opinion and explained here: https://bitcoin.stackexchange.com/a/100829/

  2. Bitcoin scaling works in layers: https://bitcoinkpis.com/layer2 and this does not mean on-chain development has stopped or will not focus on scaling. Example:

Compared to ECDSA signatures, Schnorr signatures are between 6 and 9 byte shorter. These savings stem from the removed encoding overhead and the default SigHash flag. With a Schnorr signature adoption of 20%, and assuming all of the 800.000 inputs spent per day contain only a single signature, more than 1MB of blockchain space is saved per day.

https://web.archive.org/web/20201214095704/https://www.advancingbitcoin.com/blog/evolution-signature-size-bitcoin/

This does not address your main question but response to some of the wrong assumptions in the question:

  1. Bitcoin blocksize is not 1 MB: What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?

Blocksize

  1. A major problem with simple approaches to increasing the Bitcoin blocksize is that for certain transactions, signature-hashing scales quadratically rather than linearly.

https://bitcoincore.org/en/2016/01/26/segwit-benefits/

  1. Increasing the blocksize every few months or increasing it by more than 1000x will most probably increase the blockchain size unexpectedly/rapidly, cost to run full nodes and other issue so decrease decentralization.

blocksize-decentralizations

  1. 1 Bitcoin transaction can be done for more than 1 real world payment so transactions per second when comparing with few other systems is a wrong metric in my opinion and explained here: https://bitcoin.stackexchange.com/a/100829/

  2. Bitcoin scaling works in layers: https://bitcoinkpis.com/layer2 and this does not mean on-chain development has stopped or will not focus on scaling. Example:

Compared to ECDSA signatures, Schnorr signatures are between 6 and 9 byte shorter. These savings stem from the removed encoding overhead and the default SigHash flag. With a Schnorr signature adoption of 20%, and assuming all of the 800.000 inputs spent per day contain only a single signature, more than 1MB of blockchain space is saved per day.

https://web.archive.org/web/20201214095704/https://www.advancingbitcoin.com/blog/evolution-signature-size-bitcoin/

Source Link
user103136
user103136

This does not address your main question but response to some of the wrong assumptions in the question:

  1. Bitcoin blocksize is not 1 MB: What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?

Blocksize

  1. A major problem with simple approaches to increasing the Bitcoin blocksize is that for certain transactions, signature-hashing scales quadratically rather than linearly.

https://bitcoincore.org/en/2016/01/26/segwit-benefits/

  1. Increasing the blocksize every few months or increasing it by more than 1000x will most probably increase the blockchain size, cost to run full nodes and other issue so decrease decentralization.

blocksize-decentralizations

  1. 1 Bitcoin transaction can be done for more than 1 real world payment so transactions per second when comparing with few other systems is a wrong metric in my opinion and explained here: https://bitcoin.stackexchange.com/a/100829/

  2. Bitcoin scaling works in layers: https://bitcoinkpis.com/layer2 and this does not mean on-chain development has stopped or will not focus on scaling. Example:

Compared to ECDSA signatures, Schnorr signatures are between 6 and 9 byte shorter. These savings stem from the removed encoding overhead and the default SigHash flag. With a Schnorr signature adoption of 20%, and assuming all of the 800.000 inputs spent per day contain only a single signature, more than 1MB of blockchain space is saved per day.

https://web.archive.org/web/20201214095704/https://www.advancingbitcoin.com/blog/evolution-signature-size-bitcoin/