[Bitcoin-development] [PULL] Add scriptPubKey enforced sendescrow and redeemescrow API calls

bgroff at lavabit.com bgroff at lavabit.com
Wed Jun 22 16:23:46 UTC 2011

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

> 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.


> 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
> 3DUP ADD  ADD HASH160 ...hash(pubkey1+2+3)... EQUALVERIFY 2 3 ROLL
> 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 of
the key set so you know what keys to sign with.

> --
> Gavin Andresen
> http://clearcoin.com/

Bobby Groff

More information about the bitcoin-dev mailing list