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
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
