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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Wczvz-00015y-SK
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 16:22:07 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.170 as permitted sender)
client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f170.google.com;
Received: from mail-ob0-f170.google.com ([209.85.214.170])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wczvx-0003Ek-SK
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 16:22:07 +0000
Received: by mail-ob0-f170.google.com with SMTP id vb8so1299814obc.29
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 09:21:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.55.65 with SMTP id q1mr2181446obp.70.1398270116763; Wed,
23 Apr 2014 09:21:56 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 09:21:56 -0700 (PDT)
In-Reply-To: <CANOOu=85-6p-v8ZWPC=zGAY9TdjgR1WK_fOOJYnyFJMj+dvHUQ@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAE28kUQ9WOnHuFR6WYeU6rep3b74zDweTPxffF0L6FjZObXE6A@mail.gmail.com>
<CANEZrP3WBWi5h04yyQ115vXmVHupoj5MG+-8sx=2zEcCT5a9hg@mail.gmail.com>
<CAE28kUQqFJUJSiSV4PSF2QK04D3GuL1n2EF46Yo3o_-LYsgSTA@mail.gmail.com>
<CANOOu=85-6p-v8ZWPC=zGAY9TdjgR1WK_fOOJYnyFJMj+dvHUQ@mail.gmail.com>
Date: Wed, 23 Apr 2014 18:21:56 +0200
X-Google-Sender-Auth: 32iz17FHSVxROPNEtuKzmRoJlWM
Message-ID: <CANEZrP2FyCe68cqi4cpj=8EEr_7R+6TXuNZWtkgwkP2qwX1X4A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Christophe Biocca <christophe.biocca@gmail.com>
Content-Type: multipart/alternative; boundary=089e015388489c1e0004f7b821f7
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Wczvx-0003Ek-SK
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
Finney attacks
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 23 Apr 2014 16:22:08 -0000
--089e015388489c1e0004f7b821f7
Content-Type: text/plain; charset=UTF-8
I think the cost to mines is the same as what's possible today, actually.
Consider a group of miners who wish to do this with no changes to the rule
set. They can coordinate out of band and figure out if they have a majority
of hashpower behind the decision to orphan a block, e.g. by signing a nonce
with their coinbase keys. If they reach quorum, then they begin work on a
parallel chain. Because they have majority they are guaranteed to
eventually win, though depending on luck it may take a while. Because of
this, assuming the external quorum system is public, the moment consensus
is reached the other miners should all abandon the existing branch and
start work on the parallel chain too, lest they waste work mining on a
branch that is surely doomed.
The end result would be that the chain stops making progress, disrupting
end users and generally creating uncertainty as the new chain is forged.
Also, miners who built on top of the orphaned block end up being punished
even if they did nothing wrong. Both these side effects are undesirable and
unnecessary.
So the more I think about this scheme, the more it seems like a simple
improvement on the current status quo. Miners can do what they could
already do, but with a more reliable in-band signalling mechanism that
doesn't require things like coinbase keys to be online, and them doing so
does not disrupt existing users or waste energy.
--089e015388489c1e0004f7b821f7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">I think the cost to mines is th=
e same as what's possible today, actually.</div><div class=3D"gmail_ext=
ra"><br></div><div class=3D"gmail_extra">Consider a group of miners who wis=
h to do this with no changes to the rule set. They can coordinate out of ba=
nd and figure out if they have a majority of hashpower behind the decision =
to orphan a block, e.g. by signing a nonce with their coinbase keys. If the=
y reach quorum, then they begin work on a parallel chain. Because they have=
majority they are guaranteed to eventually win, though depending on luck i=
t may take a while. Because of this, assuming the external quorum system is=
public, the moment consensus is reached the other miners should all abando=
n the existing branch and start work on the parallel chain too, lest they w=
aste work mining on a branch that is surely doomed.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The end res=
ult would be that the chain stops making progress, disrupting end users and=
generally creating uncertainty as the new chain is forged. Also, miners wh=
o built on top of the orphaned block end up being punished even if they did=
nothing wrong. Both these side effects are undesirable and unnecessary.</d=
iv>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So the more=
I think about this scheme, the more it seems like a simple improvement on =
the current status quo. Miners can do what they could already do, but with =
a more reliable in-band signalling mechanism that doesn't require thing=
s like coinbase keys to be online, and them doing so does not disrupt exist=
ing users or waste energy.</div>
</div>
--089e015388489c1e0004f7b821f7--
|
