From: "David A. Harding" <dave@dtrt•org>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Onchain fee insurance mechanism
Date: Fri, 31 Jan 2020 15:01:29 -0600 [thread overview]
Message-ID: <20200131210129.ufnjxb2x7wllhcuw@ganymede> (raw)
In-Reply-To: <2U3WdMgyM7iLhQnak0GjkH6u6C0C_Ry59WucTiRthajkOXqAirvN55U39to0kQY5bDzv9SBZXy5Qbx2QZopJwktHqVUKbfpCjEfq1H_v0vE=@protonmail.com>
[-- 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 --]
next prev parent reply other threads:[~2020-01-31 21:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-31 3:42 ZmnSCPxj
2020-01-31 21:01 ` David A. Harding [this message]
2020-02-01 0:39 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200131210129.ufnjxb2x7wllhcuw@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox