mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

Now that we're going down that path, I'm starting to wonder whether we should treat inputs, outputs and kernels all in that same way. It's definitely simpler.

Here's the proposal:

- Across the wire, blocks have the regular list of inputs, outputs and kernels. At the minimum, they must have one output and one kernel (coinbase).

- Blocks can also include the first n bytes of input/output/kernel hashes that are part of the block but not fully included.

- A node receiving a block with partial hashes checks them against its the transaction pool.

- Known input/output/kernels are added, missing ones (or collisions) are asked to the block sending node all in one batch.

- Once everything is known, the full block can be validated.


This still leaves the possibility to have full blocks, including all the data. In the general case the blocks should be very compact and requests for more data will only be commonplace for nodes newly started. It also gives an incentive to miners to have a fairly full transaction pool (to avoid further requests).

As far as how many bytes of the hash, as John mentioned, 8 bytes (a u64) seem to suffice. I believe the chances of collisions with a pool of 100,000 elements would still be less than 0.00000003%. 4 bytes would likely be too small, a transaction pool of the same size would have 69% of collisions.

- Igno




-------- Original Message --------l
Subject: Re: [Mimblewimble] Compact blocks
Local Time: March 3, 2017 2:47 PM
UTC Time: March 3, 2017 10:47 PM
From: john.tromp@xxxxxxxxx
To: Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>, mimblewimble@xxxxxxxxxxxxxxxxxxx

dear Igno,

> 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.

Uhm, that should be: ask the sending peer to expand the hint to a full kernel.

regards,
-John