David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-27 📝 Original message: On Thu, Oct 24, 2019 at ...
📅 Original date posted:2019-10-27
📝 Original message:
On Thu, Oct 24, 2019 at 03:49:09PM +0200, Johan Torås Halseth wrote:
> [...] what about letting the rule be
>
> The last transaction which is added to a package of dependent
> transactions in the mempool must:
> * Have no more than one unconfirmed parent.
> [... subsequent email ...]
> I realize these limits are there for a reason though, but I'm wondering if
> we could relax them.
Johan,
I'm not sure any of the other replies to this thread addressed your
request for a reason behind the limits related to your proposal, so I
thought I'd point out that---subsequent to your posting here---a
document[1] was added to the Bitcoin Core developer wiki that I think
describes the risk of the approach you proposed:
> Free relay attack:
>
> - Create a low feerate transaction T.
>
> - Send zillions of child transactions that are slightly higher feerate
> than T until mempool is full.
>
> - Create one small transaction with feerate just higher than T’s, and
> watch T and all its children get evicted. Total fees in mempool drops
> dramatically!
>
> - Attacker just relayed (say) 300MB of data across the whole network
> but only pays small feerate on one small transaction.
The document goes on to describe at a high level how Bitcoin Core
attempts to mitigate this problem as well as other ways it tries to
optimize the mempool in order to maximize miner profit (and so ensure
that miners continue to use public transaction relay).
I hope that's helpful to you and to others in both understanding the
current state and in thinking about ways in which it might be improved.
-Dave
[1] https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Mempool-and-mining
Content adapted from slides by Suhas Daftuar, uploaded and formatted
by Gregory Sanders and Marco Falke.
📝 Original message:
On Thu, Oct 24, 2019 at 03:49:09PM +0200, Johan Torås Halseth wrote:
> [...] what about letting the rule be
>
> The last transaction which is added to a package of dependent
> transactions in the mempool must:
> * Have no more than one unconfirmed parent.
> [... subsequent email ...]
> I realize these limits are there for a reason though, but I'm wondering if
> we could relax them.
Johan,
I'm not sure any of the other replies to this thread addressed your
request for a reason behind the limits related to your proposal, so I
thought I'd point out that---subsequent to your posting here---a
document[1] was added to the Bitcoin Core developer wiki that I think
describes the risk of the approach you proposed:
> Free relay attack:
>
> - Create a low feerate transaction T.
>
> - Send zillions of child transactions that are slightly higher feerate
> than T until mempool is full.
>
> - Create one small transaction with feerate just higher than T’s, and
> watch T and all its children get evicted. Total fees in mempool drops
> dramatically!
>
> - Attacker just relayed (say) 300MB of data across the whole network
> but only pays small feerate on one small transaction.
The document goes on to describe at a high level how Bitcoin Core
attempts to mitigate this problem as well as other ways it tries to
optimize the mempool in order to maximize miner profit (and so ensure
that miners continue to use public transaction relay).
I hope that's helpful to you and to others in both understanding the
current state and in thinking about ways in which it might be improved.
-Dave
[1] https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Mempool-and-mining
Content adapted from slides by Suhas Daftuar, uploaded and formatted
by Gregory Sanders and Marco Falke.