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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sergiolerner@certimix.com>) id 1Xba42-0005dZ-5v
for bitcoin-development@lists.sourceforge.net;
Tue, 07 Oct 2014 19:04:50 +0000
X-ACL-Warn:
Received: from p3plsmtpa11-08.prod.phx3.secureserver.net ([68.178.252.109])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Xba41-0002q7-3b for bitcoin-development@lists.sourceforge.net;
Tue, 07 Oct 2014 19:04:50 +0000
Received: from [192.168.0.23] ([201.231.95.129])
by p3plsmtpa11-08.prod.phx3.secureserver.net with
id 0K4h1p00B2nUpUh01K4iE1; Tue, 07 Oct 2014 12:04:43 -0700
Message-ID: <54343948.1030400@certimix.com>
Date: Tue, 07 Oct 2014 16:04:40 -0300
From: Sergio Lerner <sergiolerner@certimix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
References: <543438E4.8080501@certimix.com>
In-Reply-To: <543438E4.8080501@certimix.com>
X-Enigmail-Version: 1.4.6
X-Forwarded-Message-Id: <543438E4.8080501@certimix.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [68.178.252.109 listed in list.dnswl.org]
X-Headers-End: 1Xba41-0002q7-3b
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: Tue, 07 Oct 2014 19:04:50 -0000
On 06/10/2014 08:43 p.m., Tom Harding wrote:
> On 10/5/2014 4:00 PM, Sergio Lerner wrote:
>> If everyone acts rationally in his own interest, then the best choice
>> for the remaining miners is to try to mine a competing block at the
>> same height n including the high-fee transaction, to collect the fee
>> for themselves.
>
> Sergio --
>
> Just some thoughts on your interesting problem.
>
>
> Since everybody but M10 is on equal footing, I would expect M10 to
> have some fixed advantage depending on assumptions, and the bigger the
> advantage, the shorter the "freeze time".
>
Yes, that's how simulation works. The problem is that the existence of
high-fee delays the decision to switch to M10. Since the network is
moving slower (because of fragmentation) the effect of the high-fee is
twofold: it delays the convergence because it promotes selfishness and
it delays convergence because it promotes fragmentation.
During that time window where the network is frozen, any other high-fee
transaction only makes things worse. This is a very rare example where
a well distributed network (100 miners having 1% each) is much much
worse than 3 miners having 33% each.
Using the my previous terminology, automatic fee-sharing ("ORBS") is a
solution to the freeze problem ("FRONT") but opens the windows to
"CHAKIDO" double-spending. and CHAKIDO double-spending is a much worse
problem than FRONT.
But as Tamas pointed out, sooner or later someone will implement
something like ORBS, get over the critical mass of miner adoption, and
then the CHAKIDO problem will be inevitable.
The only clean solution to this problem is the DECOR+ protocol, which
shares block-rewards by including "uncles" (as GHOST does) and splitting
the reward between all miners at the same height until coinbase maturity
is over. This way the best choice is always cooperative.
PS: Using so many acronyms makes arguments much more concise, but
suggest we should have all the attack terminology described in a single
"Bitcoin Security Wiki"...
|
