Hey all,
@Saint Wenhao
>if you take the sum of hashes, which should be finally zero, then by grinding UTXOs, someone could make it zero
That's what the secret salt prevents. You can't grind for a certain number if you don't know what the number is you are trying to collide with.
>maybe you can avoid hashing at all [...] And then, it is all about mixing the salt
Without a concrete solution I'm afraid that's wishful thinking. That last part of the sentence is why we currently need the hash, as well as for adding more data in the non-assumevalid version.
>What if instead of hash we encrypt with AES
I can't really evaluate whether this might work, but I can see the line of reasoning. Conceptually, I think what we need is something that transforms the data into fixed length blocks for which an attacker can't know the relationship between each block (i.e. via a secret). The transformation needs to be the same on the input and output side.
>Your reduction function could just be xor
I had initially ruled XOR out. Reason for this is that XOR would lead one to conclude that sets [A, B, C, C], [A, B], [A, B, D, D], etc. are all equivalent because any two values cancel each other out, regardless of whether the sets are on the input or output side. Modular add/sub doesn't have this issue. If the speedup actually turns out to be significant then there may be some clever way to salvage it like by counting the total number of inputs and outputs and relying on the knowledge that every txid must be unique, but that's a lot harder to reason about.
>even if its with a quite expensive hash function that the IBD performance will be heavily bottlenecked in network and parallelism related issues and be far from the lowest hanging fruit for a while, considering that this has eliminated the big sequential part and a number of annoying to optimize components entirely
Very true, and as you said, we can easily drop-in replace the hash function at any future point we like, without adverse consequences.
Cheers,
Ruben