[bitcoin-dev] Onchain fee insurance mechanism

[ZmnSCPxj]

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 transactions:
> >
> >     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 without considering that the patch will of course have other detrimental side effects.

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 particular, have agreed that this agreement terminates at some future data.
At setup, Alice and Ingrid create a claim transaction for Ingrid, with `nLockTime` set to the agreed-upon end-of-insurance-contract, which allows Ingrid to reclaim the original fund.

Then, at height B when Alice wants to send to Bob, they create the series of timelocked transactions, with the Ingrid output similarly having an `nLockTime`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 signatures 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 flawed protocol.

--

On the other hand, the above "Spilmanizing" of the protocol leads to a possible 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 unencumbered but tiny output that Alice can claim immediately (obviously this requires a change in the BOLT spec).
Ingrid and Alice create an insurance transaction with high feerate, which spends the above tiny output, and spends the Alice&&Ingrid output, deducting the fees from the Alice&&Ingrid output and returning what is left to Ingrid.

Then, if Alice decides to drop the unilateral close onchain:

* If fees are low at the time that unilateral close, then Alice can just claim 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 insurance contract lifetime.
* If fees are high at the time that unilateral close, then Alice can sacrifice 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 and 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 Alice&&Ingrid output (possibly with some payment from Alice to renew the contract).
* This gives an upper bound for what Alice will pay to ensure its channel is closeable at any time very quickly, which is the entire point.


Regards,
ZmnSCPxj