1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1QZOkf-0006cr-LA
for bitcoin-development@lists.sourceforge.net;
Wed, 22 Jun 2011 14:49:57 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=mh.in.england@gmail.com;
helo=mail-vw0-f47.google.com;
Received: from mail-vw0-f47.google.com ([209.85.212.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QZOke-00008B-TR
for bitcoin-development@lists.sourceforge.net;
Wed, 22 Jun 2011 14:49:57 +0000
Received: by vws2 with SMTP id 2so962827vws.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 22 Jun 2011 07:49:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.177.234 with SMTP id ct10mr1054382vdc.2.1308754191402; Wed,
22 Jun 2011 07:49:51 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.52.155.38 with HTTP; Wed, 22 Jun 2011 07:49:51 -0700 (PDT)
In-Reply-To: <BANLkTikkBoHBr8z6Uv7oGU_KuT0bvgx3HA@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>
Date: Wed, 22 Jun 2011 16:49:51 +0200
X-Google-Sender-Auth: zz6XkpYmxZqpD-cc4yzkte-oKpU
Message-ID: <BANLkTinUbJ6CKczHiyX2esMyRWgUrJ_9ASeOqZbRj+23GZgjcQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.1 (-)
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 FREEMAIL_FROM Sender email is freemail (mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 RFC_ABUSE_POST Both abuse and postmaster missing on sender domain
0.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QZOke-00008B-TR
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2011 14:49:57 -0000
> Mike: =C2=A0Did Satoshi ever tell you what he was thinking for the best w=
ay
> 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. =C2=A0It'd be nice if there were generic
> OP_N << OP_PUBKEY_N << OP_N =C2=A0... template matching opcodes, but ther=
e 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:
> =C2=A0version byte
> =C2=A0m
> =C2=A0n
> =C2=A0hash of xor of all n public keys
> =C2=A0checksum
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.
|
