summaryrefslogtreecommitdiff
path: root/82/4fd2053ff8d52633890e58e6dab51193505557
blob: 69135b38540cef9caf1b60e485c477d7ac4d6a54 (plain)
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
Return-Path: <michaelfolkson@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7EC9CC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 18:21:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 6073C4020C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 18:21:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id TVdqqNt0Iy3Q
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 18:21:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com
 [IPv6:2607:f8b0:4864:20::32c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 47C58400E8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 18:21:51 +0000 (UTC)
Received: by mail-ot1-x32c.google.com with SMTP id
 f3-20020a0568301c23b029044ce5da4794so15522724ote.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 11:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=kP8zD+Zmnu/GvNcv4o3gs0ez3q2Hd4/hO3BXtgdRu+g=;
 b=j5ryS/Eyd9oukGKww4VbPL0O0pxbZ0ex4n5c8n2eLs98vKbTf1GeMV78cHHytJUUZh
 NJfzfcOgXglRbfsL3g4y26kaF2KzfLT7uqIcUW/522AcYAR90YI+lBKmODWd9ljn7soo
 3CQMsKNv41YBsSubHB9ZGMEzh2s1u4dcYcxjzeWG4hLk00WYsMerZkcpPN4oKCDWwjCJ
 GNVmUOTZBKHnYvlyGjqXZal6h5juoHJtEYFEN7g+Vw8uvrxn0VcwCAwqGeSCZBXoeGRS
 pyFs+QhMEPdULGa8cXQ8zgqttctWToawqhT20k2oytKNv9hkxGT0RRoptg18OHHHMVlc
 qSxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=kP8zD+Zmnu/GvNcv4o3gs0ez3q2Hd4/hO3BXtgdRu+g=;
 b=Swbw1bBgNJMMTbVSRGgA+whAKLRPIvrRiObnWfckW5euy9fruSns2C3ElNwW3YC49x
 3QnSTWuOLy6hLvgOrxs7+ftjpLRmNHCDwQ7lSN6wsSFmEZ9nsp6wy787DQID5qAScPMy
 Q3Z+Tc1JriEf1AqFJzQqlnfQHelUOPZLbF2bH5oYVIlI8aBWn/V/ShUMx2vibpt+a2Ut
 crXp1FP12x06TB2lA8pMvjagUpjoHYIa83Bfmh6g99BrHwJqueGqHFfkgONQ9MZZo5p3
 0Nuf33cwdJl//qGcx+4HunWplfWpYcX++x5qT4qdhzEG55uHhlZliUyxPJ/JVFAvYAe2
 u6kw==
X-Gm-Message-State: AOAM532cDcdB4jgGyUQ82vL+wPxRmqaM38d9LyqWnq0HU/QzMGuXfQ5K
 pFVRW+gVDf6U0qSDyA+7l2ovvBvCgFEgmcFBcB0=
X-Google-Smtp-Source: ABdhPJw/P1scjG3jw15ELY8WT1+vK1m4Um/4A8NIiMZW2lhDdo8Uim/5562zXVkpDUDqZ5ifZrwdB4P3h1r34+/XiwY=
X-Received: by 2002:a9d:634d:: with SMTP id y13mr4300134otk.294.1624386110194; 
 Tue, 22 Jun 2021 11:21:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAFvNmHSYD0yZhMJC=ceBZw86+-HyZ3mj19Tx3svfZ7Gxn3FiRg@mail.gmail.com>
 <CAGpPWDYi0Cqm7JjM5CuNOutA4UpDsQS_3Nta+SmVSPxe3jaOog@mail.gmail.com>
In-Reply-To: <CAGpPWDYi0Cqm7JjM5CuNOutA4UpDsQS_3Nta+SmVSPxe3jaOog@mail.gmail.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Tue, 22 Jun 2021 19:21:39 +0100
Message-ID: <CAFvNmHQjVs02AncYmGUipwt9cG+QvHpimmuMwYT1wRoQ4HiNiw@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 23 Jun 2021 02:51:04 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev]
	=?utf-8?q?Tuesday=E2=80=99s_IRC_workshop_on_L2_onch?=
	=?utf-8?q?ain_support?=
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: Tue, 22 Jun 2021 18:21:52 -0000

Hey Billy

No, fee sensitive timelocks weren't discussed at any length in the
workshop. The workshops are obviously time limited but if they spur
future discussion and drafted proposals (whether they need soft forks
or not) outside of the workshops that would be great. This idea was
raised in the meeting by Ruben Somsen so maybe Ruben has given them
some thought. Making timelocks conditional on the current fee rate
seems challenging to me (where is the current network fee rate
obtained from and how is it fed into the script?) but I haven't
sketched out exactly how they would work.

A reminder that the second workshop (on package relay and fee bumping)
starts at 19:00 UTC today (30 minutes after I've sent this, there may
be a delay before it is published to the mailing list).

Thanks
Michael

