Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QZQDY-00083M-Jt for bitcoin-development@lists.sourceforge.net; Wed, 22 Jun 2011 16:23:52 +0000 Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1QZQDX-0005nH-HX for bitcoin-development@lists.sourceforge.net; Wed, 22 Jun 2011 16:23:52 +0000 Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10]) by karen.lavabit.com (Postfix) with ESMTP id 5603611BBAE; Wed, 22 Jun 2011 11:23:46 -0500 (CDT) Received: from lavabit.com (chomsky.torservers.net [77.247.181.162]) by lavabit.com with ESMTP id E884OOME90MX; Wed, 22 Jun 2011 11:23:46 -0500 Received: from 77.247.181.162 (SquirrelMail authenticated user bgroff) by lavabit.com with HTTP; Wed, 22 Jun 2011 12:23:46 -0400 (EDT) Message-ID: <59140.77.247.181.162.1308759826.squirrel@lavabit.com> In-Reply-To: References: <18440.87.106.138.84.1308200020.squirrel@lavabit.com> Date: Wed, 22 Jun 2011 12:23:46 -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: 1QZQDX-0005nH-HX 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 16:23:52 -0000 Gavin said: > 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. I currently have 2,ADDR1,ADDR2,ADDR3 (2-of-3 example) as this new address type. > > It would be great if the "higher level protocol" for pay-to-escrow was > just get a bitcoin address via https (or other secure mechanism), like > we do now for pay-to-single-party. Where the person you're paying has > their own mechanisms for generating or fetching/authenticating the > public keys, and knows which bitcoin addresses they've published. Agreed. > All of which makes me wonder if the straightforward "n PUBKEYS m > CHECKMULTISIG" transaction type is the right thing to do. > Following the pattern of our standard DUP HASH160 etc. transaction > type, maybe 2 of 2 and 2 of three should be: > > 2DUP ADD HASH160 ...hash(pubkey1+2)... EQUALVERIFY 2 2 ROLL > CHECKMULTISIGVERIFY > 3DUP ADD ADD HASH160 ...hash(pubkey1+2+3)... EQUALVERIFY 2 3 ROLL > CHECKMULTISIGVERIFY > > Spending those transactions would mean putting the m signatures and > the n public keys in the TxIn, but sending funds you'd only need the > hash of the sum of the public keys. This is similar to the way the current implementation works. It uses HASH160, but there's no attempt to save space by hashing the sum of the pubkeys. The major advantage of summing is shorter address for the end user to copy-paste. The disadvantage is the need for long term storage o= f the key set so you know what keys to sign with. > -- > Gavin Andresen > http://clearcoin.com/ -- Bobby Groff