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
|
Return-Path: <damian@willtech.com.au>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5363BC0012;
Thu, 9 Dec 2021 06:27:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 41E4982C9C;
Thu, 9 Dec 2021 06:27:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.035
X-Spam-Level:
X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665]
autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=neutral
reason="invalid (public key: not available)" header.d=willtech.com.au
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Hx_HEJ0yh29b; Thu, 9 Dec 2021 06:27:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from bat.birch.relay.mailchannels.net
(bat.birch.relay.mailchannels.net [23.83.209.13])
by smtp1.osuosl.org (Postfix) with ESMTPS id 08C2C82C2E;
Thu, 9 Dec 2021 06:27:08 +0000 (UTC)
X-Sender-Id: hostpapa|x-authuser|damian@willtech.com.au
Received: from relay.mailchannels.net (localhost [127.0.0.1])
by relay.mailchannels.net (Postfix) with ESMTP id EBABD521009;
Thu, 9 Dec 2021 06:27:07 +0000 (UTC)
Received: from s110.servername.online (unknown [127.0.0.6])
(Authenticated sender: hostpapa)
by relay.mailchannels.net (Postfix) with ESMTPA id 4CFD352163C;
Thu, 9 Dec 2021 06:27:07 +0000 (UTC)
X-Sender-Id: hostpapa|x-authuser|damian@willtech.com.au
Received: from s110.servername.online (s110.servername.online [204.44.192.22])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384)
by 100.127.242.165 (trex/6.4.3); Thu, 09 Dec 2021 06:27:07 +0000
X-MC-Relay: Junk
X-MailChannels-SenderId: hostpapa|x-authuser|damian@willtech.com.au
X-MailChannels-Auth-Id: hostpapa
X-Keen-Thoughtful: 5bde93c50782d8ca_1639031227792_637586518
X-MC-Loop-Signature: 1639031227791:2147802329
X-MC-Ingress-Time: 1639031227791
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=willtech.com.au; s=default; h=Content-Transfer-Encoding:Content-Type:
Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender
:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:
Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:
List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
bh=qq5rqQ73qG4zh458tbeQzaTkE58HFkXc+K4Vnq7Izbk=; b=8nrKeEYd5LLDJGoOf6NT2LR+Dl
B7tCoXBTy4q6xwE5TrMp1jGFWinkrNCxQTOKrX76D7vyG8xo2SENHvo2ByJIL5ms/v3HKi3LJxT/I
To9AcsK+qrqGz6t5Kg3xej9UJvNm9cO7BLf3F07K0i2E/o2zCW20qif1RGT5YazIst0LtqGU6PD9p
s/1xI3ZL57Dk2lg0923F3IsMH802/EG6riP8Ysrrp1kLwYCbGdOYCXRFwIB3IJclzVzUtnJadDH8T
aLYWYeLqDNemdayE3x/6l5kypm4yzFKegRNYT+U70F4uFCEnudtgRejsFjq8MXRif02TmBx2HDuMM
YZ5I9xCA==;
Received: from localhost ([127.0.0.1]:38724 helo=s110.servername.online)
by s110.servername.online with esmtpa (Exim 4.94.2)
(envelope-from <damian@willtech.com.au>)
id 1mvCtV-00Ajd5-Q9; Wed, 08 Dec 2021 22:27:06 -0800
MIME-Version: 1.0
Date: Wed, 08 Dec 2021 22:27:04 -0800
From: damian@willtech.com.au
To: Ruben Somsen <rsomsen@gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPv7TjYTK=xrOxMbpD1JKQ1vTpiWWoOeGt86erFGBOP5grFYNA@mail.gmail.com>
References: <CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com>
<CACdvm3Oynv4gWdaGXATxc3SoYDD8kuiPq-d9F2itsmayP0qeZQ@mail.gmail.com>
<CAPv7TjZBU2v2Nfw2_8Qz33rUWKJ=uJ7u+_5tFxjM94mk=RnmOA@mail.gmail.com>
<CAD5xwhiSEoBxw=NVUHnZ+s22nTZhMoWYoDrC=aQfPyvwgtLrTQ@mail.gmail.com>
<CAPv7TjYTK=xrOxMbpD1JKQ1vTpiWWoOeGt86erFGBOP5grFYNA@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <32e6a20882fa13da03aa6238f5dfff69@willtech.com.au>
X-Sender: damian@willtech.com.au
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-AuthUser: damian@willtech.com.au
X-Mailman-Approved-At: Thu, 09 Dec 2021 09:17:05 +0000
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 09 Dec 2021 06:27:11 -0000
Good Afternoon,
'Avoiding a soft-fork' is a political concession. Consensus is none of
that.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
and other projects
earn.com/willtech
linkedin.com/in/damianwilliamson
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this
email if misdelivered.
On 2021-12-08 14:51, Ruben Somsen via bitcoin-dev wrote:
> Hi Jeremy,
>
> Thanks for sharing your thoughts.
>
> To summarize your arguments: the intentionally malicious path to
> getting the 0 sat output confirmed without being spent is uneconomical
> compared to simply creating dust outputs. And even if it does happen,
> the tx spending from the 0 sat output may still be valid (as long as
> none of its inputs get spent elsewhere) and could eventually get
> confirmed.
>
> I think those are good points. I do still see a possibility where a
> user non-maliciously happens to behave in a way that causes all of the
> above to happen, but it does seem somewhat unlikely.
>
> It could happen if all of the following occurs:
> 1. Another output happens to get spent at a higher feerate (e.g.
> because an absolute timelock expires and the output gets used)
> 2. The tx spending the 0 sat output then happens to not make it into
> the block due to the lower fees
> 3. The user then happens to invalidate the tx that was spending from
> the 0 sat output (seems rational at that point)
>
> Assuming this is the only scenario (I am at least not currently aware
> of others), the question then becomes whether the above is acceptable
> in order to avoid a soft fork.
>
> Cheers,
> Ruben
>
> On Wed, Dec 8, 2021 at 6:41 PM Jeremy <jlrubin@mit.edu> wrote:
>
>> IMO this is not a big problem. The problem is not if a 0 value ever
>> enters the mempool, it's if it is never spent. And even if C2/P1
>> goes in, C1 still can be spent. In fact, it increases it's feerate
>> with P1's confirmation so it's somewhat likely it would go in. C2
>> further has to be pretty expensive compared to C1 in order to be
>> mined when C2 would not be, so the user trying to do this has to pay
>> for it.
>>
>> If we're worried it might never be spent again since no incentive,
>> it's rational for miners *and users who care about bloat* to save to
>> disk the transaction spending it to resurrect it. The way this can
>> be broken is if the txn has two inputs and that input gets spent
>> separately.
>>
>> That said, I think if we can say that taking advantage of keeping
>> the 0 value output will cost you more than if you just made it above
>> dust threshold, it shouldn't be economically rational to not just do
>> a dust threshold value output instead.
>>
>> So I'm not sure the extent to which we should bend backwards to make
>> 0 value outputs impossible v.s. making them inconvenient enough to
>> not be popular.
>>
>> -------------------------------------
>> Consensus changes below:
>> -------------------------------------
>>
>> Another possibility is to have a utxo with drop semantics; if UTXO X
>> with some flag on it is not spent in the block it is created, it
>> expires and can never be spent. This is essentially an inverse
>> timelock, but severely limited to one block and mempool evictions
>> can be handled as if a conflict were mined.
>>
>> These types of 0 value outputs could be present just for attaching
>> fee in the mempool but be treated like an op_return otherwise. We
>> could add two cases for this: one bare segwit version (just the
>> number, no data) and one that's equivalent to taproot. This covers
>> OP_TRUE anchors very efficiently and ones that require a signature
>> as well.
>>
>> This is relatively similar to how Transaction Sponsors works, but
>> without full tx graph de-linkage... obviously I think if we'll
>> entertain a consensus change, sponsors makes more sense, but
>> expiring utxos doesn't change as many properties of the tx-graph
>> validation so might be simpler.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|