1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 85E33C0019
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 11:47:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 7543D60599
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 11:47:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.202
X-Spam-Level: *
X-Spam-Status: No, score=1.202 tagged_above=-999 required=5
tests=[BAYES_50=0.8, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001,
SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001]
autolearn=no 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 gcow7SBgOggW
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 11:47:25 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp3.osuosl.org (Postfix) with ESMTPS id 9E69F600BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 11:47:25 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1lXjQ1-0007WE-PG; Sat, 17 Apr 2021 21:47:23 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Sat, 17 Apr 2021 21:47:17 +1000
Date: Sat, 17 Apr 2021 21:47:17 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210417114717.GA8079@erisian.com.au>
References: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Gradual transition to an alternate proof without
a hard fork.
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: Sat, 17 Apr 2021 11:47:30 -0000
On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-dev wrote:
> The transition *could* look like this:
> - validating nodes begin to require proof-of-burn, in addition to
> proof-of-work (soft fork)
> - the extra expense makes it more expensive for miners, so POW slowly drops
> - on a predefined schedule, POB required is increased to 100% of the
> "required work" to mine
> Given all of that, am I correct in thinking that a hard fork would not
> be necessary?
It depends what you mean by a "hard fork". By the definition that
"the old software will consider the chain followed by new versions of
the software as valid" it's a soft fork. But it doesn't maintain the
property "old software continues to follow the same chain as new software,
provided the economic majority has adopted the new software" -- because
after the PoW part has dropped its difficulty substantitally, people can
easily/cheaply make a new chain that doesn't include proof-of-burn, and
has weak proof-of-work that's nevertheless higher than the proof-of-burn
chain, so old nodes will switch to it, while new nodes will continue to
follow the proof-of-burn chain.
So I think that means it needs to be treated as a hard fork: everyone
needs to be running the new software by some date to ensure they follow
the same chain.
(The same argument applies to trying to switch to a different PoW
algorithm via a soft fork; I forget who explained this to me)
Jeremy wrote:
> I think you need to hard deprecate the PoW for this to work, otherwise
> all old miners are like "toxic waste".
>
> Imagine one miner turns on a S9 and then ramps up difficulty for
> everyone else.
If it's a soft-fork, you could only ramp up the PoW difficulty by mining
more than one block every ten minutes, but presumably the proof-of-burn
scheme would have its own way of preventing burners from mining blocks
too fast (it was assumption 2).
Cheers,
aj
|
