* [Bitcoin-development] Multisign payment protocol?
@ 2014-03-10 17:39 Drak
2014-03-10 17:49 ` Gavin Andresen
` (2 more replies)
0 siblings, 3 replies; 35+ messages in thread
From: Drak @ 2014-03-10 17:39 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1000 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-10 17:39 [Bitcoin-development] Multisign payment protocol? Drak @ 2014-03-10 17:49 ` Gavin Andresen 2014-03-10 18:01 ` Alan Reiner 2014-03-10 17:50 ` Mike Hearn 2014-03-10 18:12 ` Jeff Garzik 2 siblings, 1 reply; 35+ messages in thread From: Gavin Andresen @ 2014-03-10 17:49 UTC (permalink / raw) To: Drak; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1858 bytes --] 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 <drak@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 [-- Attachment #2: Type: text/html, Size: 2805 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-10 17:49 ` Gavin Andresen @ 2014-03-10 18:01 ` Alan Reiner 2014-03-11 0:04 ` kjj 0 siblings, 1 reply; 35+ messages in thread From: Alan Reiner @ 2014-03-10 18:01 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3570 bytes --] 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 <drak@zikula•org > <mailto:drak@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 [-- Attachment #2: Type: text/html, Size: 6378 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-10 18:01 ` Alan Reiner @ 2014-03-11 0:04 ` kjj 2014-03-11 0:09 ` Alan Reiner 0 siblings, 1 reply; 35+ messages in thread From: kjj @ 2014-03-11 0:04 UTC (permalink / raw) To: Alan Reiner; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4799 bytes --] 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 <drak@zikula•org >> <mailto:drak@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 [-- Attachment #2: Type: text/html, Size: 8716 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 0:04 ` kjj @ 2014-03-11 0:09 ` Alan Reiner 2014-03-11 0:14 ` Jeff Garzik 0 siblings, 1 reply; 35+ messages in thread From: Alan Reiner @ 2014-03-11 0:09 UTC (permalink / raw) To: kjj; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5667 bytes --] 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 <drak@zikula•org >>> <mailto:drak@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 > [-- Attachment #2: Type: text/html, Size: 10104 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 0:09 ` Alan Reiner @ 2014-03-11 0:14 ` Jeff Garzik 2014-03-11 1:15 ` Gavin Andresen 0 siblings, 1 reply; 35+ messages in thread From: Jeff Garzik @ 2014-03-11 0:14 UTC (permalink / raw) To: Alan Reiner; +Cc: Bitcoin Dev, kjj 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 <etotheipi@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 <drak@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 > > > > > ------------------------------------------------------------------------------ > 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 > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 0:14 ` Jeff Garzik @ 2014-03-11 1:15 ` Gavin Andresen 2014-03-11 11:43 ` Drak 0 siblings, 1 reply; 35+ messages in thread From: Gavin Andresen @ 2014-03-11 1:15 UTC (permalink / raw) To: Jeff Garzik; +Cc: kjj, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1812 bytes --] 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 <jgarzik@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 [-- Attachment #2: Type: text/html, Size: 2919 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 1:15 ` Gavin Andresen @ 2014-03-11 11:43 ` Drak 2014-03-11 12:38 ` Jeff Garzik 0 siblings, 1 reply; 35+ messages in thread From: Drak @ 2014-03-11 11:43 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, kjj [-- Attachment #1: Type: text/plain, Size: 3808 bytes --] 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 <gavinandresen@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 <jgarzik@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 > > [-- Attachment #2: Type: text/html, Size: 5703 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 11:43 ` Drak @ 2014-03-11 12:38 ` Jeff Garzik 2014-03-11 13:51 ` Gavin Andresen 0 siblings, 1 reply; 35+ messages in thread From: Jeff Garzik @ 2014-03-11 12:38 UTC (permalink / raw) To: Drak; +Cc: kjj, Bitcoin Dev On Tue, Mar 11, 2014 at 7:43 AM, Drak <drak@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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 12:38 ` Jeff Garzik @ 2014-03-11 13:51 ` Gavin Andresen 2014-03-11 14:13 ` Jeff Garzik 2014-03-11 17:41 ` Odinn Cyberguerrilla 0 siblings, 2 replies; 35+ messages in thread From: Gavin Andresen @ 2014-03-11 13:51 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev, kjj [-- Attachment #1: Type: text/plain, Size: 487 bytes --] On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik <jgarzik@bitpay•com> wrote: > On Tue, Mar 11, 2014 at 7:43 AM, Drak <drak@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 [-- Attachment #2: Type: text/html, Size: 1000 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 13:51 ` Gavin Andresen @ 2014-03-11 14:13 ` Jeff Garzik 2014-03-11 14:23 ` Gavin Andresen 2014-03-11 21:12 ` Peter Todd 2014-03-11 17:41 ` Odinn Cyberguerrilla 1 sibling, 2 replies; 35+ messages in thread From: Jeff Garzik @ 2014-03-11 14:13 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, kjj 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 <gavinandresen@gmail•com> wrote: > On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik <jgarzik@bitpay•com> wrote: >> >> On Tue, Mar 11, 2014 at 7:43 AM, Drak <drak@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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 14:13 ` Jeff Garzik @ 2014-03-11 14:23 ` Gavin Andresen 2014-03-11 14:34 ` Jeff Garzik 2014-03-11 14:44 ` Jeff Garzik 2014-03-11 21:12 ` Peter Todd 1 sibling, 2 replies; 35+ messages in thread From: Gavin Andresen @ 2014-03-11 14:23 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev, kjj [-- Attachment #1: Type: text/plain, Size: 725 bytes --] On Tue, Mar 11, 2014 at 10:13 AM, Jeff Garzik <jgarzik@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 [-- Attachment #2: Type: text/html, Size: 1124 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 14:23 ` Gavin Andresen @ 2014-03-11 14:34 ` Jeff Garzik 2014-03-11 14:44 ` Jeff Garzik 1 sibling, 0 replies; 35+ messages in thread From: Jeff Garzik @ 2014-03-11 14:34 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, kjj On Tue, Mar 11, 2014 at 10:23 AM, Gavin Andresen <gavinandresen@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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 14:23 ` Gavin Andresen 2014-03-11 14:34 ` Jeff Garzik @ 2014-03-11 14:44 ` Jeff Garzik 2014-03-11 14:53 ` Gary Rowe 1 sibling, 1 reply; 35+ messages in thread From: Jeff Garzik @ 2014-03-11 14:44 UTC (permalink / raw) To: Bitcoin Dev (#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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 14:44 ` Jeff Garzik @ 2014-03-11 14:53 ` Gary Rowe 2014-03-11 15:18 ` Mike Hearn 2014-03-11 15:37 ` Thomas Voegtlin 0 siblings, 2 replies; 35+ messages in thread From: Gary Rowe @ 2014-03-11 14:53 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2348 bytes --] 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 <jgarzik@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 > [-- Attachment #2: Type: text/html, Size: 3283 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 14:53 ` Gary Rowe @ 2014-03-11 15:18 ` Mike Hearn 2014-03-11 17:11 ` Miron 2014-03-11 15:37 ` Thomas Voegtlin 1 sibling, 1 reply; 35+ messages in thread From: Mike Hearn @ 2014-03-11 15:18 UTC (permalink / raw) To: Gary Rowe; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3772 bytes --] 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.rowe@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 <jgarzik@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 > > [-- Attachment #2: Type: text/html, Size: 5477 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 15:18 ` Mike Hearn @ 2014-03-11 17:11 ` Miron 0 siblings, 0 replies; 35+ messages in thread From: Miron @ 2014-03-11 17:11 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 14:53 ` Gary Rowe 2014-03-11 15:18 ` Mike Hearn @ 2014-03-11 15:37 ` Thomas Voegtlin 1 sibling, 0 replies; 35+ messages in thread From: Thomas Voegtlin @ 2014-03-11 15:37 UTC (permalink / raw) To: bitcoin-development > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 14:13 ` Jeff Garzik 2014-03-11 14:23 ` Gavin Andresen @ 2014-03-11 21:12 ` Peter Todd 1 sibling, 0 replies; 35+ messages in thread From: Peter Todd @ 2014-03-11 21:12 UTC (permalink / raw) To: Jeff Garzik; +Cc: kjj, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 591 bytes --] 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 00000000000000a636d318d7384d2891c788af10e50b8d1e27b64df847f9117b [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 685 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 13:51 ` Gavin Andresen 2014-03-11 14:13 ` Jeff Garzik @ 2014-03-11 17:41 ` Odinn Cyberguerrilla 2014-03-12 0:29 ` Jean-Pierre Rupp 1 sibling, 1 reply; 35+ messages in thread From: Odinn Cyberguerrilla @ 2014-03-11 17:41 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, kjj 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 <jgarzik@bitpay•com> wrote: > >> On Tue, Mar 11, 2014 at 7:43 AM, Drak <drak@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 > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-11 17:41 ` Odinn Cyberguerrilla @ 2014-03-12 0:29 ` Jean-Pierre Rupp 2014-03-12 2:35 ` Alan Reiner 0 siblings, 1 reply; 35+ messages in thread From: Jean-Pierre Rupp @ 2014-03-12 0:29 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1.1: Type: text/plain, Size: 1144 bytes --] 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! -- Be Happy :) [-- Attachment #1.2: 0xFF4BF34C.asc --] [-- Type: application/pgp-keys, Size: 20587 bytes --] [-- Attachment #1.3: 0xFF4BF34C.asc --] [-- Type: application/pgp-keys, Size: 20585 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 0:29 ` Jean-Pierre Rupp @ 2014-03-12 2:35 ` Alan Reiner 2014-03-12 2:48 ` Eric Lombrozo 0 siblings, 1 reply; 35+ messages in thread From: Alan Reiner @ 2014-03-12 2:35 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3351 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 4414 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 2:35 ` Alan Reiner @ 2014-03-12 2:48 ` Eric Lombrozo 2014-03-12 9:48 ` Mike Hearn 0 siblings, 1 reply; 35+ messages in thread From: Eric Lombrozo @ 2014-03-12 2:48 UTC (permalink / raw) To: Alan Reiner; +Cc: bitcoin-development [-- Attachment #1.1: Type: text/plain, Size: 4762 bytes --] Ciphrex CoinVault (https://ciphrex.com) is currently using parallel trees with lexicographic sorting of keys. CoinVault is also using a partially signed transaction format whereby 0-length placeholders are used for missing signatures in the transaction scripts. Once all the required signatures to satisfy the policy are present, the remaining zero-length placeholders are removed so the transaction can be broadcast to the network. These partially signed transactions can be shared with other parties to an account or other signing devices for the purpose of requesting additional signatures. -Eric On Mar 11, 2014, at 7:35 PM, Alan Reiner <etotheipi@gmail•com> wrote: > I might as well throw in a word about Armory. After our next release in a couple weeks, we will be going full-speed at new wallets and BIP32 integration. Just like Jean-Pierre mentioned, we'll be using parallel trees to generate P2SH addresses after sorting the keys lexicographically. We plan to introduce the concept of a wallet "bundle" (that name is far from concrete... I'd love a better word). All wallets in a bundle are protected by the same backup, and stored in the same file. The default behavior will be use new branches in the same BIP32 tree when a user creates a new "wallet", though we will allow multiple bundles in advanced and expert usermode (which is needed to have watching-only wallets from a different seed created from an offline computer). > > However, we do plan to allow separate parties to create multisig-intended wallets with public parts that can be exported and combined with other users. We feel this is critical, as it allows for linked wallets in which there was never a single-point of failure from key-generation to signing. This is especially important for contexts where employees may be handling a company's Bitcoins wallets. > > On this topic, I have gotten a lot of inquiries into BIP 38 and 39. I was not clear whether those BIPs were worth prioritizing ... i.e. is there a general consensus from a variety of wallet developers that they should be supported? Rather, I'm happy to start prioritizing them if others do too, but I haven't spent much time trying to understand them to even know if they're mature, yet. > > -Alan > > > On 03/11/2014 08:29 PM, Jean-Pierre Rupp wrote: >> Hello people, >> >> We are working on some of this stuff. We had some very early draft on >> how we envisioned multisig happening. It is all implemented in Haskoin >> available as multiple repositories in Github. I am happy to see this >> gathering momentum. >> >> Our multisig system uses BIP-0032 HD wallets, and there will soon be >> BIP-0039 support for keys compatibility. >> >> Our wallet uses synced trees rooted at the extended pubkeys of the >> participants. Currently we are sorting public keys in the scripts to >> avoid ambiguity. >> >> Download haskoin-wallet: >> >> cabal install haskoin-wallet >> >> Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to >> bring transactions into the wallet. You must initialize first with a >> seed and create an account. It supports both regular and multisig accounts. >> >> Perhaps this can lead to interesting discussions on key exchange, and >> the appropriate handling of wallet metadata. I’d love to work on a >> proper standard that could lead us to compatible implementations. >> >> This document explains how we do it now: >> >> http://haskoin.com/~xeno/hd-multisig-wallet.html >> >> Cheers! >> >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech_______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development [-- Attachment #1.2: Type: text/html, Size: 6292 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 2:48 ` Eric Lombrozo @ 2014-03-12 9:48 ` Mike Hearn 2014-03-12 15:35 ` Jeff Garzik 0 siblings, 1 reply; 35+ messages in thread From: Mike Hearn @ 2014-03-12 9:48 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1.1: Type: text/plain, Size: 1451 bytes --] Good to see so much activity! But please do remember, there's more to "multisig" than just keys - you need the whole user experience to be planned out and specced for fully interoperable implementations. For the "group account for an organisation" feature, you don't really want to expose end users to the notion of a key. Historically this has just led to confusion (and an ugly visual explosion of padlocks and small metal objects :) It'd be much better for the UI to be designed in terms of people, perhaps with a bit of social network integration to avoid having to set up profiles, and then a "group spend" feature would behind the scenes rendezvous with the others and swap signatures around, etc. So for interop, you'd need to define all the rendezvous protocols as well. > CoinVault is also using a partially signed transaction format whereby > 0-length placeholders are used for missing signatures in the > transaction scripts. I don't know how you are implementing this/what framework you're using, but I suggest using placeholders that are the length of an actual expected signature, at least when forming the transaction. This is what bitcoinj will do because otherwise you could end up miscalculating the fee, which is based on the final size. See TransactionSignature.dummy() <http://plan99.net/%7Emike/bitcoinj/0.11/com/google/bitcoin/crypto/TransactionSignature.html#dummy%28%29> in the API. [-- Attachment #1.2: Type: text/html, Size: 1885 bytes --] [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 5971 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 9:48 ` Mike Hearn @ 2014-03-12 15:35 ` Jeff Garzik 2014-03-12 16:02 ` Mike Hearn 0 siblings, 1 reply; 35+ messages in thread From: Jeff Garzik @ 2014-03-12 15:35 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev On Wed, Mar 12, 2014 at 5:48 AM, Mike Hearn <mike@plan99•net> wrote: > CoinVault is also using a partially signed transaction format whereby > 0-length placeholders are used for missing signatures in the transaction > scripts. > > I don't know how you are implementing this/what framework you're using, but > I suggest using placeholders that are the length of an actual expected > signature, at least when forming the transaction. This is what bitcoinj will > do because otherwise you could end up miscalculating the fee, which is based > on the final size. See TransactionSignature.dummy() in the API. The zero-length placeholder is not a new invention. This is what bitcoind produces and expects by default, for a partially signed transaction. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 15:35 ` Jeff Garzik @ 2014-03-12 16:02 ` Mike Hearn 2014-03-12 16:09 ` Drak 2014-03-12 16:33 ` Jeff Garzik 0 siblings, 2 replies; 35+ messages in thread From: Mike Hearn @ 2014-03-12 16:02 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 200 bytes --] > > 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? [-- Attachment #2: Type: text/html, Size: 425 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 16:02 ` Mike Hearn @ 2014-03-12 16:09 ` Drak 2014-03-12 16:14 ` Mike Hearn 2014-03-12 16:33 ` Jeff Garzik 1 sibling, 1 reply; 35+ messages in thread From: Drak @ 2014-03-12 16:09 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 496 bytes --] On 12 March 2014 16:02, Mike Hearn <mike@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? > Can this be calculated in advance knowing the initial transaction size and the number of signatures required? Should be quite easy to make an estimation from that? It's probably more of an implementation detail though... Drak [-- Attachment #2: Type: text/html, Size: 1069 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 16:09 ` Drak @ 2014-03-12 16:14 ` Mike Hearn 2014-03-12 16:24 ` Peter Todd 0 siblings, 1 reply; 35+ messages in thread From: Mike Hearn @ 2014-03-12 16:14 UTC (permalink / raw) To: Drak; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 361 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 760 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 16:14 ` Mike Hearn @ 2014-03-12 16:24 ` Peter Todd 0 siblings, 0 replies; 35+ messages in thread From: Peter Todd @ 2014-03-12 16:24 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 901 bytes --] 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 0000000000000000e18643801741dc70db6fda175230012b0f697024218cd9ef [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 685 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 16:02 ` Mike Hearn 2014-03-12 16:09 ` Drak @ 2014-03-12 16:33 ` Jeff Garzik 2014-03-12 16:41 ` Mike Hearn 1 sibling, 1 reply; 35+ messages in thread From: Jeff Garzik @ 2014-03-12 16:33 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev On Wed, Mar 12, 2014 at 12:02 PM, Mike Hearn <mike@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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 16:33 ` Jeff Garzik @ 2014-03-12 16:41 ` Mike Hearn 2014-03-12 16:47 ` Peter Todd 2014-03-12 16:57 ` Jeff Garzik 0 siblings, 2 replies; 35+ messages in thread From: Mike Hearn @ 2014-03-12 16:41 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 598 bytes --] > > 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: 1) Create tx with an estimated fee level 2) Add signatures 3) Submit. If REJECT for too low fees, increment, go to 1 and try again. [-- Attachment #2: Type: text/html, Size: 908 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 16:41 ` Mike Hearn @ 2014-03-12 16:47 ` Peter Todd 2014-03-12 16:57 ` Jeff Garzik 1 sibling, 0 replies; 35+ messages in thread From: Peter Todd @ 2014-03-12 16:47 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1176 bytes --] On Wed, Mar 12, 2014 at 05:41:33PM +0100, Mike Hearn 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: > > 1) Create tx with an estimated fee level > 2) Add signatures > 3) Submit. If REJECT for too low fees, increment, go to 1 and try again. Why? It's the raw transaction API and Bitcoin Core wallet. What should be carefully and loudly documented is the simple advice "Don't use to hold customer funds; use Bitcoinj or something instead." followed by a warning that SPV isn't secure enough for a business unless you run your own full node. The raw transaction API has no support to handle fees at all. -- 'peter'[:-1]@petertodd.org 00000000000000008aebcc3db3f73302ba290392eb783c509c5c7c4dd3971136 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 685 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-12 16:41 ` Mike Hearn 2014-03-12 16:47 ` Peter Todd @ 2014-03-12 16:57 ` Jeff Garzik 1 sibling, 0 replies; 35+ messages in thread From: Jeff Garzik @ 2014-03-12 16:57 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev On Wed, Mar 12, 2014 at 12:41 PM, Mike Hearn <mike@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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-10 17:39 [Bitcoin-development] Multisign payment protocol? Drak 2014-03-10 17:49 ` Gavin Andresen @ 2014-03-10 17:50 ` Mike Hearn 2014-03-10 18:12 ` Jeff Garzik 2 siblings, 0 replies; 35+ messages in thread From: Mike Hearn @ 2014-03-10 17:50 UTC (permalink / raw) To: Drak; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 521 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 699 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [Bitcoin-development] Multisign payment protocol? 2014-03-10 17:39 [Bitcoin-development] Multisign payment protocol? Drak 2014-03-10 17:49 ` Gavin Andresen 2014-03-10 17:50 ` Mike Hearn @ 2014-03-10 18:12 ` Jeff Garzik 2 siblings, 0 replies; 35+ messages in thread From: Jeff Garzik @ 2014-03-10 18:12 UTC (permalink / raw) To: Drak; +Cc: Bitcoin Dev 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 <drak@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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2014-03-12 16:57 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-03-10 17:39 [Bitcoin-development] Multisign payment protocol? Drak 2014-03-10 17:49 ` Gavin Andresen 2014-03-10 18:01 ` Alan Reiner 2014-03-11 0:04 ` kjj 2014-03-11 0:09 ` Alan Reiner 2014-03-11 0:14 ` Jeff Garzik 2014-03-11 1:15 ` Gavin Andresen 2014-03-11 11:43 ` Drak 2014-03-11 12:38 ` Jeff Garzik 2014-03-11 13:51 ` Gavin Andresen 2014-03-11 14:13 ` Jeff Garzik 2014-03-11 14:23 ` Gavin Andresen 2014-03-11 14:34 ` Jeff Garzik 2014-03-11 14:44 ` Jeff Garzik 2014-03-11 14:53 ` Gary Rowe 2014-03-11 15:18 ` Mike Hearn 2014-03-11 17:11 ` Miron 2014-03-11 15:37 ` Thomas Voegtlin 2014-03-11 21:12 ` Peter Todd 2014-03-11 17:41 ` Odinn Cyberguerrilla 2014-03-12 0:29 ` Jean-Pierre Rupp 2014-03-12 2:35 ` Alan Reiner 2014-03-12 2:48 ` Eric Lombrozo 2014-03-12 9:48 ` Mike Hearn 2014-03-12 15:35 ` Jeff Garzik 2014-03-12 16:02 ` Mike Hearn 2014-03-12 16:09 ` Drak 2014-03-12 16:14 ` Mike Hearn 2014-03-12 16:24 ` Peter Todd 2014-03-12 16:33 ` Jeff Garzik 2014-03-12 16:41 ` Mike Hearn 2014-03-12 16:47 ` Peter Todd 2014-03-12 16:57 ` Jeff Garzik 2014-03-10 17:50 ` Mike Hearn 2014-03-10 18:12 ` Jeff Garzik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox