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
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
|
Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A6969B9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Sep 2017 09:56:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com
[209.85.218.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6CB51BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Sep 2017 09:56:20 +0000 (UTC)
Received: by mail-oi0-f42.google.com with SMTP id x190so40118473oix.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 07 Sep 2017 02:56:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=VE13RC6aCGt+MVe3iEB6xPCTBbX80RgxJKFXXjQPYNU=;
b=ifDWICl3nQIS6eXhRXrwbNk+FNt4vBZgMi8Wd3HUUYaTae2RzoAGu3yTozf7VLUMYs
qC1PDQQFYSCl9F/x1YYTioNmGtBvkzvDmWT9+ZCbAqHNKw8o8eoZhAkqfmQ1nWwwnnl8
XEeJhIIQ5uJm0OJivz67sQO/8ScEPMXsTgY3/LRpF0z9YImKAws0eGSeGIyofV2kVX8v
+Pf8gzwWDsRMepcsI5Mo2meU6MNEoX0VX2nF+0Jr+aQPrQJ2skLwXutZklCm750H0YEV
Vk1ilQSxSAZGXeL+NvDZXtmbRTKUWqYWlydJlHiGpFTszO+rfQceqSVdeUZKMyImj0/T
8oZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=VE13RC6aCGt+MVe3iEB6xPCTBbX80RgxJKFXXjQPYNU=;
b=YaCHPDZmfAU/zK2et0kF1kEJaiJ9ptvHvg6/e2sv0jupOXywnb+GSEehN68jYc4GTW
VHETYlYTpsPavrFsREz+9UBmIIOb+e3sTwfZdhSH0xpRuD/4Q5nvMhwbD25ISfzPsKm8
DldkoejfWOua9LJebifAZPSbddL+WOO9N47Wddvje2gduKuhp8rJYDFtyfSI+4G8qWVF
0VEbPAATohTohcklLoOvH0Zxb3/Lct6ie9a+o8Z4FllcvLx3ISVOJY6uTHUu2OH5EQXn
YRzGIZTy7fGRzVPdMuWxOXx6k63xlftV2EwFEN+7LJfck0LOL0zcpgltLntA99aLVAe6
jOZw==
X-Gm-Message-State: AHPjjUgi7ct+rbLlfkofQDXaRlk63QIECqLJX9iEHDVvD3LG9FZYgRBd
fe+oJZN7nNF9wYf+Ei8fzoo14ZtlHg==
X-Google-Smtp-Source: ADKCNb7u9/W7p+9k/gk2xnhgVub/BNUV0BNEGmYhHIzi3olxFBM7rr4cRgLA6TOeeyJJq1AE+oyYMDdqdcFKFbNhTSY=
X-Received: by 10.202.87.135 with SMTP id l129mr2014788oib.293.1504778180183;
Thu, 07 Sep 2017 02:56:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.1.136 with HTTP; Thu, 7 Sep 2017 02:56:19 -0700 (PDT)
In-Reply-To: <1ffab7c0-7005-283e-07e5-4e85fc54de51@gmail.com>
References: <CABm2gDojDQWMhw8wW1UkRGKtdbby2+6AFFZLPuRcUb7WF_u5qQ@mail.gmail.com>
<CAF5CFkh4DWE6Ca-5LFrgkGxWgYqqJdEdv+JZ+3wp+0eTm_vqCw@mail.gmail.com>
<CALqxMTHxdLqms_OgT71EtS2kY2=_8yfNsatNNnOjfSHrLnQL-Q@mail.gmail.com>
<1ffab7c0-7005-283e-07e5-4e85fc54de51@gmail.com>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Thu, 7 Sep 2017 11:56:19 +0200
Message-ID: <CAFMkqK8t+iADAbpWeTLZy+YjLQC5DsxHPFAWCcp063k-Dc9DYg@mail.gmail.com>
To: CryptAxe <cryptaxe@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113de4d6e54b250558967879"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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: Thu, 07 Sep 2017 09:56:21 -0000
--001a113de4d6e54b250558967879
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Forbidding 0 satoshi outputs (I wasn't actually aware that it was possible,
is 0 satoshi inputs also allowed?) would complicate a divisibility increase
softfork (I'm working on an idea for >=3D 1 satoshi transactions, but now i=
t
seems like < 1 satoshi transactions would work too).
I don't think it's a good idea to deploy this softfork.
Hampus
2017-09-07 5:41 GMT+02:00 CryptAxe via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> After reading
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-January/012194.html
> I see that Adam is correct. Unfortunately this SF would make Felix's
> confidential transactions
> more complicated. The blinding and unblinding transactions would have to
> be created with
> minimal output values, and this will need to be considered when checking
> that the fee is equal
> to the total amount of input. (it would now be SUM(inputs) -
> SUM(minimalOutputs))
>
> Blinding transaction:
> Ins:
> All non-confidential inputs are valid
> Outs:
> - 0..N: (new confidential outputs)
> amount: 0
> scriptPubkey: OP_2 <0x{32-byte-hash-value}>
> witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
> - last:
> amount: 0
> scriptPubkey: OP_RETURN OP_2 {blinding-fee-amount}
> Fee: Sum of the all inputs value
>
>
> However, looking at the format of the blinding transaction, and how the
> GCTXO is added to the UTXO set
> by miners, it seems that a change to the blinding scriptPubKey could
> allow for the use of 0 value
> outputs. Even with the SF proposed by this email thread.
>
> OP_RETURN could be added to the scriptPubKey during blinding. The amount
> and scriptPubKey destination of
> unblinded funds is part of the witness and the outputs of an unblinded
> transaction are unspendable, so
> why not also make them unspendable in the blind transaction? As far as I
> can tell those outputs don't need to
> be spendable, they are really just encoding data. It doesn't seem like
> anything besides the confidential base
> transaction and the fee output from the blind transaction need to be in
> the UTXO set.
>
> Is it still possible to add this data to the witness if the scriptPubKey
> is unspendable? :
>
> witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
>
> I think I'm missing something obvious, someone point out why this is
> stupid please :)
>
> On 09/06/2017 06:29 PM, Adam Back wrote:
> > The pattern used by Felix Weiss' BIP for Confidential Transactions
> > depends on or is tidier with 0-value outputs.
> >
> > Adam
> >
> >
> > On 7 September 2017 at 00:54, CryptAxe via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> As long as an unspendable outputs (OP_RETURN outputs for example) with
> >> amount=3D0 are still allowed I don't see it being an issue for anythin=
g.
> >>
> >> On Sep 5, 2017 2:52 PM, "Jorge Tim=C3=B3n via bitcoin-dev"
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>> This is not a priority, not very important either.
> >>> Right now it is possible to create 0-value outputs that are spendable
> >>> and thus stay in the utxo (potentially forever). Requiring at least 1
> >>> satoshi per output doesn't really do much against a spam attack to th=
e
> >>> utxo, but I think it would be slightly better than the current
> >>> situation.
> >>>
> >>> Is there any reason or use case to keep allowing spendable outputs
> >>> with null amounts in them?
> >>>
> >>> If not, I'm happy to create a BIP with its code, this should be simpl=
e.
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev@lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113de4d6e54b250558967879
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Forbidding 0 satoshi outputs (I wasn't actua=
lly aware that it was possible, is 0 satoshi inputs also allowed?) would co=
mplicate a divisibility increase softfork (I'm working on an idea for &=
gt;=3D 1 satoshi transactions, but now it seems like < 1 satoshi transac=
tions would work too).</div><div><br></div>I don't think it's a goo=
d idea to deploy this softfork.<br><br></div>Hampus<br></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">2017-09-07 5:41 GMT+02:00 Crypt=
Axe via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">After reading<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Jan=
uary/012194.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2016-January/012194.html</a><=
br>
I see that Adam is correct. Unfortunately this SF would make Felix's<br=
>
confidential transactions<br>
more complicated. The blinding and unblinding transactions would have to<br=
>
be created with<br>
minimal output values, and this will need to be considered when checking<br=
>
that the fee is equal<br>
to the total amount of input. (it would now be SUM(inputs) -<br>
SUM(minimalOutputs))<br>
<br>
Blinding transaction:<br>
=C2=A0 Ins:<br>
=C2=A0 =C2=A0 All non-confidential inputs are valid<br>
=C2=A0 Outs:<br>
=C2=A0 - 0..N: (new confidential outputs)<br>
=C2=A0 =C2=A0 amount: 0<br>
=C2=A0 =C2=A0 scriptPubkey: OP_2 <0x{32-byte-hash-value}><br>
=C2=A0 =C2=A0 witnessOut: <0x{petersen-commitment}> <0x{range-proo=
f}><br>
=C2=A0 - last:<br>
=C2=A0 =C2=A0 amount: 0<br>
=C2=A0 =C2=A0 scriptPubkey: OP_RETURN OP_2 {blinding-fee-amount}<br>
=C2=A0 Fee: Sum of the all inputs value<br>
<br>
<br>
However, looking at the format of the blinding transaction, and how the<br>
GCTXO is added to the UTXO set<br>
by miners, it seems that a change to the blinding scriptPubKey could<br>
allow for the use of 0 value<br>
outputs. Even with the SF proposed by this email thread.<br>
<br>
OP_RETURN could be added to the scriptPubKey during blinding. The amount<br=
>
and scriptPubKey destination of<br>
unblinded funds is part of the witness and the outputs of an unblinded<br>
transaction are unspendable, so<br>
why not also make them unspendable in the blind transaction? As far as I<br=
>
can tell those outputs don't need to<br>
be spendable, they are really just encoding data. It doesn't seem like<=
br>
anything besides the confidential base<br>
transaction and the fee output from the blind transaction need to be in<br>
the UTXO set.<br>
<br>
Is it still possible to add this data to the witness if the scriptPubKey<br=
>
is unspendable? :<br>
<br>
witnessOut: <0x{petersen-commitment}> <0x{range-proof}><br>
<br>
I think I'm missing something obvious, someone point out why this is<br=
>
stupid please :)<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On 09/06/2017 06:29 PM, Adam Back wrote:<br>
> The pattern used by Felix Weiss' BIP for Confidential Transactions=
<br>
> depends on or is tidier with 0-value outputs.<br>
><br>
> Adam<br>
><br>
><br>
> On 7 September 2017 at 00:54, CryptAxe via bitcoin-dev<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>> As long as an unspendable outputs (OP_RETURN outputs for example) =
with<br>
>> amount=3D0 are still allowed I don't see it being an issue for=
anything.<br>
>><br>
>> On Sep 5, 2017 2:52 PM, "Jorge Tim=C3=B3n via bitcoin-dev&quo=
t;<br>
>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>>> This is not a priority, not very important either.<br>
>>> Right now it is possible to create 0-value outputs that are sp=
endable<br>
>>> and thus stay in the utxo (potentially forever). Requiring at =
least 1<br>
>>> satoshi per output doesn't really do much against a spam a=
ttack to the<br>
>>> utxo, but I think it would be slightly better than the current=
<br>
>>> situation.<br>
>>><br>
>>> Is there any reason or use case to keep allowing spendable out=
puts<br>
>>> with null amounts in them?<br>
>>><br>
>>> If not, I'm happy to create a BIP with its code, this shou=
ld be simple.<br>
>>> ______________________________<wbr>_________________<br>
>>> bitcoin-dev mailing list<br>
>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a><br>
>>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda=
tion.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> bitcoin-dev mailing list<br>
>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
>><br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
--001a113de4d6e54b250558967879--
|
