Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-02 📝 Original message:Sorry, I forgot one point ...
📅 Original date posted:2022-11-02
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/2c4439ba/attachment-0001.html>;
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/2c4439ba/attachment-0001.html>;