[bug]: Add option to skip courier proof transfer in FundChannel RPC

[ZZiigguurraatt]

In #1476 it is requested to allow making on chain payments without requiring a proof courier service to be used. I would also like to see this option for FundChannel as it previously was available by default.

I've just tried to use https://github.com/lightninglabs/tapdvalidation with a recent version of litd/tapd/lnd (lightninglabs/lightning-terminal#987) and I now get the following error:

controller-1  | alice funding a 23f2924c049e18eb39e92092338524986f32e345ba5556b83097955b8e9bca79 channel with bob
controller-1  | alice connecting to bob
controller-1  | syncing the universe of alice to bob (172.99.0.4:8443)
controller-1  | done syncing universe
controller-1  | unknown
controller-1  | ERROR MESSAGE: error funding channel: unable to fund channel, local proof courier is invalid: unsupported proof courier type 'hashmail', please set a universe based (universerpc://) proof courier in the proofcourieraddr configuration option or command line flag
controller-1  | Traceback (most recent call last):
controller-1  |   File "/mini_META/scripts/init_network", line 139, in <module>
controller-1  |     OpenTaprootAssetChannel(funder='alice',   peer='bob',    AssetID=TheAssetID, AssetCapacity=200000000)
controller-1  |   File "/mini_META/scripts/mini_META_lib.py", line 551, in OpenTaprootAssetChannel
controller-1  |     litd_node_objects[funder]['tapd'].fund_taprootasset_channel(asset_amount=AssetCapacity, asset_id=AssetID, peer_pubkey=bytes.fromhex(litd_node_objects[peer]['lnd'].get_info().identity_pubkey), fee_rate_sat_per_vbyte=10,push_sat=int(5*10**4))
controller-1  |   File "/usr/local/lib/python3.10/dist-packages/lndgrpc/errors.py", line 50, in wrapper
controller-1  |     raise exc
controller-1  |   File "/usr/local/lib/python3.10/dist-packages/lndgrpc/errors.py", line 26, in wrapper
controller-1  |     return fnc(*args, **kwargs)
controller-1  |   File "/usr/local/lib/python3.10/dist-packages/lndgrpc/tapchannel.py", line 37, in fund_taprootasset_channel
controller-1  |     response = self.get_tapchannel_stub().FundChannel(request)
controller-1  |   File "/usr/local/lib/python3.10/dist-packages/grpc/_channel.py", line 1181, in __call__
controller-1  |     return _end_unary_response_blocking(state, call, False, None)
controller-1  |   File "/usr/local/lib/python3.10/dist-packages/grpc/_channel.py", line 1006, in _end_unary_response_blocking
controller-1  |     raise _InactiveRpcError(state)  # pytype: disable=not-instantiable
controller-1  | grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
controller-1  | 	status = StatusCode.UNKNOWN
controller-1  | 	details = "error funding channel: unable to fund channel, local proof courier is invalid: unsupported proof courier type 'hashmail', please set a universe based (universerpc://) proof courier in the proofcourieraddr configuration option or command line flag"
controller-1  | 	debug_error_string = "UNKNOWN:Error received from peer ipv4:172.99.0.4:8443 {grpc_message:"error funding channel: unable to fund channel, local proof courier is invalid: unsupported proof courier type \'hashmail\', please set a universe based (universerpc://) proof courier in the proofcourieraddr configuration option or command line flag", grpc_status:2, created_time:"2025-04-24T02:48:34.461005356-04:00"}"
controller-1  | >

tapdvalidation manually syncs the universe before trying to fund the channel. I'm not sure why we need a proof courier if we've done that manually before trying to fund the channel? This was not a problem in earlier versions.

I'm running on regtest and I don't have proofcourieraddr defined. I'm not sure if the default value of universerpc://testnet.universe.lightning.finance:10029 is used for regtest?

I've tried to figure out what itest is doing. I find a few cases where a proof courier is defined when making on chain payments.

https://github.com/lightninglabs/lightning-terminal/blob/72477225a8892b419e8903bf746a443920598cf7/itest/assets_test.go#L89-L98

Can that get inherited/remembered for channel funding?

There are also a few spots in itest where the courier is explicitly defined like this

https://github.com/lightninglabs/lightning-terminal/blob/72477225a8892b419e8903bf746a443920598cf7/itest/litd_custom_channels_test.go#L112-L124

As a workaround in tapdvalidation, I've added --taproot-assets.proofcourieraddr=universerpc://alice:8443 and I no longer get the error above.

Also, the error message says unsupported proof courier type 'hashmail', but I've not set a hashmail server and I can't find any documentation on setting up a hashmail server address. I think this error message should be less confusing.

[ZZiigguurraatt]

I think this may be where this was introduced: e98688b .

[guggero]

As a workaround in tapdvalidation, I've added --taproot-assets.proofcourieraddr=universerpc://alice:8443 and I no longer get the error above.

This is actually what users are expected to do: Either use a default universe (pre-configured for testnet and prod) or run their own (currently needed for regtest, signet, testnet4, but we plan to create public/default universes for the default signet and testnet4).

Without a universe capable proof courier channels won't work correctly. So I don't think we should introduce a flag to skip.

[ZZiigguurraatt]

So, are you going to make that same argument against #1476 or not since with an on chain we don't have a second connected (closing) transaction that we need to worry about?

NewAddr has an option proof_courier_addr. Wondering, could we add proof_courier_addr to FundChannel to allow specifying a direct proof courier? I'm wondering why alice can't send the proof directly to bob if he has a universe server running on his node and he's let alice know about it? Seems weird to need to rely on a third party courier if you don't have to.

[guggero]

So, are you going to make that same argument against #1476 or not since with an on chain we don't have a second connected (closing) transaction that we need to worry about?

No, because you might want to manually (or through a mechanism in your application that uses tapd) transfer proofs. But for channels, since the closure negotiation in the lnd state machine can only complete when the proof transfer was successful, we don't really want to allow any manual interaction.

Wondering, could we add proof_courier_addr to FundChannel to allow specifying a direct proof courier?

Yes, that could be an option. And it would actually make sense as you describe it. But it would mean Bob would need to have a publicly reachable server exposed to the internet. Also, it's possible that Bob will close the channel and then it would upload the proof to its own universe (which works and is okay and Alice would then have to fetch it from there).

[ZZiigguurraatt]

Yes, that could be an option. And it would actually make sense as you describe it. But it would mean Bob would need to have a publicly reachable server exposed to the internet. Also, it's possible that Bob will close the channel and then it would upload the proof to its own universe (which works and is okay and Alice would then have to fetch it from there).

Say we do add this option, OR the user has the existing option taproot-assets.proofcourieraddr properly defined, are we still at risk that the proofs won't successfully transfer after the transaction has been signed and broadcast?

Or, is it not an issue because channels are currently always singly funded by the person that creates the proofs so it does not matter until the first off chain transaction happens?

[ZZiigguurraatt]

Yes, that could be an option. And it would actually make sense as you describe it. But it would mean Bob would need to have a publicly reachable server exposed to the internet. Also, it's possible that Bob will close the channel and then it would upload the proof to its own universe (which works and is okay and Alice would then have to fetch it from there).

OK, maybe let's close this issue in favor of #1489 but I'd like to know still about my last question.

[guggero]

Or, is it not an issue because channels are currently always singly funded by the person that creates the proofs so it does not matter until the first off chain transaction happens?

The party that closes the channel will create the proofs and transfer them to the other party with the courier. And until that happens, the channel will appear in "waiting close".

[levmi]

Seems this issue can be closed given the above conversation.

[ZZiigguurraatt]

Seems this issue can be closed given the above conversation.

I'm still confused, even if a proof courier is defined, if the other party force closes and fails to actually use the proof courier to transfers proofs, do we effectively loose the assets?

Based on other discussions, it sounds like theoretically both parties should be able to re-calculate the proofs on channel close without the proof courier being required, but we don't have that built in right now. So, requiring a proof courier is part of the workaround?

Right now, before signing the final co-operative close transaction, as the second part of the workaround, do we require the proofs to be received from the courier first, that way we can force the peer to provide the proofs and not just hope they will provide them after signing?

So, I don't think we are going to fix this issue because the rest of the workflows depend on the proof courier, but theoretically this should be fixable and may be better listed as a dependent of a new issue that addresses the ability to re-create the proofs by either party so that we can't be left in a situation where they fail to provide the proof and we effectively loose the assets?