Closed dr-orlovsky closed 5 years ago
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" notifications@github.com 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: https://github.com/rgb-org/spec/issues/89
@petertodd Well, these are different cases. In Bitcoin,
With RGB,
@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.
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).
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.
@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"?
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.
Subj.
@giacomozucco do I get it right? If yes, it we need to add this to the spec + proof verification code