<j​effro256:monero.social> I posted a proposal issue on Github which would reduce the amount of data needed to verify PoW by 37%: monero-project/monero #9147

but why?

the 32-byte merkle root hash is not stored anywhere, it's computed as needed

and the block hashing blob is small enough already to fit in a single network packet (even if it's json-encoded)

<j​effro256:monero.social> If you're not up to date with the network, you might need thousands and thousands of block header hashing blobs, which is when it would make a difference

<j​effro256:monero.social> If you're already up to date with the network, then yeah, a 28 byte difference doesn't mean much

what difference, these 32 bytes are not stored or transferred, they're computed from transaction hashes

<j​effro256:monero.social> Or if you're a node trying to settle a deep alternative chain, saving a third on header downloads for the alternative chain would make a difference

<j​effro256:monero.social> Right now they're not stored or transferred, we send the whole block body, which I should've clarified in my post, but these blobs are the smallest amount of information we actually need to transfer to validate PoW.

<j​effro256:monero.social> If there was a way to retreive block header hashing blobs from the nodes, we wouldn't have to send the block to verify PoW and we wouldn't have to fork or anything. Its just that no one has gone to the effort of actually writing that code

block hashing blob is 76-77 bytes, I don't see the point in optimizing it more. Reducing the merkle hash size from 32 bytes down to 4 brings cryptographic questions if it's safe to do. Also, you're trying to optimize code that doesn't even exist yet.

If you really wanted to reduce it, you'd do something like keccak(hashing_blob) and then use the 32-byte output as an input to RandomX

that'd reduce it from 76 to 32 bytes and be relatively safe

first step of RandomX is actually Blake2b hash (512 bit), so it already reduces the size to 64 bytes

But I don't see the way to reduce it a lot - you still need to know that this hashing blob comes from this specific block, so it must at least contain prev_id (+32 bytes)

<j​effro256:monero.social> How does the first Blake2 step help us since we would still have the run RandomX anyways (unlike the intermediate hash where we can sanity check by only running Blake2B)?

<j​effro256:monero.social> I thought about this, but this then has the trade-off of requiring an extra level of indirection before you can know the blockIDs, whereas compressing the merkle tree hashes doesn't

<j​effro256:monero.social> Reducing the merkle hash size down to 4/5 bytes does bring cryptographic questions if it's safe to do so, but only for the very very top block. Every block header after each block cryptographically binds the contents with a safe 256-bit hash

The only where it would be useful is when transferring many hashing blobs?

Then I'd just make it part of the RPC call specifiction thatn prev_id is skipped in all but the very first blob (because prev_id can be calculated from the previous blob)

here, 32 bytes saved right away

and no need to complicate things everywhere

what else can you save, hmm

block height (4 bytes), for example

so 36 bytes per blob saved without much effort

<j​effro256:monero.social> Block height already isn't needed for the header hashing blobs, but you might be onto something but recomputing the previous IDs

I was wrong, block height isn't stored in the hashing blob...

<j​effro256:monero.social> Since that's how block IDs are calculated anyways (except for height 202612

but timestamps are saved, so you could send timestamp delta instead of the actual timestamp, 3-4 bytes saved

<j​effro256:monero.social> We would need a new varint format that can store negative values, but yeah that could definitely save some space

I have one if it helps.

<j​effro256:monero.social> Yeah! Do you have a link?

<j​effro256:monero.social> The major block version must be equal to what it *should* be the hardforks.cpp, so we can exclude that field

Probably better to look at the latest source though, in case it got patched up since, I don't recall.

Look for VARINT_FIELD_SIGNED