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