Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B4999C002D for ; Sun, 1 Jan 2023 12:53:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 726D060E77 for ; Sun, 1 Jan 2023 12:53:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 726D060E77 Authentication-Results: smtp3.osuosl.org; dkim=pass (1024-bit key, unprotected) header.d=alfie.wtf header.i=@alfie.wtf header.a=rsa-sha256 header.s=key1 header.b=3wulMcMs X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHHHcBavWB-6 for ; Sun, 1 Jan 2023 12:53:23 +0000 (UTC) X-Greylist: delayed 00:10:10 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1E34060E76 Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1E34060E76 for ; Sun, 1 Jan 2023 12:53:22 +0000 (UTC) X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alfie.wtf; s=key1; t=1672576990; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2bfeRX1hVHHTa0wNivkhiKWXi52ZINtHJoKsok+uGFc=; b=3wulMcMsUGPV6ONint1xhKFgyFSNYEtvPonAhwplikVYGtUzIYye0bhD0wONGfivuJspgd VevjE4kKUhzsW1Dx8emdv7hkyUGM2ykRT1GWDI08spi2xcHIoNzKt/XYs+fr3HJ6ounZa/ OEX9J8j6mH1KkH7R7O0QtAHCf1ST39o= From: Alfie John Message-Id: <2480C772-EE75-4350-BF11-FA9FEFC8A4EA@alfie.wtf> Content-Type: multipart/alternative; boundary="Apple-Mail=_1765C68F-4363-4982-AB44-024DAE8DA03D" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Date: Sun, 1 Jan 2023 23:42:50 +1100 In-Reply-To: To: Peter Todd , Bitcoin Protocol Discussion References: <173552838-a7412589a40ea770709d0b227b056bd3@pmq5v.m5r2.onet> X-Migadu-Flow: FLOW_OUT X-Mailman-Approved-At: Sun, 01 Jan 2023 12:56:40 +0000 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2023 12:53:25 -0000 --Apple-Mail=_1765C68F-4363-4982-AB44-024DAE8DA03D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 31 Dec 2022, at 10:28 am, Peter Todd via bitcoin-dev = wrote: >=20 >> This way: >>=20 >> 1. system cannot be played >> 2. only in case of destructive halving: system waits for the recovery = of network security >=20 > 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?=20 > 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. Alfie -- Alfie John https://www.alfie .wtf= --Apple-Mail=_1765C68F-4363-4982-AB44-024DAE8DA03D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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? 

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.

Alfie

--
Alfie John
= --Apple-Mail=_1765C68F-4363-4982-AB44-024DAE8DA03D--