From: Erik Aronesty <erik@q32•com>
To: Eric Voskuil <eric@voskuil•org>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
John Carvalho <john@synonym•to>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Date: Fri, 8 Jul 2022 11:14:39 -0400 [thread overview]
Message-ID: <CAJowKgL9D7mC7y5zEaZDN63aVG4Tkxn971vd=W2rBy1GyC9FtA@mail.gmail.com> (raw)
In-Reply-To: <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 2978 bytes --]
On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil <eric@voskuil•org> wrote:
> Value is subjective, though a constraint of 1tx per 10 minutes seems
> unlikey to create a fee of 5000x that of 5000tx. This is of course why I
> stated my assumption. Yet this simple example should make clear that at
> some point a reduction in confirmation rate reduces reward. Otherwise a
> rate of zero implies infinite reward.
>
Like i said, it's not linear. So no, a rate of 0 does not imply an
infinite reward. A number of papers on the Nash equilibrium of mining
rewards and block size have been written. There are block sizes that
are optimal for fees, and they obviously not zero, where the system
collapses, and they are obviously not infinite... where all bidders pay 1
sat/byte.
>
> You cannot support the blanket statement (and absent any assumption) that
> lower confirmation rates produce “much higher fees” or “better security”.
>
You can look at the research and the history of zero-size block impact on
fees and see that this is true.
>
> What you call a “bidding war” is merely market pricing, as it occurs with
> any good. People *always* will pay as much as they will pay. This is
> tautological. What you cannot say is how much more someone will pay at any
> given time for any given good, until they have done it. And I’m pretty sure
> Bitcoin hasn’t done it.
>
If there is infinite supply, then there is zero value. Infinite blocks
have lower fees. This is impossible to argue against.
> You cannot prove what the price of anything will be, nor can any “papers”.
> The absurdity of S2F should have clearly demonstrated that by now. Value is
> an individual human preference.
>
A trivial example: block sizeof 10, and 10 people want to transact, all can
bid 1 SAT/byte, 2 tx are moving 100 mil sats, the other 8 are moving 10 mil
sats. Block size of 2. Now the two transactions moving 100 mil sats will
bid, they can easily pay 400 sats/byte.
You can show, from history, that when block sizes are more constrained, due
to the mining of zero byte blocks, total fees were higher. People will
always pay for "next confirm" if the cost of that is very reasonable (less
than 0.1%).
>
> If everyone pays 1 sat, then either miners are profitable at 1 sat, or
> these people are not getting confirmed (economic rationality always
> assumed).
>
Yes, and if miners are not profitable at 1 sat, then they will not mine,
and the hash rate will drop. And this reduces the security of the coin.
Hashrate is an index of security.
But there is of course no real issue here. Simply fork off an inflation
> coin and test your theory. I mean, that’s the only way it can happen anyway.
>
I would argue inflation is not a good solution. Instead, being cautious
about block-compressing tech, like mweb, and being more aggressive about
fee-driving tech, makes more sense .
[-- Attachment #2: Type: text/html, Size: 4745 bytes --]
next prev parent reply other threads:[~2022-07-08 15:14 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org>
2022-07-07 13:24 ` John Carvalho
2022-07-07 14:12 ` Peter Todd
2022-07-07 16:24 ` Eric Voskuil
2022-07-07 17:37 ` Erik Aronesty
2022-07-07 19:57 ` Eric Voskuil
2022-07-07 21:11 ` Erik Aronesty
2022-07-08 0:28 ` Eric Voskuil
2022-07-08 4:59 ` vjudeu
2022-07-08 7:26 ` John Carvalho
2022-07-08 15:14 ` Erik Aronesty [this message]
2022-07-14 4:55 ` Billy Tetrud
2022-07-07 22:06 ` Anthony Towns
2022-07-07 22:02 ` Corey Haddad
[not found] <mailman.9.1654344003.14400.bitcoin-dev@lists.linuxfoundation.org>
2022-06-04 12:27 ` John Carvalho
2022-06-04 13:48 ` Keagan McClelland
2022-06-04 16:12 ` alicexbt
2022-06-06 13:02 ` Erik Aronesty
2022-06-12 3:36 ` Peter Todd
2022-06-12 13:02 ` Erik Aronesty
2022-06-12 16:35 ` Corey Haddad
2022-06-12 19:16 ` alicexbt
2022-06-19 10:31 ` Peter Todd
2022-06-19 15:54 ` Manuel Costa
2022-06-19 18:26 ` Kate Salazar
2022-06-19 22:35 ` Erik Aronesty
2022-06-21 19:00 ` Keagan McClelland
2022-06-21 20:10 ` Eric Voskuil
2022-06-23 19:17 ` Peter Todd
2022-06-28 3:55 ` Billy Tetrud
2022-06-28 16:23 ` Alex Lee
2022-06-28 23:22 ` Peter Todd
2022-06-29 5:02 ` Alex Lee
2022-06-28 23:20 ` Peter Todd
2022-06-29 10:44 ` Kate Salazar
2022-06-30 15:25 ` Billy Tetrud
2022-07-03 9:43 ` Peter Todd
2022-07-03 10:30 ` Giuseppe B
2022-07-06 4:28 ` Corey Haddad
2022-07-06 11:10 ` vjudeu
2022-07-07 0:46 ` Billy Tetrud
2022-07-07 12:15 ` vjudeu
2022-07-07 14:05 ` Erik Aronesty
2022-07-07 14:10 ` Giuseppe B
2022-07-08 5:03 ` Billy Tetrud
2022-06-30 17:04 ` Erik Aronesty
2022-06-03 18:39 alicexbt
2022-06-04 0:29 ` micaroni
2022-06-04 18:43 ` Jorge Timón
2022-06-05 4:18 ` alicexbt
2022-06-08 3:51 ` Billy Tetrud
2022-06-08 9:22 ` Jorge Timón
2022-06-09 4:30 ` Billy Tetrud
2022-06-09 0:03 ` Ryan Grant
2022-07-19 4:44 ` Anthony Towns
2022-07-19 14:46 ` alicexbt
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='CAJowKgL9D7mC7y5zEaZDN63aVG4Tkxn971vd=W2rBy1GyC9FtA@mail.gmail.com' \
--to=erik@q32$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
--cc=john@synonym$(echo .)to \
/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