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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1Xb20O-0004SC-20
for bitcoin-development@lists.sourceforge.net;
Mon, 06 Oct 2014 06:42:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.52 as permitted sender)
client-ip=74.125.82.52; envelope-from=alex.mizrahi@gmail.com;
helo=mail-wg0-f52.google.com;
Received: from mail-wg0-f52.google.com ([74.125.82.52])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Xb20N-0000Dj-4C
for bitcoin-development@lists.sourceforge.net;
Mon, 06 Oct 2014 06:42:48 +0000
Received: by mail-wg0-f52.google.com with SMTP id a1so5656845wgh.23
for <bitcoin-development@lists.sourceforge.net>;
Sun, 05 Oct 2014 23:42:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.90.71 with SMTP id bu7mr16581217wib.33.1412577760825;
Sun, 05 Oct 2014 23:42:40 -0700 (PDT)
Received: by 10.27.175.95 with HTTP; Sun, 5 Oct 2014 23:42:40 -0700 (PDT)
In-Reply-To: <5431CD8D.7050508@certimix.com>
References: <5431CD8D.7050508@certimix.com>
Date: Mon, 6 Oct 2014 09:42:40 +0300
Message-ID: <CAE28kUTBbT5_Jh-aP_rVkLYMSdY+XeQO39LFh+EFHqSp-wFXOQ@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=f46d043be0f4a6d5d00504bb63c4
X-Spam-Score: -0.6 (/)
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
(alex.mizrahi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Xb20N-0000Dj-4C
Subject: Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack
(FRONT)
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: Mon, 06 Oct 2014 06:42:48 -0000
--f46d043be0f4a6d5d00504bb63c4
Content-Type: text/plain; charset=UTF-8
I've heard about this idea from TierNolan. Here's some quick an dirty
analysis:
Suppose the last known block claimed a large tx fee of L. A miner who owns
1/N of the total hashrate needs to choose between two strategies:
1. Mine on top of that block and win usual reward R with probability 1/N.
2. Mine on top of the previous block, trying to make two blocks in a row,
might get reward L with probability 1/N^2.
Thus for the first strategy expected payoff is R/N, and for the second the
expected pay-off is L/N^2.
Second strategy is viable if R/N < L/N^2,
R < L/N.
Now suppose the miner who claimed the unusually large reward will share it
with the next miner, for example, using coinbase output with OP_TRUE. If
that shared reward Rs is higher than L/N^2, then the next miner will be
better off mining on top of that block.
This doesn't require protocol changes(*) and can be simply incorporated
into a piece of code which decides what to do when a transaction with
unusually large fee appears. (I.e. it will automatically share the fee, and
others will recognize that). And if the biggest miner has 25% of all
hashrate, sharing 25% of your loot doesn't sound that bad.
(*) Except one problem: coinbase maturity rules won't allow one to share
the fee with the next miner.
So some protocol changes are required. But changes which affect coinbase
maturity and sharing are probably going to be simpler and smaller than what
Sergio have proposed.
--f46d043be0f4a6d5d00504bb63c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">I've heard about this idea =
from TierNolan. Here's some quick an dirty analysis:</div><div class=3D=
"gmail_extra"><br></div><div class=3D"gmail_extra">Suppose the last known b=
lock claimed a large tx fee of L. A miner who owns 1/N of the total hashrat=
e needs to choose between two strategies:</div><div class=3D"gmail_extra"><=
br></div><div class=3D"gmail_extra">1. Mine on top of that block and win us=
ual reward R with probability 1/N.</div><div class=3D"gmail_extra">2. Mine =
on top of the previous block, trying to make two blocks in a row, might get=
reward L with probability 1/N^2.</div><div class=3D"gmail_extra"><br></div=
><div class=3D"gmail_extra">Thus for the first strategy expected payoff is =
R/N, and for the second the expected pay-off is L/N^2.</div><div class=3D"g=
mail_extra"><br></div><div class=3D"gmail_extra">Second strategy is viable =
if R/N < L/N^2,</div><div class=3D"gmail_extra">=C2=A0R < L/N.</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Now suppose =
the miner who claimed the unusually large reward will share it with the nex=
t miner, for example, using coinbase output with OP_TRUE. If that shared re=
ward Rs is higher than L/N^2, then the next miner will be better off mining=
on top of that block.=C2=A0<br></div><div class=3D"gmail_extra"><br></div>=
<div class=3D"gmail_extra">This doesn't require protocol changes(*) and=
can be simply incorporated into a piece of code which decides what to do w=
hen a transaction with unusually large fee appears. (I.e. it will automatic=
ally share the fee, and others will recognize that). And if the biggest min=
er has 25% of all hashrate, sharing 25% of your loot doesn't sound that=
bad.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
(*) Except one problem: coinbase maturity rules won't allow one to shar=
e the fee with the next miner.</div><div class=3D"gmail_extra">So some prot=
ocol changes are required. But changes which affect coinbase maturity and s=
haring are probably going to be simpler and smaller than what Sergio have p=
roposed.</div><div class=3D"gmail_extra"><br></div></div>
--f46d043be0f4a6d5d00504bb63c4--
|
