Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-11 📝 Original message:On Aug 9, 2015 10:44 PM, ...

📅 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>;