Identifying Slices

[michaelpiron]

From the Project Origin registry documentation, I deduce that Slices don't have an unique identifier within the registry.

For example:
The command to slice up a Slice:
API -> ProjectOrigin.Electricity.Client.ElectricityCommandBuilder -> SliceCertificate command
We address the Slice by specifying:

• Certificate ID --> the unique ID of the parent Granular Certificate above the Slice
• Key --> signing key of the current owner of the Slice

The same structure is used for the commands to transfer Slices, and to claim Slices.

However, underneath a given Granular Certificate, you might have multiple Slices owned by a single owner. How does the command know which Slice to slice up exactly?
Shouldn't Slices have their own unique ID by which they can be addressed?

@wisbech @MartinSchmidt

[wisbech]

Great question @michaelpiron I actually understand the confusion here.

I have started digging around the documentation and have come to the following conclusion:
As @MartinSchmidt stated last week the slicing starts with 1 slice on issuance of the certificate.
This means that there no new certificates being issued, but slices are appended to the array of slices in the certificate - slices that can have different owners using the public/private key infrastructure provided by the future wallet infrastructure.

Slices are defined in the slice command docs and the overall description of slices as follows. This means that we are removing the originating slice of the certificate and issue new slices on the remainding shielded values as in the slicer example.

So that we remove the original slice and issue two new slices, with :

1. the value that should be sliced - that subsequently can be transferred (change of ownership).
2. the remainder slice.

and then issues them both and removing the originating slice.

[MartinSchmidt]

Hi @michaelpiron, a slice does have a unique value the commitment. This is used to identify slices, as they are a result of the amount (Wh) and the random value. Commitments of equal size would still have different commitments. And if you find an easy way to find amounts and random values with the same commitment, then we would have a general issue using Pedersen Commitments, as it is part of the math that it is a hard problem to solve.

We chose to use the commitment instead of introducing another ID, simple to save on space and bandwith, and it would give no benefit as we saw it.

I hope this answers the question, and a possibly great addition to the documentation.

On a side note, even if the slices was owned by the same entity, I would still recommend using different key-pairs as to hide the fact it is the same owner, and using protocols as bip32, it would be trivia.

[MartinSchmidt]

@michaelpiron just saw you asked about the client, in this specific case, it uses the shieldedValue as input, which is both the amount and random value, which can calculate the commitment of the slice, which is then used.

[michaelpiron]

Thank you, very clear!