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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 326E5C0019
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 09:41:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 16427406AB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 09:41:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=gazeta.pl
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 RwuE8ZhSclb0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 09:41:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo47.poczta.onet.pl (smtpo47.poczta.onet.pl
[213.180.142.178])
by smtp4.osuosl.org (Postfix) with ESMTPS id BC4994061C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 09:41:54 +0000 (UTC)
Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4FMp4n0QS7zlhnxb;
Sat, 17 Apr 2021 11:41:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1618652505; bh=gbTEUHz98qKurnxM8ikDvwVQkbjpu1lmKb2O7Dt26G8=;
h=From:To:Date:Subject:From;
b=lB5NGwA6Dc6sBt0/5Ux+cEL9p6KED2r+DR0DzbMx6CtIENCw742G1Acvx2f+jU/e/
6S0ud2CL1YE2ZfNh6w77wojHLmuA6eT7HZ53uLh5DGqq/acWYEaCF6lsHvKVl7DZTZ
E9qT0D7ltzqlNiKjW3vzyAHVn6ZEcgIrCkjSNTto=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.252.88] by pmq5v.m5r2.onet via HTTP id
202104171141322508010001; Sat, 17 Apr 2021 11:41:45 +0200
From: vjudeu <vjudeu@gazeta.pl>
X-Priority: 3
To: Erik Aronesty <erik@q32.com>, "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Date: Sat, 17 Apr 2021 11:41:44 +0200
Message-Id: <128966745-bb0a93fd2653dc12305b953184cbcd13@pmq5v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.252.88;PL;2
X-Mailman-Approved-At: Sat, 17 Apr 2021 11:43:40 +0000
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 09:41:59 -0000
Yes, transition from Proof of Work to Proof of Something Else is possible i=
n a soft-fork way. All that is needed is getting miners and users support. =
Then, Proof of Work difficulty should drop to one, and the rest would be so=
lved by Proof of Something Else. Old miners still could use ASIC miners to =
produce blocks with higher Proof of Work, but then their blocks would be re=
jected. Currently, you can also make a block with enormously low hash, but =
if this block would contain two transactions sending the same coins to two =
different places, it would be rejected, no matter how low that hash would b=
e. As long as miners would produce enough Proof of Something Else and as lo=
ng as most nodes would use upgraded software, it should be resistant to suc=
h attacks.
So, technically speaking, it is possible. The most difficult part is gettin=
g miners and users supporting it.
On 2021-04-16 23:47:44 user Erik Aronesty via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
> > 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 everyo=
ne else.
> >
> > On Fri, Apr 16, 2021, 2:08 PM Erik Aronesty via bitcoin-dev <bitcoin-de=
v@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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> =
|
