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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 24F28A74
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Sep 2017 10:32:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com
[209.85.218.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 98D42D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Sep 2017 10:32:22 +0000 (UTC)
Received: by mail-oi0-f49.google.com with SMTP id n18so56123201oig.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 07 Sep 2017 03:32:22 -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=N16fXnjPzeVrOrUQ6EVUfTNxiRTczGtld62faZgufqc=;
b=Quy0Xkkqh6pabPqvy0MzVuGMb+nV3SnA7gavqe5yv2A3z/idsVFCeK+bMK2r7eyYgQ
C66H5mEmjmalQDGAbNkEWXWp4SJ57JhNg6Z5ktLd3gMEtOT0Uz0Sn+RPJ5IhqMM6GAqP
M6YBbETLBwkXK6kTPPKWj49mvdEi94ESi1S3Osax6SVJp2/Ry8pohdxG9QYFoWcA64i7
dwhZeNUs3ovjo7S0/UinZkYLZza7SxNS2myCwpF95AWaYPZdtfRVQV8Oiwvg699Ep6+g
MEPZaoEhMbfyAxSqFS+s7Zd2Vqe/oJyuMUmxQAWtoqY34bkFmWpMls/h4t2HVhsmDjoB
y9gQ==
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=N16fXnjPzeVrOrUQ6EVUfTNxiRTczGtld62faZgufqc=;
b=I1tMSx8uEhjqfjsP8ZZoz8h4lDWkYSFUcRF+p3QrHxGQFSXc6j4V0KuavgeWQdUAuB
KqUx7ECrmhyeUN6yUcenWRtUEdRx4w3tN6db2o1zMN0jXwcCigUDbaBO6XMaeBC2SMJl
cZgbvulIPhh9H3tkmDh3acf4ByyPfpcFSo5+BiJFdMPTE8aPVu8MxyY5wSpg1tM9HV/R
mqGjIe9Pn/sWOVRLmdMAQzrO0kZ2fEgBkNlQQ6gStfdafknZCgW4p65Vo0alqiR3sXbl
sc9gfBYei13gtSQI8i5ZZdm4ZWzwJy1s5VkFYpn153RQ9zoifT+Z8urbuGWrZ0nSVNWk
ZacQ==
X-Gm-Message-State: AHPjjUjPKUbg26jgkM25GLjWo1NPDt+6C5sc6o/yeG8xWC56QLV/lSBW
PLZRrhUqXVuI/B3a5waBddAKGtVEew==
X-Google-Smtp-Source: ADKCNb4TNqI1PWAhCcKVNqk8jTP48Fmcmf6J+bBd4l/WuLG3/UI7PPNoPAhD2Yf/Hfy802bE4r5/rnZpwZkXA+Dm2m4=
X-Received: by 10.202.208.92 with SMTP id h89mr2854245oig.90.1504780341694;
Thu, 07 Sep 2017 03:32:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.93.71 with HTTP; Thu, 7 Sep 2017 03:31:41 -0700 (PDT)
In-Reply-To: <CAF5CFkh4DWE6Ca-5LFrgkGxWgYqqJdEdv+JZ+3wp+0eTm_vqCw@mail.gmail.com>
References: <CABm2gDojDQWMhw8wW1UkRGKtdbby2+6AFFZLPuRcUb7WF_u5qQ@mail.gmail.com>
<CAF5CFkh4DWE6Ca-5LFrgkGxWgYqqJdEdv+JZ+3wp+0eTm_vqCw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Thu, 7 Sep 2017 11:31:41 +0100
Message-ID: <CAE-z3OWYmi+4jVO8kKB1EBT7mYhPE=MNf6JvNVYteVfZ24qqkg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113ca1debb56eb055896f9e2"
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 10:32:23 -0000
--001a113ca1debb56eb055896f9e2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
You could have a timelocked transaction that has a zero value input (and
other non-zero inputs). If the SF happened, that transaction would become
unspendable.
The keys to the outputs may be lost or the co-signer may refuse to
cooperate.
There seems to be some objections to long term timelocked transactions.
If someone asked me about it, I would recommend that any timelocked
transactions should very carefully make sure that they use forms that are
popular.
I think the fairest rule would be that any change which makes some
transactions invalid should be opt-in and only apply to new transaction
version numbers.
If you create a timelocked transactions with an undefined version number,
then you have little to complain about.
If the version number is defined and in-use, then transactions should not
suddenly lose validity.
A refusal to commit to that makes long term locktime use much more risky.
On Thu, Sep 7, 2017 at 12:54 AM, 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 anything.
>
> On Sep 5, 2017 2:52 PM, "Jorge Tim=C3=B3n via bitcoin-dev" <bitcoin-dev@l=
ists.
> 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 the
>> 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 simple.
>> _______________________________________________
>> 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
>
>
--001a113ca1debb56eb055896f9e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>You could have a timelocked transaction that has a ze=
ro value input (and other non-zero inputs).=C2=A0 If the SF happened, that =
transaction would become unspendable.<br><br></div><div>The keys to the out=
puts may be lost or the co-signer may refuse to cooperate.<br><br></div><di=
v>There seems to be some objections to long term timelocked transactions.<b=
r><br></div><div>If someone asked me about it, I would recommend that any t=
imelocked transactions should very carefully make sure that they use forms =
that are popular.<br><br></div><div>I think the fairest rule would be that =
any change which makes some transactions invalid should be opt-in and only =
apply to new transaction version numbers.<br><br></div><div>If you create a=
timelocked transactions with an undefined version number, then you have li=
ttle to complain about.=C2=A0 <br><br>If the version number is defined and =
in-use, then transactions should not suddenly lose validity.<br><br></div><=
div>A refusal to commit to that makes long term locktime use much more risk=
y.<br></div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Thu, Sep 7, 2017 at 12:54 AM, CryptAxe via bitcoin-dev <span dir=3D=
"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"auto">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 anything.=C2=A0</div><div class=3D"HOE=
nZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Sep 5, 2017 2:52 PM, "Jorge Tim=C3=B3n via bitcoin-dev" =
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br type=3D"at=
tribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">This is not a priority, not very =
important either.<br>
Right now it is possible to create 0-value outputs that are spendable<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 attack 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 outputs<br>
with null amounts in them?<br>
<br>
If not, I'm happy to create a BIP with its code, this should be simple.=
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
</blockquote></div></div>
</div></div><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>
<br></blockquote></div><br></div></div></div></div>
--001a113ca1debb56eb055896f9e2--
|
