[feature]: Handle Invalid Proof Courier Address During Ongoing Asset Transfer

[ffranr]

The proof courier service encoded in a tap address may become permanently offline or its address may be misspent. In such cases, if a user has already initiated an asset transfer to that tap address, the anchoring transaction might confirm on-chain, but the associated proofs cannot be delivered to the intended peer due to the invalid courier address.

Problem:

• The proof courier address in the tap address could be invalid or unreachable after an asset transfer has begun.
• The anchoring transaction may confirm on-chain, but the proofs required for the transfer cannot be delivered, potentially causing issues in completing the transfer.

Proposed Solutions:
To handle this scenario, we need to implement a mechanism that allows the user to specify an alternative strategy for delivering the proofs. Here are some potential options:

1. Override Proof Courier Address:

   • Allow the user to override the proof courier address after the transfer has started.
   • This would require adding a new RPC endpoint that the user can call to specify a new, valid courier address.

2. Force Delivery to Public Universe Server:

   • Provide an option for the user to force the tapd to deliver the proof to a public universe server instead.
   • Optionally, the user might be able to configure tapd to do this automatically if the proof courier address is detected as invalid.

3. Pre-Transfer Proof Courier Ping:

   • Before the asset transfer process begins, implement a check that pings the proof courier service.
   • If the service does not respond, the transfer process should not proceed, preventing potential issues with undeliverable proofs later on.

Implementing these strategies will ensure that the proofs can still be delivered and the asset transfer completed, even if the initial proof courier service is no longer available.