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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
Return-Path: <earonesty@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id E9C65C000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Apr 2021 21:48:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id D024A41853
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Apr 2021 21:48:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id BjpSemREwwhy
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Apr 2021 21:47:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com
[IPv6:2607:f8b0:4864:20::102d])
by smtp4.osuosl.org (Postfix) with ESMTPS id 1F68E41850
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Apr 2021 21:47:57 +0000 (UTC)
Received: by mail-pj1-x102d.google.com with SMTP id lt13so5867962pjb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Apr 2021 14:47:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=q32-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=anlqnc+4cHnQgrTw0ZfBXine/Kv0aDcw5XDbBF+2E2A=;
b=X3dwhekPnMqjRVojxpAd3Tm5J7Y5IZx2BZevlgvcOPg0dk1VP+RjwTKlB9CzEbH/Rj
Y//j4rFr/ABb91vWjUwgrzpmLlP7+3P9xEb714De5qsJ/9mbsymiSQ5KH4Dbz8KaynS2
yygwYe7MkGq7SI/+n2PW/Dx/T/z/eCKwdUC7U/4KElXIkwZeBPHtkdn8FEgtMr54l0sT
BW0m0DQrfMXTXvs1nNfrhL1teNBjcdGi5cgcpscOkscpH2c8elYyZoer3HD4csSgGDPM
wRvhVcaFTzDvMT5Ua8CpAGE8Mbr8cnVV2Z+h2g8q/ARd+IRGlSehgcgoqmAl6PT4APHd
EnNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=anlqnc+4cHnQgrTw0ZfBXine/Kv0aDcw5XDbBF+2E2A=;
b=W0w1sP/aQePWmLJxcouyLQB6O62mhVXGg0DzGX5NC59nJm7aa1HGO+ZUyw32cVP/VW
S/IQIL0KKp0HWVGd548rmY20fe5xwEa854fYtEx5lMNe4YsqEl3+gUseQ33rBd4chUZi
pB+0jJ5YkXoUyF6sB+aVnmTZVwElZgtkfCs7GfGgFrxAsI9Uu2mJztCPXg98n1wEDzE8
7911hPzx0x2ek/UKAOyHK6WhWTWJSZYAtCkuxtgZKBmvuskUctAdF4BD0+cfjn20J6/f
vzx4UKBECHOTQskQ1qWjGipsaCHxbBnA4JyONMWzSb8sCx0nbDAxyormbaY5/yS1pT8Y
YWrA==
X-Gm-Message-State: AOAM531yNF1uGYsX5+2FLrqcRjcfOliqYZY4xzEixZdLOYulgl3kQG4u
aoNgY1kz5QPJm8v9qfniEJtG24S1zPEVum7EWsjjHM8=
X-Google-Smtp-Source: ABdhPJz3M3A/eXCCaJc2Up9iabwajRXbHogu4LLMi9HLYuvQqvzJjHDL6WLX/K7qNfhMJXR1HV8aEa/DBcnhCEV5MRc=
X-Received: by 2002:a17:90a:bd8c:: with SMTP id
z12mr12036530pjr.83.1618609676534;
Fri, 16 Apr 2021 14:47:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
<CAD5xwhjWHsEZjTKJA3e+mwKZxuXf043jKvqDG4_hYRhd1jR07g@mail.gmail.com>
In-Reply-To: <CAD5xwhjWHsEZjTKJA3e+mwKZxuXf043jKvqDG4_hYRhd1jR07g@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 16 Apr 2021 17:47:44 -0400
Message-ID: <CAJowKgLNubeU0nVHqx+c8Jz+qMtOgmqwrCRdzCmaLvU67Jo6zw@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Fri, 16 Apr 2021 21:49:09 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 16 Apr 2021 21:48:01 -0000
> I think you need to hard deprecate the PoW for this to work, otherwise all old miners are like "toxic waste".
what would be the incentive? a POB would be required on every block
(and would be lost if not used). so any miner doing this would just
be doing "extra work" and strictly losing money over a miner that
doesn't. a 99% reduction would be more than enough tho.
On Fri, Apr 16, 2021 at 5:24 PM Jeremy <jlrubin@mit.edu> 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.
>
> On Fri, Apr 16, 2021, 2:08 PM Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Not sure of the best place to workshop ideas, so please take this with
>> a grain of salt.
>>
>> Starting with 3 assumptions:
>>
>> - assume that there exists a proof-of-burn that, for Bitcoin's
>> purposes, accurately-enough models the investment in and development
>> of ASICs to maintain miner incentive.
>> - assume the resulting timing problem "how much burn is enough to keep
>> blocks 10 minutes apart and what does that even mean" is also...
>> perfectly solvable
>> - assume "everyone unanimously loves this idea"
>>
>> 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?
>>
>> IE: We could transition to another "required proof" - such as a
>> quantum POW or a POB (above) or something else .... in a back-compat
>> way (existing nodes not aware of the rules would continue to
>> validate).
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
