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
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1WNZ1U-000055-7z
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 02:36:00 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.180 as permitted sender)
client-ip=209.85.216.180; envelope-from=etotheipi@gmail.com;
helo=mail-qc0-f180.google.com;
Received: from mail-qc0-f180.google.com ([209.85.216.180])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WNZ1T-00035U-4P
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 02:36:00 +0000
Received: by mail-qc0-f180.google.com with SMTP id x3so10608196qcv.39
for <bitcoin-development@lists.sourceforge.net>;
Tue, 11 Mar 2014 19:35:53 -0700 (PDT)
X-Received: by 10.140.107.10 with SMTP id g10mr46735076qgf.63.1394591753692;
Tue, 11 Mar 2014 19:35:53 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPSA id u1sm73949573qac.1.2014.03.11.19.35.52
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 11 Mar 2014 19:35:53 -0700 (PDT)
Message-ID: <531FC808.7060709@gmail.com>
Date: Tue, 11 Mar 2014 22:35:52 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CANAnSg3Bt0e7CfUcJXe96xhU6nqif9ey_vurZMZkSa9OHjHStw@mail.gmail.com> <CABsx9T0SMi6Gp4JY=CpHxLEu5pVkvDmnug7PsY7m_dvtT7khzg@mail.gmail.com> <531DFDF8.80008@gmail.com> <531E52FE.5090107@jerviss.org> <531E5454.1030601@gmail.com> <CAJHLa0NZkzQQvMxgCJAJGT=Yn6vrVNK8Bg7RAfAjctpnrfg5zA@mail.gmail.com> <CABsx9T3eViYDsEmLm7ceimJNwci3mCOxWoVnVZHrqp7pDmm0+g@mail.gmail.com> <CANAnSg2kzPF0886PsQW8chzsWi6Urp+=-x+9bbv8Mv6hmpvBPw@mail.gmail.com> <CAJHLa0Mu2kiv3CCme7BPwzWtT++PNLQ2aAKdLyA8LFTtXEg9fg@mail.gmail.com> <CABsx9T0Lvg84qFVRbc7Ef4vZEQj9eO7Jhup5PTRLLeuJFvXi-w@mail.gmail.com> <4fca6b510dd57d2f92affeb988d2ee5d.squirrel@fulvetta.riseup.net>
<531FAA55.2020108@xeno-genesis.com>
In-Reply-To: <531FAA55.2020108@xeno-genesis.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative;
boundary="------------040503000302020300020300"
X-Spam-Score: -0.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
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1WNZ1T-00035U-4P
Subject: Re: [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: Wed, 12 Mar 2014 02:36:00 -0000
This is a multi-part message in MIME format.
--------------040503000302020300020300
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
I might as well throw in a word about Armory. After our next release in
a couple weeks, we will be going full-speed at new wallets and BIP32
integration. Just like Jean-Pierre mentioned, we'll be using parallel
trees to generate P2SH addresses after sorting the keys
lexicographically. We plan to introduce the concept of a wallet
"bundle" (that name is far from concrete... I'd love a better word).
All wallets in a bundle are protected by the same backup, and stored in
the same file. The default behavior will be use new branches in the
same BIP32 tree when a user creates a new "wallet", though we will allow
multiple bundles in advanced and expert usermode (which is needed to
have watching-only wallets from a different seed created from an offline
computer).
However, we do plan to allow separate parties to create
multisig-intended wallets with public parts that can be exported and
combined with other users. We feel this is critical, as it allows for
linked wallets in which there was never a single-point of failure from
key-generation to signing. This is especially important for contexts
where employees may be handling a company's Bitcoins wallets.
On this topic, I have gotten a lot of inquiries into BIP 38 and 39. I
was not clear whether those BIPs were worth prioritizing ... i.e. is
there a general consensus from a variety of wallet developers that they
should be supported? Rather, I'm happy to start prioritizing them if
others do too, but I haven't spent much time trying to understand them
to even know if they're mature, yet.
-Alan
On 03/11/2014 08:29 PM, Jean-Pierre Rupp wrote:
> Hello people,
>
> We are working on some of this stuff. We had some very early draft on
> how we envisioned multisig happening. It is all implemented in Haskoin
> available as multiple repositories in Github. I am happy to see this
> gathering momentum.
>
> Our multisig system uses BIP-0032 HD wallets, and there will soon be
> BIP-0039 support for keys compatibility.
>
> Our wallet uses synced trees rooted at the extended pubkeys of the
> participants. Currently we are sorting public keys in the scripts to
> avoid ambiguity.
>
> Download haskoin-wallet:
>
> cabal install haskoin-wallet
>
> Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to
> bring transactions into the wallet. You must initialize first with a
> seed and create an account. It supports both regular and multisig accounts.
>
> Perhaps this can lead to interesting discussions on key exchange, and
> the appropriate handling of wallet metadata. I?d love to work on a
> proper standard that could lead us to compatible implementations.
>
> This document explains how we do it now:
>
> http://haskoin.com/~xeno/hd-multisig-wallet.html
>
> Cheers!
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------040503000302020300020300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I might as well throw in a word about Armory. After our next
release in a couple weeks, we will be going full-speed at new
wallets and BIP32 integration. Just like Jean-Pierre mentioned,
we'll be using parallel trees to generate P2SH addresses after
sorting the keys lexicographically. We plan to introduce the
concept of a wallet "bundle" (that name is far from concrete... I'd
love a better word). All wallets in a bundle are protected by the
same backup, and stored in the same file. The default behavior will
be use new branches in the same BIP32 tree when a user creates a new
"wallet", though we will allow multiple bundles in advanced and
expert usermode (which is needed to have watching-only wallets from
a different seed created from an offline computer).<br>
<br>
However, we do plan to allow separate parties to create
multisig-intended wallets with public parts that can be exported and
combined with other users. We feel this is critical, as it allows
for linked wallets in which there was never a single-point of
failure from key-generation to signing. This is especially
important for contexts where employees may be handling a company's
Bitcoins wallets.<br>
<br>
On this topic, I have gotten a lot of inquiries into BIP 38 and 39.
I was not clear whether those BIPs were worth prioritizing ... i.e.
is there a general consensus from a variety of wallet developers
that they should be supported? Rather, I'm happy to start
prioritizing them if others do too, but I haven't spent much time
trying to understand them to even know if they're mature, yet.<br>
<br>
-Alan<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/11/2014 08:29 PM, Jean-Pierre
Rupp wrote:<br>
</div>
<blockquote cite="mid:531FAA55.2020108@xeno-genesis.com" type="cite">
<pre wrap="">Hello people,
We are working on some of this stuff. We had some very early draft on
how we envisioned multisig happening. It is all implemented in Haskoin
available as multiple repositories in Github. I am happy to see this
gathering momentum.
Our multisig system uses BIP-0032 HD wallets, and there will soon be
BIP-0039 support for keys compatibility.
Our wallet uses synced trees rooted at the extended pubkeys of the
participants. Currently we are sorting public keys in the scripts to
avoid ambiguity.
Download haskoin-wallet:
cabal install haskoin-wallet
Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to
bring transactions into the wallet. You must initialize first with a
seed and create an account. It supports both regular and multisig accounts.
Perhaps this can lead to interesting discussions on key exchange, and
the appropriate handling of wallet metadata. I’d love to work on a
proper standard that could lead us to compatible implementations.
This document explains how we do it now:
<a class="moz-txt-link-freetext" href="http://haskoin.com/~xeno/hd-multisig-wallet.html">http://haskoin.com/~xeno/hd-multisig-wallet.html</a>
Cheers!
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/13534_NeoTech">http://p.sf.net/sfu/13534_NeoTech</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------040503000302020300020300--
|
