public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@bitpay.com>
To: Alan Reiner <etotheipi@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	kjj <bitcoin-devel@jerviss.org>
Subject: Re: [Bitcoin-development] Multisign payment protocol?
Date: Mon, 10 Mar 2014 20:14:56 -0400	[thread overview]
Message-ID: <CAJHLa0NZkzQQvMxgCJAJGT=Yn6vrVNK8Bg7RAfAjctpnrfg5zA@mail.gmail.com> (raw)
In-Reply-To: <531E5454.1030601@gmail.com>

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/



  reply	other threads:[~2014-03-11  0:15 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10 17:39 [Bitcoin-development] Multisign payment protocol? Drak
2014-03-10 17:49 ` Gavin Andresen
2014-03-10 18:01   ` Alan Reiner
2014-03-11  0:04     ` kjj
2014-03-11  0:09       ` Alan Reiner
2014-03-11  0:14         ` Jeff Garzik [this message]
2014-03-11  1:15           ` Gavin Andresen
2014-03-11 11:43             ` Drak
2014-03-11 12:38               ` Jeff Garzik
2014-03-11 13:51                 ` Gavin Andresen
2014-03-11 14:13                   ` Jeff Garzik
2014-03-11 14:23                     ` Gavin Andresen
2014-03-11 14:34                       ` Jeff Garzik
2014-03-11 14:44                       ` Jeff Garzik
2014-03-11 14:53                         ` Gary Rowe
2014-03-11 15:18                           ` Mike Hearn
2014-03-11 17:11                             ` Miron
2014-03-11 15:37                           ` Thomas Voegtlin
2014-03-11 21:12                     ` Peter Todd
2014-03-11 17:41                   ` Odinn Cyberguerrilla
2014-03-12  0:29                     ` Jean-Pierre Rupp
2014-03-12  2:35                       ` Alan Reiner
2014-03-12  2:48                         ` Eric Lombrozo
2014-03-12  9:48                           ` Mike Hearn
2014-03-12 15:35                             ` Jeff Garzik
2014-03-12 16:02                               ` Mike Hearn
2014-03-12 16:09                                 ` Drak
2014-03-12 16:14                                   ` Mike Hearn
2014-03-12 16:24                                     ` Peter Todd
2014-03-12 16:33                                 ` Jeff Garzik
2014-03-12 16:41                                   ` Mike Hearn
2014-03-12 16:47                                     ` Peter Todd
2014-03-12 16:57                                     ` Jeff Garzik
2014-03-10 17:50 ` Mike Hearn
2014-03-10 18:12 ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJHLa0NZkzQQvMxgCJAJGT=Yn6vrVNK8Bg7RAfAjctpnrfg5zA@mail.gmail.com' \
    --to=jgarzik@bitpay.com \
    --cc=bitcoin-devel@jerviss.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=etotheipi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox