Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WNALs-00053X-Aa for bitcoin-development@lists.sourceforge.net; Tue, 11 Mar 2014 00:15:24 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.212.176 as permitted sender) client-ip=209.85.212.176; envelope-from=jgarzik@bitpay.com; helo=mail-wi0-f176.google.com; Received: from mail-wi0-f176.google.com ([209.85.212.176]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WNALr-0008Bl-2V for bitcoin-development@lists.sourceforge.net; Tue, 11 Mar 2014 00:15:24 +0000 Received: by mail-wi0-f176.google.com with SMTP id hr14so175783wib.9 for ; Mon, 10 Mar 2014 17:15:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RzW3fJesIxLoKrJ69AKxWIRIN+IjObDbU66fFNiOf5Y=; b=hbzPT0ykM3ltUK4WEV9BYXywPuxcgTguNZ2w83C3E6MJyTWhjOH9AkS8MghP6vXw/M +l66ZcNeEuwjLLY0Ay3uemsBiIZgXspVDVbi4nBPbIFi3uPlRfYXhx8DNppCxa7ow9Qv WjmHtCAb3h1jRDusGaIrwk5ZIfwvbij8EHzz349YU760cTk/BQZy4BYgEjEH/OyHAynA BMUOjgpZD40BYETKJXas7zIzlP6RHsKgt/CNjjJrbFMj9WKMOofPFU0KmTsZQSQzfhVT 4Hd7fDeJoACuczbuhNf33Y1mtjKFTPUtEg3EjbnPJwa2Mot3TMGyct44FnV3+rxZdIOY 71qQ== X-Gm-Message-State: ALoCoQn4D6SGJpHd6WXIQXHOByMbyXR6qAQV4I/d7EzgU61le6n+2n8HCmut7lCY9NOv6ZH1Db+t X-Received: by 10.194.174.42 with SMTP id bp10mr389645wjc.57.1394496916831; Mon, 10 Mar 2014 17:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.82.197 with HTTP; Mon, 10 Mar 2014 17:14:56 -0700 (PDT) In-Reply-To: <531E5454.1030601@gmail.com> References: <531DFDF8.80008@gmail.com> <531E52FE.5090107@jerviss.org> <531E5454.1030601@gmail.com> From: Jeff Garzik Date: Mon, 10 Mar 2014 20:14:56 -0400 Message-ID: To: Alan Reiner Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WNALr-0008Bl-2V Cc: Bitcoin Dev , kjj Subject: Re: [Bitcoin-development] Multisign payment protocol? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 00:15:24 -0000 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 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 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/