From: jk_14@op•pl
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
Date: Sat, 21 Jan 2023 11:20:02 +0100 [thread overview]
Message-ID: <82931557-3188a24755a7c83182882dc9296aa6e0@pmq6v.m5r2.onet> (raw)
This is the phrase that should be recalled very often:
"the total reward per transaction is Three Orders of Magnitude
higher than typical fees. Sufficient fee increases to bring back hashing power
in a scenario like that would cause Enormous Disruption to many things,
including Lightning channels"
> Your proposal does not address that problem as it can only measure difficulty prior to the halving point
Yes, my proposal of fixing the inevitable (but only spreaded over the long time) failure - is quite conservative, surprisingly.
Simplifying it to the edge case:
If in a four-year perspective there is no the average price +100% increase - to properly compensate last halving,
but instead there is a hashrate -50% drop - another possible and "proper" (!) compensation
- absolutely don't worse the situation by executing next halving,
accept such drop because there is nothing you can do about it
and wait with halvings for the hashrate to recover. As long as it takes.
Maybe even 20 years if necessary (fortunately we are at mature phase of ASIC technology right now),
And iterate.
This way we land at lowest possible annual inflation and set by a free market.
As I said this is quite conservative approach. It would suit bitcoin,.
Too bad it wasn't foreseen at the beginning...
W dniu 2023-01-18 21:58:15 użytkownik Peter Todd <pete@petertodd•org> napisał:
> On Sun, Jan 01, 2023 at 11:42:50PM +1100, Alfie John wrote:
> On 31 Dec 2022, at 10:28 am, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> >> This way:
> >>
> >> 1. system cannot be played
> >> 2. only in case of destructive halving: system waits for the recovery of network security
> >
> > The immediate danger we have with halvings is that in a competitive market,
> > profit margins tend towards marginal costs - the cost to produce an additional
> > unit of production - rather than total costs - the cost necessary to recover
> > prior and future expenses. Since the halving is a sudden shock to the system,
> > under the right conditions we could have a significant amount of hashing power
> > just barely able to afford to hash prior to the halving, resulting in all that
> > hashing power immediately having to shut down and fees increasing dramatically,
> > and likely, chaotically. Your proposal does not address that problem as it can
> > only measure difficulty prior to the halving point.
>
>
> > ... Since the halving is a sudden shock to the system
>
> Is it though? Since everyone knows of the possible outcomes, wouldn't a possible halving be priced in?
Re-read that I said. That explains why despite the halving being a forseeable
event, there's no mechanism to "price it in" when it comes to hashing power.
> > resulting in all that hashing power immediately having to shut down and fees increasing dramatically
>
> Which should cause that hashing power to come back because of this fee increases.
Right now the total reward per transaction is $63, three orders of magnitude
higher than typical fees. Sufficient fee increases to bring back hashing power
in a scenario like that would cause enormous disruption to many things,
including Lightning channels.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
next reply other threads:[~2023-01-21 10:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 10:20 jk_14 [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-02-01 22:04 jk_14
[not found] <mailman.9.1674388803.14535.bitcoin-dev@lists.linuxfoundation.org>
2023-01-22 14:13 ` John Tromp
2023-01-07 18:52 jk_14
2023-01-07 23:22 ` Eric
2023-01-02 23:02 jk_14
2023-01-04 16:03 ` Billy Tetrud
2023-01-01 22:27 jk_14
2023-01-01 21:23 jk_14
2023-01-02 4:53 ` Billy Tetrud
2022-12-27 15:34 jk_14
2022-12-30 18:20 ` Billy Tetrud
2022-12-23 18:43 jk_14
2022-12-30 23:28 ` Peter Todd
2023-01-01 12:42 ` Alfie John
2023-01-18 20:58 ` Peter Todd
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=82931557-3188a24755a7c83182882dc9296aa6e0@pmq6v.m5r2.onet \
--to=jk_14@op$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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