* [bitcoin-dev] Onchain fee insurance mechanism
@ 2020-01-31 3:42 ZmnSCPxj
2020-01-31 21:01 ` David A. Harding
0 siblings, 1 reply; 3+ messages in thread
From: ZmnSCPxj @ 2020-01-31 3:42 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Onchain fee insurance mechanism
2020-01-31 3:42 [bitcoin-dev] Onchain fee insurance mechanism ZmnSCPxj
@ 2020-01-31 21:01 ` David A. Harding
2020-02-01 0:39 ` ZmnSCPxj
0 siblings, 1 reply; 3+ messages in thread
From: David A. Harding @ 2020-01-31 21:01 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Onchain fee insurance mechanism
2020-01-31 21:01 ` David A. Harding
@ 2020-02-01 0:39 ` ZmnSCPxj
0 siblings, 0 replies; 3+ messages in thread
From: ZmnSCPxj @ 2020-02-01 0:39 UTC (permalink / raw)
To: David A. Harding; +Cc: Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-02-01 0:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-31 3:42 [bitcoin-dev] Onchain fee insurance mechanism ZmnSCPxj
2020-01-31 21:01 ` David A. Harding
2020-02-01 0:39 ` ZmnSCPxj
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox