To address the issue of someone changing the attachment of a note in an unintended way, we can introduce a concept of note sealing. That is, the user could call something like output_note::seal to seal a given output note, and after this point the note would become immutable.
Originally posted by @bobbinth in #2109
This issue is to discuss whether we want to introduce note sealing or not.
I don't want to get bogged down with the implementation details, especially if we decide sealing is not needed, but I think it would roughly work as follows:
- Developers can call
output_note::seal at any time after the note has been created.
- This will set some flag on this note that it's been sealed. Probably there will be a memory section allocated to this flag, somewhere following the
OUTPUT_NOTE_SECTION_OFFSET. Let's name it OUTPUT_NOTE_IS_SEALED.
- When any procedure call tries to modify an output note, the value at
OUTPUT_NOTE_IS_SEALED is checked (get_sealed_flag assertz)
My initial thinking is that while the implementation wouldn't be all that complicated, it's an unnecessary addition:
- Sealing is optional and most developers will never need it.
- Since the note creation script is fully local to the caller, there is no risk of an outside party interfering with the sealing process.
So unless we can come up with a concrete malicious scenario posing a security risk, which can only be mitigated by sealing, I'd strongly prefer not to introduce it.
Let's discuss
Originally posted by @bobbinth in #2109
This issue is to discuss whether we want to introduce note sealing or not.
I don't want to get bogged down with the implementation details, especially if we decide sealing is not needed, but I think it would roughly work as follows:
output_note::sealat any time after the note has been created.OUTPUT_NOTE_SECTION_OFFSET. Let's name itOUTPUT_NOTE_IS_SEALED.OUTPUT_NOTE_IS_SEALEDis checked (get_sealed_flag assertz)My initial thinking is that while the implementation wouldn't be all that complicated, it's an unnecessary addition:
So unless we can come up with a concrete malicious scenario posing a security risk, which can only be mitigated by sealing, I'd strongly prefer not to introduce it.
Let's discuss