Multisign payment protocol?
35 messages, 10 to 12 Mar 2014. Started by Drak.
Jeff Garzik (9), Mike Hearn (6), Gavin Andresen (4), Drak (3), Alan Reiner (3), Peter Todd (3), Kyle Jerviss, Gary Rowe, +5 more
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
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:
Quoted text (32 lines)
> 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 > >
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.
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:
Quoted text (71 lines)
> 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
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:
Quoted text (30 lines)
> 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 >
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:
Quoted text (105 lines)
> 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
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:
Quoted text (118 lines)
> 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 >
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:
Quoted text (147 lines)
> 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 >
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:
Quoted text (5 lines)
> 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,
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:
Quoted text (62 lines)
> 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 > >
On Tue, Mar 11, 2014 at 7:43 AM, Drak <drak@zikula•org> wrote:
Quoted text (2 lines)
> 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.
On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:
Quoted text (6 lines)
> 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.
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:
Quoted text (15 lines)
> 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
On Tue, Mar 11, 2014 at 10:13 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:
Quoted text (4 lines)
> 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).
On Tue, Mar 11, 2014 at 10:23 AM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (4 lines)
> 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.
(#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.
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:
Quoted text (30 lines)
> (#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 >
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:
Quoted text (68 lines)
> 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 > >
Quoted text (1 line)
> 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
On Tue, 2014-03-11 at 16:18 +0100, Mike Hearn wrote:
Quoted text (10 lines)
> 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.
Quoted text (6 lines)
> > 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.
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.
Quoted text (25 lines)
> 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 >
On Tue, Mar 11, 2014 at 10:13:48AM -0400, Jeff Garzik wrote:
Quoted text (4 lines)
> 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.
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!
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:
Quoted text (46 lines)
> 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
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:
Quoted text (66 lines)
> 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
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.
Quoted text (3 lines)
> 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.
On Wed, Mar 12, 2014 at 5:48 AM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (9 lines)
> 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.
Quoted text (3 lines)
> > 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?
On 12 March 2014 16:02, Mike Hearn <mike@plan99•net> wrote:
Quoted text (7 lines)
> 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
Quoted text (4 lines)
> > 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.
On Wed, Mar 12, 2014 at 05:14:25PM +0100, Mike Hearn wrote:
Quoted text (9 lines)
> > > > 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)
On Wed, Mar 12, 2014 at 12:02 PM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (4 lines)
>> 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.
Quoted text (4 lines)
> > 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.
On Wed, Mar 12, 2014 at 05:41:33PM +0100, Mike Hearn wrote:
Quoted text (14 lines)
> > > > 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.
On Wed, Mar 12, 2014 at 12:41 PM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (9 lines)
>> 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