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
|
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 533D6B6C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Sep 2017 09:24:47 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148108.authsmtp.net (outmail148108.authsmtp.net
[62.13.148.108])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5BF913E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Sep 2017 09:24:46 +0000 (UTC)
Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245])
by punt23.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8D9OdYk043398;
Wed, 13 Sep 2017 10:24:39 +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 v8D9Oav5053671
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 13 Sep 2017 10:24:37 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id A55864010B;
Wed, 13 Sep 2017 09:24:35 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id DC8CE20435; Wed, 13 Sep 2017 05:24:34 -0400 (EDT)
Date: Wed, 13 Sep 2017 05:24:34 -0400
From: Peter Todd <pete@petertodd.org>
To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@jtimon.cc>
Message-ID: <20170913092434.GA1094@savin.petertodd.org>
References: <CABm2gDojDQWMhw8wW1UkRGKtdbby2+6AFFZLPuRcUb7WF_u5qQ@mail.gmail.com>
<20170907180014.GA13727@fedora-23-dvm>
<CABm2gDpy3a0vc+4=0a2vFSQ2d1gaAWFkPtzdbXLpNKYFepDU3A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z"
Content-Disposition: inline
In-Reply-To: <CABm2gDpy3a0vc+4=0a2vFSQ2d1gaAWFkPtzdbXLpNKYFepDU3A@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 5cc7cbc5-9865-11e7-801f-9cb654bb2504
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwEUC1AEAgsB AmEbWlReUll7WmQ7 bghPaBtcak9QXgdq
T0pMXVMcUg0cCGNQ QBseVxp0cAQIcXl0 ZwhnDSNcDxYpcFt0
SkhRCGwHMGB9YGAe Bl1RJFFSdQcYLB1A alQxNiYHcQ5VPz4z
GA41ejw8IwAXEwod WhsKNVUJSEJZViYm QBADFzQzVVADXD0+
KRAvIFoRVEEMLl0v LUBpRlMEM31aAwhZ AkdRVXcx
X-Authentic-SMTP: 61633532353630.1039: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] 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 09:24:47 -0000
--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Sep 09, 2017 at 11:11:57PM +0200, Jorge Tim=F3n wrote:
> Tier Nolan, right, a new tx version would be required.
>=20
> I have to look deeper into the CT as sf proposal.
>=20
> What futures upgrades could this conflict with it's precisely the
> question here. So that vague statement without providing any example
> it's not very valuable.
So with Confidential Transactions, the only thing that's changed relative t=
o a
normal Bitcoin transaction is that fact that the sum of input values is >=
=3D the
sum of output values is proven via a CT proof, rather than revealing the ac=
tual
sums. Other than that, CT transactions don't need to be any different from
regular transactions.
For CT to be a softfork, we have to ensure that each CT transaction's sum of
inputs and outputs is valid. An obvious way to do this is to have a pool of
"shielded" outputs, whose total value is the sum of all CT-protected output=
s.
Outputs in this pool would appear to be anyone-can-spend outputs to pre-CT
nodes.
This gives us three main cases:
1) Spending unshielded outputs to CT-shielded outputs
Since the CT-shielded output's value is unknown, we can simply set their va=
lue
to zero. Secondly, we will add the newly CT-shielded value to the pool with=
an
additional output whose value is the sum of all newly created CT-shielded
outputs.
2) Spending CT-shielded outputs to unshielded outputs
Here one or more CT-shielded outputs will be spent. Since their value is ze=
ro,
we make up the difference by spending one or more outputs from the CT pool,
with the change - if any - assigned to a CT-pool output.
3) Spending CT-shielded outputs to CT-shielded outputs
Since both the inputs and outputs are zero-valued, to pre-CT nodes the
transaction is perfectly valid: the sum of coins spent is 0 BTC, and the su=
m of
coins created is also 0 BTC. We do have the problem of paying miners fees, =
but
that could be done with an additional CT output that the miner can spend, a
child-pays-for-parent transaction, or something else entirely that I haven't
thought of.
> Although TXO commitments are interesting, I don't think they make UTXO
> growth a "non-issue" and I also don't think they justify not doing
> this.
>=20
> Yeah, the costs for spammers are very small and doesn't really improve
> things all that much, as acknowledged in the initial post.
Suppose zero-valued outputs are prohibited. In case #3 above, if there are =
more
outputs than inputs, we need to add an additional input from the CT-shielded
pool to make up the difference, and an additional change output back to the
CT-shielded pool.
If shielded-to-shielded transactions are common, these extra outputs could
consume a significant % of the total blockchain space - that's a significant
cost. Meanwhile the benefit is so small it's essentially theoretical: an
additional satoshi per output is an almost trivial cost to an attacker.
Quite simply, I just don't think the cost-benefit tradeoff of what you're
proposing makes sense.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJZuPlPAAoJECSBQD2l8JH7co4H/AxfpvIWpLMPbQaZKv98I0hS
CAIq8Pu2eNtMfYFadnuHE/deTdhJGT1oIPU6Yn9aGieoGT8PGU5TcEZBKOn8n2+R
ttWb64Kwpe78euXkPldldWUBD/sN312g1QhHLMo8ISotdGRnfjx/TlPhbsGCfWfU
6jIsjlZxfV5Q+rGEpP8rhgvxBgvhZG9RsVMT8FA7MOUWmRApQAtPTk0ldx2lP73k
S0yafZprCsKbnSpFLsOU7U+b87owxxLPsnRi18x59Dm81uESsKfUEfSV/kII/odF
lZo627ysqJBfXswgRJy90FfAqYGFZsIWM5dHTplVJzPNSHV2Gdh6fmjDMOITdZw=
=ghij
-----END PGP SIGNATURE-----
--Nq2Wo0NMKNjxTN9z--
|
