2

I've installed two major Lightning Network implementations, CLN (formerly c-lightning) and LND, with bitcoind testnet as backchain on the same server. On the first startup I noticed CLN synchronizes all blocks from the beginning of the blockchain:

2022-07-05T23:31:29.487Z DEBUG   lightningd: Still waiting for initial block download
2022-07-05T23:31:29.593Z DEBUG   lightningd: Adding block 1: 00000000b873e79784647a6c82962c70d228557d24a747ea4d1b8bbe878e1206
2022-07-05T23:31:29.647Z DEBUG   lightningd: Adding block 2: 000000006c02c8ea6e4ff69651f7fcde348fb9d557a06e6957b65552002a7820
2022-07-05T23:31:29.685Z DEBUG   lightningd: Adding block 3: 000000008b896e272758da5297bcd98fdc6d97c9b765ecec401e286dc1fdbe10
2022-07-05T23:31:29.732Z DEBUG   lightningd: Adding block 4: 000000008b5d0af9ffb1741e38b17b193bd12d7683401cecd2fd94f548b6e5dd
2022-07-05T23:31:29.752Z DEBUG   lightningd: Adding block 5: 00000000bc45ac875fbd34f43f7732789b6ec4e8b5974b4406664a75d43b21a1
2022-07-05T23:31:29.774Z DEBUG   lightningd: Adding block 6: 000000006633685edce4fa4d8f12d001781c6849837d1632c4e2dd6ff2090a7b
2022-07-05T23:31:29.792Z DEBUG   lightningd: Adding block 7: 00000000e29e3aa65f3d12440eac9081844c464aeba7c6e6121dfc8ac0c02ba6

while LND only scans blocks from the wallet's birthday onwards:

