Drop last bits of rescan as its too complicated to be worth having 2020-09-no-rescan
authorMatt Corallo <git@bluematt.me>
Wed, 30 Sep 2020 19:18:29 +0000 (15:18 -0400)
committerMatt Corallo <git@bluematt.me>
Fri, 2 Oct 2020 16:36:46 +0000 (12:36 -0400)
commit2bd571d2f9b1e4868708eb4b46832d290d497e04
tree4d3603ae6750b25206af3710f2fab1a3343b10a3
parentb627aa6e7ceb0852e097ec7809d64823bb8d3082
Drop last bits of rescan as its too complicated to be worth having

Previously, we had a concept of "rescaning" blocks when we detected
a need to monitor for a new set of outputs in future blocks while
connecting a block. In such cases, we'd need to possibly learn about
these new spends later in the *same block*, requiring clients who
filter blocks to get a newly-filtered copy of the same block. While
redoing the chain access API, it became increasingly clear this was
an overly complicated API feature, and it seems likely most clients
will not use it anyway.

Further, any client who *does* filter blocks can simply update their
filtering algorithm to include any descendants of matched
transactions in the filter results, avoiding the need for rescan
support entirely.

Thus, it was decided that we'd move forward without rescan support
in #649, however to avoid significant further changes in the
already-large 649, we decided to fully remove support in a
follow-up.

Here, we remove the API features that existed for rescan and fix
the few tests to not rely on it.

After this commit, we now only ever have one possible version of
block connection transactions, making it possible to be
significantly more confident in our test coverage actually
capturing all realistic scenarios.
lightning/src/chain/chainmonitor.rs
lightning/src/ln/functional_test_utils.rs
lightning/src/ln/functional_tests.rs