From: Peter Todd <pete@petertodd•org>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime
Date: Wed, 9 Nov 2022 07:41:30 -0500 [thread overview]
Message-ID: <Y2uf+hRBdLxOl6LT@petertodd.org> (raw)
In-Reply-To: <CALZpt+GgH7B-sSWndNfrMp8qza=LmZQ6BWGGFjFxcutat7Nxww@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4397 bytes --]
On Mon, Nov 07, 2022 at 05:55:59PM -0500, Antoine Riard wrote:
> Hi Peter,
>
> > We can ensure with high probability that the transaction can be cancelled/mined
> > at some point after N blocks by pre-signing a transaction, with nLockTime set
> > sufficiently far into the future, spending one or more inputs of the
> > transaction with a sufficiently high fee that it would replace transaction(s)
> > attempting to exploit Rule #3 pinning (note how the package limits in Bitcoin
> > Core help here).
>
> From my understanding, there are many open questions to such a
> pre-signed high-fee solution aiming to address Rule #3 pinning.
> Determining the high-fee to guarantee replacements with high odds. I
> think it should be superior to current top network mempools sat/vb *
> MAX_STANDARD_TX_WEIGHT, otherwise an adversary can pin the multi-party
> funded transaction on the ground of Core's
> replacement rule ("The replacement transaction's feerate is greater
> than the feerates of all directly conflicting transactions''). Though
> note the difficulty, the sat/vb is an unknown fact at time of
> signatures exchange among the multi-party funded transaction
> participants. Solving this issue probably requires from then to
> overshoot, and adopt a historical worst-case mempool feerate.
First of all, since this is a punishment scenario, overshooting in general is a
good thing provided that the bad actor is the one paying for the overshoot.
I may be mistaken on this point. But IIRC rule #6, "The replacement
transaction's feerate is greater than the feerates of all directly conflicting
transactions.", refers to the overall package feerate including all
transactions that would need to be mined.
This is relevant as we have two scenarios for pinning that could try to exploit
rule #6 while pinning, and neither works:
1) A large, low fee rate, transaction is spent by a high fee rate transaction.
In this case the package fee rate of the second tx is still low, because the
low fee rate tx would need to be mined first.
2) A small, high fee rate tx, is spent by a large low fee rate tx. In this case
the second low fee rate tx is irrelevant, because the high fee rate tx will get
mined soon, breaking the pin and costing the attacker money.
Now, if my understanding of rule #6 is incorrect, obviously we should fix that!
It's incentive incompatible to reject a high fee rate replacement that overall
pays more in fees (rule #3), on the basis that we expect a *different* miner to
mine the low fee rate tx it spends. Because unless we're expecting the
transaction to somehow get mined by someone else in the near future, why aren't
we mining what pays more money now?
> This "historically-worst" sat/vb introduces two new issues, first I
> think this is an economic lower bound on the funds that can be staked
> in the collaborative transaction. Second I believe this constitutes a
> griefing vector, where a participant could deliberately pin to inflict
> an asymmetric damage, without entering into any fee competition. This
> griefing vector could be leveraged as hard as being triggered by a
> miner-as-participant in so-called miner harvesting attacks.
>
> Further, I think this solution relying on nLocktime doesn't solve the
> timevalue DoS inflicted to the participants UTXOs, until the
> pre-signed high-fee transaction is final. If participants prefer to
> save the timevalue of their contributed UTXOs over operation success,
> a better approach could be for them to unilaterally spend after a
> protocol/implementation timepoint (e.g LN's funding timeout recovery
> mechanism).
>
> A more workable solution I believe could be simply to rely on
> package-relay, an ephemeral anchor output, and a special replacement
> regime (e.g nVersion=3) to allow the multi-party funded transaction
> coordinator to unilateral fee-bump, in a step-by-step approach. I.e
> without making assumptions on the knowledge of network mempools and
> burning directly the worst amount in fees.
Note that if you are considering miner harvesting attacks as part of the threat
model, it's not clear to me that the v3 rules that depend on miners arbitrarily
rejecting transactions from their mempools are actually sufficiently incentive
compatible to work.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-11-09 12:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 20:17 [bitcoin-dev] Removing BIP-125 Rule #5 Pinning with the Always-Replaceable Invariant Peter Todd
2022-11-07 21:17 ` [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime Peter Todd
2022-11-07 22:55 ` Antoine Riard
2022-11-09 12:41 ` Peter Todd [this message]
2022-11-11 3:00 ` David A. Harding
2022-11-07 21:21 ` [bitcoin-dev] Removing BIP-125 Rule #5 Pinning with the Always-Replaceable Invariant Suhas Daftuar
2022-11-07 21:27 ` Peter Todd
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=Y2uf+hRBdLxOl6LT@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=antoine.riard@gmail$(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