Automate the submission of note scripts for public ntx notes

[mmagician]

From the user's standpoint the process should be relatively simple:

• To add a note script to this "registry" they'd need to execute one transaction that created a public note with the script they care about (this needs to be done once per script and could be done by the app developer).

Continuing the excellent thread by @partylikeits1983 on Slack:
I think this could lead to a particularly obscure DevEx if not abstracted well. Specifically, if Note A directed at a ntx account were to create a previously-unseen note, the transaction that creates Note A would succeed from the users' point of view. However, it would later fail at the ntx transaction builder, with the details (logs) only available to us on the node, making it near impossible to debug for the users/developers.

A good abstraction on the client that handles the scenario of ntx transactions creating public notes would look like:

1. Client detects that a note created by the user is for a ntx account (presumably by the NoteTag prefix?)
2. Client dry-runs this transaction, and sees that it would create a public output note.*
3. Client queries the node to see if this note's script is available in the registry.

If it is available, proceed as normal.
If it is not available, the client effectively needs to do something equivalent to a POST /add_note_script_to_registry request to the node. However, due to spam concerns, this needs gatekeeping and is likely best achieved at the protocol level. Namely, as mentioned above, the client would have to "execute one transaction that created a public note with the script they care about".
One optimization here: I don't think this needs to be a separate transaction: we can extend the transaction script to output the desired note (TransactionRequestBuilder::own_output_notes) and just create one transaction.

I'm not a huge fan of creating an output note just for the purpose of registering its script. For one, it's an anti-pattern for using notes in Miden. Then there might be unforeseen security implications we might need to think about: can such an "empty" note be exploited?
While there are mechanisms that let users add note scripts to the node's registry (e.g. API-key - based), atm I can't convince myself of a better solution than what was originally suggested^, but I wanted to at least mention that there might be alternatives in case others have better ideas for populating the note script registry outside the protocol.

---

*How the client dry-runs a transaction where the network account consumes the note is not implemented AFAIK. It's still unclear to me how this would be done, but likely along the lines of running the ntx transaction builder locally.

Originally posted by @mmagician in #1748

[bobbinth]

Copying my reply here as well :)

I think there are 3 separate issues here:

1. How can a client detect which not scripts would be needed for successful execution of future network transactions.
2. How can we ensure that clients don't submit transactions which could create notes that can't be consumed in future network transactions.
3. How should the client add note scripts to the "script registry".

I think the first point is the concern of the client and there could be multiple strategies there. In some cases, the required note scripts could be known statically, in other cases we may need to determine them dynamically. We may also be able to use TransactionRequest struct to communicate this info. For example, we could either check the existing "expected future notes" field or maybe add "expected future scripts" field so that the creator of the transaction request could specify which note scripts need to be on-chain to successfully execute this and future transactions.

The second point should probably be handled by the client as well. Another option is to delegate this to the node by including something like "required public scripts" field in ProvenTransaction - but I think handling this on the client is cleaner.

The third point is the protocol concern. Here, I still think that it is better to use the existing note architecture to keep track of the public note script registry (rather than creating a separate structure for this). We could consider creating a special note to make this more explicit - e.g., something like "script registration" note. This would have some benefits (e.g., the node would know that only these types of notes should be considered when adding scripts to the public registry) - but it also require more thinking to make sure we handle all the edge cases correctly. So, it is not clear if such special note types are worth it.