[bug]: Mailbox Collisions in Hashmail Proof Courier When Closing Tap Asset Lightning Channels

[ffranr]

trafficstars

A bug has been encountered when closing a Tap Asset Lightning Channel using the Hashmail proof courier. The issue arises in the process of delivering the channel close proof to the channel counterparty peer.

Observed Behavior

When closing a Tap Asset Lightning Channel, the same script pub key is used for all receiving peers. As a result, mailbox collisions occur when the Hashmail proof courier service is used to facilitate proof transfers. This happens because mailbox addresses are derived from the receiver's script pub key, and the Hashmail service only allows a single client connection to wait on a receiver's ACK stream for a given mailbox. Consequently, all channel-closing peers must process sequentially, leading to potential connection timeouts if a receiver delays returning an ACK. In practice, this blocks all proof transfers for channel closures using the Hashmail service.

This behavior has been observed when using the Polar testing framework, the frontend-regtest framework, and was also reproduced in a lightning-terminal integration test.

The earliest version of tapd where this has been observed is v0.4.0-alpha. It may occur in earlier versions.

Steps to Reproduce

1. Set up a Tap Asset Lightning Channel.
2. Close the channel while using the Hashmail proof courier.
3. Observe that the same script pub key is used independent of the receiving peer. In other words, every receiving peer will use the same script pub key and therefore the same Hashmail service mailbox (for receiver ACK).

Suggested Fix

Investigate alternative methods for designating mailboxes in the Hashmail proof courier service that ensure each peer has a unique mailbox for proof transfer. This might involve using an identifier other than the script pub key to avoid mailbox conflicts and allow for concurrent processing of channel close proof transfers.

Priority

Low - The Hashmail proof courier is not the default proof courier for Tap Nodes.

[ffranr]

PR which investigated this bug: https://github.com/lightninglabs/taproot-assets/pull/1104

Itest modifications to reproduce the bug in lightning-terminal: https://github.com/lightninglabs/taproot-assets/pull/1104#issuecomment-2315749372

Mailbox SID where collision is observed: 2a59fe87c90d5de0a883e280681e4d72fb2c74ceeee462a3e4ae938fe7e3015ef30806eff1be1daf399cd756c26da002d12b3e562d4b72cd8670071af20b0e8e

[Roasbeef]

A solution here may be to revamp the way we compute stream_id. We can use a new proof courier URI for this. We want something that isn't solely dependent on public data. As is, we have the script_key stored in the address itself, or the given output, this is under control of the receiver(s). We can then combine that with an expose public key from the set of inputs, via ECDH to compute the stream_id needed for the transfer. This looks similar to the way silent payments works.

[dstadulis]

Shedding from v0.5 since universe use will be performant and hashmail support isn't critical path

[guggero]

With https://github.com/lightninglabs/taproot-assets/pull/1412 merged, we can close this. The hashmail proof courier was just a first proof courier version to get us going until we had the universe proof courier. And with #1412 merged, we don't allow hashmail based proof couriers to be used when creating Taproot Asset channels.