On Tue, Jun 22, 2021 at 7:02 PM Billy Tetrud <billy.tetrud@gmail.com> wrote=
:
>
> Thanks for the Summary Michael!
>
> It seems like fee-sensitive timelocks weren't discussed too much in the w=
orkshop, unless I'm missing something. I also don't see any downside to it =
discussed (other than that it needs a soft-fork). It seems like that would =
be a great way to substantially increase the resilience of the LN to tempor=
ary periods of fee congestion, even potentially long-running periods that l=
ast weeks. It might even help in non-temporary fee market increases by givi=
ng participants extra time to use some fee-bumping technique to close or re=
structure their channels to compensate for the elevated fee market.
>
> On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org> wrote:
>>
>> The workshop was previously announced by ariard on the bitcoin-dev
>> mailing list here:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/01884=
1.html
>>
>> A reminder was posted to the bitcoin-dev mailing list here:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068=
.html
>>
>> The conversation log for the workshop is here:
>> https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4
>>
>> I=E2=80=99ll summarize what was discussed during the meeting but please =
refer
>> to the L2 zoology repo ariard has set up for background context and
>> additional notes: https://github.com/ariard/L2-zoology
>>
>> General considerations
>>
>> I think it is worth first reiterating the obvious that there will
>> never be perfect security guarantees on network transaction fee rates
>> or transaction relay. Network fee rates can in theory go up to
>> anything (upper limit of infinity) and will always to some degree be
>> inherently unpredictable. In addition transaction acceptance can never
>> be guaranteed even if you attempt a direct connection to a miner. At
>> the same time L2 protocols (e.g. Lightning and DLCs) elevate
>> transaction propagation and inclusion in a time sensitive mined block
>> to a security assumption from what used to just be a usability
>> assumption (BlueMatt). Within those confines these workshops are
>> attempting to strengthen that security assumption knowing that
>> guaranteeing it is out of reach.
>>
>> There are considerations that blocked transaction propagation isn=E2=80=
=99t
>> necessarily a problem for the victim if it is also blocked for the
>> attacker. In addition some successful attacks present an opportunity
>> for the victim to divert their funds to miner fees (e.g. scorched
>> earth) ensuring the attacker doesn=E2=80=99t financially benefit from th=
e
>> attack (harding). Personally I would argue neither of these present
>> much assurance to the victim. Out of conservatism one should assume
>> that the attacker has greater resources than the victim (e.g. a direct
>> line to a miner) and knowing a victim=E2=80=99s lost funds went to the m=
iner
>> instead of the attacker isn=E2=80=99t of much comfort to the victim (oth=
er
>> than potentially presenting a disincentive for the attack in the first
>> place). This is obviously further complicated if the miner is the
>> attacker. In addition any incentive for miners to not mine
>> transactions to wait for a potential pay-all-to-fee are troubling
>> (t-bast).
>>
>> New(ish) ideas
>>
>> RubenSomsen brought up the idea of fee sensitive timelocks, they would
>> need a soft fork. ariard briefly discussed the idea of a transaction
>> relay overlay network. harding stated his opinion that we should be
>> leaning more on miners=E2=80=99 profit incentive rather than attempting =
to
>> normalize mempool policy (e.g.
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002=
664.html).
>> t-bast raised the prospect of mining pools exposing public APIs to
>> push them transactions directly.
>>
>> The impact of changes to Bitcoin Core on L2 protocols
>>
>> Some changes to Core (e.g. some privacy improvements) can conflict
>> with the goal of minimizing transaction propagation times.
>> Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L2
>> developers a way to write regression tests against the latest builds
>> of bitcoind. He added that L2 devs should write automated regression
>> test suites against bitcoind exposed RPC commands. t-bast would like a
>> bitcoind =E2=80=9Cevicttx=E2=80=9D RPC to remove a transaction from the =
mempool on
>> regtest.
>>
>> Full RBF
>>
>> In advance of the workshop ariard posted to the mailing list a
>> proposal for full RBF in a future version of Bitcoin Core:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074=
.html
>>
>> Progress in this direction has been attempted in the past (e.g.
>> https://github.com/bitcoin/bitcoin/pull/10823) BlueMatt pointed out
>> that even with full RBF it is trivial to create mempool partitions. As
>> long as RBF has a fee rate increase minimum an attacker can trivially
>> split the mempool by broadcasting two conflicting transactions with
>> the same fee.
>>
>> ariard plans to contact businesses (e.g. Lightning onboarding services
>> relying on zero confirmations) to check that this possible eventual
>> move to full RBF doesn=E2=80=99t present a problem for them. There could=
 well
>> be engineering work required in advance of the possible change being
>> made.
>>
>> Next week=E2=80=99s meeting
>>
>> Next week=E2=80=99s meeting (Tuesday 22nd June, 19:00 UTC,
>> #l2-onchain-support, Libera) will be on fee bumping and package relay
>> that glozow has recently been working to advance in Bitcoin Core.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson@gmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



--=20
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3