Skip to content
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

suggestion: it would be really useful to include mempool total value (utxo totals), and total value xfer rate #2

Open
tphyahoo opened this issue Feb 6, 2016 · 3 comments

Comments

@tphyahoo
Copy link

tphyahoo commented Feb 6, 2016

For mempool value (utxo total sat in mempool): I would try to include this first by adding a second y axis for mempool utxo totals. If that screws up chart visually, it could be added as additional chart instead.

This would reveal if mempool spikes are likely spam, or looks like real value is pushing up the mempool.

A related metric would be total value xfer rate, i.e. utxo total sat / kB. If the fee rate is spiking, but the total value xfer rate is crashing, this would be suspicious, or at any rate evidence that there are plenty of low value transactions that could wait their turn without making more block space available.

If both fee rate and total value xfer rate are spiking, that means there are high values of bitcoin trying to move around, that are getting close to being crowded out. Which would be evidence that big blockers are right, and the time to 2mb-fork is closer than the small blockers think.

@tphyahoo tphyahoo changed the title suggestion: it would be really useful to include mempool value (utxo totals) along with mempool size suggestion: it would be really useful to include mempool total value (utxo totals), and total value xfer rate Feb 6, 2016
@kravets
Copy link

kravets commented Feb 6, 2016

0.12.0 version eliminates what's called "priority transaction" sub-pool, i.e. upto 50,000 bytes in each block that was allocated to transactions with large amount of days destroyed, etc ... after the size of this "priority area" is changed to 0 by default, no transaction with the fee under the dust relay minimum will propagate at all. At this point, one can argue that there is no more spam left bc if a transaction is paying more than dust relay minimum, then it's not spam (according to Bitcoin's working definition).

@tphyahoo
Copy link
Author

tphyahoo commented Feb 6, 2016

My definition of spam is suspect uneconomic transactions: transactions created specifically to manipulate statistics and public perception. It's impossible to prove definitely where tx statistics manipulation is taking place, but my purpose with this suggestion is to make it as difficulat as possible, by providing public metrics that are increasingly difficult/expensive to convincingly fake.

@bitcoinfees
Copy link
Owner

Thanks for the suggestions.

It's indeed useful, but outside the scope of this project, which is simply to estimate the required tx fee needed for a given wait time.

I believe tradeblock does show the data that you are looking for (under "recent mempool").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants