📅 Original date posted:2015-06-08
📝 Original message:> the only way a transaction can be removed from a Bitcoin Core mempool is
> through it getting mined, double-spent, or the node restarting.
Right. And that results in some transactions with insufficient fees getting
dropped today after many hours.
> The protection that we have against that attack is that you need access to
> a lot of bitcoins to pay enough fees.
That's no protection against a well-funded private and/or public entity.
Without the block size limit, this attack doesn't exist. It would simply
result in a transfer of wealth from spammer to miners, which is a nicely
antifragile response for the Bitcoin network.
-----Original Message-----
From: Peter Todd
Sent: Monday, June 08, 2015 2:33 PM
To: Raystonn .
Cc: Patrick Mccorry (PGR) ; Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential
solution described: Dropped-transaction spam attack against the blocksize
limit
> > there is no memory pool cap currently
>
> Real hardware does not have an infinite amount of RAM. Memory pool sizes
> cannot grow unbounded. Some transactions with insufficient fees do get
> dropped today after many hours.
Actually they don't, which is an unfortunate problem with the existing
mempool implementation; the only way a transaction can be removed from a
Bitcoin Core mempool is through it getting mined, double-spent, or the
node restarting.
The protection that we have against that attack is that you need access
to a lot of bitcoins to pay enough fees. With the 0.01mBTC/KB minimum
relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram
consumed, and furthermore, actually getting that many transactions to
propagate over the network is non-trivial. (no, I'm not going to tell
you how)
The obvious solution is to cap the size of the mempool and evict
transactions lowest fee/KB first, but if you do that they you (further)
break zeroconf security. On the other hand, if you don't break zeroconf
security an attacker can prevent reasonable fee transactions from
propagating.
I probably should get around to fixing this...
Raystonn . [ARCHIVE] /
npub18e…20rmx
2023-06-07 15:37:08
in reply to nevent1q…fpsh
Author Public Key
npub18e464uqlzh9e8qm5dmnurg39za2s9t9uxg608eppvzkhr5q3uzfqg20rmxSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:37:08Event JSON
{
"id": "46b8ac5e0d95f9ca45c471521148c04ed660aa819d68d29e04a33d42bbb15466",
"pubkey": "3e6baaf01f15cb9383746ee7c1a225175502acbc3234f3e42160ad71d011e092",
"created_at": 1686152228,
"kind": 1,
"tags": [
[
"e",
"bb822df33a2311a9ca89d4569d257edafe783786283eeb6a07e4d92a36b392d7",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-06-08\n📝 Original message:\u003e the only way a transaction can be removed from a Bitcoin Core mempool is \n\u003e through it getting mined, double-spent, or the node restarting.\n\nRight. And that results in some transactions with insufficient fees getting \ndropped today after many hours.\n\n\u003e The protection that we have against that attack is that you need access to \n\u003e a lot of bitcoins to pay enough fees.\n\nThat's no protection against a well-funded private and/or public entity. \nWithout the block size limit, this attack doesn't exist. It would simply \nresult in a transfer of wealth from spammer to miners, which is a nicely \nantifragile response for the Bitcoin network.\n\n\n-----Original Message----- \nFrom: Peter Todd\nSent: Monday, June 08, 2015 2:33 PM\nTo: Raystonn .\nCc: Patrick Mccorry (PGR) ; Bitcoin Dev\nSubject: Re: [Bitcoin-development] New attack identified and potential \nsolution described: Dropped-transaction spam attack against the blocksize \nlimit\n\n\u003e \u003e there is no memory pool cap currently\n\u003e\n\u003e Real hardware does not have an infinite amount of RAM. Memory pool sizes\n\u003e cannot grow unbounded. Some transactions with insufficient fees do get\n\u003e dropped today after many hours.\n\nActually they don't, which is an unfortunate problem with the existing\nmempool implementation; the only way a transaction can be removed from a\nBitcoin Core mempool is through it getting mined, double-spent, or the\nnode restarting.\n\nThe protection that we have against that attack is that you need access\nto a lot of bitcoins to pay enough fees. With the 0.01mBTC/KB minimum\nrelay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram\nconsumed, and furthermore, actually getting that many transactions to\npropagate over the network is non-trivial. (no, I'm not going to tell\nyou how)\n\nThe obvious solution is to cap the size of the mempool and evict\ntransactions lowest fee/KB first, but if you do that they you (further)\nbreak zeroconf security. On the other hand, if you don't break zeroconf\nsecurity an attacker can prevent reasonable fee transactions from\npropagating.\n\nI probably should get around to fixing this...",
"sig": "848079a844776cae5513ea93f50c6b5c662da72e47d01d2e0db6f74461fd9aefba67f514b946eb4691db2bf863f4a588cf9c9de091182ad7855ecbebe0a5735d"
}