2022-07-05 23:21:55.757 [INF] LTND: Waiting for chain backend to finish sync, start_height=2284292
2022-07-05 23:21:56.613 [DBG] LNWL: Chain backend synced to tip!
2022-07-05 23:21:56.614 [DBG] LNWL: Locating suitable block for birthday 2022-07-03 15:15:05 -0300 -03 between blocks 0-2284292
2022-07-05 23:21:56.617 [DBG] LNWL: Checking candidate block: height=1142146, hash=00000000000bee59e6acdb88deee299fcce4c8603a04a60b022d70f256b4d880, timestamp=2017-06-18 16:00:52 -0300 -03
2022-07-05 23:21:56.619 [DBG] LNWL: Checking candidate block: height=1713219, hash=000000000000905bf5e522da9cc5d30a93728feb51f3409396193f120505e2ca, timestamp=2020-04-14 06:51:58 -0300 -03
2022-07-05 23:21:56.621 [DBG] LNWL: Checking candidate block: height=1998755, hash=00000000000009aa098093884b3f352bfc1efa24ec2af3d541e2fa2ba7e54d6b, timestamp=2021-06-02 19:57:47 -0300 -03
2022-07-05 23:21:56.623 [DBG] LNWL: Checking candidate block: height=2141523, hash=00000000849bdb7b93b3deb7182cb1ec3dc2e470d4359ac6fe67d19e5bd5f84e, timestamp=2022-02-14 17:16:49 -0300 -03
2022-07-05 23:21:56.625 [DBG] LNWL: Checking candidate block: height=2212907, hash=00000000000004e43dbee8c2f5ae622bb6a984183ef07a8341b1eec6ce331ce5, timestamp=2022-04-28 00:06:02 -0300 -03
2022-07-05 23:21:56.627 [DBG] LNWL: Checking candidate block: height=2248599, hash=00000000000009c8763aaa3757774b8c8611495dd2f190672d1c4084d40368d6, timestamp=2022-05-26 08:36:29 -0300 -03
2022-07-05 23:21:56.629 [DBG] LNWL: Checking candidate block: height=2266445, hash=00000000000022f256ef974c1467221afc19f6c087ffb147554191d128099438, timestamp=2022-06-16 10:46:47 -0300 -03
2022-07-05 23:21:56.631 [DBG] LNWL: Checking candidate block: height=2275368, hash=0000000000000069a27c710313fc5a764e8bab5fed550af837d0c8b1d6fdd558, timestamp=2022-06-16 14:23:46 -0300 -03
2022-07-05 23:21:56.633 [DBG] LNWL: Checking candidate block: height=2279830, hash=00000000000001d54cbb97ed368723e4ae7681f6c3d625d517b9dbe3a7d0678a, timestamp=2022-06-18 00:41:09 -0300 -03
2022-07-05 23:21:56.635 [DBG] LNWL: Checking candidate block: height=2282061, hash=00000000000000b1517a474a0c8e32a9bd452bd1117cc2a799195991d10c3306, timestamp=2022-06-23 13:04:59 -0300 -03
2022-07-05 23:21:56.637 [DBG] LNWL: Checking candidate block: height=2283176, hash=00000000000000498bf2dbab757cba69b77a8d31ea437b2a377aabdb08c0d3cc, timestamp=2022-06-28 19:37:39 -0300 -03
2022-07-05 23:21:56.639 [DBG] LNWL: Checking candidate block: height=2283734, hash=000000000000003a55f287f3243841f215572c092995ccf286d9d92398d21785, timestamp=2022-07-02 14:50:17 -0300 -03
2022-07-05 23:21:56.641 [DBG] LNWL: Checking candidate block: height=2284013, hash=000000000000004f39aada91825e5d6121e6d7bcda6be504a6f2c13dac133df9, timestamp=2022-07-04 05:13:13 -0300 -03
2022-07-05 23:21:56.643 [DBG] LNWL: Checking candidate block: height=2283873, hash=000000003c07419de729aa383f639e506e24dc5f7e947f80cfaf5d2e67837c43, timestamp=2022-07-03 08:31:57 -0300 -03
2022-07-05 23:21:56.645 [DBG] LNWL: Checking candidate block: height=2283943, hash=0000000000000017b3b716a4e380900fbf2e114d2536a6f5e71427e5b10a34f8, timestamp=2022-07-03 17:57:30 -0300 -03
2022-07-05 23:21:56.647 [DBG] LNWL: Checking candidate block: height=2283908, hash=000000000000004aef1f2fc4dc6973f7c9ac67e5f6c69e1df089f92c83e91324, timestamp=2022-07-03 13:34:25 -0300 -03
2022-07-05 23:21:56.647 [DBG] LNWL: Found birthday block: height=2283908, hash=000000000000004aef1f2fc4dc6973f7c9ac67e5f6c69e1df089f92c83e91324, timestamp=2022-07-03 13:34:25 -0300 -03
2022-07-05 23:21:56.656 [INF] LNWL: Started rescan from block 000000000000004aef1f2fc4dc6973f7c9ac67e5f6c69e1df089f92c83e91324 (height 2283908) for 0 addresses
2022-07-05 23:21:56.687 [INF] LNWL: Catching up block hashes to height 2283919, this might take a while
2022-07-05 23:21:56.693 [INF] LNWL: Done catching up block hashes
2022-07-05 23:21:56.693 [INF] LNWL: Rescanned through block 0000000000000005cdcf62d03147fc812f5b01b21a919bdbe38a3588cafdd5f8 (height 2283919)
2022-07-05 23:21:59.062 [INF] LNWL: Catching up block hashes to height 2284292, this might take a while
2022-07-05 23:21:59.063 [INF] LNWL: Done catching up block hashes
2022-07-05 23:21:59.063 [INF] LNWL: Finished rescan for 0 addresses (synced to block 00000000eb61cbd41eaaa4c3646418dd1acf75d30b04239385b19c51fef43cec, height 2284292)
2022-07-05 23:21:59.785 [INF] LTND: Chain backend is fully synced (end_height=2284292)!

This seems to give a huge advantage over CLN on first startup times. As of now, my CLN node has spent over 14 hours synchronizing while LND worked in a few seconds. Also, as far I understand, a Lightning node should sync the full UTXO set to verify open channels. But this should be provided by the backchain.

Is there a good reason for CLN to reprocess everything? Also, if LND only syncs from the wallet's birthday, how does it verify channels' funding transactions?

Thanks in advance.

