📅 Original date posted:2015-06-08
📝 Original message:On Mon, Jun 08, 2015 at 02:14:01PM -0700, Raystonn . wrote:
> > 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...
--
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150608/8ec8b81f/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 15:37:05
in reply to nevent1q…uvg6
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 15:37:05Event JSON
{
"id": "4b72ed52f23a4c0b25c31b9a61be7898a27862d626c7bcd29203690d14126521",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686152225,
"kind": 1,
"tags": [
[
"e",
"87a31647709d131b7c0b391071dd87fb26301bd49b03e22ae1ae5f0e22f42304",
"",
"root"
],
[
"e",
"f918f54e0fe756d9b280cbfe9cf49301034060634eaad4c9d13b9488b3d07f03",
"",
"reply"
],
[
"p",
"3e6baaf01f15cb9383746ee7c1a225175502acbc3234f3e42160ad71d011e092"
]
],
"content": "📅 Original date posted:2015-06-08\n📝 Original message:On Mon, Jun 08, 2015 at 02:14:01PM -0700, Raystonn . wrote:\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...\n\n-- \n'peter'[:-1]@petertodd.org\n0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150608/8ec8b81f/attachment.sig\u003e",
"sig": "d8bfcc1b7c5f172ec4f9e5d2b95adf91eab94dd0abfba9a79180f4f60eb145fb14bf13def59af5d7eef29d78442d1cfa204f2c43512625f9583ca481fead2a78"
}