mimblewimble team mailing list archive

[John Tromp <john.tromp@xxxxxxxxx>]

dear Igno,

>> The second largest piece of data is composed of the transaction kernels
>> (~100 bytes each). We can't fully avoid sending those as they're not
>> "anchored" on anything, like the range proof is anchored on an output.
>> However we could send a shortened version of their hash. In this scheme,
>> when sent across the wire, a block would only contain the first 16 bytes (or
>> maybe even 12) of the hash of the whole kernel. Upon reception, an exchange
>> similar to the one for range proofs would occur. Note that this requires the
>> pool maintains a mapping of those truncated hashes with the actual kernels.
>
> I feel less enthusiastic about this. The reduction is block size is
> rather modest,
> and somewhat negated by the need for extra querying traffic, which will be
> exacerbated by clients submitting transactions directly to mining pool(s) for
> improved aggregation, rather than through the peer-to-peer network.

If you do pursue this path, then the hash-prefix serves merely as a kernel hint.
That is, the receiver will look up how many kernel she has matching the hint.
If 0 or more than 1, it will query peers for a list of all known
matching kernels.
If exactly 1, then it will use that, but if validation fails, it will
again have to go back
to querying peers for ALL the hints this time, so that it may learn of other
matching kernels that would validate. In this approach, even 12 bytes
is overkill,
and somewhere between  and 8 bytes suffices.

Btw, how should we encode inputs? There's two ways to get away with 8 bytes:

1) a 32 bit block number and 32 bit index in sorted outputs of that block
2) a single 64 bit index in list all of outputs, sorted first by block.

regards,
-John