chainntnfs: validate conf/spend ntfn registration parameters #3405
Conversation
wpaulino
requested review from
cfromknecht and
joostjager
and removed request for
halseth
wpaulino
changed the title
|
As a result of having the validation checks being done at the chain notifier level, a bug was discovered with the BumpFee RPC that would cause us to scan the chain from genesis due to a 0 height hint. See the relevant commit for more details. |
wpaulino
requested review from
cfromknecht and
joostjager
and removed request for
Roasbeef
joostjager
left a comment
joostjager
left a comment
There was a problem hiding this comment.
This pr did get quite out of hand. I didn't expect the move of subscription logic to txNotifier to involve so many changed lines of code. To me the end result looks definitely like an improvement. I hope you found it worthwhile to do. I left some non-blocking comments.
There was a problem hiding this comment.
Do this as first thing in this function, so that txNotifier.RegisterSpend can accept it as a value parameter?
There was a problem hiding this comment.
Yeah that's what's returned by the underlying call for unconfirmed transactions.
There was a problem hiding this comment.
const unconfirmed = -1 would be nice
A height hint not being set would cause lnd to scan for the confirmation/spend of a txid/outpoint/address from genesis. The number of confirmations not being set within a confirmation request would cause the internal TxNotifier to deadlock when dispatching updates.
This prevents a deadlock while tearing down the TxNotifier if it's currently blocked delivering a notification. By closing the quit chan first, we ensure blocked sends/reads can exit and allow the TxNotifier to proceed tearing down.
These fields are only relevant for spent transaction outputs.
The cache wasn't really serving a purpose as FetchInputInfo isn't known to be a hot path. Also, with a planned addition of returning the confirmation status of an output within FetchInputInfo in a later commit, caching won't be useful as we'll have to go to disk anyway to determine the confirmation status.
We already have all of the information required for the outputs from the ListUnspent method.
In this commit, we address an issue that would cause us to scan from the genesis block for the spend of an output that we wish to use to raise the fee of a transaction through CPFP. This was due to setting a 0 height hint when constructing the input required by the sweeper and was discovered due to the recently added validation checks at the chain notifier level. We'll now use the current height as the height hint instead as the sweeper will end up creating a new transaction that spends the input.
cfromknecht
left a comment
cfromknecht
left a comment
There was a problem hiding this comment.
LGTM 👌 nice to see chainntnfs getting some more love!
|
I see an issue here where I get this error when trying to restore an SCB
|
5 participants
A height hint not being set would cause lnd to scan for the confirmation/spend of a txid/outpoint/address from genesis.
The number of confirmations not being set within a confirmation request would cause the internal TxNotifier to deadlock when dispatching updates. To prevent this, we default to dispatching a notification upon one confirmation.
Fixes #3398.