Next scheduled rescrape ... never
Version 1
Last scraped
Scraped on 10/08/2025, 16:53:27 UTC
Quote
2. They chose SPHINCS+ which have 49,856 bytes. Without also proposing to increase block size, it would massively reduce TPS (transaction per second).

On the website https://quantum-resistant-bitcoin.bitcoin.foundation they mention SegWit v3+:
Quote
SegWit v3+ witness structures efficiently accommodate large signatures without blockchain bloat, while priority mempool treatment for QR transactions during transition phases creates economic incentives for adoption.

When I look at this: https://raw.githubusercontent.com/bitcoin/bitcoin/refs/heads/master/src/consensus/consensus.h I see that the max "block size" is limited to 4 MB
Code:
/** The maximum allowed size for a serialized block, in bytes (only for buffer size limits) */
static const unsigned int MAX_BLOCK_SERIALIZED_SIZE = 4000000;
/** The maximum allowed weight for a block, see BIP 141 (network rule) */
static const unsigned int MAX_BLOCK_WEIGHT = 4000000;
/** The maximum allowed number of signature check operations in a block (network rule) */
static const int64_t MAX_BLOCK_SIGOPS_COST = 80000;

I don't see why it cannot be increased to the extreme, let's say to 2100000000 bytes (2.1 GB). I don't think there will be ever so much transactions in the block to take up all that huge space.

Example, calculate with let's say 55 KB (SPHINCS+-SHAKE256f signature + other transaction data).
Currently in one block there are approximately 2-5000 transaction the max.

So:
5000 x 55000 bytes = 275,000,000 bytes or 275 MB (With a connection speed of 50 Mbps it would take approximately 46 seconds to download the block, if the network speed is 1 Gbps then the download of the block would take around 2.2 seconds)
5000 x 55000 bytes = 275,000,000 bytes or 275 MB (With a connection speed of 50 Mbps it would take approximately 46 seconds to download the block, if the network speed is  1 Gbps then the download of the block would take around 2.2 seconds)

So even if the 4000000 bytes is changed in Bitcoin's SegWit to just 275000000 bytes, it would handle up to around 5000 transactions / block.

This is why I think this BIP is much better than other proposals. It is proposing a new version of SegWit (SegWit v3+) as a solution to the large signature size that SPHINCS+ produces with SHAKE256f. To implement it wouldn't need to change much in Bitcoin and far as I see it wouldn't be a "hard fork" either.
Original archived Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
Scraped on 10/08/2025, 16:48:54 UTC
Quote
2. They chose SPHINCS+ which have 49,856 bytes. Without also proposing to increase block size, it would massively reduce TPS (transaction per second).

On the website https://quantum-resistant-bitcoin.bitcoin.foundation they mention SegWit v3+:
Quote
SegWit v3+ witness structures efficiently accommodate large signatures without blockchain bloat, while priority mempool treatment for QR transactions during transition phases creates economic incentives for adoption.

When I look at this: https://raw.githubusercontent.com/bitcoin/bitcoin/refs/heads/master/src/consensus/consensus.h I see that the max "block size" is limited to 4 MB
Code:
/** The maximum allowed size for a serialized block, in bytes (only for buffer size limits) */
static const unsigned int MAX_BLOCK_SERIALIZED_SIZE = 4000000;
/** The maximum allowed weight for a block, see BIP 141 (network rule) */
static const unsigned int MAX_BLOCK_WEIGHT = 4000000;
/** The maximum allowed number of signature check operations in a block (network rule) */
static const int64_t MAX_BLOCK_SIGOPS_COST = 80000;

I don't see why it cannot be increased to the extreme, let's say to 2100000000 bytes (2.1 GB). I don't think there will be ever so much transactions in the block to take up all that huge space.

Example, calculate with let's say 55 KB (SPHINCS+-SHAKE256f signature + other transaction data).
Currently in one block there are approximately 2-5000 transaction the max.
So:

5000 x 55000 bytes = 275,000,000 bytes or 275 MB (With a connection speed of 50 Mbps it would take approximately 46 seconds to download the block, if the network speed is  1 Gbps then the download of the block would take around 2.2 seconds)

So even if the 4000000 bytes is changed in Bitcoin's SegWit to just 275000000 bytes, it would handle up to around 5000 transactions / block.

This is why I think this BIP is much better than other proposals. It is proposing a new version of SegWit (SegWit v3+) as a solution to the large signature size that SPHINCS+ produces with SHAKE256f. To implement it wouldn't need to change much in Bitcoin and far as I see it wouldn't be a "hard fork" either.