public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail.com>
To: Erik Aronesty <erik@q32.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: John Carvalho <john@synonym.to>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Date: Wed, 13 Jul 2022 23:55:35 -0500	[thread overview]
Message-ID: <CAGpPWDaNtn7WsXv-_vMfv5f9eUma3jPVF_+9XjTFzECRE+2ZaQ@mail.gmail.com> (raw)
In-Reply-To: <CAJowKgL9D7mC7y5zEaZDN63aVG4Tkxn971vd=W2rBy1GyC9FtA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6631 bytes --]

@Peter Todd

> The fact of the matter is that the present amount of security is about
1.7% of
the total coin supply/year

That's on the order of what I calculated
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#analysis-of-various-consensus-algorithms>:
~0.5%. I'm curious where the 1.7% number comes from.  Perhaps much of the
difference in our two numbers likely comes from me incorporating what I
call the "Economic Mining Monopoly Attack"
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#economic-mining-monopoly-attack>
which effectively cuts the security in half.

> There's zero reason to stress about finding an "optimal" amount. An
amount low enough to be easily affordable, but non-zero, is fine.

That's fair. What I mean is that we should estimate an optimal value to
some degree of accuracy. It doesn't have to be super accurate. But too low
and we could have a bad time. Too high and its a deadweight cost forever
(which increases fees, slows adoption, and causes an inflation-like
devaluation force on bitcoin, which has all the familiar market distorting
effects, albeit to a much smaller degree than we're used to).  In any case,
we need to come to an accurate enough estimate of how much is enough
security so that we ensure we're above that amount.

> These are all amounts that are likely to be dwarfed by economic shifts.

Perhaps you're right. Regardless, its certainly an improvement to what
we've had the last 100 years.

@Erik Voskuil
> You cannot support the blanket statement (and absent any assumption) that
lower confirmation rates produce “much higher fees” or “better security”.

I can in fact support it. The theory of supply and demand supports it.
Well, depending on what you mean by "fees". Reducing the block size will
certainly increase average fees/vbyte. Whether it increases total fees
collected by miners (and thus lead to "better security") is another story -
a story that depends on the demand dynamics in the market. It could very
well be that reducing the blocksize reduces the number of transactions by a
higher proportion than fees go up. As we have seen in past periods of high
traffic tho, total fees go up *quite* a lot. So it seems pretty clear to me
that constraining the block size would very likely increase total fees
collected by miners, at least for the near future.

@Carvalho
>  I will reiterate. Proof of work and the difficulty adjustment scheme
already solve all of these issues

You haven't addressed any of the comments that disagree with you above. You
didn't address any of my comments originally. You are simply claiming
things without any logical support. If you want to be a respectable part of
this conversation, I'd recommend explaining yourself much more thoroughly.

> That restaurant is too popular, nobody goes there anymore.

If you could feed 100,000 people with 1 entire from a restaurant, your
restaurant might not make enough money to survive despite feeding the
entire country. That's what the lightning network does for/to bitcoin. We
need to make sure the restaurant can afford to staff itself despite massive
increases in food-use efficiency.

On Fri, Jul 8, 2022 at 12:32 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 .
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 9397 bytes --]

  reply	other threads:[~2022-07-14  4:55 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 ` [bitcoin-dev] Bitcoin covenants are inevitable 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
2022-07-14  4:55                 ` Billy Tetrud [this message]
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=CAGpPWDaNtn7WsXv-_vMfv5f9eUma3jPVF_+9XjTFzECRE+2ZaQ@mail.gmail.com \
    --to=billy.tetrud@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=erik@q32.com \
    --cc=john@synonym.to \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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