From: Nagaev Boris <bnagaev@gmail•com>
To: Greg Tonoski <gregtonoski@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
Date: Tue, 16 Jan 2024 20:29:58 -0300 [thread overview]
Message-ID: <CAFC_Vt4aDvWsUh4q+UxFa3ZyRC_eK2ek7HR-G+nOiaC-wSa-WA@mail.gmail.com> (raw)
In-Reply-To: <CAMHHROxBqLrBCT-y4Va5=xe6JUqb=FPyEq2PJ7=JrpqmHOJd8Q@mail.gmail.com>
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
next prev parent reply other threads:[~2024-01-16 23:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
2023-12-27 21:43 vjudeu
2024-01-16 10:40 ` Greg Tonoski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFC_Vt4aDvWsUh4q+UxFa3ZyRC_eK2ek7HR-G+nOiaC-wSa-WA@mail.gmail.com \
--to=bnagaev@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gregtonoski@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox