New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mempool usage #266

Closed
ghost opened this Issue May 21, 2017 · 4 comments

Comments

Projects
None yet
1 participant
@ghost

ghost commented May 21, 2017

Right now the mempool usage in my node is 238956256 and the maxmempool is 300000000. If i'm understanding correctly, that puts it at about 79% full. Which is probably OK for now. But in the medium term, given core's dicking around with a 1 MiB block size, we're probably going to see that % rise. It might be handy to have some kind of configuration option in Options to set the maxmempool much higher (albeit with a warning that you need this much at least swap available in order for it to make sense).

As a side note, this may be the way that bitcoin classic nodes become useful to the network - by being the only place where "dust" transactions exist in the mempool - core nodes would be smart to connect to us at least sometimes, guaranteeing that even if we can't get the whole of the network that we don't ever get cut out of it.

( Qt version 5.7.1.
Bitcoin Classic version v1.2.5.0-18bd3372 (64-bit)
Ubuntu zesty 17.04 )

edit my core node was much lower than my classic node, mempool wise.

@zander

This comment has been minimized.

Show comment
Hide comment
@zander

zander May 22, 2017

Hi,

in Bitcoin Classic there are two configuration options available in the config-file while not being present in the GUI.

These are;

maxmempool=<n> Keep the transaction memory pool below <n> megabytes (default: 300)
mempoolexpiry=<n> Do not keep transactions in the mempool longer than <n> hours (default: 72)

I think the first option would have the effect you are after.

zander commented May 22, 2017

Hi,

in Bitcoin Classic there are two configuration options available in the config-file while not being present in the GUI.

These are;

maxmempool=<n> Keep the transaction memory pool below <n> megabytes (default: 300)
mempoolexpiry=<n> Do not keep transactions in the mempool longer than <n> hours (default: 72)

I think the first option would have the effect you are after.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 22, 2017

Thanks for digging these up. I do think though that up until recently they were kind of obscure, the kind of things that only tinkerers would even care about, but lately we're passing to a point where normal users are increasingly going to have to tweak them. ie they belong in a gui.

ghost commented May 22, 2017

Thanks for digging these up. I do think though that up until recently they were kind of obscure, the kind of things that only tinkerers would even care about, but lately we're passing to a point where normal users are increasingly going to have to tweak them. ie they belong in a gui.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 24, 2017

Digging further I'm not so sure this is a wise idea. My real issue is with stuck transactions and I'm no loner convinced that this is the way to handle them.

ghost commented May 24, 2017

Digging further I'm not so sure this is a wise idea. My real issue is with stuck transactions and I'm no loner convinced that this is the way to handle them.

@ghost ghost closed this May 24, 2017

@zander

This comment has been minimized.

Show comment
Hide comment
@zander

zander May 24, 2017

My real issue is with stuck transactions and I'm no loner convinced that this is the way to handle them.

The way to handle stuck transactions is to support software teams that scale on-chain and do not object to enlarging the block size as that is the main reason your transactions can not be confirmed. Miners are forbidden from producing enough block space to fit all transactions people create.

For more; https://bitcoinclassic.com/devel/Blocksize.html

zander commented May 24, 2017

My real issue is with stuck transactions and I'm no loner convinced that this is the way to handle them.

The way to handle stuck transactions is to support software teams that scale on-chain and do not object to enlarging the block size as that is the main reason your transactions can not be confirmed. Miners are forbidden from producing enough block space to fit all transactions people create.

For more; https://bitcoinclassic.com/devel/Blocksize.html

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment