Non-initiator channels

[ecdsa]

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 remote node_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 encrypted node_id. Assume that we know how the encrypted node_id looks like, without knowing the remote node_id (encryption can be performed with a nonce that we give to the remote during the negotiation phase).

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 remote node_id, in order to contact them. That node_id could be encoded in another OP_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.

[SomberNight]

Several remarks:

• a tx cannot have more than one OP_RETURN output, according to current Bitcoin Core standardness rules
  • so if we want both the current OP_RETURN for onchain chan backups (encoding the remote node id), and add an additional OP_RETURN to encode the local node id, naively that would be a non-std txn
• this would require modifying the channel opening flow (bolt-02) to ask the remote to add an OP_RETURN, but channel v2 already gives us this functionality anyway (with some caveats).
  • if we had channel v2:
    • we could use the tx_add_input/tx_add_output msgs during the channel-opening negotiation to add inputs/outputs
      • although note spec PR text:

        script is the scriptPubKey for the output (with its length omitted). scripts are not required to follow standardness rules: non-standard scripts such as OP_RETURN may be accepted, but the corresponding transaction may fail to relay across the network.

    • also note that if we use tx_add_output, we need to pay for those outputs by adding an input of our own
      • see "Fee Responsibility" section
      • so as-is I guess we couldn't use it for this purpose for a fresh/empty wallet without UTXOs
• electrumx atm does not index OP_RETURN outputs; unsure about other server impls
  • see code here:
    • https://github.com/spesmilo/electrumx/blob/75d0e25bf022355941ae4ecb4d5eba41babcf041/electrumx/lib/script.py#L75
    • https://github.com/spesmilo/electrumx/blob/75d0e25bf022355941ae4ecb4d5eba41babcf041/electrumx/server/block_processor.py#L409
    • https://github.com/spesmilo/electrumx/blob/75d0e25bf022355941ae4ecb4d5eba41babcf041/electrumx/server/block_processor.py#L454-L458
  • I guess kyuupichan had decided not to index OP_RETURNs as there is limited usefulness in naive lookups for them:
    • in your current proposal you want to use an OP_RETURN with fixed known data as a marker to find txns, so this could work with naive indexing
    • imagine we wanted to combine the two OP_RETURNs mentioned above into one, now we would need some kind of partial search which would need a more complicated index (as the full OP_RETURN payload and hence the scriptPubKey and hence the scripthash is not known when doing the lookup)

[SomberNight]

• also note that if we use tx_add_output, we need to pay for those outputs by adding an input of our own
  • see "Fee Responsibility" section
  • so as-is I guess we couldn't use it for this purpose for a fresh/empty wallet without UTXOs

Note that if we need to add our own input anyway, then the marker OP_RETURN is not needed. We can simply tx_add_output the OP_RETURN we are already adding (encoding the first 16 bytes of the remote node id) and add a UTXO of our own (, and likely add another tx_add_output for a change output). When restoring from seed we will find the funding tx in the onchain history because of having contributed an input.

But again, this assumes that nodes implementing channel v2 will allow adding an OP_RETURN output.

[ecdsa]

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.