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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 39E22C0171
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jan 2020 03:42:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 2816C203B0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jan 2020 03:42:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id DMLtt0I5ouaN
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jan 2020 03:42:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by silver.osuosl.org (Postfix) with ESMTPS id D1D0B20017
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jan 2020 03:42:13 +0000 (UTC)
Date: Fri, 31 Jan 2020 03:42:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1580442130;
bh=eY3HbPgP0iGXwKyhBLNFb7lX5BvIP7m3daII0gDuwpc=;
h=Date:To:From:Reply-To:Subject:Feedback-ID:From;
b=Pylhbebfz/w3Dmxy0+Lq/xSMb1KAOgNNiEIgeIthsAQuWRg+EbGD3V3tv1ZSa81Cq
aT2XwGI3dnBPR6DEV+mhL2U93bOzzjm9GBB39+evzxw6ZE5wK7xuCah3phU67N0HFv
VTUAazIQ+fJy5O7R9pP35V5BPuXVBgaGaj+ZqGyQ=
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2U3WdMgyM7iLhQnak0GjkH6u6C0C_Ry59WucTiRthajkOXqAirvN55U39to0kQY5bDzv9SBZXy5Qbx2QZopJwktHqVUKbfpCjEfq1H_v0vE=@protonmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Onchain fee insurance mechanism
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: Fri, 31 Jan 2020 03:42:17 -0000
Good morning list,
During LNConf 2019, Jack Mallers presented about hedging of onchain fees, w=
hich he argues is necessary in order to have a smooth experience interfacin=
g between onchain and offchain (in particular, when closing and opening cha=
nnels).
The exact mechanism proposed was to construct a futures market on onchain f=
eerates, with miners taking short positions on fees (they are naturally lon=
g on fees) while users take long positions on fees (they are naturally shor=
t on fees).
I observe that what the users effectively experience is similar to a consta=
nt feerate (indeed the positions the user takes up are arranged such that t=
he user takes a constant feerate for a vast majority of the expected future=
outcomes).
This is effectively an insurance policy against increases in feerate.
Let me then propose a specific mechanism for feerate insurance against onch=
ain feerate spikes.
Let us suppose that the user Alice, has 500000 satoshi, and has to pay Bob =
400000 satoshi.
Further, Alice and Bob have a fee insurance provider Ingrid.
Ingrid assures Alice and Bob that 600 satoshi is sufficient to confirm the =
payment from Alice to Bob within 4 blocks.
Ingrid also happens to have a 800000 satoshi output lying around.
At current blockheight B, Alice and Ingrid then arrange a series of transac=
tions:
nLockTime: B+1
nSequence: RBF enabled, no relative locktime.
inputs: Alice 5000000, Ingrid 800000
outputs:
Bob 400000
Alice 99400
Ingrid 800400
fee: 200
nLockTime: B+2
nSequence: RBF enabled, no relative locktime.
inputs: Alice 5000000, Ingrid 800000
outputs:
Bob 400000
Alice 99400
Ingrid 800200
fee: 400
nLockTime: B+3
nSequence: RBF enabled, no relative locktime.
inputs: Alice 5000000, Ingrid 800000
outputs:
Bob 400000
Alice 99400
Ingrid 800001
fee: 599
nLockTime: B+4
nSequence: RBF enabled, no relative locktime.
inputs: Alice 5000000, Ingrid 800000
outputs:
Bob 400000
Alice 99400
Ingrid 797000
fee: 3600
Basically, if the first transaction is able to be included in the next bloc=
k immediately, then Ingrid is able to earn the most of the fee paid by Alic=
e.
However, as more blocks pass without the transaction getting committed, the=
transaction in the mempool is replaced by transactions that bump up the fe=
e, until the time limit is reached and Ingrid pays out significantly in ord=
er to ensure the payment pushes through.
As far as I can tell, this mechanism will also work for CPFP-style transact=
ions.
In general, the insurance provider Ingrid will be a miner.
--
In the original context, this is generally about fast confirmation of chann=
el closes.
At the time that a commitment transaction is made, it is uncertain if the f=
eerate for it would still remain valid for some future spike.
The safest is that, if the counterparty is offline, if the feerate spikes, =
we should drop the channel unilaterally onchain before it rises so high tha=
t the commitment transaction cannot be confirmed in a timely manner.
However, if the feerate then settles lower afterwards, we have already broa=
dcasted the channel closure will no longer be able to use the fund on Light=
ning.
Unfortunately, the mechanism described above requires absolute locktimes, w=
hich would impose a maximum lifetime on channels, which we would like to av=
oid.
Thus, the mechanism cannot be used for Lightning closes.
For the Lightning case, what we want is something like:
* Ingrid assures Alice and Bob that the close transaction can be confirmed =
at any time, for only N satoshi.
The previous mechanism described is nearer to:
* Ingrid assures Alice that the transaction can be confirmed up to B blocks=
from now, for only N satoshi.
The issue is that relative locktimes require that a transaction be confirme=
d, and it is transaction itself that we want to assure.
Thus, we cannot use relative locktimes for any kind of fee-insurance mechan=
ism.
Thus, we must somehow tie down the blockheight at which we start our countd=
own, and so we cannot use this for Lightning closes, since Lightning closes=
must be freely doable at any time.
Still, the mechanism might be useful for onchain transactions to help reass=
ure users (which is why I send this post to bitcoin-dev).
Regards,
ZmnSCPxj
|
