Erik Aronesty [ARCHIVE] on Nostr: đź“… Original date posted:2022-07-08 đź“ť Original message:On Thu, Jul 7, 2022 at ...
đź“… Original date posted:2022-07-08
đź“ť Original message:On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil <eric at 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 .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220708/d70ca037/attachment-0001.html>;
đź“ť Original message:On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil <eric at 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 .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220708/d70ca037/attachment-0001.html>;