From: Matt Corallo <lf-lists@mattcorallo•com>
To: Rusty Russell <rusty@rustcorp•com.au>
Cc: bitcoin-dev@lists•linuxfoundation.org,
lightning-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)
Date: Mon, 7 Jan 2019 15:18:52 +0000 [thread overview]
Message-ID: <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com> (raw)
In-Reply-To: <878t163qzi.fsf@rustcorp.com.au>
Sorry for the late reply.
Hmm, I included the old RBF-pinning proposal as a comparison.
Personally, I find it both less clean and less convincingly secure.
Ultimately, defining a "near the top of the mempool" criteria is fraught
with issues. While it's probably OK for the original problem (large
batched transactions where you don't want a single counterparty to
prevent confirmation), lightning's requirements are very different.
Instead is wanting a high probability that the transaction in question
confirms "soon", we need certainty that it will confirm by some deadline.
Thus, even if you imagine a steady-state mempool growth, unless the
"near the top of the mempool" criteria is "near the top of the next
block" (which is obviously *not* incentive-compatible), its easy to see
how the package would fail to confirm within a handful of blocks given
block time variance. Giving up the ability to RBF/CPFP more than once in
case the fee moves away from us seems to be a rather significant
restriction.
THe original proposal is somewhat of a hack, but its a hack on the
boundary condition where packages meet our local anti-DoS rules in
violation of the "incentive compatible" goal anyway (essentially, though
miners also care about anti-DoS). This proposal is very different and,
similar to how it doesn't work if blocks randomly come in a bit slow for
an hour or two, isn't incentive compatible if blocks come in a bit fast
for an hour or two, as all of a sudden that "near the top of the
mempool" criteria makes no sense and you should have accepted the new
transaction(s).
As for package relay, indeed, we can probably do soemthing simpler for
this specific case, but itdepends on what the scope of that design is.
Suhas opened an issue to try to scope it out a bit more at
https://github.com/bitcoin/bitcoin/issues/14895
Matt
> On Dec 3, 2018, at 22:33, Rusty Russell <rusty@rustcorp•com.au> wrote:
>
> Matt Corallo <lf-lists@mattcorallo•com> writes:
>> As an alternative proposal, at various points there have been
>> discussions around solving the "RBF-pinning" problem by allowing
>> transactors to mark their transactions as "likely-to-be-RBF'ed", which
>> could enable a relay policy where children of such transactions would be
>> rejected unless the resulting package would be "near the top of the
>> mempool". This would theoretically imply such attacks are not possible
>> to pull off consistently, as any "transaction-delaying" channel
>> participant will have to place the package containing A at an effective
>> feerate which makes confirmation to occur soon with some likelihood. It
>> is, however, possible to pull off this attack with low probability in
>> case of feerate spikes right after broadcast.
>
> I like this idea.
>
> Firstly, it's incentive-compatible[1]: assuming blocks are full, miners
> should always take a higher feerate tx if that tx would be in the
> current block and the replaced txs would not.[2]
>
> Secondly, it reduces the problem that the current lightning proposal
> adds to the UTXO set with two anyone-can-spend txs for 1000 satoshis,
> which might be too small to cleanup later. This rule would allow a
> simple single P2WSH(OP_TRUE) output, or, with IsStandard changed,
> a literal OP_TRUE.
>
>> Note that this clearly relies on some form of package relay, which comes
>> with its own challenges, but I'll start a separate thread on that.
>
> Could be done client-side, right? Do a quick check if this is above 250
> satoshi per kweight but below minrelayfee, put it in a side-cache with a
> 60 second timeout sweep. If something comes in which depends on it
> which is above minrelayfee, then process them as a pair[3].
>
> Cheers,
> Rusty.
> [1] Miners have generally been happy with Defaults Which Are Good For The
> Network, but I feel a long term development aim should to be reduce
> such cases to smaller and smaller corners.
> [2] The actual condition is subtler, but this is a clear subset AFAICT.
> [3] For Lightning, we don't care about child-pays-for-grandparent etc.
next prev parent reply other threads:[~2019-01-07 15:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-29 19:37 [bitcoin-dev] " Matt Corallo
2018-11-30 17:38 ` Russell O'Connor
2018-11-30 19:33 ` Matt Corallo
2018-12-02 15:08 ` Bob McElrath
2018-12-03 4:16 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2018-12-04 3:33 ` Rusty Russell
2019-01-07 15:18 ` Matt Corallo [this message]
2019-01-08 5:50 ` Rusty Russell
2019-01-08 14:46 ` Matt Corallo
2019-02-13 4:22 ` Rusty Russell
2019-10-24 13:49 ` Johan Torås Halseth
2019-10-24 21:25 ` Matt Corallo
2019-10-25 7:05 ` Johan Torås Halseth
2019-10-25 17:30 ` Matt Corallo
2019-10-27 19:13 ` Jeremy
2019-10-28 9:45 ` Johan Torås Halseth
2019-10-28 17:14 ` David A. Harding
2019-10-30 7:22 ` Johan Torås Halseth
2019-10-27 22:54 ` David A. Harding
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=725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
--cc=rusty@rustcorp$(echo .)com.au \
/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