[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.
   • COMPLETE: Add preliminary proof courier connection check to ChainPorter #1470

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.