public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: bgroff@lavabit•com
To: "Gavin Andresen" <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [PULL] Add scriptPubKey enforced sendescrow and redeemescrow API calls
Date: Wed, 22 Jun 2011 12:23:46 -0400 (EDT)	[thread overview]
Message-ID: <59140.77.247.181.162.1308759826.squirrel@lavabit.com> (raw)
In-Reply-To: <BANLkTikP-VheXQyXikH6jvaqnWfH_cNjnw@mail.gmail.com>

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 of
the key set so you know what keys to sign with.

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

--
Bobby Groff





  parent reply	other threads:[~2011-06-22 16:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-16  4:53 bgroff
2011-06-22 13:24 ` Mike Hearn
2011-06-22 13:42   ` Mike Hearn
2011-06-22 16:01     ` bgroff
2011-06-22 14:08   ` Gavin Andresen
2011-06-22 14:49     ` Mike Hearn
2011-06-22 15:32       ` Gavin Andresen
2011-06-22 16:02         ` Mike Hearn
2011-06-22 16:23         ` bgroff [this message]
2011-06-22 19:33           ` bgroff
2011-06-22 20:44         ` bgroff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59140.77.247.181.162.1308759826.squirrel@lavabit.com \
    --to=bgroff@lavabit$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=gavinandresen@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox