: Bitcoin blockspace price discrimination put simple transactions at disadvantage
10 messages, 27 Dec 2023 to 21 Jan 2024. Started by Greg Tonoski.
Greg Tonoski (5), Boris Nagaev (3), vjudeu, Keagan McClelland
Blockspace price for data of a simple transaction is higher than the one for data of other ("complex") transactions: 3 vs 1.49 "weight"/byte in the examples below: - 3=616 "weight" / 205 bytes (txid: aabbcce67f2aa71932f789cac5468d39e3d2224d8bebb7ca2c3bf8c41d567cdd) - 1.49=1140 "weight" / 767 bytes (txid: 1c35521798dde4d1621e9aa5a3bacac03100fca40b6fb99be546ec50c1bcbd4a).
As a result, there are incentives structure distorted and critical inefficiencies/vulnerabilities (e.g. misallocation of block space, blockspace value destruction, disincentivized simple transaction, centralization around complex transactions originators).
Price of blockspace should be the same for any data (1 byte = 1 byte, irrespectively of location inside or outside of witness), e.g. 205/205 and 767/767 bytes in the examples above.
Perhaps, the solution (the same price, "weight" of each bit of a transaction) could be introduced as part of the next version of Segwit transactions.
Let's fix it. What do you think?
On Wed, Dec 27, 2023 at 2:26 PM Greg Tonoski via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (8 lines)
> As a result, there are incentives structure distorted and critical > inefficiencies/vulnerabilities (e.g. misallocation of block space, > blockspace value destruction, disincentivized simple transaction, > centralization around complex transactions originators). > > Price of blockspace should be the same for any data (1 byte = 1 byte, > irrespectively of location inside or outside of witness), e.g. 205/205 > and 767/767 bytes in the examples above.
Witness data does not contribute to utxo set. The discount on storing data in witness creates an incentive to store data exactly in the witness and not in the parts contributing to utxo set.
$ du -sh blocks/ chainstate/ 569G blocks/ 9.3G chainstate/
Witness data is part of the "blocks" directory which is not latency-critical and can be stored on a slow and cheap storage device. Directory "chainstate" contains the data needed to validate new transactions and should fit into a fast storage device otherwise initial block download takes weeks. It is important to maintain the incentives structure, resulting in a small chainstate.
I think it should be fixed. Because now, sending coins into P2WPKH is cheaper than sending them to P2TR, even though finally, when those coins are spent, the blockspace usage is cheaper for Taproot (when you spend by key) than for Segwit, because public key hash is not stored anywhere. But of course, because the cost is splitted between sender and spender, it is more profitable to send to P2WPKH, and spend from P2TR.
Quoted text (1 line)
> As a result, there are incentives structure distorted and critical
inefficiencies/vulnerabilities (e.g. misallocation of block space, blockspace value destruction, disincentivized simple transaction, centralization around complex transactions originators).
Can you please describe the mechanism here?
Quoted text (1 line)
> Price of blockspace should be the same for any data (1 byte = 1 byte,
irrespectively of location inside or outside of witness), e.g. 205/205 and 767/767 bytes in the examples above.
"Should" ... to what end?
Keags
On Wed, Dec 27, 2023 at 10:26 AM Greg Tonoski via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (27 lines)
> Blockspace price for data of a simple transaction is higher than the
> one for data of other ("complex") transactions: 3 vs 1.49
> "weight"/byte in the examples below:
> - 3=616 "weight" / 205 bytes (txid:
> aabbcce67f2aa71932f789cac5468d39e3d2224d8bebb7ca2c3bf8c41d567cdd)
> - 1.49=1140 "weight" / 767 bytes (txid:
> 1c35521798dde4d1621e9aa5a3bacac03100fca40b6fb99be546ec50c1bcbd4a).
>
> As a result, there are incentives structure distorted and critical
> inefficiencies/vulnerabilities (e.g. misallocation of block space,
> blockspace value destruction, disincentivized simple transaction,
> centralization around complex transactions originators).
>
> Price of blockspace should be the same for any data (1 byte = 1 byte,
> irrespectively of location inside or outside of witness), e.g. 205/205
> and 767/767 bytes in the examples above.
>
> Perhaps, the solution (the same price, "weight" of each bit of a
> transaction) could be introduced as part of the next version of Segwit
> transactions.
>
> Let's fix it. What do you think?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>On Wed, Dec 27, 2023 at 8:06 PM Nagaev Boris <bnagaev@gmail•com> wrote:
Quoted text (26 lines)
> > On Wed, Dec 27, 2023 at 2:26 PM Greg Tonoski via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: > > As a result, there are incentives structure distorted and critical > > inefficiencies/vulnerabilities (e.g. misallocation of block space, > > blockspace value destruction, disincentivized simple transaction, > > centralization around complex transactions originators). > > > > Price of blockspace should be the same for any data (1 byte = 1 byte, > > irrespectively of location inside or outside of witness), e.g. 205/205 > > and 767/767 bytes in the examples above. > > Witness data does not contribute to utxo set. The discount on storing > data in witness creates an incentive to store data exactly in the > witness and not in the parts contributing to utxo set. > > $ du -sh blocks/ chainstate/ > 569G blocks/ > 9.3G chainstate/ > > Witness data is part of the "blocks" directory which is not > latency-critical and can be stored on a slow and cheap storage device. > Directory "chainstate" contains the data needed to validate new > transactions and should fit into a fast storage device otherwise > initial block download takes weeks. It is important to maintain the > incentives structure, resulting in a small chainstate.
I think that the argument "discount on storing data in witness creates an incentive to store data exactly in the witness (...)" is fallacious. The "witness discount" does not affect the cost of data storage in a Bitcoin node. What the "witness discount" affects is the priority of a transaction pending confirmation only. For example, a SegWit type of transaction of size of 1MB is prioritized (by miners) over a non-SegWit transaction of the same size and fee. "Segwit discount" benefits bloated transactions and puts simple transactions at disadvantage (demonstrated at "https://gregtonoski.github.io/bitcoin/segwit-mispricing/comparison-of-costs.html" and "https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_4MB_and_1.33MB_blocks_in_Bitcoin.pdf").
The Bitcoin fee is not charged per UTXO set size. It is not charged from a node operator. Nodes are up and running independently of Bitcoin fees.
Any relation between UTXO set size and discount would be artificial and inefficient, wouldn't it?
On Wed, Dec 27, 2023 at 11:39 PM Keagan McClelland <keagan.mcclelland@gmail•com> wrote:
Quoted text (7 lines)
> > > As a result, there are incentives structure distorted and critical > inefficiencies/vulnerabilities (e.g. misallocation of block space, > blockspace value destruction, disincentivized simple transaction, > centralization around complex transactions originators). > > Can you please describe the mechanism here?
Sure. Because of the preferential treatment there is incentive to bloat the underpriced part of transaction data (so-called Witness) at the expense of a number of genuine, simple transactions and so a number of updates in the ledger. Blockspace is allocated to useless, irrelevant data that don't affect state of Bitcoin, e.g. the transaction 1c35521798dde4d1621e9aa5a3bacac03100fca40b6fb99be546ec50c1bcbd4a could have been stripped of bloat and UTXO set wouldn't have changed; at the same time the freed space could have been allocated to a simple transaction that updates UTXO set (improving cost effectivness at the same time).
Additionally, bloated transactions are bigger and so require more time to be downloaded during Initial Block Download - wasting bandwith (cost borne by node operators).
Quoted text (6 lines)
> > > Price of blockspace should be the same for any data (1 byte = 1 byte, > irrespectively of location inside or outside of witness), e.g. 205/205 > and 767/767 bytes in the examples above. > > "Should" ... to what end?
"Should" in order to avoid hazard of centralization. A single bidder who takes advantage of "buy 1 get 3 megabytes free" may outcompete a number of individuals whose simple transactions recieve anti-preferential treatment - "buy 1 get 0.33 megabytes free" in aggregate. There is the illustration at: "https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_4MB_and_1.33MB_blocks_in_Bitcoin.pdf".
On Wed, Dec 27, 2023 at 10:43 PM <vjudeu@gazeta•pl> wrote:
Quoted text (2 lines)
> > I think it should be fixed. Because now, sending coins into P2WPKH is cheaper than sending them to P2TR, even though finally, when those coins are spent, the blockspace usage is cheaper for Taproot (when you spend by key) than for Segwit, because public key hash is not stored anywhere. But of course, because the cost is splitted between sender and spender, it is more profitable to send to P2WPKH, and spend from P2TR.
The difference between P2WPKH and P2TR is a different topic, I think. A single bloated transaction would be treated with higher priority than a number of simple transactions of the same total size and fee - irrespectively of P2WPKH and P2TR type.
On Sat, Jan 13, 2024 at 12:03 PM Greg Tonoski <gregtonoski@gmail•com> wrote:
Quoted text (47 lines)
> > On Wed, Dec 27, 2023 at 8:06 PM Nagaev Boris <bnagaev@gmail•com> wrote: > > > > On Wed, Dec 27, 2023 at 2:26 PM Greg Tonoski via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation•org> wrote: > > > As a result, there are incentives structure distorted and critical > > > inefficiencies/vulnerabilities (e.g. misallocation of block space, > > > blockspace value destruction, disincentivized simple transaction, > > > centralization around complex transactions originators). > > > > > > Price of blockspace should be the same for any data (1 byte = 1 byte, > > > irrespectively of location inside or outside of witness), e.g. 205/205 > > > and 767/767 bytes in the examples above. > > > > Witness data does not contribute to utxo set. The discount on storing > > data in witness creates an incentive to store data exactly in the > > witness and not in the parts contributing to utxo set. > > > > $ du -sh blocks/ chainstate/ > > 569G blocks/ > > 9.3G chainstate/ > > > > Witness data is part of the "blocks" directory which is not > > latency-critical and can be stored on a slow and cheap storage device. > > Directory "chainstate" contains the data needed to validate new > > transactions and should fit into a fast storage device otherwise > > initial block download takes weeks. It is important to maintain the > > incentives structure, resulting in a small chainstate. > > I think that the argument "discount on storing data in witness creates > an incentive to store data exactly in the witness (...)" is > fallacious. The "witness discount" does not affect the cost of data > storage in a Bitcoin node. What the "witness discount" affects is the > priority of a transaction pending confirmation only. For example, a > SegWit type of transaction of size of 1MB is prioritized (by miners) > over a non-SegWit transaction of the same size and fee. "Segwit > discount" benefits bloated transactions and puts simple transactions > at disadvantage (demonstrated at > "https://gregtonoski.github.io/bitcoin/segwit-mispricing/comparison-of-costs.html" > and "https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_4MB_and_1.33MB_blocks_in_Bitcoin.pdf"). > > The Bitcoin fee is not charged per UTXO set size. It is not charged > from a node operator. Nodes are up and running independently of > Bitcoin fees. > > Any relation between UTXO set size and discount would be artificial > and inefficient, wouldn't it?
Node operators are likely to put UTXO set to SSD and blocks to HDD. SSD is more expensive than HDD. It is aligned with the fact that people putting data into blockchain are financially motivated to put it into witness data, i.e. into HDD. If miners charge the same per 1 byte in a transaction output and 1 byte in witness, then people putting data into blockchain could put it into transaction outputs (why not, if the price is the same), inflating the UTXO set and making node operators buy bigger SSD (more costs for node operators). As a node operator, I prefer the current structure.
On Sun, Jan 14, 2024 at 10:21 AM Greg Tonoski via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (12 lines)
> > > Price of blockspace should be the same for any data (1 byte = 1 byte, > > irrespectively of location inside or outside of witness), e.g. 205/205 > > and 767/767 bytes in the examples above. > > > > "Should" ... to what end? > > "Should" in order to avoid hazard of centralization. A single bidder > who takes advantage of "buy 1 get 3 megabytes free" may outcompete a > number of individuals whose simple transactions recieve > anti-preferential treatment - "buy 1 get 0.33 megabytes free" in > aggregate. There is the illustration at: > "https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_4MB_and_1.33MB_blocks_in_Bitcoin.pdf".
It is not sufficient to be a centralized sender to utilize this advanage. The sender has to store data in the blockchain which itself is not the best utilization of money, even given the discount. Also what is the danger of centralization of such senders? The dangerous centralization is the centralization of real bitcoin sending, which has already happened - exchanges utilize batch transaction sending, saving on fees over a regular bitcoin sender, because they avoid change creation. This has nothing to do with witness discount, though.
Quoted text (4 lines)
> _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On Wed, Jan 17, 2024 at 12:30 AM Nagaev Boris <bnagaev@gmail•com> wrote:
Quoted text (3 lines)
> > Node operators are likely to put UTXO set to SSD and blocks to HDD. > SSD is more expensive than HDD.
Again, the UTXO set size argument is irrelevant. A simple transaction is at disadvantage even if it doesn't result in a change of UTXO set size.
Quoted text (6 lines)
> It is aligned with the fact that > people putting data into blockchain are financially motivated to put > it into witness data, i.e. into HDD. If miners charge the same per 1 > byte in a transaction output and 1 byte in witness, then people > putting data into blockchain could put it into transaction outputs > (why not, if the price is the same), (...)
By the same token, "people putting data into blockchain are financially" demotivated to put them into non-witness data (e.g. outputs) - which make vast majority of a simple, genuine transaction. As a result "blockchain" changes its nature and becomes full of bloated witness data (e.g. a JPEG in a single transaction in a "pathological" 4MB block) instead of simple, genuine transactions.
Quoted text (1 line)
> inflating the UTXO set (...).
UTXO set inflates naturally as there are more and more participants. Besides, blockspace price discrimination didn't stop it. Again, the UTXO set size argument is irrelevant to the subject.