Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WN4Am-0006MZ-CQ for bitcoin-development@lists.sourceforge.net; Mon, 10 Mar 2014 17:39:32 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of zikula.org designates 74.125.82.42 as permitted sender) client-ip=74.125.82.42; envelope-from=drak@zikula.org; helo=mail-wg0-f42.google.com; Received: from mail-wg0-f42.google.com ([74.125.82.42]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WN4Aj-0002hA-IX for bitcoin-development@lists.sourceforge.net; Mon, 10 Mar 2014 17:39:32 +0000 Received: by mail-wg0-f42.google.com with SMTP id y10so9053342wgg.25 for ; Mon, 10 Mar 2014 10:39:23 -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:from:date:message-id:subject:to :content-type; bh=kDOSnLjJuAoiCqxj9+P2AG1eJGbA1NAf0B5c0ckYhxc=; b=citDDcKJZEiThyCoO5kMub7pvReQAPYKgXh3Q5/3uPmfyuc82E38oT7/FxNrlHf8cC VXai4Ci5WGqIh1cqKqBa//GZRyIMxuulTgV7vevHld8lsIjDQ7XHSPDQ3UuNuBdD2BGq zD8M621ebYqwbpAGM+pUwNHkccCAZUTq6FC0WZ8ZoKxE+tf1cij49Ycx/6rbggf7XycO AvR29bqzAZ5NW/PfIMleKI+Yn4tEEMPjwHZJCXEPIC5zL+OOsFjRKlXZTi/Enta1Kfqw Xdi/g/sXSTQDdLY7Qnj1QFdPd1aVrTXZbKo9d74dCn9jMMtFkVl6u0ARQL84XHuUGPjp Fn2w== X-Gm-Message-State: ALoCoQl5n8UWXh08TvSKPIZDcJ3jYhrXdv+UHDADtfUUObJXJqp18ddiEBoRL3kjLXrpGSypOttd X-Received: by 10.194.82.35 with SMTP id f3mr32655367wjy.36.1394473163258; Mon, 10 Mar 2014 10:39:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.205.69 with HTTP; Mon, 10 Mar 2014 10:39:03 -0700 (PDT) From: Drak Date: Mon, 10 Mar 2014 17:39:03 +0000 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7bf0c1068b967704f4441513 X-Spam-Score: -0.5 (/) 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 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WN4Aj-0002hA-IX Subject: [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: Mon, 10 Mar 2014 17:39:32 -0000 --047d7bf0c1068b967704f4441513 Content-Type: text/plain; charset=UTF-8 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 --047d7bf0c1068b967704f4441513 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was wondering if there would be merit in a kind of BIP f= or 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 inst= ead of 2 of 2 where the malicious party generates the multisig address+scri= pt and thus be able to run off with funds anyway.

It's also terribly complex to generate and keep tra= ck of. There's been a nice attempt at creating an browser interface at = coinb.in/multisig but it still lac= ks the kind of ease with created by the payment protocol. If there was a BI= P then it would go a long way to aiding future usability of multisig wallet= implementations.

What are your thoughts?

Drak
--047d7bf0c1068b967704f4441513--