bitcoin-dev

Combined summary - [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage

Combined summary - [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage

The ongoing debate regarding the use of blockchain for data storage highlights several key issues.

Firstly, transactions that incorporate large amounts of non-essential witness data, such as an image in a single transaction, could change the nature of the blockchain by inflating it with this 'bloated' data. The UTXO set naturally expands as the number of participants grows, and price discrimination for block space has not halted this inflation.

The cost-effectiveness of storing data on the blockchain is scrutinized, particularly given the financial implications which do not seem to be offset by discounts. There's also concern about centralization within the Bitcoin network; centralized batch transactions by exchanges have already led to significant centralization, independent of any benefits from witness discounting.

Node operators typically situate UTXO sets on SSDs due to their speed, while blocks are stored on HDDs, which are less costly. If miners were to charge the same for storing one byte of transaction output as they do for witness data, it could lead to an increase in UTXO set size, forcing node operators to invest in more expensive SSD storage. The current pricing structure, which differentiates between the two types of data, helps maintain economic balance for node operators.

While transaction type—P2WPKH or P2TR—is important, prioritization in blockchain networks is more complex, often depending more on transaction size and fees. 'Bloated' transactions may be prioritized over simpler ones, despite the cumulative size and fees being comparable.

Discussion around the allocation of block space to witness data reveals that the preferential pricing model can lead to artificial inflation of witness data. This misallocation can negatively impact network efficiency, impose bandwidth costs on nodes, and risk centralizing control of the Bitcoin network. For visual reference on the disparities in block allocation, see Bitcoin Segwit Mispricing Comparison.

Moreover, the "witness discount" affects how transactions are prioritized but does not translate into storage costs for nodes. The connection between the UTXO set size and the witness discount doesn't influence operational node expenses, and linking the two could introduce system inefficiencies.

There are concerns about the blockchain's operational mechanisms, specifically whether inefficiencies occur inside or outside the witness, and how these affect simple transactions versus complex ones. This calls for a deeper understanding of how these issues manifest in the system.

Comparatively, sending coins to a P2WPKH address is currently cheaper than to a P2TR address, though spending Taproot transactions is more block space-efficient since no public key hash needs to be stored. The discrepancy between the costs of sending versus spending suggests the need for a revised fee structure that accounts for the long-term benefits of Taproot transactions.

Finally, the current incentivization structure favors storing data in the witness section, as evidenced by the substantial size difference between the "blocks" directory and the "chainstate" directory—the former being much larger due to the lower latency requirements and thus, less expensive storage solutions. A balanced incentive for keeping the "chainstate" streamlined is crucial for efficient transaction validation.

In conclusion, there is a call for a uniform pricing strategy across all bytes within the blockchain, irrespective of their position in the transaction data. A 1:1 weight-to-byte ratio would ensure equity in block space pricing and could be considered for future Segwit updates. The community's reception to this proposal will likely shape the direction of blockchain development.

Discussion History

0
Greg TonoskiOriginal Post
December 27, 2023 16:44 UTC
1
December 27, 2023 19:06 UTC
2
December 27, 2023 21:43 UTC
3
December 27, 2023 22:39 UTC
4
January 13, 2024 15:04 UTC
5
January 14, 2024 13:10 UTC
6
January 16, 2024 10:40 UTC
7
January 16, 2024 23:29 UTC
8
January 16, 2024 23:40 UTC
9
January 21, 2024 17:14 UTC