[Bitcoin-development] Multisign payment protocol?

[Bitcoin-development] Multisign payment protocol?

[Drak]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Gavin Andresen]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Alan Reiner]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Jeff Garzik]

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/

Re: [Bitcoin-development] Multisign payment protocol?

[kjj]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Alan Reiner]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Jeff Garzik]

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/

Re: [Bitcoin-development] Multisign payment protocol?

[Gavin Andresen]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Drak]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Jeff Garzik]

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/

Re: [Bitcoin-development] Multisign payment protocol?

[Gavin Andresen]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Jeff Garzik]

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/

Re: [Bitcoin-development] Multisign payment protocol?

[Gavin Andresen]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Jeff Garzik]

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/

Re: [Bitcoin-development] Multisign payment protocol?

[Jeff Garzik]

(#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/

Re: [Bitcoin-development] Multisign payment protocol?

[Gary Rowe]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Thomas Voegtlin]

> 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

Re: [Bitcoin-development] Multisign payment protocol?

[Miron]

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

Re: [Bitcoin-development] Multisign payment protocol?

[Odinn Cyberguerrilla]

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
>

Re: [Bitcoin-development] Multisign payment protocol?

[Peter Todd]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Jean-Pierre Rupp]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Alan Reiner]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Eric Lombrozo]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Jeff Garzik]

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/

Re: [Bitcoin-development] Multisign payment protocol?

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Drak]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Peter Todd]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Jeff Garzik]

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/

Re: [Bitcoin-development] Multisign payment protocol?

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Peter Todd]

[-- 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 --]

Re: [Bitcoin-development] Multisign payment protocol?

[Jeff Garzik]

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/