+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.&nbsp; After our next

+ release in a couple weeks, we will be going full-speed at new

+ wallets and BIP32 integration.&nbsp; Just like Jean-Pierre mentioned,

+ we'll be using parallel trees to generate P2SH addresses after

+ sorting the keys lexicographically.&nbsp; We plan to introduce the

+ concept of a wallet "bundle" (that name is far from concrete... I'd

+ love a better word).&nbsp; All wallets in a bundle are protected by the

+ same backup, and stored in the same file.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp;

+ 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?&nbsp; 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&#146;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--

+

+