100 sats \ 2 replies \ @xz 1 Jan \ parent \ on: On mempool.space, what is the difference between expected block and actual block bitcoin_beginners
Don't think there is such a tool yet.
Not to say that couldn't be built. I'm guessing it would be tricky to work out what is and what is not a transaction which is a financial transaction versus something else.
I know that's already done in a way to highlight which transactions are ordinals or something else, inscriptions etc. It's not something I know much about at all. Just wanted to to reply to your question saying that :-)
One interesting resource I haven't had time to fully digest yet ..
https://blog.lopp.net/economically-unspendable-bitcoin-utxos/
https://jlopp.github.io/unspendable-utxo-calculator/?ref=blog.lopp.net
I imagine what you're asking fore would be some kind of calculation similar to this, married to some kind of graph / visualization?
Cheers for your reply. One way of thinking about the question is I don't really care about defining a financial transaction vs something else. The data will do that by itself. In the example above, someone is "sending" 20,000 sats and spending 14,700 sats to do so - i.e. a fee of about 75% of the amount they are sending, it's clearly not a financial transaction anyway!
So what I am looking for is something like - for each block, every single transaction will have an amount sent and a fee rate paid to send it. From that we could work out a fee perecentage for every single transaction. By looking at the average (or other metrics) of all of those, I think it would start to get interesting. Perhaps it's difficult to pick up those numbers in practice.
I know people sometimes talk about total value sent over the network, so it's clearly aggregated at times from data. Interestingly though, I don't think you could look at total value sent per block and use that in combination with total fees in a block, as if a whale comes along and sends 1,000 BTC in on a transaction in one block and not the next, that would obviously distort the data.
I'll keep looking!
reply
reply