Date: Fri, 31 Jan 2020 03:42:08 +0000
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2U3WdMgyM7iLhQnak0GjkH6u6C0C_Ry59WucTiRthajkOXqAirvN55U39to0kQY5bDzv9SBZXy5Qbx2QZopJwktHqVUKbfpCjEfq1H_v0vE=@protonmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Onchain fee insurance mechanism
Precedence: list

Good morning list,

During LNConf 2019, Jack Mallers presented about hedging of onchain fees, w=
hich he argues is necessary in order to have a smooth experience interfacin=
g between onchain and offchain (in particular, when closing and opening cha=
nnels).

The exact mechanism proposed was to construct a futures market on onchain f=
eerates, with miners taking short positions on fees (they are naturally lon=
g on fees) while users take long positions on fees (they are naturally shor=
t on fees).

I observe that what the users effectively experience is similar to a consta=
nt feerate (indeed the positions the user takes up are arranged such that t=
he 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 onch=
ain 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 transac=
tions:

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

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

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

--

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

Unfortunately, the mechanism described above requires absolute locktimes, w=
hich would impose a maximum lifetime on channels, which we would like to av=
oid.
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 confirme=
d, and it is transaction itself that we want to assure.
Thus, we cannot use relative locktimes for any kind of fee-insurance mechan=
ism.
Thus, we must somehow tie down the blockheight at which we start our countd=
own, 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 reass=
ure users (which is why I send this post to bitcoin-dev).

Regards,
ZmnSCPxj