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
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1RIzK4-0006rf-Cc
for bitcoin-development@lists.sourceforge.net;
Wed, 26 Oct 2011 08:58:56 +0000
X-ACL-Warn:
Received: from backup-server.nordu.net ([193.10.252.66])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1RIzK2-0007lT-Kq
for bitcoin-development@lists.sourceforge.net;
Wed, 26 Oct 2011 08:58:56 +0000
Received: from [109.105.106.199] ([109.105.106.199]) (authenticated bits=0)
by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9Q8wjo1029693
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Wed, 26 Oct 2011 10:58:47 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CALf2ePy=3N1JQodP3s9PzH=Af1z-7qGdy_4=QW9-CJmaxYGz5Q@mail.gmail.com>
Date: Wed, 26 Oct 2011 10:58:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A50EE90-0FFC-45FB-A27F-786AEB23A8CA@ceptacle.com>
References: <CANEZrP1ic4RXFzoqf66MGv=rJe3MgWxVi5nnk2VKkMc4VMCDyw@mail.gmail.com>
<CABsx9T3WKv3RLWT+Q6s7cCLzDL3sVRCWfmPiKcSp=_Re05m+zQ@mail.gmail.com>
<CAAS2fgSYwUdiyY2XfHhWn+aN_6a72XRKs-8W7ibZM5t0tZ28rg@mail.gmail.com>
<CALf2ePy=3N1JQodP3s9PzH=Af1z-7qGdy_4=QW9-CJmaxYGz5Q@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
X-Mailer: Apple Mail (2.1251.1)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1RIzK2-0007lT-Kq
Subject: Re: [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: Wed, 26 Oct 2011 08:58:56 -0000
I think it is a very important feature to be able to extract transaction =
to/from you only from your private keys. In the standard transactions =
this is easily accomplished - in the case you only want to find the addr =
to tx mapping:
vector<pair<opcodetype, vector<unsigned char> > > vSolution;
if (!Solver(scriptPubKey, vSolution))
return 0;
BOOST_FOREACH(PAIRTYPE(opcodetype, vector<unsigned char>)& item, =
vSolution)
{
vector<unsigned char> vchPubKey;
if (item.first =3D=3D OP_PUBKEY)
// encode the pubkey into a hash160
return Hash160(item.second);
else if (item.first =3D=3D OP_PUBKEYHASH)
return uint160(item.second); =20
}
This possibility is used today in:
* blockexplorer
* bitcoin-js
* my own tiered implementation for thin clients
I agree that you can of course always construct payment schemes to hide =
payments (hashes from classic novels, sending the private key off line =
etc), but I consider those either exotic or on purpose hidden, and hence =
they are not really a problem, nor an argument that this feature does =
not really exist today.
So, if we introduce a standard (multikey) payment that hides the address =
(or makes it overly complicated to extract it) it will be a major =
problem for the projects that I listed above.=20
I will post a more detailed technical comment reflecting directly on the =
BIPs, but the wiki is currently down and I need to re-read the BIPs =
first.
Cheers,
Michael
On 25/10/2011, at 18:47, Alan Reiner wrote:
> On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell <gmaxwell@gmail.com> =
wrote:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen =
<gavinandresen@gmail.com> wrote:
>> You give the hash to whoever is paying you, and store the hash -->
>> script mapping when you do that (assuming you're not using a
>> deterministic wallet; if you are, you probably just increment a
>> counter in the wallet).
>=20
> If anyone finds that solution unsatisfying, consider=97 It's already =
the
> case that I could take one of your disclosed public keys and create an
> infinite series of secondary keys out of it for which only you could
> decode, and the only way for you to find them in the blockchain would
> be to have performed the same procedure and made a note of the
> addresses you're watching for.
>=20
>=20
> (1) As I understand it, OP_EVAL is being proposed as an *optional* =
tool for multi-signature transactions. It sounds like to me, that you =
can still use the regular OP_CHECKMULTISIG if you are concerned about =
these things. If you're dealing with too many parties with questionable =
reliability that they will notify you of transacitons that include you, =
I don't see anything wrong with declaring that you'd only prefer dealing =
with OP_CMS transactions and not OP_EVAL (besides some grumbling from =
them that their way is "better"). Either way, they're screwing =
themselves, too, if they want to include you on transactions and don't =
notify you as such (kind of defeats the purpose of multi-sig txs).
>=20
> (2) I think it's unnecessary to discuss cases where you somehow lose =
your mappings but not your private keys. In order for OP_EVAL scripts =
to work, the subscripts/mappings are *just as important* as your regular =
private keys. They should be kept in your wallet forever just like your =
private keys--and thus you lose none of them or all of them. The only =
real difference is that they aren't sensitive like your private keys, so =
they don't have to be encrypted.
>=20
> (3) There should most definitely be a button on the main client that =
allows you to "Add OP_EVAL script" or something along those lines (maybe =
something with a less obscure name). We need to make it as easy as =
possible for someone to add such a script/mapping to their wallet. =
Although, this invites a breach of one of my core rules of user =
interfaces: if the functionality is dependent on the user performing =
some regular maintenance task, you better be prepared for all users to =
fail at doing it. Even diligent users are going to forget/mess-up =
sometimes. If failure at performing this task results in breaking the =
client or losing money, we should avoid promoting that usage paradigm.
>=20
> =
--------------------------------------------------------------------------=
----
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn=20
> about Cisco certifications, training, and career opportunities.=20
> =
http://p.sf.net/sfu/cisco-dev2dev_________________________________________=
______
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
