Good morning David,
> On Fri, Jan 31, 2020 at 03:42:08AM +, 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 500, Ingrid 80
> > outputs:
> > Bob 40
> > 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 Ingri
