Subject: [bitcoin-dev] Onchain fee insurance mechanism

From: ZmnSCPxj <[email-masked]>
Date: Fri, 31 Jan 2020 03:42:08 +0000

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.

--

In the original context, this is generally about fast confirmation of channel closes.
At the time that a commitment transaction is made, it is uncertain if the feerate 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 that the commitment transaction cannot be confirmed in a timely manner.
However, if the feerate then settles lower afterwards, we have already broadcasted the channel closure will no longer be able to use the fund on Lightning.

Unfortunately, the mechanism described above requires absolute locktimes, which would impose a maximum lifetime on channels, which we would like to avoid.
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 confirmed, and it is transaction itself that we want to assure.
Thus, we cannot use relative locktimes for any kind of fee-insurance mechanism.
Thus, we must somehow tie down the blockheight at which we start our countdown, 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 reassure users (which is why I send this post to bitcoin-dev).

Regards,
ZmnSCPxj