Implement multiverse transfer proof distribution via RPC courier

[ffranr]

A tapd instance should be able to serve as a multiverse transfer proof distribution service. A receiver during the asset send procedure should be able to query the service for the transfer proof associated with the send event.

This work depends on issue #434

[dstadulis]

Need:
Draft PR to add RPC endpoints to see if that would satisfy OKR

[ffranr]

@Roasbeef For the time being, should we ignore authentication constraints for the new proof courier RPC endpoints?

[Roasbeef]

@ffranr why would there be any authentication constraints? Why do new proof courier RPC endpoints even need to exist?

[ffranr]

@Roasbeef

why would there be any authentication constraints?

Because a third party service serving as a courier (proof temporary store/retrieve) for free can be abused.

Why do new proof courier RPC endpoints even need to exist?

To replace our use of hashmail with RPC endpoints that can tie in multiverse construction/verification.

[Roasbeef]

Because a third party service serving as a courier (proof temporary store/retrieve) for free can be abused.

What's the difference between a proof courier as you envision it compared to the universe RPCs after #416? A universe server allows insertion of a valid state transition proof (rn just issuance, but that just needs a conditional removed), does that differ from what a courier needs to do? Does the Universe interface have any built in DoS protection or cost to submit a valid proof instance?

To replace our use of hashmail with RPC endpoints that can tie in multiverse construction/verification.

Does the daemon actually implement end hashmail RPC endpoints itself? How does this relate to #432? In that PR, what should be the default behavior if there's no Universe server specified as a TLV field?

[ffranr]

In answering your questions @Roasbeef, here are some ideas/perspectives I discussed with Oli today:

What's the difference between a proof courier as you envision it compared to the universe RPCs after #416? A universe server allows insertion of a valid state transition proof (rn just issuance, but that just needs a conditional removed), does that differ from what a courier needs to do?

A node might want to keep its courier service and multiverse/universe trees separate. For example, the node might only want to track issuance proofs over the long term. If a courier service updates a universe tree with each transfer proof then sync partners would be prompted to sync. The universe root would be modified and the sync node would need to sync even if they were only interested in new issuances.

Perhaps the courier service should delay adding a transfer proof to its universe encase of a re-org. Or just delay outbound syncing of the new universe. I'm not sure.

The current aperture proof courier can forget proofs. A universe RPC proof courier would have a different memory profile.

Does the Universe interface have any built in DoS protection or cost to submit a valid proof instance?

I think the proof verification serves as DoS protection.

---

Does the daemon actually implement end hashmail RPC endpoints itself?

Yes, I think it should. And then we can have an implementation of Courier which can make use of those RPC endpoints.

How does this relate to #432?

The proof courier address field added in that PR should be used by the sender communicate with a preferred courier service. The proof courier address needs to include the courier protocol, something like:

universerpc://the.host.name:port
hashmail://mailbox.server:port

I don't think #432 is directly related to universes. I could make a start on it and just support hashmail.

In that PR, what should be the default behaviour if there's no Universe server specified as a TLV field?

I think the new TLV field should be mandatory. But if it's populated with null then we could fallback to the default hashmail service that we're currently using (we will need to add a mainnet equivalent).

[Roasbeef]

A node might want to keep its courier service and multiverse/universe trees separate.

I think that depends on the landscape, still to be explored. In the short term, I'd imagine people just use existing Universe explorers to obtain proof information. As that doesn't require them to actually run their own instance, let alone a publicly reachable one. Consider a mobile user, they'd likely just use w/e popular explorer pops up to receive transfer proofs, as from the explorers PoV, it's just serving a proof like any other relevant event.

I think the idea of having your own "private" proof submission be distinct from your own tracked universe tree is interesting, but I think that's more of a power user thing, as you'd need to be running a persistent server reachable over a public interface.

The universe root would be modified and the sync node would need to sync even if they were only interested in new issuances.

IMO that would depend on the configured sync time. For simplicity imagine mempool.space launches a public Universe server. You wouldn't necessarily try to do a full sync, instead you'd poll the relevant endpoint (/assetID/scriptKey), etc until the information you needed showed up. I don't think we'd modify the sync flow, instead it would be a new courier instance that basically does the same thing, but today it tries to read something from the hashmail server.

The current aperture proof courier can forget proofs. A universe RPC proof courier would have a different memory profile.
Yes, I think it should. And then we can have an implementation of Courier which can make use of those RPC endpoints.

So in my mind, there's literally no difference between a proof courier and a Universe server. One can make a proof courier implementation using a Universe server. The RPCs were even set up to support such a concrete implementation, in addition to the actual commitment structure. If I know that I have an incoming transfer of asset A, via outpoint O, and my script key is S (bound in the addr), then I know to look up /v1/taproot-assets/universe/proofs/asset-id/A/O/S. I may not even need to go to the same server each time, if one assumes the sync protocol eventually syncs all new state on a ~10 minute interval.

The proof courier address field added in that PR should be used by the sender communicate with a preferred courier service. The proof courier address needs to include the courier protocol, something like

See above comment.

I don't think #432 is directly related to universes. I could make a start on it and just support hashmail.

I think it is, see above comment.

Zooming out I think our divergence in mental models is viewing a courier as a concrete system, when it's just an abstraction over obtaining proofs. We used hashmasil at first since we hadn't finished the Universe server DB or RPC stuff. Now that that's in place, any public Universe server can serve the exact same role. In the future people can also use nostr or w/e other distribution mechanism. A difference between Universe servers and nostr is that they actually sync information between each other, which makes it easier to obtain information.

I think the new TLV field should be mandatory. But if it's populated with null then we could fallback to the default hashmail service that we're currently using (we will need to add a mainnet equivalent).

Allowing something to be null, while also saying it's mandatory is at odds with each other. Perhaps you mean optional, falling back to some other default if not populated?

[ffranr]

Addressed here: #473