summaryrefslogtreecommitdiff
path: root/df/cf477761f3b4ad52d9f05eb003f04df246d3c1
blob: 71041b9030b6604a1b736deeb6c22d697a6030b5 (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
Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4CFBEC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Jun 2021 03:09:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 269E560746
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Jun 2021 03:09:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id fNWWORg3PHKn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Jun 2021 03:09:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [IPv6:2a00:1450:4864:20::133])
 by smtp3.osuosl.org (Postfix) with ESMTPS id A1FD8600CA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Jun 2021 03:09:06 +0000 (UTC)
Received: by mail-lf1-x133.google.com with SMTP id x24so18846108lfr.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Jun 2021 20:09:06 -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; bh=h359UEd3KkDeu01cvx91+IUKUTK+Rni6Gm31WDbX7Go=;
 b=TtHQ++wUTKAU6vuFX4uhYaDYy3Id6t5RpgmHvJ6w5K+s/RcI+R49Ax0E9ZEcihqCK8
 rGds7sxTfCllYfbBQTZxZMzvaK9qGCkg9t38s/aW7Ficn9MZZrItwmYSWQ7K6xD81NMS
 L0lyp/i9I5Tq1GclETcVTT8JvJUL9tlf7uWsk2y5+Al/uR8b2kiwWeVSndBiLkMKcS2Z
 KCewAHpibFfYCfo07CQlqGAqHA7JyVlfPtR5CW8Yr1RXY+sFSubYOVKD4/Gnr4/wTNnY
 FXhaSs0MlUtEQ4V7w33ZRLuMbd0ulzzmy+oGI6v7Fa/hnEwPd9f8PPH7BkJEHu9yxKE8
 T0Fg==
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;
 bh=h359UEd3KkDeu01cvx91+IUKUTK+Rni6Gm31WDbX7Go=;
 b=RwFzkj9BReaCvN61MjyRF3Lt3AJO4xuupJc3XarDppiM0xQ6p4nWfHQJBJL2dMktR1
 OWsK0kB7uu68musE33mKNBZfMmwU5EBAaduZbuYDpoc+7SAUOys/AYRWbbVrhUhyn79y
 by1tLiJtSvMktkMczGKSavgYJNHiVet+ETx3hQYZCL4su+Jsr8O4Py+8ak3XkDbDXSFh
 MYGl3pXqbeZNZgqVzIX9aOgF5moNUIdcPVWRXlUvwtog6NdFvowk22ssIA6tuQRjRSQj
 CgqwZ3o+amltm4ekDEpUPX0bOvZ83ip3v545CRUyxFb5Z4ZvtK4UqJQrBmFdDzmAjjQI
 LOPg==
X-Gm-Message-State: AOAM532l7wbsQ2x3dUjFcV0aJYxOYcCjG/iF33h6FlQ7bxZezjqJzh9e
 M4viJGKNHe+c6luejPBnpFmpFi6mgm4X3eZ19SA=
X-Google-Smtp-Source: ABdhPJxiplaaLzWkDhjoozEhUTkroPT2ZGbCV1ukTGLOmhHiy4TegZlaGaciWCEuxmxp2BhqUIUb1JD6w4VHfYDPvVk=
X-Received: by 2002:a05:6512:332c:: with SMTP id
 l12mr15183014lfe.454.1623726544271; 
 Mon, 14 Jun 2021 20:09:04 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+FvLb=N5Qygs+dPmh1o9QCwXj8RoznF5n47opOq7CG_0g@mail.gmail.com>
 <CAH5Bsr2gmqqS1LWuT679vzOEywo=gCdNdOX-Jb9aFFb=EPZcHg@mail.gmail.com>
 <CALZpt+Hj-KdiuQueAhkeTwzJvu5Wo9zdBQ39aZGrSmjJvgbkDQ@mail.gmail.com>
 <CAH5Bsr0V6r3+GsDg=CbDshj=QnpAr+saXftG_pazkWvL=m-W3g@mail.gmail.com>
 <CALZpt+E09jViG0owWpSWBoG5rjk_=HdMgQisp_1DsBEKBq-D2w@mail.gmail.com>
 <CAH5Bsr1NxM6WcpagwpmFC=Nn3tzK+H8n-Vx1_ObMGEejnD4SjA@mail.gmail.com>
In-Reply-To: <CAH5Bsr1NxM6WcpagwpmFC=Nn3tzK+H8n-Vx1_ObMGEejnD4SjA@mail.gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Tue, 15 Jun 2021 13:08:37 +1000
Message-ID: <CAH5Bsr0XNiMUbCDXBxW7DWmmUrqNY53WbZfv+iChnnr18sK1EQ@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e23df205c4c54b23"
X-Mailman-Approved-At: Tue, 15 Jun 2021 07:33:23 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques :
 Input-Based vs Child-Pay-For-Parent
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, 15 Jun 2021 03:09:08 -0000

--000000000000e23df205c4c54b23
Content-Type: text/plain; charset="UTF-8"

On Tue, 15 Jun 2021 at 10:59, Lloyd Fournier <lloyd.fourn@gmail.com> wrote:

