From: Eric Lombrozo <elombrozo@gmail•com>
To: Alan Reiner <etotheipi@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Multisign payment protocol?
Date: Tue, 11 Mar 2014 19:48:13 -0700 [thread overview]
Message-ID: <9A6499BC-E546-45CC-A7EF-5182FC86052D@gmail.com> (raw)
In-Reply-To: <531FC808.7060709@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4762 bytes --]
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 <etotheipi@gmail•com> 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).
>
> 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
>
> ------------------------------------------------------------------------------
> 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
[-- Attachment #1.2: Type: text/html, Size: 6292 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2014-03-12 2:48 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 17:39 Drak
2014-03-10 17:49 ` Gavin Andresen
2014-03-10 18:01 ` Alan Reiner
2014-03-11 0:04 ` kjj
2014-03-11 0:09 ` Alan Reiner
2014-03-11 0:14 ` Jeff Garzik
2014-03-11 1:15 ` Gavin Andresen
2014-03-11 11:43 ` Drak
2014-03-11 12:38 ` Jeff Garzik
2014-03-11 13:51 ` Gavin Andresen
2014-03-11 14:13 ` Jeff Garzik
2014-03-11 14:23 ` Gavin Andresen
2014-03-11 14:34 ` Jeff Garzik
2014-03-11 14:44 ` Jeff Garzik
2014-03-11 14:53 ` Gary Rowe
2014-03-11 15:18 ` Mike Hearn
2014-03-11 17:11 ` Miron
2014-03-11 15:37 ` Thomas Voegtlin
2014-03-11 21:12 ` Peter Todd
2014-03-11 17:41 ` Odinn Cyberguerrilla
2014-03-12 0:29 ` Jean-Pierre Rupp
2014-03-12 2:35 ` Alan Reiner
2014-03-12 2:48 ` Eric Lombrozo [this message]
2014-03-12 9:48 ` Mike Hearn
2014-03-12 15:35 ` Jeff Garzik
2014-03-12 16:02 ` Mike Hearn
2014-03-12 16:09 ` Drak
2014-03-12 16:14 ` Mike Hearn
2014-03-12 16:24 ` Peter Todd
2014-03-12 16:33 ` Jeff Garzik
2014-03-12 16:41 ` Mike Hearn
2014-03-12 16:47 ` Peter Todd
2014-03-12 16:57 ` Jeff Garzik
2014-03-10 17:50 ` Mike Hearn
2014-03-10 18:12 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9A6499BC-E546-45CC-A7EF-5182FC86052D@gmail.com \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=etotheipi@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox