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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1RIeZL-00035S-JD
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Oct 2011 10:49:19 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RIeZJ-0006eW-CU
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Oct 2011 10:49:19 +0000
Received: by wwi36 with SMTP id 36so473678wwi.10
for <bitcoin-development@lists.sourceforge.net>;
Tue, 25 Oct 2011 03:49:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.143.13 with SMTP id k13mr4593078wej.61.1319539751099; Tue,
25 Oct 2011 03:49:11 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.10.148 with HTTP; Tue, 25 Oct 2011 03:49:11 -0700 (PDT)
Date: Tue, 25 Oct 2011 12:49:11 +0200
X-Google-Sender-Auth: Xq2Z58vYWdtDene0Y87vfSrfnoc
Message-ID: <CANEZrP1ic4RXFzoqf66MGv=rJe3MgWxVi5nnk2VKkMc4VMCDyw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
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 commonly abused enduser mail provider
(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.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RIeZJ-0006eW-CU
Subject: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to
you
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: Tue, 25 Oct 2011 10:49:19 -0000
scriptPubKeys that use OP_EVAL contain a hash of a script. If I
understand correctly, that means to detect a transaction in a block
that is relevant to your wallet, that means you need to pre-calculate
every possible hash that might appear.
For the case of a single payment, that's not a problem. It means for
each key you now have to check for:
- raw key
- key hash
- hash of script that contains key hash
- hash of script that contains raw key
which isn't so bad.
What is the complexity like when multi-signing comes into the picture?
I *think* it's not an issue for the use cases currently envisioned,
but being unable to "see into" a script could complicate things later.
Specifically: for a wallet protection service, you have to make sure
the WPS keys are matched 1:1 with your own private keys. You must
never mix them up otherwise you have to check the block chain for the
cross-product. Deterministic wallets are one way to achieve that
without compromising privacy.
For escrow contracts, using OP_EVAL means you cannot detect them
unless the sender has told you the pubkey they are going to use,
because otherwise you can't recreate the hashed script. Escrow
protocols require some out of band communication anyway in order to
set up the escrow key, so this isn't inherently a problem.
Are there any use cases where you will want to recognize transactions
to you, where you can't predict the full script contents?
|
