summaryrefslogtreecommitdiff
path: root/ce/87e7f3c9d89f0425806b44fad12a3a6c8a87b2
blob: e1c113bb86f66f33265ae33d36f93cc5c6f98519 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <drak@zikula.org>) id 1WN4Am-0006MZ-CQ
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Mar 2014 17:39:32 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of zikula.org
	designates 74.125.82.42 as permitted sender)
	client-ip=74.125.82.42; envelope-from=drak@zikula.org;
	helo=mail-wg0-f42.google.com; 
Received: from mail-wg0-f42.google.com ([74.125.82.42])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WN4Aj-0002hA-IX
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Mar 2014 17:39:32 +0000
Received: by mail-wg0-f42.google.com with SMTP id y10so9053342wgg.25
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 10 Mar 2014 10:39:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to
	:content-type;
	bh=kDOSnLjJuAoiCqxj9+P2AG1eJGbA1NAf0B5c0ckYhxc=;
	b=citDDcKJZEiThyCoO5kMub7pvReQAPYKgXh3Q5/3uPmfyuc82E38oT7/FxNrlHf8cC
	VXai4Ci5WGqIh1cqKqBa//GZRyIMxuulTgV7vevHld8lsIjDQ7XHSPDQ3UuNuBdD2BGq
	zD8M621ebYqwbpAGM+pUwNHkccCAZUTq6FC0WZ8ZoKxE+tf1cij49Ycx/6rbggf7XycO
	AvR29bqzAZ5NW/PfIMleKI+Yn4tEEMPjwHZJCXEPIC5zL+OOsFjRKlXZTi/Enta1Kfqw
	Xdi/g/sXSTQDdLY7Qnj1QFdPd1aVrTXZbKo9d74dCn9jMMtFkVl6u0ARQL84XHuUGPjp
	Fn2w==
X-Gm-Message-State: ALoCoQl5n8UWXh08TvSKPIZDcJ3jYhrXdv+UHDADtfUUObJXJqp18ddiEBoRL3kjLXrpGSypOttd
X-Received: by 10.194.82.35 with SMTP id f3mr32655367wjy.36.1394473163258;
	Mon, 10 Mar 2014 10:39:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.205.69 with HTTP; Mon, 10 Mar 2014 10:39:03 -0700 (PDT)
From: Drak <drak@zikula.org>
Date: Mon, 10 Mar 2014 17:39:03 +0000
Message-ID: <CANAnSg3Bt0e7CfUcJXe96xhU6nqif9ey_vurZMZkSa9OHjHStw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7bf0c1068b967704f4441513
X-Spam-Score: -0.5 (/)
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 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1WN4Aj-0002hA-IX
Subject: [Bitcoin-development] Multisign payment protocol?
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, 10 Mar 2014 17:39:32 -0000

--047d7bf0c1068b967704f4441513
Content-Type: text/plain; charset=UTF-8

I was wondering if there would be merit in a kind of BIP for a payment
protocol using multisig?

Currently, setting up a multisig is quite a feat. Users have to exchange
public keys, work out how to get the public keys from their addresses. If
one of the parties are not savvy enough, an malicious party could easily be
setup that was 2 of 3 instead of 2 of 2 where the malicious party generates
the multisig address+script and thus be able to run off with funds anyway.

It's also terribly complex to generate and keep track of. There's been a
nice attempt at creating an browser interface at coinb.in/multisig but it
still lacks the kind of ease with created by the payment protocol. If there
was a BIP then it would go a long way to aiding future usability of
multisig wallet implementations.

What are your thoughts?

Drak

--047d7bf0c1068b967704f4441513
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I was wondering if there would be merit in a kind of BIP f=
or a payment protocol using multisig?<div><br><div>Currently, setting up a =
multisig is quite a feat. Users have to exchange public keys, work out how =
to get the public keys from their addresses. If one of the parties are not =
savvy enough, an malicious party could easily be setup that was 2 of 3 inst=
ead of 2 of 2 where the malicious party generates the multisig address+scri=
pt and thus be able to run off with funds anyway.</div>

<div><br></div><div>It&#39;s also terribly complex to generate and keep tra=
ck of. There&#39;s been a nice attempt at creating an browser interface at =
<a href=3D"http://coinb.in/multisig">coinb.in/multisig</a> but it still lac=
ks the kind of ease with created by the payment protocol. If there was a BI=
P then it would go a long way to aiding future usability of multisig wallet=
 implementations.</div>

<div><br></div><div>What are your thoughts?</div><div><br></div><div>Drak</=
div></div></div>

--047d7bf0c1068b967704f4441513--