Sorry, I forgot one point which is pertinent to this conversation.

*Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are still an issue in coinjoin scenarios. 

Each coinjoin adversary can double-spend their coin to either full package weight(101kvb),
or give 24 descendants, which means you quickly pay out the nose in rule#3 or are excluded
from RBFing it if you have 4+ greifers in your coinjoin violating rule#5.

If we instead narrowed this policy to marking a transaction output as opt-in to V3, it gets a bit more interesting. Unfortunately, double-spending counterparties can still cause rule#3 pain, one 100kvb package of junk per peer, but rule#5 violations is at least contained to coinjoins with ~50 peers(assuming two transactions booted per input double-spent, which would be the V3 max bumped per input).

It's still worth exploring, but very speculatively.

Greg

On Wed, Nov 2, 2022 at 10:04 AM Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev wrote:
> Hi list,
>
> Reading Suhas's post on mempool policy consistency rules, and the grounded
> suggestion that as protocol developers we should work on special policy
> rules to support each reasonable use case on the network rather to arbiter
> between class of use-cases in the design of an
> unified set of rules, reminded me there is another solution to solve
> multi-party funding pinning rather than wide deployment of fullrbf. This
> was communicated to me a while back, and it was originally dismissed
> because of the privacy trade-offs (and potential slight fees overhead
> cost). However, if widely adopted, they might sound acceptable to
> contracting protocol developers and operators.

Strong NACK.

Zeroconf is, at best, a very marginal usecase. The only services that have
spoken up in support of it are Bitrefill and Muun, and the latter says they're
working to get rid of their vulnerability to it. People attempting to make it
secure have repeatedly done sybil attacks against the network in attempts to
measure transaction propagation. And of course, if transaction fees and full
mempools are in our near future - as is widely expected - mempool consistency
will even further diminish making zeroconf even harder to achieve.

Incurring a bunch of engineering costs and harming privacy for the sake of
continuing this nonsense is ridiculous.

If anything, we should be moving to full-RBF so we can undo the privacy cost
that is opt-in-RBF: right now 30% of transactions are having to harm their
privacy by signalling support for it. Full-RBF will allow that wallet
distinguisher to be eliminated.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev