Jeff Garzik [ARCHIVE] on Nostr: š Original date posted:2014-03-10 š Original message:All of that only melds ...
š
Original date posted:2014-03-10
š Original message: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 at 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 at 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 at 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 at 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 at 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 at 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/
š Original message: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 at 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 at 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 at 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 at 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 at 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 at 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/