David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2020-09-19 📝 Original message:On Sat, Sep 19, 2020 at ...
📅 Original date posted:2020-09-19
📝 Original message:On Sat, Sep 19, 2020 at 09:30:56AM -0700, Jeremy wrote:
> Yup, I was aware of this limitation but I'm not sure how practical it is as
> an attack because it's quite expensive for the attacker.
It's cheap if:
1. You were planning to consolidate all those UTXOs at roughly that
feerate anyway.
2. After you no longer need your pinning transaction in the mempool, you
make an out-of-band arrangement with a pool to mine a small
conflicting transaction.
> But there are a few simple policies that can eliminate it:
>
> 1) A Sponsoring TX never needs to be more than, say, 2 inputs and 2
> outputs. Restricting this via policy would help, or more flexibly
> limiting the total size of a sponsoring transaction to 1000 bytes.
I think that works (as policy).
> 2) Make A Sponsoring TX not need to pay more absolute fee, just needs to
> increase the feerate (perhaps with a constant relay fee bump to prevent
> spam).
I think it'd be hard to find a constant relay fee bump amount that was
high enough to prevent abuse but low enough not to unduly hinder
legitimate users.
> I think 1) is simpler and should allow full use of the sponsor mechanism
> while preventing this class of issue mostly.
Agreed.
Thanks,
-Dave
-------------- 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/20200919/15f5bf2c/attachment.sig>;
📝 Original message:On Sat, Sep 19, 2020 at 09:30:56AM -0700, Jeremy wrote:
> Yup, I was aware of this limitation but I'm not sure how practical it is as
> an attack because it's quite expensive for the attacker.
It's cheap if:
1. You were planning to consolidate all those UTXOs at roughly that
feerate anyway.
2. After you no longer need your pinning transaction in the mempool, you
make an out-of-band arrangement with a pool to mine a small
conflicting transaction.
> But there are a few simple policies that can eliminate it:
>
> 1) A Sponsoring TX never needs to be more than, say, 2 inputs and 2
> outputs. Restricting this via policy would help, or more flexibly
> limiting the total size of a sponsoring transaction to 1000 bytes.
I think that works (as policy).
> 2) Make A Sponsoring TX not need to pay more absolute fee, just needs to
> increase the feerate (perhaps with a constant relay fee bump to prevent
> spam).
I think it'd be hard to find a constant relay fee bump amount that was
high enough to prevent abuse but low enough not to unduly hinder
legitimate users.
> I think 1) is simpler and should allow full use of the sponsor mechanism
> while preventing this class of issue mostly.
Agreed.
Thanks,
-Dave
-------------- 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/20200919/15f5bf2c/attachment.sig>;