Onchain fee insurance mechanism

Good morning list,

During LNConf 2019, Jack Mallers presented about hedging of onchain fees, which he argues is necessary in order to have a smooth experience interfacing between onchain and offchain (in particular, when closing and opening channels).

The exact mechanism proposed was to construct a futures market on onchain feerates, with miners taking short positions on fees (they are naturally long on fees) while users take long positions on fees (they are naturally short on fees).

I observe that what the users effectively experience is similar to a constant feerate (indeed the positions the user takes up are arranged such that the 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 onchain 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 transactions:

    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 block immediately, then Ingrid is able to earn the most of the fee paid by Alice. However, as more blocks pass without the transaction getting committed, the transaction in the mempool is replaced by transactions that bump up the fee, until the time limit is reached and Ingrid pays out significantly in order to ensure the payment pushes through.

As far as I can tell, this mechanism will also work for CPFP-style transactions.

In general, the insurance provider Ingrid will be a miner.

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.

-Dave

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.