MIME-Version: 1.0
References: <CAMHHROxsKuqzVsU90srQBNDj4redB11uqB2JxmDK=G1LDw9_HA@mail.gmail.com>
 <CAFC_Vt4pjZCMAZSi32Y3z-F3rrnnXVR4pvF5T4Ojrdb=Lsu97A@mail.gmail.com>
In-Reply-To: <CAFC_Vt4pjZCMAZSi32Y3z-F3rrnnXVR4pvF5T4Ojrdb=Lsu97A@mail.gmail.com>
From: Greg Tonoski <gregtonoski@gmail.com>
Date: Sat, 13 Jan 2024 16:04:12 +0100
Message-ID: <CAMHHROxBqLrBCT-y4Va5=xe6JUqb=FPyEq2PJ7=JrpqmHOJd8Q@mail.gmail.com>
To: Nagaev Boris <bnagaev@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination
 put simple transactions at disadvantage
Precedence: list

On Wed, Dec 27, 2023 at 8:06=E2=80=AFPM Nagaev Boris <bnagaev@gmail.com> wr=
ote:
>
> On Wed, Dec 27, 2023 at 2:26=E2=80=AFPM 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 =3D 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-cost=
s.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?