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; 
Message-ID: <59140.77.247.181.162.1308759826.squirrel@lavabit.com>
In-Reply-To: <BANLkTikP-VheXQyXikH6jvaqnWfH_cNjnw@mail.gmail.com>
References: <18440.87.106.138.84.1308200020.squirrel@lavabit.com>
	<BANLkTi=FTLnU-riNVYssnR9FLdcEeZX7gOS6Zdv1f_XDcJoSSg@mail.gmail.com>
	<BANLkTikkBoHBr8z6Uv7oGU_KuT0bvgx3HA@mail.gmail.com>
	<BANLkTinUbJ6CKczHiyX2esMyRWgUrJ_9ASeOqZbRj+23GZgjcQ@mail.gmail.com>
	<BANLkTikP-VheXQyXikH6jvaqnWfH_cNjnw@mail.gmail.com>
Date: Wed, 22 Jun 2011 12:23:46 -0400 (EDT)
From: bgroff@lavabit.com
To: "Gavin Andresen" <gavinandresen@gmail.com>
User-Agent: SquirrelMail/1.4.13
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [PULL] Add scriptPubKey enforced
 sendescrow and redeemescrow API calls
Precedence: list

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