From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QZUI3-00019Z-2y for bitcoin-development@lists.sourceforge.net; Wed, 22 Jun 2011 20:44:47 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of lavabit.com designates 72.249.41.33 as permitted sender) client-ip=72.249.41.33; envelope-from=bgroff@lavabit.com; helo=karen.lavabit.com; Received: from karen.lavabit.com ([72.249.41.33]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1QZUI2-0007qe-77 for bitcoin-development@lists.sourceforge.net; Wed, 22 Jun 2011 20:44:46 +0000 Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10]) by karen.lavabit.com (Postfix) with ESMTP id 7604711BB4C; Wed, 22 Jun 2011 15:44:40 -0500 (CDT) Received: from lavabit.com (raidz.torservers.net [46.19.138.242]) by lavabit.com with ESMTP id BKK3H9FHOM1V; Wed, 22 Jun 2011 15:44:38 -0500 Received: from 46.19.138.242 (SquirrelMail authenticated user bgroff) by lavabit.com with HTTP; Wed, 22 Jun 2011 16:44:38 -0400 (EDT) Message-ID: <11814.46.19.138.242.1308775478.squirrel@lavabit.com> In-Reply-To: References: <18440.87.106.138.84.1308200020.squirrel@lavabit.com> Date: Wed, 22 Jun 2011 16:44:38 -0400 (EDT) From: bgroff@lavabit.com To: "Gavin Andresen" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.4 (-) 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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-Headers-End: 1QZUI2-0007qe-77 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] [PULL] Add scriptPubKey enforced sendescrow and redeemescrow API calls 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: Wed, 22 Jun 2011 20:44:47 -0000 Gavin wrote: > It would be spiffy to publish a new type of bitcoin address that is an > "m of n address", that anybody could pay into, but would require m of > n signatures to spend. Publishing a really really long address with > all n public keys would work. Here's a strawman use-case for a browser centric flow for a 2-of-3 scenar= io. Funding: * User is on Merchant site on the checkout page * User selects a transaction Observer (I'm trying to get away from using the word escrow, because the funds are not held by the third party) * Merchant redirects to the Observer, passing in the Merchant's payout address * The User enters User's address * Observer presents multisign address "2,merchant-addr,user-addr,observer-addr" and terms and conditions - i.e. under what circumstances the Observer will sign * User copy/pastes the multisign address to their bitcoin client and send= s funds * After some blocks go by, merchant ships Redemption: * Merchant reminds User to release funds * User creates a partial tx paying out to merchant-addr and emails or copy-pastes to Merchant * Merchant signs and publishes the tx Funding requires two pastes and redemption requires one. A browser plug-in would reduce the User effort to a couple of confirmatory clicks - "do you want to send X BTC to Merchant Y with Observer Z?" and "do you want to release X BTC to Merchant Y?". -- Bobby Groff