>
>
> On Tue, 15 Jun 2021 at 02:47, Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> > This makes a lot of sense as it matches the semantics of what we are
>> trying
>> to achieve: allow the owner of an output (whether an individual or group)
>> to reduce that output's value to pay a higher fee.
>>
>> Note, I think you're still struggling with some trust issue that anchor
>> upgrade is at least eliminating for LN, namely the pre-agreement among a
>> group of signers about the effective feerate to use at some unknown time
>> point in the future. If you authorize your counterparty for a broadcast at
>> feerate X, how do you prevent a broadcast at feerate Y, where Y is far
>> under X, thus maliciously burning a lot of your fee-bumping reserve ?
>>
>> Of course, one mitigation is to make a contribution to a common
>> fee-bumping output reserve proportional to what has been contributed as a
>> funding collateral. Thus disincentivizing misuse of the common fee-bumping
>> reserve in a game-theoretical way. But if you take the example of a LN
>> channel, you're now running into another issue. Off-chain balances might
>> fluctuate in a way that most of the time, your fee-bumping reserve
>> contribution is out-of-proportion with your balance amounts to protect ?
>> And as such enduring some significant timevalue bleeding on your
>> fee-bumping reserve.
>>
>> Single-party managed fee-bumping reserve doesn't seem to suffer from this
>> drawback ?
>>
>
> I claim that what I am suggesting is a single-party managed fee-bumping
> system that solves all fee-bumping requirements of lightning without
> needing external utxos and without additional interaction or fee
> pre-agreement between parties. On the commit tx you have your balance going
> exclusively towards you which you can unilaterally reduce to increase the
> fee up to whatever threshold you want. With a HTLC or PTLC you also always
> have a tx with an output that you can unilaterally drain to bump fee
> (either the hltc-success or htlc-timeout). Are you saying that there are
> protocols where this would require pre-arrangement or are you saying that
> it would require pre-arrangement in lightning for some reason I don't see?
>

Ok now I see what I am missing: We don't really know who owns certain
outputs in lightning until the most-recent-state-enforcement mechanism has
done its job. i.e. the outputs are 2-of-2s up until that has been resolved.
I was operating on some simplified imaginary lightning. Indeed this makes
the proposal far less attractive and does require interaction and
pre-agreement. This complexity here makes it worse than just keeping
external fee-bumping utxos around (as undesirable as this is). Thanks for
helping me figure this out.

LL

--000000000000e23df205c4c54b23
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, 15 Jun 2021 at 10:59, Lloyd F=
ournier &lt;<a href=3D"mailto:lloyd.fourn@gmail.com">lloyd.fourn@gmail.com<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Tue, 15 Jun 2021 at 02:47, Antoine =
Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com" target=3D"_blank">anto=
ine.riard@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr">&gt; This makes a lot of sense as it ma=
tches the semantics of what we are trying<br>to achieve: allow the owner of=
 an output (whether an individual or group)<br>to reduce that output&#39;s =
value to pay a higher fee.<br><br>Note, I think you&#39;re still struggling=
 with some trust issue that anchor upgrade is at least eliminating for LN, =
namely the pre-agreement among a group of signers about the effective feera=
te to use at some unknown time point in the future. If you authorize your c=
ounterparty for a broadcast at feerate X, how do you prevent a broadcast at=
 feerate Y, where Y is far under X, thus maliciously burning a lot of your =
fee-bumping reserve ?<br><br>Of course, one mitigation is to make a contrib=
ution to a common fee-bumping output reserve proportional to what has been =
contributed as a funding collateral. Thus disincentivizing misuse of the co=
mmon fee-bumping reserve in a game-theoretical way. But if you take the exa=
mple of a LN channel, you&#39;re now running into another issue. Off-chain =
balances might fluctuate in a way that most of the time, your fee-bumping r=
eserve contribution is out-of-proportion with your balance amounts to prote=
ct ? And as such enduring some significant timevalue bleeding on your fee-b=
umping reserve.<br><br>Single-party managed fee-bumping reserve doesn&#39;t=
 seem to suffer from this drawback ?<br></div></blockquote><br></div><div c=
lass=3D"gmail_quote">I claim that what I am suggesting is a single-party ma=
naged fee-bumping system=20
that solves all fee-bumping requirements of lightning without needing exter=
nal utxos and without additional interaction or fee pre-agreement between p=
arties. On the commit tx you have your balance going exclusively towards yo=
u which you can unilaterally reduce to increase the fee up to whatever thre=
shold you want. With a HTLC or PTLC you also always have a tx with an outpu=
t that you can unilaterally drain to bump fee (either the hltc-success or h=
tlc-timeout). Are you saying that there are protocols where this would requ=
ire pre-arrangement or are you saying that it would require pre-arrangement=
 in lightning for some reason I don&#39;t see?</div></div></blockquote><div=
><br></div><div>Ok now I see what I am missing: We don&#39;t really know wh=
o owns certain outputs in lightning until the most-recent-state-enforcement=
 mechanism has done its job. i.e. the outputs are 2-of-2s up until that has=
 been resolved. I was operating on some simplified imaginary lightning.  In=
deed this makes the proposal far less attractive and does require interacti=
on and pre-agreement. This complexity here makes it worse than just keeping=
 external fee-bumping utxos around (as undesirable as this is).=20
Thanks for helping me figure this out.<br></div><div><br></div><div>LL<br><=
/div><div> <br></div></div></div>

--000000000000e23df205c4c54b23--