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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1RJKRx-0004FG-Jv
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Oct 2011 07:32:29 +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 1RJKRv-0005iv-W0
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Oct 2011 07:32:29 +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 p9R7WGXu027850
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Thu, 27 Oct 2011 09:32:18 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CABsx9T3YnK9ogc3J39nO=Q+29daMTDhP2J_FGvpozTGAxD1z6Q@mail.gmail.com>
Date: Thu, 27 Oct 2011 09:32:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1089B122-1274-454C-9097-700D392BF0FA@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>
<7A50EE90-0FFC-45FB-A27F-786AEB23A8CA@ceptacle.com>
<CAAS2fgTx8gEztUt-UrDObMCQtfdzZc52fzS6c1q8mm+a-TjwjQ@mail.gmail.com>
<CABsx9T3YnK9ogc3J39nO=Q+29daMTDhP2J_FGvpozTGAxD1z6Q@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
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: 1RJKRv-0005iv-W0
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: Thu, 27 Oct 2011 07:32:29 -0000
OK, let me try to explain what I see is the problem:
So far we the bitcoin addresses are (for all practical purposes) a =
one-to-one mapping between a pubkey and uint160. This mean that your =
wallet is defined solely by your privatekeys (from which you can extract =
pubkeys and then uint160 btc-addresses).
This also enables you to make a uint160 to tx mapping on a server (like =
on blockexplorer) and use a thin client to query for transactions just =
from a list of uint160 (whether it holds the private keys behind them or =
not).
In the case of a multisig transaction, lets say the 2of3 example, you =
could e.g. have all 3 corresponding uint160s but only one privkey, but =
still query the server and know the value of an asset of uint160s.
This, I find a nice and clean setup, where cryptographic keys can be =
mapped to assets.
If we now consider the OP_EVAL proposal. Here, a new use of the uint160, =
namely as a mapping of ripemd160(something extra and hash256(pubkey)) is =
introduced. This means that this clean mapping is broken. Your will have =
an extra "public key" being the "something extra", and there is no easy =
way to do the mapping from a list of private keys to public keys to =
uint160s that will result in the new condensed uint160, except if you =
also have the knowledge of the script that was used.=20
I agree that it will work and I (and bitcoin-js and blockexplorer) can =
of change the concept of a wallet to also include scripts, but it breaks =
an intrinsic logic of uint160s and transactions that has so far been =
quite nice and clean.
So I also support checkmultisig to be the standard transaction type, but =
I do not appreciate the support of OP_EVAL.
Cheers,
Michael
On 26/10/2011, at 17:00, Gavin Andresen wrote:
> On Wed, Oct 26, 2011 at 4:58 AM, Michael Gr=F8nager =
<gronager@ceptacle.com> wrote:
>> I think it is a very important feature to be able to extract =
transaction to/from you only from your private keys.
>=20
> Why? If somebody is sending me bitcoins, then they'll have to get
> either an address or one or more public keys from me. OP_EVAL just
> lets me give them a short address that represents an arbitrary number
> of keys combined in an arbitrary way.
>=20
> I agree with Gregory: it shouldn't matter if that address is
> HASH(public key) or HASH(op_eval_script), the issues are the same (if
> you lose or cannot re-create the key/script then you're in trouble).
>=20
> Maybe I'm missing something; are you worried that blockexplorer won't
> know that coins sent to HASH(op_eval_script) are actually a
> complicated transaction until the coins are spent again? I'd consider
> that a feature, not a bug, because only the people involved in the
> transaction need to know the details until after the transaction is
> complete.
>=20
> Feel free to contact me about your 'tiered implementation for thin
> clients' -- I don't think OP_EVAL will make that significantly harder.
>=20
> I also agree with Alan: using OP_EVAL is not mandatory, I'm proposing
> that CHECKMULTISIG becomes a standard transaction type.
>=20
> --=20
> --
> Gavin Andresen
Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: gronager@ceptacle.com
|
