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-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sergiolerner@certimix.com>) id 1Xb8EA-0007HT-Qc
for bitcoin-development@lists.sourceforge.net;
Mon, 06 Oct 2014 13:21:26 +0000
X-ACL-Warn:
Received: from p3plsmtpa12-06.prod.phx3.secureserver.net ([68.178.252.235])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Xb8E9-00011D-Lt for bitcoin-development@lists.sourceforge.net;
Mon, 06 Oct 2014 13:21:26 +0000
Received: from [192.168.0.23] ([201.231.95.129])
by p3plsmtpa12-06.prod.phx3.secureserver.net with
id zpMH1o00J2nUpUh01pMJNY; Mon, 06 Oct 2014 06:21:20 -0700
Message-ID: <5432974B.4000606@certimix.com>
Date: Mon, 06 Oct 2014 10:21:15 -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@lists.sourceforge.net
References: <5431CD8D.7050508@certimix.com>
<CAE28kUTBbT5_Jh-aP_rVkLYMSdY+XeQO39LFh+EFHqSp-wFXOQ@mail.gmail.com>
In-Reply-To: <CAE28kUTBbT5_Jh-aP_rVkLYMSdY+XeQO39LFh+EFHqSp-wFXOQ@mail.gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
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.235 listed in list.dnswl.org]
X-Headers-End: 1Xb8E9-00011D-Lt
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 13:21:27 -0000
Comments between lines...
On 06/10/2014 03:42 a.m., Alex Mizrahi wrote:
> .....
>
> 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.
The problem with this approach is that once the bitcoind has been
modified to allow this sharing of the high-tx fee by delegation, then
the same system can be used for an attack.
Let's call a system that makes the Optimum Rational Best-chain Selection
for maximizing profit "ORBS", just to give it a name. The system assures
that the best chain chosen is always the optimum in terms of profit,
taking into account fee delegation and all the game-theoretic incentives
derived. It's only a theoretical abstraction, but could be approximated
in practice.
The attack is called Chained Kickback DOuble-spend attack (or “CHAKIDO”)
and is an extension of Bonneau's kickback attack. Basically the attack
is to create the ORBS patch, and start convincing miners to use it,
sending some probe high-fees tx.
Once you have ORBS working in a majority of the mining nodes, you can
perform a double-spend against a target like an exchange by:
- Buy some btc X
- Send those btc to an exchange (suppose the exchange requires 6
confirmations) in a transaction TX
- Immediately convert those btc to an alt-coin, and collect the alt-coins
- Create a high fee tx that is a double-spend of TX having a high fee Y
such that Y < X but Y triggers a ORBS reorganization.
- Profit
(This rollback attack was performed against whitecoin, I think)
This attack gets terrible powerful if there is no subsidy. You may need
500 blocks of confirmation to protect from a 10 BTC spend with current
fees and no subsidy. This is because once 100% of the nodes use ORBS,
the fee delegation is linear (it doesn't grow exponentially with the
number of blocks). So ORBS should never be implemented without
additional protective measures in merchant applications.
If we had a closed formula for ORBS, then all merchants could compute
the minimum confirmation blocks such that always Y > X, but such formula
involves many unknowns which would need to be dynamically estimated, and
also it should take into account the number of simultaneous payment
attempts.
My conclusions are:
- We should never allow ORBS to be implemented unless merchants are also
aware of it. If are aware of ORBS then Bitcoin with no subsidy will be
become a terrible slow payment system so ...
- We could implement the protections that work even if some nodes
implement ORBS, such as fee and burn btc sharing, as I described before
- Or we need some high percentage of miners to be irrational, to force
ORBS fee delegation have an exponential decay.
Best regards,
Sergio.
|
