{"type":"rich","version":"1.0","author_name":"npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","author_url":"https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-03-10\n📝 Original message:All of that only melds with the payment protocol under an extremely\nexpansive definition of \"payment.\"  The payment protocol is really\ngeared towards a direct one-to-one relationship.\n\nWe can make the payment protocol do all this, if you squeeze and push\nand try reall hard; it is mainly a question of protocol design and\nintended usage:  is PP intended to be, ultimately, an expansive,\nuniversal protocol for gossiping with other parties about bitcoin\ntransactions in a not-flood-fill manner?\n\n\n\n\nOn Mon, Mar 10, 2014 at 8:09 PM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e As far as I'm concerned, the way forward is to scrap BIP 10 and build up\n\u003e something new that is flexible and extensible.  Also, my understanding is\n\u003e that there may be room in the payment protocol for this stuff though I'm not\n\u003e sure if it is really adapted well to all the steps: exchanging public keys,\n\u003e creating multi-sig/P2SH addresses, proposing multi-sig spends, bundling\n\u003e meta-data needed for lite/offline nodes, aggregating signatures, and any\n\u003e other details.\n\u003e\n\u003e When I start multisig integration into Armory (very soon!) I'll write a list\n\u003e of requirements for the new format/process and post it here for a wider\n\u003e discussion.  Certainly, if the payment protocol can already handle all this,\n\u003e that would be awesome.\n\u003e\n\u003e -Alan\n\u003e\n\u003e\n\u003e On 03/10/2014 08:04 PM, kjj wrote:\n\u003e\n\u003e I was trying to use bip10 for multisig and coinjoin, but there was a problem\n\u003e with it.  I'll have to look back at my notes, but I thought I sent you a\n\u003e message about it.  And then real life swallowed my bitcoin time...\n\u003e\n\u003e I think the bottom line was that it would be useful in the generic case with\n\u003e just one minor change.  If there is interest, and it sounds like there just\n\u003e may be, I can dust off my notes and see where I left it.  Probably should do\n\u003e it soon before someone implements it in PB or XML.\n\u003e\n\u003e Alan Reiner wrote:\n\u003e\n\u003e Then of course I tried to do this with BIP 10  when Armory implemented\n\u003e offline-transactions two years ago.  I got some positive feedback, but no\n\u003e one wanted to help improve it, etc.  I guess nobody else was doing it and/or\n\u003e cared at the time.  So I continue to use BIP 10 even though it's pretty\n\u003e crappy.  I wanted it to be useful for multisig, too, but it has some\n\u003e deficiencies there (it was done when Armory was extremely young and OP_EVAL\n\u003e was still on the table).\n\u003e\n\u003e However, with all this activity, we should start thinking about that and\n\u003e discussing it.  Otherwise, I'll just do my own thing again and probably end\n\u003e up with something that fits my own needs, but not anyone else's.  Really\n\u003e though, multisig shouldn't require all the same app to work.\n\u003e\n\u003e -Alan\n\u003e\n\u003e\n\u003e On 03/10/2014 01:49 PM, Gavin Andresen wrote:\n\u003e\n\u003e In my experience, best process for standardizing something is:\n\u003e\n\u003e 1) Somebody has a great idea\n\u003e 2) They implement it\n\u003e 3) Everybody agrees, \"Great idea!\" and they copy it.\n\u003e 4) Idea gets refined by the people copying it.\n\u003e 5) It gets standardized.\n\u003e\n\u003e Mutisig wallets are at step 2 right now. BIP is step 5, in my humble\n\u003e opinion...\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On Mon, Mar 10, 2014 at 1:39 PM, Drak \u003cdrak at zikula.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e I was wondering if there would be merit in a kind of BIP for a payment\n\u003e\u003e protocol using multisig?\n\u003e\u003e\n\u003e\u003e Currently, setting up a multisig is quite a feat. Users have to exchange\n\u003e\u003e public keys, work out how to get the public keys from their addresses. If\n\u003e\u003e one of the parties are not savvy enough, an malicious party could easily be\n\u003e\u003e setup that was 2 of 3 instead of 2 of 2 where the malicious party generates\n\u003e\u003e the multisig address+script and thus be able to run off with funds anyway.\n\u003e\u003e\n\u003e\u003e It's also terribly complex to generate and keep track of. There's been a\n\u003e\u003e nice attempt at creating an browser interface at coinb.in/multisig but it\n\u003e\u003e still lacks the kind of ease with created by the payment protocol. If there\n\u003e\u003e was a BIP then it would go a long way to aiding future usability of multisig\n\u003e\u003e wallet implementations.\n\u003e\u003e\n\u003e\u003e What are your thoughts?\n\u003e\u003e\n\u003e\u003e Drak\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Learn Graph Databases - Download FREE O'Reilly Book\n\u003e\u003e \"Graph Databases\" is the definitive new guide to graph databases and their\n\u003e\u003e applications. Written by three acclaimed leaders in the field,\n\u003e\u003e this first edition is now available. Download your free book today!\n\u003e\u003e http://p.sf.net/sfu/13534_NeoTech\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\n\u003e\n\u003e\n\u003e --\n\u003e --\n\u003e Gavin Andresen\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Learn Graph Databases - Download FREE O'Reilly Book\n\u003e \"Graph Databases\" is the definitive new guide to graph databases and their\n\u003e applications. Written by three acclaimed leaders in the field,\n\u003e this first edition is now available. Download your free book today!\n\u003e http://p.sf.net/sfu/13534_NeoTech\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Learn Graph Databases - Download FREE O'Reilly Book\n\u003e \"Graph Databases\" is the definitive new guide to graph databases and their\n\u003e applications. Written by three acclaimed leaders in the field,\n\u003e this first edition is now available. Download your free book today!\n\u003e http://p.sf.net/sfu/13534_NeoTech\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Learn Graph Databases - Download FREE O'Reilly Book\n\u003e \"Graph Databases\" is the definitive new guide to graph databases and their\n\u003e applications. Written by three acclaimed leaders in the field,\n\u003e this first edition is now available. Download your free book today!\n\u003e http://p.sf.net/sfu/13534_NeoTech\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\n\n\n-- \nJeff Garzik\nBitcoin core developer and open source evangelist\nBitPay, Inc.      https://bitpay.com/"}