From: jk_14@op•pl
To: Peter Todd <pete@petertodd•org>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
Date: Sun, 01 Jan 2023 23:27:38 +0100 [thread overview]
Message-ID: <149371042-9e9acf88755b97f4a249777ce88d0078@pmq8v.m5r2.onet> (raw)
Is a storage fee averaged out over many future blocks - but not hardcoded value and regulated by a free market?
The problem with demurrage I see is that the fee is taken when you spend. There is no additional income for miners if people are still hoarding.
In tail emission even if people are still hoarding - the fee is taken immediately and is distributed to miners.
We have a hope there is still the global adoption ahead (most of countries are like El Salvador). It may increase price and marketcap of Bitcoin by order of magnitude.
And that's why hoarding in demurrage may still exist: due to extremely appealing long-term risk/reward (i.e. relatively small, delayed tax versus huge possible profit)
W dniu 2022-12-31 00:29:08 użytkownik Peter Todd <pete@petertodd•org> napisał:
> 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
next reply other threads:[~2023-01-01 22:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-01 22:27 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-21 10:20 jk_14
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 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=149371042-9e9acf88755b97f4a249777ce88d0078@pmq8v.m5r2.onet \
--to=jk_14@op$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)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