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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1RuR60-0000sX-CV
for bitcoin-development@lists.sourceforge.net;
Mon, 06 Feb 2012 16:07:12 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=gavinandresen@gmail.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RuR5u-0001Dv-Vk
for bitcoin-development@lists.sourceforge.net;
Mon, 06 Feb 2012 16:07:12 +0000
Received: by wibhq7 with SMTP id hq7so6355386wib.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 06 Feb 2012 08:07:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.107.34 with SMTP id gz2mr28007249wib.21.1328544420838;
Mon, 06 Feb 2012 08:07:00 -0800 (PST)
Received: by 10.223.112.199 with HTTP; Mon, 6 Feb 2012 08:07:00 -0800 (PST)
Date: Mon, 6 Feb 2012 11:07:00 -0500
Message-ID: <CABsx9T09h4EQ=3BFyu-7k9D_t1ryWoC5go4yu4xwsaob9ciK6Q@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.0 T_FRT_ADULT2 BODY: ReplaceTags: Adult
-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: 1RuR5u-0001Dv-Vk
Subject: [Bitcoin-development] Multisignature transaction support in the GUI
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 Feb 2012 16:07:12 -0000
I've been testing how the Bitcoin-Qt GUI deals with multisignature transactions.
The good news is it seems to display them just fine; even my
insanely-messy test wallets look reasonable.
It does not support sending multisig/BIP16 transactions, which is
definitely a feature for the main network (we don't want users sending
them until they will get relayed, get mined, AND will be fully
verified by a large super-majority of miners).
But... to encourage more testing it might make sense to enable sending
multisig transactions in the GUI if (fTestNet).
So I see two possible paths:
1) Leave the GUI as-is; require multisig testing to use the RPC interface.
Note: the RPC call that make multisig sends possible
(addmultisigaddress) is disabled for the main network for the 0.6
release.
Don't start rolling out GUI support until the next (0.7?) release cycle.
2) Start implementing multisig support in the GUI during the 0.6
release process, enabled only for test network. This could be as
simple as allowing the 35-character BIP16 multisig addresses in the
'send' dialog, to as complicated as adding/extending dialogs that let
you create multisig addresses to add to your address book.
Advantage of (1) is it should mean 0.6 gets to final release faster.
Advantage of (2) is it should mean more testing of multisig, and fewer
bug reports of "I added a multisig address via RPC but I can't send to
it using the GUI"
My opinion: I think it is worth allowing send-to-multisig-address via
the GUI (should be a very simple change to the address validation
logic). But creating multisig addresses via the GUI should wait until
the next release.
--
--
Gavin Andresen
|
