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/
next prev parent 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 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$(echo .)com \
--cc=bitcoin-devel@jerviss$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=etotheipi@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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