Date: Sat, 01 Feb 2020 00:39:36 +0000
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
Precedence: list

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