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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1XavZv-0000Ds-5f
for bitcoin-development@lists.sourceforge.net;
Sun, 05 Oct 2014 23:51:03 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.171 as permitted sender)
client-ip=209.85.213.171; envelope-from=gmaxwell@gmail.com;
helo=mail-ig0-f171.google.com;
Received: from mail-ig0-f171.google.com ([209.85.213.171])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XavZu-0007zv-CA
for bitcoin-development@lists.sourceforge.net;
Sun, 05 Oct 2014 23:51:03 +0000
Received: by mail-ig0-f171.google.com with SMTP id h15so1758991igd.16
for <bitcoin-development@lists.sourceforge.net>;
Sun, 05 Oct 2014 16:50:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.51.17.66 with SMTP id gc2mr16929491igd.40.1412553056953;
Sun, 05 Oct 2014 16:50:56 -0700 (PDT)
Received: by 10.107.168.5 with HTTP; Sun, 5 Oct 2014 16:50:56 -0700 (PDT)
In-Reply-To: <CAAS2fgQ-MrmBGjcuqYdvfs0g2b6+vAOVR3sUCCyQy386CY8EDA@mail.gmail.com>
References: <5431CD8D.7050508@certimix.com>
<CAAS2fgQ-MrmBGjcuqYdvfs0g2b6+vAOVR3sUCCyQy386CY8EDA@mail.gmail.com>
Date: Sun, 5 Oct 2014 16:50:56 -0700
Message-ID: <CAAS2fgTXWznKYCcqAP_+CkaoGikL1sTnvPnf2WGHS=MbYGsw+w@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: 1XavZu-0007zv-CA
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:51:03 -0000
On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell <gmaxwell@gmail.com>
> I should point you to some of the tools that have been discussed in
> the past which are potentially helpful here:
Ah, I should also mention a somewhat more far out approach which helps
here as a side effect:
If transactions were using the BLS short signature scheme (a very
compact EC signature based on pairing cryptography) there is a scheme
so that you securely can aggregate the signatures from multiple
messages into a single signature (also has nice bandwidth properties)
and still verify it. It also works recursively, so aggregates can be
further aggregated.
A consequence of this is that you cannot remove a (set of)
signature(s) from the aggregate without knowing the (set of)
signature(s) by itself.
If the coinbase transaction also contains a signature and if some
non-trivial portion of fee paying users relayed their transaction
privately to miners it, then other miners would only learn of the
transaction in aggregated form. Without knowing the transaction by
itself they could not pull it out of a block separately from the
coinbase payment and add it to their own block in a fork.
(In general this provides several anti-censorship properties, since if
someone passed you an aggregate of several transactions you could only
accept or reject them as a group unless you knew the members
separately).
The use in aggregation can be done in a way which is purely additive
(e.g. in addition to regular DSA signatures), so even if the
cryptosystem is broken the only harm would be allowing
disaggregation... but unfortunately the pairing crypto is pretty slow
(verification takes a 0.5ms-ish pairing operation per transaction).
|
