-
Notifications
You must be signed in to change notification settings - Fork 121
Description
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::sealto 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::sealat 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 itOUTPUT_NOTE_IS_SEALED. - When any procedure call tries to modify an output note, the value at
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:
- 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