Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

3. Updated the node config with bitcoin.defaultchanconfs=4. confirmations_until_active value in pendingchannels response doesn't track. It still starts off with a value of 3 (should start with 4) and channels gets active after 3 confirmations. Test fail.

I checked this locally and it works for me. I have also added an itest for this case. Not entirely sure, but it seems like you might have missed what bitcoin.defaultchanconfs means is "We'll require any incoming channel requests to wait for this many confirmations before we consider the channel active."

So:

• Alice -> Bob (the confirmations_until_active starts off with a value of Bob's defaultchanconfs)
• Bob -> Alice (the confirmations_until_active starts off with a value of Alice's defaultchanconfs)

3. Updated the node config with bitcoin.defaultchanconfs=4. confirmations_until_active value in pendingchannels response doesn't track. It still starts off with a value of 3 (should start with 4) and channels gets active after 3 confirmations. Test fail.

I checked this locally and it works for me. I have also added an itest for this case. Not entirely sure, but it seems like you might have missed what bitcoin.defaultchanconfs means is "We'll require any incoming channel requests to wait for this many confirmations before we consider the channel active."

So:

• Alice -> Bob (the confirmations_until_active starts off with a value of Bob's defaultchanconfs)
• Bob -> Alice (the confirmations_until_active starts off with a value of Alice's defaultchanconfs)

Good clarification. Tested again by updating the peer's setting and was able to get the correct values for confirmations_until_active.

/gemini review

didn't test a reorg

should I add an itest for this? I'm not sure if there's a way to do it in itest, but I can check/implement if possible.

should I add an itest for this?

I don't think it is super important for this feature, however if you are interested you can look at testOpenChannelAfterReorg how to design a reorg test.

I don't think it is super important for this feature, however if you are interested you can look at testOpenChannelAfterReorg how to design a reorg test.

while working on this, I found a critical bug (in this PR) that occurs during a reorg -- the NegativeConf notification is only sent if the Confirmed notification has already been sent. So, if a reorg happens before the channel becomes active, NegativeConf won't be sent. As a result, even after one confirmation we won't be able to reset ConfirmationHeight. Later, when the funding tx is confirmed again, ConfirmationHeight will not be updated because of the if completeChan.ConfirmationHeight == 0 check, so we'll end up with incorrect data.

while working on this, I found a critical bug (in this PR) that occurs during a reorg -- the NegativeConf notification is only sent if the Confirmed notification has already been sent. So, if a reorg happens before the channel becomes active, NegativeConf won't be sent. As a result, even after one confirmation we won't be able to reset ConfirmationHeight. Later, when the funding tx is confirmed again, ConfirmationHeight will not be updated because of the if completeChan.ConfirmationHeight == 0 check, so we'll end up with incorrect data.

Perfect, also a reminder to always test ! So let's fix the problem can you push the itest.

I think we just need to make a litter change here:

// dispatchConfReorg dispatches a reorg notification to the client if the
// confirmation notification was already delivered.
//
// NOTE: This must be called with the TxNotifier's lock held.
func (n *TxNotifier) dispatchConfReorg(ntfn *ConfNtfn,
	heightDisconnected uint32) error {

	// If the request's confirmation notification has yet to be dispatched,
	// we'll need to clear its entry within the ntfnsByConfirmHeight index
	// to prevent from notifying the client once the notifier reaches the
	// confirmation height.
	if !ntfn.dispatched {
		confHeight := heightDisconnected + ntfn.NumConfirmations - 1
		ntfnSet, exists := n.ntfnsByConfirmHeight[confHeight]

		// We also signal the reorg to the notifier in case the
		// subscriber is also interested in the reorgs before the
		// transaction received it required confirmation.
		//
		// Because as soon as a new block is connected which has the
		// transaction included again we preemptively read the buffered
		// channel.
		select {
		case ntfn.Event.NegativeConf <- int32(n.reorgDepth):
		case <-n.quit:
			return ErrTxNotifierExiting
		}

		if exists {
			delete(ntfnSet, ntfn)
		}
		return nil
	}

	// Otherwise, the entry within the ntfnsByConfirmHeight has already been
	// deleted, so we'll attempt to drain the confirmation notification to
	// ensure sends to the Confirmed channel are always non-blocking.
	select {
	case <-ntfn.Event.Confirmed:
	case <-n.quit:
		return ErrTxNotifierExiting
	default:
	}

	ntfn.dispatched = false

	// Send a negative confirmation notification to the client indicating
	// how many blocks have been disconnected successively.
	select {
	case ntfn.Event.NegativeConf <- int32(n.reorgDepth):
	case <-n.quit:
		return ErrTxNotifierExiting
	}

	return nil
}

@NishantBansal2003 please be aware that we prioritized this for LND20, are you able to fix the underlying issue in the next days ? Otherwise we move it into LND 21

Oops, apologies, everything is done locally, only my testing remains. I will test and push by the end of today (IST timezone)