Re: [Bitcoin-development] Multisign payment protocol?
Can this be calculated in advance knowing the initial transaction size and the number of signatures required? Sure of course. You assume each signature to be placed in the tx is 73 bytes. Not very hard, but if the tx you get back from the API doesn't contain such a 73-byte sentinel value then it's harder to be sure that this part was done correctly. -- 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 Wed, Mar 12, 2014 at 05:14:25PM +0100, Mike Hearn wrote: Can this be calculated in advance knowing the initial transaction size and the number of signatures required? Sure of course. You assume each signature to be placed in the tx is 73 bytes. Not very hard, but if the tx you get back from the API doesn't contain such a 73-byte sentinel value then it's harder to be sure that this part was done correctly. Multisig signing is an example of untrusted input from an adversary; this is a good example where you'd be better off just handling it correctly rather than trying to make it easier. (although handling it correctly may include internally converting every not-yet-signed dummy signature into a 73 bytes pushdata prior to calculating the size) -- 'peter'[:-1]@petertodd.org e18643801741dc70db6fda175230012b0f697024218cd9ef 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?
On Wed, Mar 12, 2014 at 12:02 PM, Mike Hearn m...@plan99.net wrote: This is what bitcoind produces and expects by default, for a partially signed transaction. What happens if the act of filling out the signature pushes the transaction into a higher fee level? Partially signed and multisig transactions within bitcoind go through the raw transaction API, which does absolutely nothing if the sig pushes the TX to a higher fee level. -- 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 Wed, Mar 12, 2014 at 12:41 PM, Mike Hearn m...@plan99.net wrote: Partially signed and multisig transactions within bitcoind go through the raw transaction API, which does absolutely nothing if the sig pushes the TX to a higher fee level. Well, we'll have to make sure this is carefully and loudly documented in the new developer part of the website that's being worked on. Because this seems like a recipe for people writing flaky apps. In practice it would seem like you need to implement the fee loop in your own app: It's the raw transaction API. If you break something, you get to keep both pieces. On a related note, sipa has proposed a more useful raw transaction API call, that figures out fees, change and other details: https://github.com/bitcoin/bitcoin/issues/3794 -- 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?
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
[Bitcoin-development] Multisign payment protocol?
I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- 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?
In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- 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 -- -- 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?
No, this doesn't make any sense. Multisig outputs are a tool you use to build helpful features, not a feature in and of themselves. By all means create a nice protocol, implementation and BIP for something like: - Creation of multi-user money pools for managing an organisations funds - Dispute mediated transactions - Watchdog services that provide a third party risk analysis of transactions - Micropayment channels (actually me and Matt already did this, sans BIP) but trying to do just multisig won't work well. -- 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?
Payment protocol currently supports payments to multi-sig addresses. In general, almost all wallet software sucks RE multisig. Just try any of these actions in Bitcoin-Qt or another wallet: * obtain a public key you control, given a bitcoin address * easily share public keys * easily share partially signed transactions * build a P2SH multisig address from public keys, reliably. Right now, participants have no idea about pubkey order, leading various N possible P2SH addresses, given a list of public keys. Reproducing the P2SH address is harder than it should be. * track partially controlled balance (balance of coins of which you may sign at least 1 of N) * support for remote oracles and services that provide 1-of-N signatures etc. On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- 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 -- 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?
As far as I'm concerned, the way forward is to scrap BIP 10 and build up something new that is flexible and extensible. Also, my understanding is that there may be room in the payment protocol for this stuff though I'm not sure if it is really adapted well to all the steps: exchanging public keys, creating multi-sig/P2SH addresses, proposing multi-sig spends, bundling meta-data needed for lite/offline nodes, aggregating signatures, and any other details. When I start multisig integration into Armory (very soon!) I'll write a list of requirements for the new format/process and post it here for a wider discussion. Certainly, if the payment protocol can already handle all this, that would be awesome. -Alan On 03/10/2014 08:04 PM, kjj wrote: I was trying to use bip10 for multisig and coinjoin, but there was a problem with it. I'll have to look back at my notes, but I thought I sent you a message about it. And then real life swallowed my bitcoin time... I think the bottom line was that it would be useful in the generic case with just one minor change. If there is interest, and it sounds like there just may be, I can dust off my notes and see where I left it. Probably should do it soon before someone implements it in PB or XML. Alan Reiner wrote: Then of course I tried to do this with BIP 10 https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki when Armory implemented offline-transactions two years ago. I got some positive feedback, but no one wanted to help improve it, etc. I guess nobody else was doing it and/or cared at the time. So I continue to use BIP 10 even though it's pretty crappy. I wanted it to be useful for multisig, too, but it has some deficiencies there (it was done when Armory was extremely young and OP_EVAL was still on the table). However, with all this activity, we should start thinking about that and discussing it. Otherwise, I'll just do my own thing again and probably end up with something that fits my own needs, but not anyone else's. Really though, multisig shouldn't require all the same app to work. -Alan On 03/10/2014 01:49 PM, Gavin Andresen wrote: In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org mailto:d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig http://coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- 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 mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- 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
Re: [Bitcoin-development] Multisign payment protocol?
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. We can make the payment protocol do all this, if you squeeze and push and try reall hard; it is mainly a question of protocol design and intended usage: is PP intended to be, ultimately, an expansive, universal protocol for gossiping with other parties about bitcoin transactions in a not-flood-fill manner? On Mon, Mar 10, 2014 at 8:09 PM, Alan Reiner etothe...@gmail.com wrote: As far as I'm concerned, the way forward is to scrap BIP 10 and build up something new that is flexible and extensible. Also, my understanding is that there may be room in the payment protocol for this stuff though I'm not sure if it is really adapted well to all the steps: exchanging public keys, creating multi-sig/P2SH addresses, proposing multi-sig spends, bundling meta-data needed for lite/offline nodes, aggregating signatures, and any other details. When I start multisig integration into Armory (very soon!) I'll write a list of requirements for the new format/process and post it here for a wider discussion. Certainly, if the payment protocol can already handle all this, that would be awesome. -Alan On 03/10/2014 08:04 PM, kjj wrote: I was trying to use bip10 for multisig and coinjoin, but there was a problem with it. I'll have to look back at my notes, but I thought I sent you a message about it. And then real life swallowed my bitcoin time... I think the bottom line was that it would be useful in the generic case with just one minor change. If there is interest, and it sounds like there just may be, I can dust off my notes and see where I left it. Probably should do it soon before someone implements it in PB or XML. Alan Reiner wrote: Then of course I tried to do this with BIP 10 when Armory implemented offline-transactions two years ago. I got some positive feedback, but no one wanted to help improve it, etc. I guess nobody else was doing it and/or cared at the time. So I continue to use BIP 10 even though it's pretty crappy. I wanted it to be useful for multisig, too, but it has some deficiencies there (it was done when Armory was extremely young and OP_EVAL was still on the table). However, with all this activity, we should start thinking about that and discussing it. Otherwise, I'll just do my own thing again and probably end up with something that fits my own needs, but not anyone else's. Really though, multisig shouldn't require all the same app to work. -Alan On 03/10/2014 01:49 PM, Gavin Andresen wrote: In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- 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 -- -- 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
Re: [Bitcoin-development] Multisign payment protocol?
I was trying to use bip10 for multisig and coinjoin, but there was a problem with it. I'll have to look back at my notes, but I thought I sent you a message about it. And then real life swallowed my bitcoin time... I think the bottom line was that it would be useful in the generic case with just one minor change. If there is interest, and it sounds like there just may be, I can dust off my notes and see where I left it. Probably should do it soon before someone implements it in PB or XML. Alan Reiner wrote: Then of course I tried to do this with BIP 10 https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki when Armory implemented offline-transactions two years ago. I got some positive feedback, but no one wanted to help improve it, etc. I guess nobody else was doing it and/or cared at the time. So I continue to use BIP 10 even though it's pretty crappy. I wanted it to be useful for multisig, too, but it has some deficiencies there (it was done when Armory was extremely young and OP_EVAL was still on the table). However, with all this activity, we should start thinking about that and discussing it. Otherwise, I'll just do my own thing again and probably end up with something that fits my own needs, but not anyone else's. Really though, multisig shouldn't require all the same app to work. -Alan On 03/10/2014 01:49 PM, Gavin Andresen wrote: In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org mailto:d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig http://coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- 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 mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- 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 -- 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
Re: [Bitcoin-development] Multisign payment protocol?
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
