rich1.0npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8njumphttps://nostr.ae📅 Original date posted:2015-08-11 📝 Original message:On Aug 9, 2015 10:44 PM, "Dave Scotese via bitcoin-dev" < bitcoin-dev at lists.linuxfoundation.org> wrote: > > On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: >> >> On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote: >> > Someone mentioned that when the backlog grows faster than it shrinks, that >> > is a real problem. I don't think it is. It is a problem for those who >> > don't wait for even one confirmation >> >> The mention you refer to was about the fact that the software doesn't cope >> well with a continuously growing mempool. >> If Bitcoind starts eating more and more memory, I expect lots of people that >> run it now to turn it off. > > > That is a real problem then. While emptying the mempool faster with bigger blocks will help to reduce the occurrence of that problem, I propose a user-configurable default limit to the size of the mempool as a permanent solution regardless of block size. "This software has stopped consuming memory necessary to validate transactions. You can override this by ..." If anyone feels that protecting those running full nodes from bitcoind eating more and more memory this way is a good idea, I can make a BIP out of it if that would help. You are completely right: this problem has nothing to do with the consensus block size maximum and it has to be solved regardless of what the maximum is. No BIP is necessary for this. The "doing nothing side" has been working on this too: https://github.com/bitcoin/bitcoin/pull/6470 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/277e1f15/attachment.html>