In mint-mint.tapscript, witness1 and witness2 can be negative. This is the data that the oracle is signing, so we can say that oracle just will not sign invalid data. But if for some reason the oracle makes a mistake and signs and releases the data with invalid burn timestamp and invalid price, then the next covenants in chain will become unspendable. Maybe we should add a check in the mint-mint covenant to at least guarantee that negative values or too big values are not set for wit1 and wit2 ?
Of course the oracle is responsible for validating the data it signs, and those who send money to mint-mint covenant should check these values also. The question is - is it worth a few more sats in the fee for these additional 'belts and suspenders' checks ? (because this is additional opcodes in the covenant that would slightly increase the witness size)
This issue created for future reference, to make sure that this fact is noted and considered.
In mint-mint.tapscript, witness1 and witness2 can be negative. This is the data that the oracle is signing, so we can say that oracle just will not sign invalid data. But if for some reason the oracle makes a mistake and signs and releases the data with invalid burn timestamp and invalid price, then the next covenants in chain will become unspendable. Maybe we should add a check in the mint-mint covenant to at least guarantee that negative values or too big values are not set for wit1 and wit2 ?
Of course the oracle is responsible for validating the data it signs, and those who send money to mint-mint covenant should check these values also. The question is - is it worth a few more sats in the fee for these additional 'belts and suspenders' checks ? (because this is additional opcodes in the covenant that would slightly increase the witness size)
This issue created for future reference, to make sure that this fact is noted and considered.