Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: jk_14@op.pl
To: Peter Todd <pete@petertodd.org>
Date: Sun, 01 Jan 2023 23:27:38 +0100
Message-Id: <149371042-9e9acf88755b97f4a249777ce88d0078@pmq8v.m5r2.onet>
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Sun, 01 Jan 2023 23:33:11 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Jan 2023 22:37:37 -0000


Is a storage fee averaged out over many future blocks - but not hardcoded v=
alue and regulated by a free market?


The problem with demurrage I see is that the fee is taken when you spend. T=
here is no additional income for miners if people are still hoarding.
In tail emission even if people are still hoarding - the fee is taken immed=
iately 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 or=
der of magnitude.
And that's why hoarding in demurrage may still exist: due to extremely appe=
aling long-term risk/reward (i.e. relatively small, delayed tax versus huge=
 possible profit)


W dniu 2022-12-31 00:29:08 u=C5=BCytkownik Peter Todd <pete@petertodd.org> =
napisa=C5=82:
> 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 r=
etargets (100 fit well in 210,000 / 2016 =3D 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_d=
iffs
> 	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 additio=
nal
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 syste=
m,
under the right conditions we could have a significant amount of hashing po=
wer
just barely able to afford to hash prior to the halving, resulting in all t=
hat
hashing power immediately having to shut down and fees increasing dramatica=
lly,
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 theo=
ry,
be a positive improvement on the status quo. But it is a hard fork and I do=
n't
think there is much hope for such hard forks to be implemented. I believe t=
hat
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