Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-02 📝 Original message:On Tue, Nov 01, 2022 at ...
📅 Original date posted:2022-11-02
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/57de210a/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/57de210a/attachment.sig>;