Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
On Wed, Jan 17, 2024 at 12:30 AM Nagaev Boris wrote: > > 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. > 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. > 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
On Wed, Dec 27, 2023 at 10:43 PM wrote: > > 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
On Wed, Dec 27, 2023 at 11:39 PM Keagan McClelland 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). > > 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). > > > 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";. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
On Wed, Dec 27, 2023 at 8:06 PM Nagaev Boris wrote: > > On Wed, Dec 27, 2023 at 2:26 PM Greg Tonoski via bitcoin-dev > 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/ > 569Gblocks/ > 9.3Gchainstate/ > > 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? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
Unfortunately, as near as I can tell there is no sensible way to
prevent people from storing arbitrary data in witnesses ...
To prevent "from storing arbitrary data in witnesses" is the extreme
case of the size limit discussed in this thread. Let's consider it along
with other (less radical) options in order not to lose perspective, perhaps.
...without incentivizing even worse behavior and/or breaking
legitimate use cases.
I can't find evidence that would support the hypothesis. There had not
been "even worse behavior and/or breaking legitimate use cases" observed
before witnesses inception. The measure would probably restore
incentives structure from the past.
As a matter of fact, it is the current incentive structure that poses
the problem - incentivizes worse behavior ("this sort of data is toxic
to the network") and breaks legitimate use cases like a simple transfer
of BTC.
If we ban "useless data" then it would be easy for would-be data
storers to instead embed their data inside "useful" data such as dummy
signatures or public keys.
There is significant difference when storing data as dummy signatures
(or OP_RETURN) which is much more expensive than (discounted) witness.
Witness would not have been chosen as the storage of arbitrary data if
it cost as much as alternatives, e.g. OP_RETURN.
Also, banning "useless data" seems to be not the only option suggested
by the author who asked about imposing "a size limit similar to OP_RETURN".
But from a technical point of view, I don't see any principled way to
stop this.
Let's discuss ways that bring improvement rather than inexistence of a
perfect technical solution that would have stopped "toxic data"/"crap on
the chain". There are at least a few:
- https://github.com/bitcoin/bitcoin/pull/28408
- https://github.com/bitcoin/bitcoin/issues/29146
- deprecate OP_IF opcode.
I feel like the elephant in the room has been brought up. Do you want to
maintain Bitcoin without spam or a can't-stop-crap alternative, everybody?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
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
