From: jk_14@op•pl
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
Date: Tue, 27 Dec 2022 16:34:07 +0100 [thread overview]
Message-ID: <173647633-76b3b19c83c720cc30cb8fcb603b5251@pmq5v.m5r2.onet> (raw)
It seems like the more elegant solution could be by using a chainwork parameter instead.
i.e. comparison just before halving - if the last 210,000 block interval has a higher chainwork difference between the begining and the end of interval
than any other such inter-halving interval before.
LIttle digression yet:
A system in which all users participate in ensuring its security looks better than one in which only some (i.e. active) of them participate (and passive stakeholders are de facto free riders)
In my opinion this concept above is only the complement of currently missing mechanism: achieving equilibrium regarding costs of security between two parties with opposing interests.
It's easy to understand and - most important - it has no hardcoded value of tail emission - what is the clear proof it is based on a free market.
And last but not least, if someone is 100% sure that income from transactions will takeover security support from block subsidy - accepting such proposal is like putting the money where the mouth is: this safety measure will never be triggered, then (no risk of fork)
Best Regards
Jaroslaw
W dniu 2022-12-23 20:29:20 użytkownik Jaroslaw via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> napisał:
>
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
Best Regards
Jaroslaw
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next reply other threads:[~2022-12-27 15:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-27 15:34 jk_14 [this message]
2022-12-30 18:20 ` Billy Tetrud
-- 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 22:27 jk_14
2023-01-01 21:23 jk_14
2023-01-02 4:53 ` 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=173647633-76b3b19c83c720cc30cb8fcb603b5251@pmq5v.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