From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WNZDW-0000eH-Fm for bitcoin-development@lists.sourceforge.net; Wed, 12 Mar 2014 02:48:26 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.173 as permitted sender) client-ip=209.85.192.173; envelope-from=elombrozo@gmail.com; helo=mail-pd0-f173.google.com; Received: from mail-pd0-f173.google.com ([209.85.192.173]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WNZDU-0005B6-Uk for bitcoin-development@lists.sourceforge.net; Wed, 12 Mar 2014 02:48:26 +0000 Received: by mail-pd0-f173.google.com with SMTP id z10so426748pdj.4 for ; Tue, 11 Mar 2014 19:48:19 -0700 (PDT) X-Received: by 10.68.218.3 with SMTP id pc3mr1824235pbc.71.1394592499110; Tue, 11 Mar 2014 19:48:19 -0700 (PDT) Received: from [192.168.1.107] (cpe-76-88-33-166.san.res.rr.com. [76.88.33.166]) by mx.google.com with ESMTPSA id vb7sm2019263pbc.13.2014.03.11.19.48.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Mar 2014 19:48:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_55900BF5-A5DF-4933-87CA-D9C41B1FED3B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Eric Lombrozo In-Reply-To: <531FC808.7060709@gmail.com> Date: Tue, 11 Mar 2014 19:48:13 -0700 Message-Id: <9A6499BC-E546-45CC-A7EF-5182FC86052D@gmail.com> References: <531DFDF8.80008@gmail.com> <531E52FE.5090107@jerviss.org> <531E5454.1030601@gmail.com> <4fca6b510dd57d2f92affeb988d2ee5d.squirrel@fulvetta.riseup.net> <531FAA55.2020108@xeno-genesis.com> <531FC808.7060709@gmail.com> To: Alan Reiner X-Mailer: Apple Mail (2.1510) X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.192.173 listed in list.dnswl.org] -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 (elombrozo[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: 1WNZDU-0005B6-Uk Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Multisign payment protocol? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 02:48:26 -0000 --Apple-Mail=_55900BF5-A5DF-4933-87CA-D9C41B1FED3B Content-Type: multipart/alternative; boundary="Apple-Mail=_1511D332-608E-42BF-8F01-B6B2450979F9" --Apple-Mail=_1511D332-608E-42BF-8F01-B6B2450979F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ciphrex CoinVault (https://ciphrex.com) is currently using parallel = trees with lexicographic sorting of keys. CoinVault is also using a partially signed transaction format whereby = 0-length placeholders are used for missing signatures in the transaction = scripts. Once all the required signatures to satisfy the policy are = present, the remaining zero-length placeholders are removed so the = transaction can be broadcast to the network. These partially signed = transactions can be shared with other parties to an account or other = signing devices for the purpose of requesting additional signatures. -Eric On Mar 11, 2014, at 7:35 PM, Alan Reiner wrote: > 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). >=20 > 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. >=20 > 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. >=20 > -Alan >=20 >=20 > On 03/11/2014 08:29 PM, Jean-Pierre Rupp wrote: >> Hello people, >>=20 >> 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. >>=20 >> Our multisig system uses BIP-0032 HD wallets, and there will soon be >> BIP-0039 support for keys compatibility. >>=20 >> 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. >>=20 >> Download haskoin-wallet: >>=20 >> cabal install haskoin-wallet >>=20 >> 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. >>=20 >> Perhaps this can lead to interesting discussions on key exchange, and >> the appropriate handling of wallet metadata. I=92d love to work on a >> proper standard that could lead us to compatible implementations. >>=20 >> This document explains how we do it now: >>=20 >> http://haskoin.com/~xeno/hd-multisig-wallet.html >>=20 >> Cheers! >>=20 >>=20 >>=20 >> = --------------------------------------------------------------------------= ---- >> 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 >>=20 >>=20 >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 > = --------------------------------------------------------------------------= ---- > 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 --Apple-Mail=_1511D332-608E-42BF-8F01-B6B2450979F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 https://ciphrex.com) is currently using = parallel trees with lexicographic sorting of = keys.

CoinVault is also using a partially signed = transaction format whereby 0-length placeholders are used for missing = signatures in the transaction scripts. Once all the required signatures = to satisfy the policy are present, the remaining zero-length = placeholders are removed so the transaction can be broadcast to the = network. These partially signed transactions can be shared with other = parties to an account or other signing devices for the purpose of = requesting additional = signatures.

-Eric


On Mar 11, 2014, at 7:35 PM, Alan Reiner <etotheipi@gmail.com> = wrote:

=20 =20
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=92d love to work on a
proper standard that could lead us to compatible implementations.

This document explains how we do it now:

http://haskoin.c=
om/~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_NeoTe=
ch


_______________________________________________
Bitcoin-development mailing list
Bitcoin-developm=
ent@lists.sourceforge.net
=
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

= --------------------------------------------------------------------------= ----
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.sourcef= orge.net/lists/listinfo/bitcoin-development

= --Apple-Mail=_1511D332-608E-42BF-8F01-B6B2450979F9-- --Apple-Mail=_55900BF5-A5DF-4933-87CA-D9C41B1FED3B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJTH8rtAAoJEAA1EyJsW9n+S9IP/25ZWAx+Iz3/5tu4Sngfh7fK c5q3b/PXAlmFcQ54dN31+E/j58LwHt1KYx6a4QHoNJll7T5Z4Jj62z1HxR3YRCEn GijHzvY1zP11qIfg7LdIFVqtJegRGx/s+xLd6upfIeRMnB+6UJe1aGKQava23Em7 v8KyE0NQTtNEaActdoP1bTycVjY7pFVSg+03WghXENoK+cQvh9jIrIyMNEPjYmEN Y/mNKPqT6v2SnmAXpZTDWCBsZVhuRkm4Zcifol7qBSies41gMRNtHzAcFXJMVU6H CDxLroT9jB/IO4Fc7nBR3l8PhmPk4wf6F3+XPSl6phTdq8g9joLmOG+T/xe8s0rd 2/LIX4IO06lnc4yQ/tiEbAIqq2jfAvKvLy42UY44KM67xVvr349Or2BptzFIoG42 bsjnL00Yk0LDP1TUQEPomoQ5iXfNtISisHPUHtn6Qkol19EEHWCgEeKOUIzGJqmF YwyYBxbXrjHqR4SiR98nzUa3CWEYh1z5Q5aL5Jq9OnVHxw73+543jbDHgXCXxdRN rwfCX1SAMMumMOZ4ziewvX0dt2hEU1kIbTagz3T+VPXvBozUqF05nsz/ul1cBv2T ZWQUyQ/03W4sDNGt4IWNbOvmTXrXIWaxOgxQepWLC21GPTnRP2shhYKPQICSwFj+ hx2prlqHaQgZtlc/Ti6v =8BO/ -----END PGP SIGNATURE----- --Apple-Mail=_55900BF5-A5DF-4933-87CA-D9C41B1FED3B--