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
What happens if we start and there's channelmonitors that are on different sides of a fork? We need to detect that somehow and get them back to a common ancestor before moving forward with normal block sync.
Tagging this 0.5 as it might finally become relevant after adding bitcoind RPC support. Though, addressing this properly will be a headscratcher as we (do and need to) load ChannelMonitors and give them to ChainMonitor in the Builder, but while only being able to actually connect and poll the RPC ChainSource after/upon start.
Actually, we can close this as we will synchronize listeners via lightning-block-sync::init::synchronize_listeners upon restart. However, the current issue is still that we sync from chain origin on start, but that's orthogonal to the described issue, AFAIU.
Activity
tnull commentedon Oct 9, 2024
Tagging this 0.5 as it might finally become relevant after adding bitcoind RPC support. Though, addressing this properly will be a headscratcher as we (do and need to) load
ChannelMonitorsand give them toChainMonitorin theBuilder, but while only being able to actually connect and poll the RPCChainSourceafter/uponstart.tnull commentedon Nov 10, 2025
Actually, we can close this as we will synchronize listeners via
lightning-block-sync::init::synchronize_listenersupon restart. However, the current issue is still that we sync from chain origin on start, but that's orthogonal to the described issue, AFAIU.Implement fee source (lightningdevkit#29)
tnull commentedon Oct 13, 2026
Turns out this wasn't fully resolved, see #1076.