* Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
@ 2023-12-27 21:43 vjudeu
2024-01-16 10:40 ` Greg Tonoski
0 siblings, 1 reply; 10+ messages in thread
From: vjudeu @ 2023-12-27 21:43 UTC (permalink / raw)
To: Greg Tonoski, Bitcoin Protocol Discussion, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 433 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
2023-12-27 21:43 [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage vjudeu
@ 2024-01-16 10:40 ` Greg Tonoski
0 siblings, 0 replies; 10+ messages in thread
From: Greg Tonoski @ 2024-01-16 10:40 UTC (permalink / raw)
To: vjudeu; +Cc: bitcoin-dev
On Wed, Dec 27, 2023 at 10:43 PM <vjudeu@gazeta•pl> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
2024-01-16 23:29 ` Nagaev Boris
@ 2024-01-21 17:14 ` Greg Tonoski
0 siblings, 0 replies; 10+ messages in thread
From: Greg Tonoski @ 2024-01-21 17:14 UTC (permalink / raw)
To: Nagaev Boris; +Cc: Bitcoin Protocol Discussion
On Wed, Jan 17, 2024 at 12:30 AM Nagaev Boris <bnagaev@gmail•com> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
2024-01-14 13:10 ` Greg Tonoski
@ 2024-01-16 23:40 ` Nagaev Boris
0 siblings, 0 replies; 10+ messages in thread
From: Nagaev Boris @ 2024-01-16 23:40 UTC (permalink / raw)
To: Greg Tonoski, Bitcoin Protocol Discussion
On Sun, Jan 14, 2024 at 10:21 AM Greg Tonoski via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> > > 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Best regards,
Boris Nagaev
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
2024-01-13 15:04 ` Greg Tonoski
@ 2024-01-16 23:29 ` Nagaev Boris
2024-01-21 17:14 ` Greg Tonoski
0 siblings, 1 reply; 10+ messages in thread
From: Nagaev Boris @ 2024-01-16 23:29 UTC (permalink / raw)
To: Greg Tonoski; +Cc: Bitcoin Protocol Discussion
On Sat, Jan 13, 2024 at 12:03 PM Greg Tonoski <gregtonoski@gmail•com> wrote:
>
> 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.
--
Best regards,
Boris Nagaev
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
2023-12-27 22:39 ` Keagan McClelland
@ 2024-01-14 13:10 ` Greg Tonoski
2024-01-16 23:40 ` Nagaev Boris
0 siblings, 1 reply; 10+ messages in thread
From: Greg Tonoski @ 2024-01-14 13:10 UTC (permalink / raw)
To: Keagan McClelland; +Cc: Bitcoin Protocol Discussion
On Wed, Dec 27, 2023 at 11:39 PM Keagan McClelland
<keagan.mcclelland@gmail•com> 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".
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
2023-12-27 19:06 ` Nagaev Boris
@ 2024-01-13 15:04 ` Greg Tonoski
2024-01-16 23:29 ` Nagaev Boris
0 siblings, 1 reply; 10+ messages in thread
From: Greg Tonoski @ 2024-01-13 15:04 UTC (permalink / raw)
To: Nagaev Boris; +Cc: Bitcoin Protocol Discussion
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
2023-12-27 16:44 Greg Tonoski
2023-12-27 19:06 ` Nagaev Boris
@ 2023-12-27 22:39 ` Keagan McClelland
2024-01-14 13:10 ` Greg Tonoski
1 sibling, 1 reply; 10+ messages in thread
From: Keagan McClelland @ 2023-12-27 22:39 UTC (permalink / raw)
To: Greg Tonoski, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]
> 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?
> 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:
> 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
>
[-- Attachment #2: Type: text/html, Size: 2584 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
2023-12-27 16:44 Greg Tonoski
@ 2023-12-27 19:06 ` Nagaev Boris
2024-01-13 15:04 ` Greg Tonoski
2023-12-27 22:39 ` Keagan McClelland
1 sibling, 1 reply; 10+ messages in thread
From: Nagaev Boris @ 2023-12-27 19:06 UTC (permalink / raw)
To: Greg Tonoski, Bitcoin Protocol Discussion
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.
--
Best regards,
Boris Nagaev
^ permalink raw reply [flat|nested] 10+ messages in thread
* [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
@ 2023-12-27 16:44 Greg Tonoski
2023-12-27 19:06 ` Nagaev Boris
2023-12-27 22:39 ` Keagan McClelland
0 siblings, 2 replies; 10+ messages in thread
From: Greg Tonoski @ 2023-12-27 16:44 UTC (permalink / raw)
To: bitcoin-dev
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-01-21 17:14 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-27 21:43 [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage vjudeu
2024-01-16 10:40 ` Greg Tonoski
-- strict thread matches above, loose matches on Subject: below --
2023-12-27 16:44 Greg Tonoski
2023-12-27 19:06 ` Nagaev Boris
2024-01-13 15:04 ` Greg Tonoski
2024-01-16 23:29 ` Nagaev Boris
2024-01-21 17:14 ` Greg Tonoski
2023-12-27 22:39 ` Keagan McClelland
2024-01-14 13:10 ` Greg Tonoski
2024-01-16 23:40 ` Nagaev Boris
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox