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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 18A35B9E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Sep 2017 10:03:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149058.authsmtp.co.uk (outmail149058.authsmtp.co.uk
[62.13.149.58])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 57604A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Sep 2017 10:03:34 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8DA3WKZ071963;
Wed, 13 Sep 2017 11:03:32 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8DA3TH9062166
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 13 Sep 2017 11:03:30 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 5A8C940107;
Wed, 13 Sep 2017 10:03:29 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 91EE220435; Wed, 13 Sep 2017 06:03:28 -0400 (EDT)
Date: Wed, 13 Sep 2017 06:03:28 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <greg@xiph.org>
Message-ID: <20170913100328.GA1613@savin.petertodd.org>
References: <CAAS2fgTGhCztV5bwLQj28_M7e=uzwbdF2Rum_7gmQGjhgxqLuQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <CAAS2fgTGhCztV5bwLQj28_M7e=uzwbdF2Rum_7gmQGjhgxqLuQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: cbe0a3db-986a-11e7-b1e8-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwEUC1AEAgsB AmEbWlVeUF57WmI7 bghPaBtcak9QXgdq
T0pMXVMcUg0ccB9l fhceVBtzcQMIeX52 bEIsDSIOXBV5IRRg
S0ZSRHAHZDJndTIe BUhFdwNVdQJNeEwU a1l3GhFYa3V6PyQl
Aw46dzE3dR5jYCpS WEknLE4ZRkcNWHYD TgtQVQ4BVVUfQD00
NBUieBYEBkERM08z LTlpRFQDKxIUBgRU G0wFBzJFP0QdXGI0
DB9aFUcbFyBbXXIE agAA
X-Authentic-SMTP: 61633532353630.1038:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW
autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Minutia in CT for Bitcoin. Was: SF proposal:
prohibit unspendable outputs with amount=0
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Sep 2017 10:03:35 -0000
--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Sep 13, 2017 at 09:39:28AM +0000, Gregory Maxwell wrote:
> On Wed, Sep 13, 2017 at 9:24 AM, Peter Todd via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 2) Spending CT-shielded outputs to unshielded outputs
> >
> > Here one or more CT-shielded outputs will be spent. Since their value i=
s zero,
> > we make up the difference by spending one or more outputs from the CT p=
ool,
> > with the change - if any - assigned to a CT-pool output.
>=20
> Can we solve the problem that pool inputs are gratuitously non-reorg
> safe, without creating something like a maturity limit for shielded to
> unshielded?
So to be clear, we have two versions of this problem:
1) CT signatures do *not* sign which pool input they're using
Here, obviously the inputs can be changed at will by miners. An implementat=
ion
could have the exact CT pool input be something miners add; the CT transact=
ions
broadcast on the P2P network wouldn't actually need them.
2) CT signatures *do* sign which pool input they're using
Wallets would pick the input at random. This is required if you want to hav=
e a
transaction spending both CT and legacy inputs. This reduces the reorg risk=
to
double-spends. While double-spends are always a potential problem, the prob=
lem
is somewhat worse here, as even regular wallets are spending inputs that an=
yone
can choose to spend.
> So far the best I have is this: Support unshielded coins in shielded
> space too. So the only time you transition out of the pool is paying
> to a legacy wallet. If support were phased in (e.g. addresses that
> say you can pay me in the pool after its enabled), and the pool only
> used long after wallets supported getting payments in it, then this
> would be pretty rare and a maturity limit wouldn't be a big deal.
So basically, you're essentially observing that in the event that everyone =
uses
CT, this isn't actually a problem; you're allowing everyone to "use" CT, by
trying to allow even unshielded outputs to "use" it.
Which means by "unshielded output", what you *actuall* mean is creating a CT
transaction where the output - even though it's a zero-valued CT output - is
constructed such that the value is public information.
Or do you mean trying to have non-CT outputs in the pool somehow? I don't t=
hink
that makes sense, because the whole point of the pool is that the outputs i=
n it
are anyone-can-spend, and thus any CT transaction may spend them; which CT
transaction spends them gives no information about the ownership of the coi=
ns.
This is incompatible with anything but anyone-can-spend outputs.
> Can better be done?
Note that the order in which outputs in the pool are spent can be
deterministic. For example, you could say that each transaction must spend =
the
oldest outputs in the pool (that sum to the value needed). You could probab=
ly
come up with a scheme where the outputs that will be spent in the future in=
the
event that the output is spent back to an unshielded output is fixed when t=
he
output was created, for example, by picking a random index. While this woul=
dn't
prevent all collisions, it'd may be possible to make reorgs relatively safe=
, by
constraining how miners could txids.
Specifically, you could imagine a scheme where if a given input set can onl=
y be
satisified by unspent pool outputs with index's >=3D i, then the miner woul=
d need
to have the ability to mine a conflicting transaction that also happened to
have the same pool output set. Given a sufficiently large set of pool outpu=
ts,
this may be an impractical attack most of the time.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJZuQJsAAoJECSBQD2l8JH72K8H/2xNHvF9K+t0sWF+ALvKcs0g
o7cq64NpTduzkPRcfNk3ZjyuTJJ6wxwtOXVS+wRGq74OvcX8uCryAi4Ak8cfVn/X
Ya6opzbZ82/Wo82nK5oyq/VR250wxvVNrLFIqF28ywQf2FoIbzLWNwxTO7R97J4w
astJyZQYUcXdchKit2cFlJHZKGgW7yhlQ1xFj6iA0ZV+PdD2aY+nGWeiVkjUHQ6m
HWyEG0qiiWod5r31wdfKo8TL7CKRBEhxNgtkDtLrE6obZhdo0GD/w0YFV9irQoPA
48UBdu6azMgnIvMC+EOgioJw2kpT4qtOv0FjMuYvuUb+9iH16TmliheE/bo5qMM=
=CBVX
-----END PGP SIGNATURE-----
--W/nzBZO5zC0uMSeA--
|
