Be able to connect / open a channel before the node is fully sync.

[nicolasburtey]

Currently, if a node tries to open a channel before the chain (and graph?) is synced, lnd returns an error.

There is one use case where it would be useful to be able to open a channel while the chain is still syncing. It is if another node is offering to open a channel and lock up liquidity right away, in a way where there would be no risk for the synching node to accept the creation of the channel.

The reason the other node would open a channel as a result of some form of trust involved, eg: the other node know for some reason that he'll be able to send/receive transaction from this new node (think of a banking app to his customers), and is ok to lock up liquidity with a smooth/faster onboarding possible.

This would help to reduce onboarding time for new users to go from 0 to first successful lightning inbound transactions, especially on mobile phones.

[nicolasburtey]

After discussion with @Roasbeef yesterday, I think it worth clarifying that the goal is to be able to connect with a (semi-trusted) peer / create a channel before the chain and graph are synced. This would already be very helpful.

Another more advanced use case could be to also accept payment in this not-yet-synced state but this would be difficult to implement to not break security assumption (so it's out of the scope of this ticket)

[nicolasburtey]

Actually, looking more into it, it seems the thing that would be needed is to be able to start the PeerNotifier earlier.

Looking some logs:

2020-01-24 15:33:41.229 [INF] LNWL: Catching up block hashes to height 1663755, this might take a while

at this point, no peer connection is possible.

2020-01-24 15:35:13.567 [INF] LNWL: Done catching up block hashes
2020-01-24 15:35:13.567 [INF] LNWL: Finished rescan for 0 addresses (synced to block 0000000000006f88d7fbde16937caa1b72bab4643e81e9819691ffc235fdf55f, height 1663755)
2020-01-24 15:35:14.432 [INF] LTND: Chain backend is fully synced (end_height=1663755)!
2020-01-24 15:35:14.839 [INF] PRNF: PeerNotifier starting
2020-01-24 15:35:14.881 [INF] HSWC: Starting HTLC Switch

1.5 min later, now the lnd can connect to another peer. Is there a hard dependancy between start peer notifier earlier and be able to be on the last block?

Or what would be the tradeoff if starting Peer Notifier before the chain has been sync?

[wpaulino]

There is one use case where it would be useful to be able to open a channel while the chain is still syncing. It is if another node is offering to open a channel and lock up liquidity right away, in a way where there would be no risk for the synching node to accept the creation of the channel.

Even then, the node syncing will need to detect the channel as confirmed before being able to use it, so it'll need to wait until it's synced. Are you suggesting that this is bypassed as well?

1.5 min later, now the lnd can connect to another peer. Is there a hard dependancy between start peer notifier earlier and be able to be on the last block?
Or what would be the tradeoff if starting Peer Notifier before the chain has been sync?

The PeerNotifier is just responsible for notifying peer connections, not establishing them.

[nicolasburtey]

Even then, the node syncing will need to detect the channel as confirmed before being able to use it, so it'll need to wait until it's synced. Are you suggesting that this is bypassed as well?

Being able to initiate the channel opening would be the step I'd like to have without being fully synced. by the time the channel confirm (ie: the block get mined), it's likely the node will be synced.

[hsjoberg]

There's an open PR that seems to do want you want to do: #3727

[nicolasburtey]

oh, awesome. it seems to be a small diff. @wpaulino could you confirm this is the case? I'll close this ticket then

[hsjoberg]

Even then, the node syncing will need to detect the channel as confirmed before being able to use it, so it'll need to wait until it's synced. Are you suggesting that this is bypassed as well?

Hypothetically I guess this could as well be bypassed with the turbochannels fork of lnd (= trust unconfirmed).

[cfromknecht]

Being able to initiate the channel opening would be the step I'd like to have without being fully synced. by the time the channel confirm (ie: the block get mined), it's likely the node will be synced.

If the node isn't synced, how can the node initiate an opening w/o knowing what UTXOs it has?

[nicolasburtey]

If the node isn't synced, how can the node initiate an opening w/o knowing what UTXOs it has?

my assumption is that the other node is opening the channel

[nicolasburtey]

Hypothetically I guess this could as well be bypassed with the turbochannels fork of lnd (= trust unconfirmed).

Where is this fork?

[hsjoberg]

Where is this fork?

Sorry, I don't remember. I'll get back to you.

[cfromknecht]

my assumption is that the other node is opening the channel

gotcha, yeah accepting a channel opening seems more plausible than initiating. in theory it'd be possible to externally fund a channel using the new funding APIs, but they'd need to be made available before the node is finishes syncing.

one thing we will need to be cautious of implementation-wise is to prevent these early connections to nodes that we already have active channels with, otherwise we might bring up channels too soon in their lifecycle w/o making the host of safety checks that are typically performed. but if the main goal is just to get that first channel this doesn't seem too burdensome.