From: Peter Todd <pete@petertodd•org>
To: jk_14@op•pl
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
Date: Fri, 30 Dec 2022 18:28:58 -0500 [thread overview]
Message-ID: <Y690OjY0MA/YQ9IL@petertodd.org> (raw)
In-Reply-To: <173552838-a7412589a40ea770709d0b227b056bd3@pmq5v.m5r2.onet>
[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]
On Fri, Dec 23, 2022 at 07:43:36PM +0100, jk_14@op•pl wrote:
>
> Necessary or not - it doesn't hurt to plan the robust model, just in case. The proposal is:
>
> Let every 210,000 the code calculate the average difficulty of 100 last retargets (100 fit well in 210,000 / 2016 = 104.166)
> and compare with the maximum of all such values calculated before, every 210,000 blocks:
>
>
> if average_diff_of_last_100_retargets > maximum_of_all_previous_average_diffs
> do halving
> else
> do nothing
>
>
> This way:
>
> 1. system cannot be played
> 2. only in case of destructive halving: system waits for the recovery of network security
First of all - while I suspct you already understand this issue - I should
point out the following:
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.
Other than that problem, I agree that this proposal would, at least in theory,
be a positive improvement on the status quo. But it is a hard fork and I don't
think there is much hope for such hard forks to be implemented. I believe that
a demmurrage soft-fork, implemented via a storage fee averaged out over many
future blocks, has a much more plausible route towards implementation.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-12-30 23:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-23 18:43 jk_14
2022-12-30 23:28 ` Peter Todd [this message]
2023-01-01 12:42 ` Alfie John
2023-01-18 20:58 ` Peter Todd
2022-12-27 15:34 jk_14
2022-12-30 18:20 ` Billy Tetrud
2023-01-01 21:23 jk_14
2023-01-02 4:53 ` Billy Tetrud
2023-01-01 22:27 jk_14
2023-01-02 23:02 jk_14
2023-01-04 16:03 ` Billy Tetrud
2023-01-07 18:52 jk_14
2023-01-07 23:22 ` Eric
2023-01-21 10:20 jk_14
[not found] <mailman.9.1674388803.14535.bitcoin-dev@lists.linuxfoundation.org>
2023-01-22 14:13 ` John Tromp
2023-02-01 22:04 jk_14
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=Y690OjY0MA/YQ9IL@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jk_14@op$(echo .)pl \
/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