New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-initiator channels #8093
Comments
Several remarks:
|
Note that if we need to add our own input anyway, then the marker OP_RETURN is not needed. But again, this assumes that nodes implementing channel v2 will allow adding an OP_RETURN output. |
Thanks for the clarification. Keep in mind that the main UX reason to support non-initiator channels is to let users receive LN payments on startup, when their wallet does not have any coins. In that scenario it is not possible to contribute an input to the funding transaction. |
One of the reasons why we do not accept channels initiated by a remote node, is we want to be able to recover a backup from seed. Client-initiated channels funding transactions have an
OP_RETURN
that contains the encrypted remotenode_id
. However, allowing remote parties to open channels to us would have major usability advantages (see phoenix).Here is a suggestion: Assume the channel opener creates an
OP_RETURN
output, that contains our encryptednode_id
. Assume that we know how the encryptednode_id
looks like, without knowing the remotenode_id
(encryption can be performed with a nonce that we give to the remote during the negotiationphase).
If we subscribe to the corresponding
scripthash
, then we can learn about the existence of this channel, without being the initiator. The only thing we need is the remotenode_id
, in order to contact them. That node_id could be encoded in anotherOP_RETURN
, like we do currently.This requires a modification of the channel negotiation protocol, but it potentially allows any party to open a recoverable channel to us.
The text was updated successfully, but these errors were encountered: