The proof MUST be considered invalid if the asset amount in its outputs != inputs

[dr-orlovsky]

Subj.

@giacomozucco do I get it right? If yes, it we need to add this to the spec + proof verification code

[petertodd]

Why? The equivalent in Bitcoin is blocks are allowed to claim less than the total amount of fees, and that's useful for soft-forks.

…

On July 10, 2019 3:40:30 PM PDT, "Dr. Maxim Orlovsky" ***@***.***> wrote: Subj. @giacomozucco do I get it right? If yes, it we need to add this to the spec + proof verification code -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #89

[dr-orlovsky]

@petertodd Well, these are different cases. In Bitcoin,

1. The fees (difference input-output) go to the miners
2. We can always compute total supply

With RGB,

1. We have no party to allocate the difference between the input and output — so we have no other options than to "burn" it
2. The total supply of the asset is specified only in the contract, so if some of the assets will be burned in non-public proofs, nobody will know about the circulating supply. In case of things like publicaly traded corporate shares, it is an issue.

[petertodd]

@dr-orlovsky That all sounds like fair arguments to me.

Maybe worth writing up an explicit "how would we upgrade this?" section in the docs.

[inaltoasinistra]

nobody will know about the circulating supply

In any case the circulating supply is unknown, because private keys and proofs could be lost.

In order to reduce a bit the size of proofs, the unspent assets could be deterministically binded to an output (e.g. the last).

[dr-orlovsky]

Maybe worth writing up an explicit "how would we upgrade this?" section in the docs.

Yes, we already had that idea and certainly need to do it. But there are already a number of opened issues requiring changing some (not clear/incomplete/contradicting) parts of the spec, so we are working on the spec update, which will be complete during this month – and will add this part into it as well.

[dr-orlovsky]

@inaltoasinistra

In any case the circulating supply is unknown, because private keys and proofs could be lost.

Yes, it seems so... But still No 1 applies

In order to reduce a bit the size of proofs, the unspent assets could be deterministically binded to an output (e.g. the last).

It will create more complications and would not help in reducing the size of the proof... Or you mean that the last triplet in the proof need not to list an asset amount and allocate of of the "change"?

[inaltoasinistra]

Or you mean that the last triplet in the proof need not to list an asset amount and allocate of of the "change"?

Yes, I mean that a triplet for each asset type of the proof can be omitted. This should save 40 bytes (plus encoding overhead) for each asset type.

Wallets must validate all the input proofs, them must compute inputs and outputs assets to check validity. With this change the algorithm would compute the last output assets instead of check them. It would be almost the same operations.

On the other hand the upgrade strategy of the protocol could impact on this, as said by Peter Todd.