Confirm used sender tags

[nventuro]

#9762 expands on the current mechanism for sender tags by searching for used tags (and therefore indices) in the node prior to injecting the current tag in the circuit. However, this mechanism is accompanied by PXE also tracking that the just-injected tag has been used and its index therefore taken, so that future notes do not use the same tag (even in the same transaction!¹). This is problematic in the case of non-included transactions.

If a transaction is never included or reverted, then the index and therefore tag have not been used, and these values should not be skipped when producing future tags. Otherwise, if the log ended up never being included the recipient would never see said tag, and would not look any further. This will cause a desync between sender and recipient that we currently lack the tools to resolve (though the sender using #9369 would eventually fix the situation).

Solving this might be a bit tricky since we can't just not increment the index until the transaction is mined, since the user may wish to send further transactions before they get a confirmation, and non-strict transaction ordering means that the second transaction may go through even if the first one is never included (or of it reverts). A potential solution would be to have the recipient be a bit more lax and not just search for the very first unseen tag, but instead look a bit further (say the next 10 tags) in an attempt to detect skipped indices.

Footnotes

1. Notes in future transactions would use the correct tag thanks to the syncing process, but notes in the current transaction would use the same index if we didn't increment it. This is bad because tags are public, and we'd be therefore be leaking that two notes in a given transaction correspond to the same (sender, recipient, app) tuple. ↩

[nventuro]

See https://forum.aztec.network/t/on-note-discovery-and-index-coordination/7165 for more considerations on this topic.