Re: [Bitcoin-development] Multisign payment protocol?
Gavin, You have pretty much nailed my intent in both respects. This sets up a way to negotiate the address and abstract away the nasty details of finding public keys from bitcoin addresses, and provides a nice clean way for redemption abstracting away the long strings of hex. For redemption, I think as each party signs the tx if the script returns true, it would be acceptable to just go right ahead and broadcast it, or maybe as you suggest all signatures go back to the initiating party and they do the final work. I very much like the idea of assuming each party uses HD wallets, that certainly simplifies things greatly. I also like the use of email addresses as a negotiation medium, but I also wonder if this could be made agnostic in any BIP proposal so it could work with other communication mediums like bitmessage for example (just forward thinking anonymity a little). I definitely think there is a need for a protocol because multisig, regardless of the application has two technically involved steps: negotiation of an address, and redemption of any subsequently encumbered funds. A protocol would enable different wallet implementations to participate in such a transaction and make wide-spread use much more likely and possible. Drak On 11 March 2014 01:15, Gavin Andresen gavinandre...@gmail.com wrote: Multisig is orthogonal to the payment protocol (but payment protocol is needed first). There need to be protocols for: a) Establishing multisig wallets of various sorts. See: https://moqups.com/gavinandresen/no8mzUDB/ https://moqups.com/gavinandresen/no8mzUDB/p:ab18547e0 ... etc. for a UI mock-up. There needs to be some protocol so all participants in a multisig wallet contribute keys (actually, we should just assume everybody uses BIP32 HD public keys so we get privacy from the start). Multi-person shared wallets, escrows, and wallet protection service wallets (which might be protected with two-factor authentication) are different use cases and probably use slightly different protocols (and will probably need different BIPs eventually). b) Gathering signatures for a multisig spend. Here is where the payment protocol is useful; the PaymentRequest message should be passed around so all participants know what is being paid for, and maybe a partially-signed Payment message is where the signatures are gathered (or maybe the signatures are sent separately and one of the participants creates and submits the Payment and gets the PaymentACK... to be designed). See: https://moqups.com/gavinandresen/no8mzUDB/p:a7e81be96 https://moqups.com/gavinandresen/no8mzUDB/p:af7339204 ... for UI mock-up for the multi-person-spend case. And maybe a protocol for I don't want to be part of this multisig any more / I lost control of my private key don't trust me in this multisig any more. On Mon, Mar 10, 2014 at 8:14 PM, Jeff Garzik jgar...@bitpay.com wrote: All of that only melds with the payment protocol under an extremely expansive definition of payment. The payment protocol is really geared towards a direct one-to-one relationship -- Gavin Andresen -- 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
Re: [Bitcoin-development] Multisign payment protocol?
On Tue, Mar 11, 2014 at 7:43 AM, Drak d...@zikula.org wrote: I very much like the idea of assuming each party uses HD wallets, that certainly simplifies things greatly. It also assumes a reality different from our current one. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
Re: [Bitcoin-development] Multisign payment protocol?
On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Mar 11, 2014 at 7:43 AM, Drak d...@zikula.org wrote: I very much like the idea of assuming each party uses HD wallets, that certainly simplifies things greatly. It also assumes a reality different from our current one. Multisig wallets are a different reality from our current one, so when we move to that new reality we should do it correctly from the beginning. -- -- Gavin Andrese -- 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
Re: [Bitcoin-development] Multisign payment protocol?
Sure, but I don't see wallets being able to _assume_ _remote_ parties have an HD wallet for a long, long time. Interoperability common sense implies the environment will be heterogenous, perhaps forever, invalidating assume-each-party-uses-HD logic. On Tue, Mar 11, 2014 at 9:51 AM, Gavin Andresen gavinandre...@gmail.com wrote: On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Mar 11, 2014 at 7:43 AM, Drak d...@zikula.org wrote: I very much like the idea of assuming each party uses HD wallets, that certainly simplifies things greatly. It also assumes a reality different from our current one. Multisig wallets are a different reality from our current one, so when we move to that new reality we should do it correctly from the beginning. -- -- Gavin Andrese -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
Re: [Bitcoin-development] Multisign payment protocol?
On Tue, Mar 11, 2014 at 10:13 AM, Jeff Garzik jgar...@bitpay.com wrote: Sure, but I don't see wallets being able to _assume_ _remote_ parties have an HD wallet for a long, long time. Interoperability common sense implies the environment will be heterogenous, perhaps forever, invalidating assume-each-party-uses-HD logic. If the remote party is one of the parties involved in a multisig, and speaks the Lets set up a multisig wallet together / Lets spend from a multisig protocols, then it should be perfectly reasonable to assume that they're HD-capable. Remote parties paying into a multisig, or receiving funds from a multisig, don't have to support it (that's what P2SH gives us). -- -- Gavin Andresen -- 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
Re: [Bitcoin-development] Multisign payment protocol?
On Tue, Mar 11, 2014 at 10:23 AM, Gavin Andresen gavinandre...@gmail.com wrote: If the remote party is one of the parties involved in a multisig, and speaks the Lets set up a multisig wallet together / Lets spend from a multisig protocols, then it should be perfectly reasonable to assume that they're HD-capable. Disagree. It is an unnecessary restriction. People are already writing and starting to deploy multisig wallets in the field, that do not match this assumption. In general, HD is really cool, but even the barest amount of infrastructure is lacking. Popular libraries and the reference client all lack support. Building a protocol that assumes HD is optimistic at this stage. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
Re: [Bitcoin-development] Multisign payment protocol?
(#include rant.h) Right now, HD is hot air. Let us end the pie-in-the-sky assumptions about how HD will save the day, with zero code to back it up. Bitcoin Wallet purportedly fails to rotate addresses, a privacy ugly, because of this Waiting For Godot situation. An attempt to add a simple, stateless RPC stalled because we are all Waiting For Godot, also: https://github.com/bitcoin/bitcoin/pull/3520 Until the major user wallets and bitcoind have -basic- HD support, it is premature to build anything on top of HD. We really have no clue at this juncture how difficult will be the HD rollout. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
Re: [Bitcoin-development] Multisign payment protocol?
Speaking from the MultiBit perspective, all future protocol development (with the exception of critical security and network compatibility fixes) will be put into a HD wallet. Over time we want to see MultiBit Classic gracefully retire and be fully superseded. Right now, HD is not out there but there is a lot of work going on between wallet developers to harmonise on HD implementation through BIP32/39. The result of that work should see a significant migration away from random private keys. Thus it would appear likely that by the time this protocol sees widespread use the presence of HD is likely to be rising fast or possibly dominant. At MultiBit we anticipate a release of HD code within 2 months, with private beta occurring within weeks. Trezor and Electrum may be earlier than this. As far as I am aware both Hive and Haskoin are committed to HD. If anyone wants early access to the alpha code, let me know and I'll make the arrangements. On 11 March 2014 14:44, Jeff Garzik jgar...@bitpay.com wrote: (#include rant.h) Right now, HD is hot air. Let us end the pie-in-the-sky assumptions about how HD will save the day, with zero code to back it up. Bitcoin Wallet purportedly fails to rotate addresses, a privacy ugly, because of this Waiting For Godot situation. An attempt to add a simple, stateless RPC stalled because we are all Waiting For Godot, also: https://github.com/bitcoin/bitcoin/pull/3520 Until the major user wallets and bitcoind have -basic- HD support, it is premature to build anything on top of HD. We really have no clue at this juncture how difficult will be the HD rollout. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
Re: [Bitcoin-development] Multisign payment protocol?
You can follow HDW progress in bitcoinj on this branch: https://github.com/bitcoinj/bitcoinj/commits/keychain I've been working on it for a couple of months now. Electrum (Thomas V) is also making good progress, and Trezor already uses HD wallets. I think most popular end user wallets except blockchain.info and Bitcoin Core will support HDW soon enough. At any rate, as Gavin said already, the best way to make a feature you want happen is just to write it. Devrandom is already working on a watchdog service, as is another group (TrustedCoin), and that's an obvious use for multisig/p2sh. They have API's already, it's just a case of standardising them once we get more experience. On Tue, Mar 11, 2014 at 3:53 PM, Gary Rowe g.r...@froot.co.uk wrote: Speaking from the MultiBit perspective, all future protocol development (with the exception of critical security and network compatibility fixes) will be put into a HD wallet. Over time we want to see MultiBit Classic gracefully retire and be fully superseded. Right now, HD is not out there but there is a lot of work going on between wallet developers to harmonise on HD implementation through BIP32/39. The result of that work should see a significant migration away from random private keys. Thus it would appear likely that by the time this protocol sees widespread use the presence of HD is likely to be rising fast or possibly dominant. At MultiBit we anticipate a release of HD code within 2 months, with private beta occurring within weeks. Trezor and Electrum may be earlier than this. As far as I am aware both Hive and Haskoin are committed to HD. If anyone wants early access to the alpha code, let me know and I'll make the arrangements. On 11 March 2014 14:44, Jeff Garzik jgar...@bitpay.com wrote: (#include rant.h) Right now, HD is hot air. Let us end the pie-in-the-sky assumptions about how HD will save the day, with zero code to back it up. Bitcoin Wallet purportedly fails to rotate addresses, a privacy ugly, because of this Waiting For Godot situation. An attempt to add a simple, stateless RPC stalled because we are all Waiting For Godot, also: https://github.com/bitcoin/bitcoin/pull/3520 Until the major user wallets and bitcoind have -basic- HD support, it is premature to build anything on top of HD. We really have no clue at this juncture how difficult will be the HD rollout. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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 -- 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
Re: [Bitcoin-development] Multisign payment protocol?
Trezor and Electrum may be earlier than this. Sorry for not joining the discussion earlier. I have postponed the release of bip32 features in Electrum due to ongoing discussions with Trezor and bitcoinj developers. I planned to post a summary in a separate thread, but this info is also relevant for this thread, so I'm posting here. (sorry if this is a bit offtopic, though) I plan to create a 2-factor authentication service that uses p2sh addresses in Electrum. All addresses are derived from the wallet root seed, and should be recoverable from it. (of course this departs from scenarios where master keys are generated independently; my opinion is that both should be possible) So, when the user activates 2fa protection, the root private key is deleted from their hard drive, as well as the master private key of one of the branches used to create p2sh addresses (which is sent to a remote server). See this (fairly old) description here for more details: https://bitcointalk.org/index.php?topic=274182.0 Since I still want to be able to generate 1of1 accounts after the 2fa protection is activated, 1of 1 accounts should not be generated directly from the root of the tree. Thus, an extra level must be inserted in the tree. For example, 1of1 addresses can be derived as follows: m/reserved'/n' where n is the account index, and reserved is an index that indicates the type of address. (0 would be reserved for 1of1 addresses) slush suggested that another layer of derivation would be useful, in order to use wallets with altcoins on the same seed. This lead to this type of derivation: m/coin'/reserved'/n' where coin would be 0 for Bitcoin, and reserved would be 0 for 1of1 addresses Thomas -- 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
Re: [Bitcoin-development] Multisign payment protocol?
On Tue, 2014-03-11 at 16:18 +0100, Mike Hearn wrote: You can follow HDW progress in bitcoinj on this branch: https://github.com/bitcoinj/bitcoinj/commits/keychain I've been working on it for a couple of months now. Electrum (Thomas V) is also making good progress, and Trezor already uses HD wallets. I think most popular end user wallets except blockchain.info and Bitcoin Core will support HDW soon enough. Interestingly, Blockchain's android wallet is based on Android Wallet / bitcoinj. So with HD in bitcoinj we would get Multibit, Android Wallet (Andreas Schildbach's) and remove one roadblock to Blockchain going HD. Electrum HD seems more or less ready. So I'm optimistic that we'll see a pretty fast transition to HD for the majority of the user base. HD is important for some multisig flows, including the watchdog type where you want to detect change going back to the wallet. At any rate, as Gavin said already, the best way to make a feature you want happen is just to write it. Devrandom is already working on a watchdog service, as is another group (TrustedCoin), and that's an obvious use for multisig/p2sh. They have API's already, it's just a case of standardising them once we get more experience. We have a proposed flow for watchdog type multisig here: https://cryptocorp.co/technology.htm and a reference implementation off the Electrum 2.0 branch. It actually works just like a regular spend from a UX point of view, unless the watchdog decides that it needs a second factor for a risky transaction. With a risky transaction, the user just gets a callback or enters an OTP. -- Miron -- 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
Re: [Bitcoin-development] Multisign payment protocol?
Hello, I wanted to just add a very brief note to this discussion, that presently for multisignature creation and management (new transaction etc) I've been using this: https://coinb.in/multisig/ There were some initial bumps in the road but they were worked out, see full thread more or less beginning from here: https://bitcointalk.org/index.php?topic=390046.msg4687868#msg4687868 Curious as to what wallets actually support multisig / P2SH at this point? Unsure. Am assuming more than previously. On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Mar 11, 2014 at 7:43 AM, Drak d...@zikula.org wrote: I very much like the idea of assuming each party uses HD wallets, that certainly simplifies things greatly. It also assumes a reality different from our current one. Multisig wallets are a different reality from our current one, so when we move to that new reality we should do it correctly from the beginning. -- -- Gavin Andrese -- 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
Re: [Bitcoin-development] Multisign payment protocol?
On Tue, Mar 11, 2014 at 10:13:48AM -0400, Jeff Garzik wrote: Sure, but I don't see wallets being able to _assume_ _remote_ parties have an HD wallet for a long, long time. Interoperability common sense implies the environment will be heterogenous, perhaps forever, invalidating assume-each-party-uses-HD logic. Maybe never: you can implement a wallet that uses stealth addresses for change, and doing appears to be advantageous in some scenarious with regard to privacy. -- 'peter'[:-1]@petertodd.org 00a636d318d7384d2891c788af10e50b8d1e27b64df847f9117b signature.asc Description: Digital signature -- 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
Re: [Bitcoin-development] Multisign payment protocol?
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. Id 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! -- Be Happy :) 0xFF4BF34C.asc Description: application/pgp-keys 0xFF4BF34C.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- 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
Re: [Bitcoin-development] Multisign payment protocol?
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
Re: [Bitcoin-development] Multisign payment protocol?
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 etothe...@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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
