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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1R9J9Y-0006pm-3Y
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Sep 2011 16:08:04 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.161.47 as permitted sender)
client-ip=209.85.161.47; envelope-from=gavinandresen@gmail.com;
helo=mail-fx0-f47.google.com;
Received: from mail-fx0-f47.google.com ([209.85.161.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1R9J9X-0001iA-3m
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Sep 2011 16:08:04 +0000
Received: by fxi1 with SMTP id 1so2789036fxi.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 29 Sep 2011 09:07:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.5.76 with SMTP id 12mr16481639fau.103.1317312461766; Thu,
29 Sep 2011 09:07:41 -0700 (PDT)
Received: by 10.152.25.105 with HTTP; Thu, 29 Sep 2011 09:07:41 -0700 (PDT)
Date: Thu, 29 Sep 2011 12:07:41 -0400
Message-ID: <CABsx9T2QzafV-uzn7yL01gs2mrzLaP0FCgjt_O--Ldw+s-Xm9w@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
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
(gavinandresen[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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R9J9X-0001iA-3m
Subject: [Bitcoin-development] Multisignature transations
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: Thu, 29 Sep 2011 16:08:04 -0000
Design discussion: https://gist.github.com/39158239e36f6af69d6f
Pull request: https://github.com/bitcoin/bitcoin/pull/541
Initial support for multisignature transactions
This adds initial support for three new types of transactions:
(a and b)
(a or b)
(a and b) or c
... where a/b/c are keys. These new transaction types will enable
better wallet security and backup in future versions of bitcoin.
I've taken a conservative approach with this initial pull; the new
transaction types will be relayed and included in blocks, but are
ignored by the wallet code, so will not affect the balance and will
never be considered available to spend. I'm going to start a
discussion on bitcoin-dev to do a bit of a brain-dump on what NOT to
do with multi-signature transactions (there are several potential
attacks that we'll need to be careful to avoid).
I'll be creating a multisig_testing branch in the gavinandresen github
fork that WILL add multisig transactions to the balance, will have a
new RPC call to create multisig transactions, and will be able to
spend the multisig transactions; that will be for testing this PULL
only for now.
=======================
Here's the discussion of potential attacks that occurred to me while I
was working on this:
+ Attacker has an account and a funding address/key ("a") at a
shared-wallet service. Attacker also has their own address/key ("b").
+ They send 100 bitcoins that can be spent by (a or b). Note that the
shared-wallet service can't stop the attacker from doing that.
IF the shared-wallet service credits their account (because "a" can
spend the coins), then Bad Things might happen:
+ The shared-wallet service probably assumes that it controls all the
keys in its wallet, and the only time coins in its wallet will be
spent will be when it issues a send* RPC command. But the attacker can
spend using "b" anytime they like.
+ If the shared-wallet service allows importing of keys then the
attacker might be able to get double-credit by importing "b"
(depending on what the 'import private key' code does).
The pull I've submitted doesn't have any of those issues because
multisignature transactions are not credited / added to the wallet.
Going forward, I think the right thing to do is only add
multisignature transactions to the wallet's balance (and make them
available to spend) if the public half of ALL of the keys involved are
known to the wallet. The private half of the key may not be in the
wallet (maybe it is on another device or maybe it is a deterministic
backup master key protected by a passphrase), but the public key must
be known and in the wallet.
I'd really like to get this into the 0.5 release because it will
enable much better wallet security and backup in some future release
or alternative client (but these transaction types need to be relayed
and mined BEFORE then to make that possible).
--
--
Gavin Andresen
|
