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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 87905C0171
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Feb 2020 00:39:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 57EE586144
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Feb 2020 00:39:53 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id wLveHvfr4WA7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Feb 2020 00:39:51 +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 fraxinus.osuosl.org (Postfix) with ESMTPS id 2722684CC2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Feb 2020 00:39:50 +0000 (UTC)
Date: Sat, 01 Feb 2020 00:39:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1580517587;
bh=UWqTwtpohHg2JJylMvlXgmMA2uCV96Q+jYYziiyEmas=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=q2Twq7ZbuokTsDejvGAk9ZkrZRkQYOl9KxQAps27XdrKv51g7B/SluQZCwlQo1nBK
EZIKc49bwbiGlokFzKtf6zRitiCMDZcny95dSiJP31nHR0rg/0NZ+Br2Klxjh7EIq8
diEH+rTwftZQm5Ib1BqW71lxBwVcSty3A54bu2h8=
To: "David A. Harding" <dave@dtrt.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2XX6GT0e_q6BTo0HQnromtAwL6A9MGW-RCE-G9Ge-pKlreanboQQW1izVYxVXl3aqRQSG1xoOmNIcgFHNXDVfUI_DXzyUuxJiajhDpSP73I=@protonmail.com>
In-Reply-To: <20200131210129.ufnjxb2x7wllhcuw@ganymede>
References: <2U3WdMgyM7iLhQnak0GjkH6u6C0C_Ry59WucTiRthajkOXqAirvN55U39to0kQY5bDzv9SBZXy5Qbx2QZopJwktHqVUKbfpCjEfq1H_v0vE=@protonmail.com>
<20200131210129.ufnjxb2x7wllhcuw@ganymede>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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: Sat, 01 Feb 2020 00:39:53 -0000
Good morning David,
> On Fri, Jan 31, 2020 at 03:42:08AM +0000, ZmnSCPxj via bitcoin-dev wrote:
>
> > Let me then propose a specific mechanism for feerate insurance against =
onchain feerate spikes.
> > [...]
> > At current blockheight B, Alice and Ingrid then arrange a series of tra=
nsactions:
> >
> > nLockTime: B+1
> > nSequence: RBF enabled, no relative locktime.
> > inputs: Alice 5000000, Ingrid 800000
> > outputs:
> > Bob 400000
> > Alice 99400
> > Ingrid 800400
> > fee: 200
> >
> >
> > [...]
>
> Ingrid is able to rescind this series of pre-signed transactions at any
> time before one of the transactions is confirmed by double spending her
> UTXO (e.g. via a RBF fee bump). If Alice needs to trust Ingrid to honor
> the contract anyway, they might as well not include Ingrid's input or
> output in the transaction and instead use an external accounting and
> payment mechanism. For example, Alice and Ingrid agree to a fee
> schedule:
>
> > height: B+1
> > fee: 200
> >
> > height: B+2
> > fee: 400
> >
> > height: B+3
> > fee: 599
> >
> > height: B+4
> > fee: 3600
> >
>
> Then they wait for whichever version of the transaction to confirm and
> one of them remits to the other the appropriate amount (either 400, 200,
> or 1 base unit to Ingrid, or 3,000 base units to Alice). This
> remittance can be done by whatever mechanism they both support (e.g. an
> onchain transaction, an LN payment, or just credit on an exchange).
>
> Since it's possible to achieve equivilent security (or lack thereof)
> without the locktime mechanism, I don't think the locktime mechanism
> adds anything to the idea of hedging fees---and, as you note, it suffers
> from incompatibility with some cases where users would be especially
> eager to obtain feerate insurance.
Indeed, the rescindability is a flaw.
I will now do something really evil: I will attempt to patch this flaw with=
out considering that the patch will of course have other detrimental side e=
ffects.
Rather than have the Ingrid-input (and output) be solely under the control =
of Ingrid, it is a 2-of-2 with Ingrid and Alice.
Long before the Alice->Bob transaction, Alice has already commissioned the =
services of Ingrid.
They have already agreed on the specs of the insurance policy, and in parti=
cular, have agreed that this agreement terminates at some future data.
At setup, Alice and Ingrid create a claim transaction for Ingrid, with `nLo=
ckTime` set to the agreed-upon end-of-insurance-contract, which allows Ingr=
id to reclaim the original fund.
Then, at height B when Alice wants to send to Bob, they create the series o=
f timelocked transactions, with the Ingrid output similarly having an `nLoc=
kTime`d transaction that lets Ingrid reclaim the earned funds.
Against this patched scheme, of course, new problems arise:
* During times of low fees, Alice can just create a non-insured transaction=
directly on the blockchain, denying Ingrid its earnings.
* During times of high fees, Ingrid can go offline and refuse to provide si=
gnatures needed for the insured transactions, denying Alice its service.
* This is significant if Alice prepaid for the insurance contract.
Thus, as we can see, patching a flawed protocol still leaves us with a flaw=
ed protocol.
--
On the other hand, the above "Spilmanizing" of the protocol leads to a poss=
ible insurance policy for Lightning channel closures.
At the same time as channel establishment between Alice and Bob, Alice also=
starts an insurance contract with Ingrid.
Alice prepays Ingrid, using a CoinJoined transaction that spends from Alice=
and Ingrid inputs, with the combined premium plus Ingrid inputs value put =
in an output locked to Alice && Ingrid, and a maximum contract lifetime (an=
`nLockTime`d transaction that claims the Alice&&Ingrid output and returns =
the fund, plus insurance premium, to Ingrid).
Then, at each commitment transaction signing, there is an additional unencu=
mbered but tiny output that Alice can claim immediately (obviously this req=
uires a change in the BOLT spec).
Ingrid and Alice create an insurance transaction with high feerate, which s=
pends the above tiny output, and spends the Alice&&Ingrid output, deducting=
the fees from the Alice&&Ingrid output and returning what is left to Ingri=
d.
Then, if Alice decides to drop the unilateral close onchain:
* If fees are low at the time that unilateral close, then Alice can just cl=
aim the tiny output itself.
* Alice is incentivized to do so because it means she will still control =
that tiny output.
* Ingrid can then reclaim its fund, plus the premium, at the end of the i=
nsurance contract lifetime.
* If fees are high at the time that unilateral close, then Alice can sacrif=
ice the value of the tiny output and attach the insurance transaction with =
high feerate.
Further:
* If on a new commitment transaction, Ingrid does not cooperate, then Alice=
can drop onchain *and* punish Ingrid by dropping the previous commitment a=
nd also broadcasting the insurance transaction.
* Alice has to sacrifice its tiny output to do so, but it would be worth =
it to punish Ingrid and deter this non-cooperation.
* When the insurance contract lifetime is near, Alice and Ingrid can renew =
the contract by cooperatively spending the Alice&&Ingrid output to a new Al=
ice&&Ingrid output (possibly with some payment from Alice to renew the cont=
ract).
* This gives an upper bound for what Alice will pay to ensure its channel i=
s closeable at any time very quickly, which is the entire point.
Regards,
ZmnSCPxj
|
