With multiple attachments per note (#2555), the possibility of multiple NetworkAccountTarget attachments per note exists and we can't prevent this at the protocol level. The same will be true for other attachments where only one should be added.
Options are:
- Pick the first one as the canonical one
- Consider network notes with multiple such attachments invalid
- Add support in the kernel for specifying that schemes in range 0..2^15 can only be added once and schemes in range 2^15..2^16 can be added multiple times. The tx kernel would check and enforce this.
For simplicity and time reasons, for now the first option is implemented.
There don't seem to be any real negative effects of having multiple network account target attachments in a note, other than incurring more fees for the creator (which is itself a disincentive to not do that).
More generally, since attachments validate nothing about their content, adding multiple attachments of the same scheme is the same category of error as creating a network account target attachment with an invalid target account ID.
This issue mainly exists to document the overall strategy and we can re-evaluate in the future (e.g. adding "attachment constructors").
With multiple attachments per note (#2555), the possibility of multiple
NetworkAccountTargetattachments per note exists and we can't prevent this at the protocol level. The same will be true for other attachments where only one should be added.Options are:
For simplicity and time reasons, for now the first option is implemented.
There don't seem to be any real negative effects of having multiple network account target attachments in a note, other than incurring more fees for the creator (which is itself a disincentive to not do that).
More generally, since attachments validate nothing about their content, adding multiple attachments of the same scheme is the same category of error as creating a network account target attachment with an invalid target account ID.
This issue mainly exists to document the overall strategy and we can re-evaluate in the future (e.g. adding "attachment constructors").