search

txstreet / processor

For processing txs and blocks, and subbing to node events.
7 stars 15 forks source link

Wrong blocksizes and fees calculations for Monero #2

Open Roman2K opened 6 months ago

Roman2K commented 6 months ago

[Cross-posting from this txstreet/txstreet issue by @HardenedSteel]

Buses are always loaded with maximum size even the transaction fees are not enough.

Roman2K commented 6 months ago

Thanks @HardenedSteel for the report. Indeed prediction calculations for Monero seem wrong on various levels. I just watched 2 consecutive blocks (3100761 and 3100762) being filled and confirmed, with wrong sizes, number of transactions and fees distribution.

Both showed ~670 KB and ~70 transactions, with varying fees around the 20-320 Nanomonero range). Both ended up confirmed with ~330 KB and ~210 transactions, with fees ranging 31-22817 Micromonero (note: micro not nano).

That said, buses being all fully loaded, does seem correct despite their contents being wrong. Though there should be a third as many lined up.

Suggestions, ideas or PRs are welcome :pray:

Other reports of flawed calculation:

HardenedSteel commented 6 months ago

This Python code can help: https://github.com/spackle-xmr/Dynamic_Block_Demo

Roman2K commented 6 months ago

Nice, thanks!

Another cool project with charts: https://xmr-tw.org/xmr-eta/ (from a Reddit comment) It's open-source: GitHub

HardenedSteel commented 6 months ago

Thanks I looked up but they also have same issue with Txstreet, opened an issue at their repo.

If the issue isn't clear enough; Txstreet needs to calculate block size using dynamic block size algorithm. At this moment it simply just assumes block size is median block size * 2

spackle-xmr commented 6 months ago

This sort of visualization is a bit more art than science. I am no great artist, but I have a few ideas on what could be done...

Assuming:

  1. Buses must be shown as full during congestion.
  2. Block size growth is shown.
  3. The absolute limit of block growth is shown.
  4. Transactions should be ordered by fee per byte, then by age to show the correct expected order on the buses.

I might propose:

  1. Buses be shown as the size of the penalty median so they are always full during congestion.
  2. The block confirmation/"green light" animation is altered so that 'extra' transactions included the block (past the penalty median) board the bus (perhaps with a green plus over their head or the bus?) when the block is confirmed.
  3. I do not have a good idea for how this should be done that wouldn't also be a massive pain.
  4. This should be done.

I can offer my input on calculations if you want the buses to change size dynamically as transactions come in (or something similar). That would be a fairly perfect representation of what is happening. I have not looked at the code and I do not know how difficult such a change would be.

HardenedSteel commented 6 months ago

Changing the percentages would be helpful; the median block size should be 100% (instead of 50%) and the maximum allowed block size should be 200% (instead of 100%).

As a result, users can understand that blocks are getting larger when they see buses loaded above 100%.