From: Mike Hearn <mike@plan99•net>
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 16:49:51 +0200 [thread overview]
Message-ID: <BANLkTinUbJ6CKczHiyX2esMyRWgUrJ_9ASeOqZbRj+23GZgjcQ@mail.gmail.com> (raw)
In-Reply-To: <BANLkTikkBoHBr8z6Uv7oGU_KuT0bvgx3HA@mail.gmail.com>
> Mike: Did Satoshi ever tell you what he was thinking for the best way
> to implement MULTISIG transactions?
He didn't. Satoshi told me very little unfortunately. What he did tell
me, I've written up about half of it. I still have high frequency
trading and some details of obscure SIGHASH types to go, but I wanted
to find examples to illustrate them first as Satoshi only gave the
vaguest of outlines.
> I'm wondering if hard-coding new standard script templates in
> script.cpp Solver():
CHECKMULTISIG allows up to 20 keys, I think. So it'd probably be
better to just have a bit of custom logic that checks if the script is
of the right form.
> ... would be the right approach to support 1/2 of 2 and 1/2/3 of 3
> signatures. It'd be nice if there were generic
> OP_N << OP_PUBKEY_N << OP_N ... template matching opcodes, but there aren't.
I suppose they could be added if need be. Template matching opcodes
might come in useful later when clients only want to download
transactions of interest to them.
> I'm also wondering if it makes sense to just support 2-of-2 (for
> validate-on-multiple-devices) and 2-of-3 (for escrow) for now.
Given the costs involved with adding new transaction types, I'd go for
allowing any number of signatures up to the max.
> I think all of these could use a new type of bitcoin payment address;
> it might make sense for THAT to be generic, maybe containing:
> version byte
> m
> n
> hash of xor of all n public keys
> checksum
I don't understand what this is for. For triggering such a transaction
via the UI, I think establishing a higher level protocol would be
needed. It's a separate step.
For instance, it's not safe to use escrow until you've checked that
the escrow key is owned by who you think it is. Otherwise a buyer
could give you a 2-of-3 transaction where they own both keys. So there
needs to be some kind of protocol (probably HTTP based) where the
buyer communicates to the merchant a list of acceptable escrow
agencies, the merchant intersects with the list of agencies it
accepts, there needs to be a way to request a pubkey from a remote
domain, one side needs to be able to challenge that domain with a
nonce, etc. It's quite complicated and would need to be specced out
independently of supporting multipay transactions.
> I'm most interested in the 2-of-2 case; I think merchants and
> exchanges need bitcoin deposit/payment addresses that they can make
> secure by requiring a 2-step signature process for spending those
> funds.
Yes it's one way to achieve security. Having BitBanks that store your
coins and require you to verify tx acceptance with an external device
is even stronger, because that external device can be guaranteed
virus/clone-proof. Some banks do this today for wire transfers (they
implicitly assume you get the wire details out of band or that no
virus can rewrite wiring instructions to point somewhere else).
But it'll be a while yet before any such company arises. Until then
2-of-2 transactions are probably a good halfway point.
next prev parent reply other threads:[~2011-06-22 14:49 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 [this message]
2011-06-22 15:32 ` Gavin Andresen
2011-06-22 16:02 ` Mike Hearn
2011-06-22 16:23 ` bgroff
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=BANLkTinUbJ6CKczHiyX2esMyRWgUrJ_9ASeOqZbRj+23GZgjcQ@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--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