Improve this question
6
  • Hi Gabriel, I updated the title of your question to better summarize the main point of your question. Please take a look whether I understood you right and feel free to further edit or rollback.
    – Murch ♦
    Commented Jul 6, 2022 at 13:49
  • Was bitcoind still synchronizing with the blockchain when you started CLN? CLN would technically only scan the last 6 blocks if not started with something like --rescan, as we assume this is a new node, and not trying to recover. Scanning the whole blockchain is definitely not intended and a bug if not caused by --rescan or a mismatched bitcoind
    – cdecker
    Commented Jul 6, 2022 at 14:28
  • @cdecker Yes, it was. I ran this command from CLN's installation guide: bitcoind & ./lightningd/lightningd & ./cli/lightning-cli help, which I believe started CLN's lightningd before bitcoind was fully synchronized. But then I stopped it, waited for the synchronization to complete, and started CLN again. It resumed from where it had stopped instead of scanning the latest blocks.
    – Gabriel Rebello
    Commented Jul 6, 2022 at 14:40
  • 1
    Hm, well not so sure it's a bug now: CLN just take bitcoinds current head and starts syncing from there, so if bitcoind is at <6 blocks then it is perfectly normal for it to start at height 0. Gabriel, you can have lightningd start at a later height by specifying a negative rescan: lightningd --rescan=-600000 will set the sync height to block 600k and it'll sync from there.
    – cdecker
    Commented Jul 7, 2022 at 10:37
  • 1
    Added my more complete answer, with a couple of resolutions, as an answer too :-)
    – cdecker
    Commented Jul 7, 2022 at 10:45

2 Answers 2

Reset to default
3

CLN should start from close to the current blockchain height, however that current blockchain height is learned from bitcoind which in your case was still syncing.

By starting bitcoind and lightningd at roughly the same time, we get a bitcoind that reports the current height very close to the genesis block at height 0. When lightningd then asks bitcoind for the current blockchain height it gets that low-balled height back and assumes it should start syncing from that height, leading to the entire blockchain to be processed.

There are a couple of solutions:

  1. Wait for bitcoind to sync completely (or almost completely if you're fine with CLN processing a few more blocks) and only then start CLN
  2. If you started CLN before bitcoind was synced you can reset the height from which lightningd syncs by specifying the absolute height to sync from with a dash (-, or minus) in front of it: lightningd --rescan=-600000 [other options] will reset the blockchain height to 600k and lightningd should continue scanning from that height.
  3. Use an alternative backend such as sauron or btcli4j which talk to an explorer instead of a local bitcoind for super lightweight (but more trusted) bitcoin backend. You can later switch over to a local bitcoind once that's synced too.

If there is an idea on how to make this more user-friendly we're open to suggestions.

Disclaimer: I'm one of the CLN maintainers.

Improve this answer
1

For a wallet to assess how many Bitcoin it controls it needs to scan the blockchain for UTXOs that are controlled by the wallet.

LND uses a wallet seed format called aezeed which defines a wallet birthday (days since Bitcoin's genesis). It scans the blockchain from this birthday rather than from genesis for relevant UTXOs and assumes that it doesn't control any UTXOs created prior to this birthday.

I don't understand why I should synchronize my Lightning node at all if I run a Bitcoin full node on the same server (why not just tell CLN/LND where the blocks are?).

Your Bitcoin full node verifies the blockchain from genesis. It is interested in all transactions and all blocks being valid and meeting consensus rules, not just the UTXOs that are relevant to the wallet. Once your full node has done this your wallet can assume it is scanning the valid blockchain.

Improve this answer
12
  • I thought the main reason to sync the blockchain would be to verify channel funding UTXOs and ensure the network topology contains only valid channels. If this is true, I don't understand how LND does it without looking at older blocks. And I do understand why the Bitcoin node needs to sync, but not why the Lightning node (see the CLN logs, for example) needs to re-process all those blocks instead of either: 1) just accessing the already-synchronized blockchain; or 2) relying on the UTXO set provided by the Bitcoin node.
    – Gabriel Rebello
    Commented Jul 6, 2022 at 13:24
  • @GabrielRebello: It depends what you are running LND with. There are 3 options as far as I'm aware, running it with Bitcoin Core, btcd (alternative implementation in Go) or Neutrino. In the case of running it with Bitcoin Core or btcd, Bitcoin Core or btcd is validating the chain not LND.
    – Michael Folkson
    Commented Jul 6, 2022 at 13:26
  • In the case of the CLN logs it is not reverifying the blockchain once Bitcoin Core has already done it. It is logging that Bitcoin Core is verifying the blockchain (I think)
    – Michael Folkson
    Commented Jul 6, 2022 at 13:36
  • I'm not sure because lightning-cli --testnet getinfo gives me a warning: warning_lightningd_sync: Still loading latest blocks from bitcoind. and blockheight = 0. It shouldn't take 14 hours to just log blocks either. My Bitcoin node itself is fully synchronized.
    – Gabriel Rebello
    Commented Jul 6, 2022 at 13:43
  • Are you sure your CLN node is connected to your already fully synchronized Bitcoin node? I wonder if it is starting a new IBD for a new Bitcoin node...
    – Michael Folkson
    Commented Jul 6, 2022 at 13:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.