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