so they say

<hyc> a block depends on the hash of its preceding block, and the hashes of the txns it contains.

^ that goes recursively for all preceding blocks, hence O(n).

this is why such blockchain structures are not scalable enough to function as 'money'. imagine getting 7000 transactions per second? one would have to download gigabytes of data per day in order to verify transactions.

and, for new installers who wish to verify since genesis, they'd have to download at least terabytes of data per month since genesis. much worse in practice as these giga/tera-bytes are counted based on a very minimalist transaction format.

Just to chime in on the earlier discussion as the resident Rust screecher, I'm interested in seeing how it works out. My objections to the above is it almost competes with Monero, when I believe cooperation should be pursued. While I understand the described work would run now, albeit parasitically/insecurely until some eventual impl of Levin, I'd personally prefer Levin be prioritized. Then other protocols can come around and we can

discuss Monero, not a specific Monero node, moving forward.

... but it's also not my project and I'm still excited to see what it turns up regardless :D Who am I to say cool work being put forth isn't good enough. Cool work is cool work

I have the modern Monero TX types usable under monero-serai. monero-rs should have them all, yet with minimal operations on them.

So you shouldn't *have* to redo either, Artem Vorotnikov ;)

If you did want to impl historic TX validation, I can PR beg since I want that functionality anyways, or you can fork or go your own route. I was a *bit* opinionated...

Now, I just want to say this right now. That regardless of what they say about it, there is nothign new, only different. Never forget this. The future is to those who take it. Well I say that nothing is easy, and the best things are the hardest. That isn't enough. It is madness.

> <@kayabanerve:matrix.org> Just to chime in on the earlier discussion as the resident Rust screecher, I'm interested in seeing how it works out. My objections to the above is it almost competes with Monero, when I believe cooperation should be pursued. While I understand the described work would run now... (full message at <libera.ems.host/_matrix/media/v3/do…bc9485c08953fec0653302f60ba21888e8c>)

I rewrote devp2p, I know what it looks like - a cave where you dig yourself in with no way out, so it's best to save for the last

Some of you may want everything at once, yesterday and immediately perfect but that's not how it works in real life

monerod's `get_fee_estimate` returns an undocumented field, `fees`, e.g.: `{"credits":0,"fee":1200000,"fees":[1200000,4700000,19000000,240000000],"quantization_mask":10000,"status":"OK","top_hash":"","untrusted":false}`. do those represent the base fees at different priorities (slow, normal, fast, and fastest)?

makes sense

Yes.

will add to -site thanks

the lowest base fee from `get_fee_estimate` is consistently 36% higher than wallet txs created with default priority. any idea what could cause that?

i.e. `fees[0]` * tx hex length is more than 36% higher than normal wallet txs

this is on a local testnet if that helps

Fees are based off tx weight. While this is usually the same as tx size, it needs not be.

weight is higher than size, so it wouldn't make sense for a size-based fee to be higher I think

But tx hex length is twice the tx size :P

(phew)

The four levels of fees are described here apparently: github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2021-02.pdf

oh

The difference only shows up for > 2 outputs though, which is usually not the case in testing.

Or maybe get_fee_estimate is just buggy.

ah yes that works, thanks