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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1XavQ4-0008Hu-KD
for bitcoin-development@lists.sourceforge.net;
Sun, 05 Oct 2014 23:40:52 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.173 as permitted sender)
client-ip=209.85.213.173; envelope-from=gmaxwell@gmail.com;
helo=mail-ig0-f173.google.com;
Received: from mail-ig0-f173.google.com ([209.85.213.173])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XavQ1-0002rQ-A0
for bitcoin-development@lists.sourceforge.net;
Sun, 05 Oct 2014 23:40:52 +0000
Received: by mail-ig0-f173.google.com with SMTP id h18so1773062igc.0
for <bitcoin-development@lists.sourceforge.net>;
Sun, 05 Oct 2014 16:40:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.84.198 with SMTP id n6mr114334icl.73.1412552443934; Sun,
05 Oct 2014 16:40:43 -0700 (PDT)
Received: by 10.107.168.5 with HTTP; Sun, 5 Oct 2014 16:40:43 -0700 (PDT)
In-Reply-To: <5431CD8D.7050508@certimix.com>
References: <5431CD8D.7050508@certimix.com>
Date: Sun, 5 Oct 2014 16:40:43 -0700
Message-ID: <CAAS2fgQ-MrmBGjcuqYdvfs0g2b6+vAOVR3sUCCyQy386CY8EDA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Sergio Lerner <sergiolerner@certimix.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1XavQ1-0002rQ-A0
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
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: Sun, 05 Oct 2014 23:40:52 -0000
On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner <sergiolerner@certimix.com> wrote:
> I would like to share with you a vulnerability in the Bitcoin protocol I've
> been thinking of which might have impact on the future of Bitcoin. Please
> criticize it!
> The Freeze on Transaction Problem
I should point you to some of the tools that have been discussed in
the past which are potentially helpful here:
The first is the use of locktime on normal transactions. This
behavior is already in Bitcoin core git: The idea is that users of
the system should locktime their transaction at a point as high as
they expect it to get included. If used well this means that there
should always be a base of fees which can only be collected by future
blocks, creating an incentive to move forward. This may be
particularly effective if the limitations on blocksize mean that there
is always a healthy standing load.
The second is having block commitments in transactions
(https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas). The idea is that
the data under signature in a transaction could commit to some recent
block which _must_ be in the chain or the transaction's fee cannot be
collected (or, at least, not all of the fee). This would allow
transacting users to 'vote with their fees' on the honest chain.
Arguably this could also be used to pay for doublespending forks, but
you can already do that by paying fees via a chain that stems from the
doublespend. This greatly complicates strategy for forking miners,
since future transactions which you haven't even seen yet may have
fees conditional on the honest chain.
I think both of the above are obviously useful, should be done, but
don't completely address the concern, they may be adequate.
The third is fee forwarding. An example form would be that the miner
gets half the fees, the rest are added to a pool which pays out half
in every successive block. This can prevent unusually high fees from
making as much reorg pressure and more correctly models what people
would like to pay for: getting their txn buried. The huge problem
with this class is that miners can demand users pay fees "out of
band", e.g. with additional txouts (just make a different version of
the tx for each miner you wish to pay) and escape the process. I have
had some notions about fees that come in the form of adjusting the
difficulty of creating a block slightly (which is something that can't
be paid out of band), but such schemes becomes very complicated very
fast. I am unsure if any form of fee forwarding is workable.
Something you might want to try to formalize in your analysis is the
proportion of the network which is "rational" vs
"honest"/"altruistic". Intuitively, if there is a significant amount
of honest hashrate which is refusing to aid the greedy behavior even
at a potential loss to themselves this strategy becomes a loser even
for the purely greedy participants. It would be interesting to
characterize the income tradeoffs for different amounts of altruism,
or whatever convergence problems an attempt by altruistic
participaints to punish the forkers might create.
|
