You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Motivation: The C= swap-in-potentiam work-in-progress spec defines a 0-conf channel open flow, where the channel open is funded by one or more swap-in-potentiam UTXOs from the client as Alice with the LSP as Bob. The advantage of implementing the 0-conf funding flow first BEFORE implementing swaps from the swap-in-potentiam is that if the client has no channels at all yet but DOES have onchain funds in a swap-in-potentiam address, the client can immediately 0-conf-fund a channel and immediately get outbound liquidity on Lightning.
For the swap-in-potentiam 0-conf channel specifically, normally a 0-conf channel open means that the acceptor fully trusts the initiator. However, if the 0-conf channel funding is from swap-in-potentiam UTXOs only, and all swap-in-potentiam addresses have the acceptor as the Bob role and co-signer, and none of the swap-in-potentiam UTXOs are too deeply or too shallowly confirmed, then the acceptor need not trust the opener, provided the acceptor actually validates that the scriptPubKey of the funding transaction (which they sign for, as the swap-in-potentiam Bob role) matches the correct one for the channel open and therefore for the commitment transactions they make.
The scriptPubKey can be computed as soon as the two peers have exchanged open_channel and accept_channel. In LDK, the OpenChannelRquest event represents receiving the open_channel message, and the accept_inbound_channel causes accept_channel to be sent out. At accept_inbound_channel, it should be possible to know what the funding_pubkey that accept_channel will contain, and from there derive the scriptPubKey, which can then be returned to the caller.
I think it is fine to have a separate accept_inbound_channel variant, e.g. accept_inbound_channel_and_return_funding_script. However, perhaps it is simply better to have accept_inbound_channel return a Result<InboundChannelAccepted, APIError> where InboundChannelAccepted is a struct with pub fields (which can be extended later) that include the funding scriptPubKey.
In addition, swap-in-potentiam 0-conf channel funding requires #2137 or a variant of it (I believe ChannelPending event can replace the event in that PR).
The text was updated successfully, but these errors were encountered:
Sure, would be nice. I might alternatively suggest including the amount and sPK in ChannelDetails, which means users can access them at any point, rather than only on accept_channel.
Motivation: The C= swap-in-potentiam work-in-progress spec defines a 0-conf channel open flow, where the channel open is funded by one or more swap-in-potentiam UTXOs from the client as Alice with the LSP as Bob. The advantage of implementing the 0-conf funding flow first BEFORE implementing swaps from the swap-in-potentiam is that if the client has no channels at all yet but DOES have onchain funds in a swap-in-potentiam address, the client can immediately 0-conf-fund a channel and immediately get outbound liquidity on Lightning.
For the swap-in-potentiam 0-conf channel specifically, normally a 0-conf channel open means that the acceptor fully trusts the initiator. However, if the 0-conf channel funding is from swap-in-potentiam UTXOs only, and all swap-in-potentiam addresses have the acceptor as the Bob role and co-signer, and none of the swap-in-potentiam UTXOs are too deeply or too shallowly confirmed, then the acceptor need not trust the opener, provided the acceptor actually validates that the
scriptPubKey
of the funding transaction (which they sign for, as the swap-in-potentiam Bob role) matches the correct one for the channel open and therefore for the commitment transactions they make.The
scriptPubKey
can be computed as soon as the two peers have exchangedopen_channel
andaccept_channel
. In LDK, theOpenChannelRquest
event represents receiving theopen_channel
message, and theaccept_inbound_channel
causesaccept_channel
to be sent out. Ataccept_inbound_channel
, it should be possible to know what thefunding_pubkey
thataccept_channel
will contain, and from there derive thescriptPubKey
, which can then be returned to the caller.I think it is fine to have a separate
accept_inbound_channel
variant, e.g.accept_inbound_channel_and_return_funding_script
. However, perhaps it is simply better to haveaccept_inbound_channel
return aResult<InboundChannelAccepted, APIError>
whereInboundChannelAccepted
is astruct
withpub
fields (which can be extended later) that include the fundingscriptPubKey
.In addition, swap-in-potentiam 0-conf channel funding requires #2137 or a variant of it (I believe
ChannelPending
event can replace the event in that PR).The text was updated successfully, but these errors were encountered: