]> git.bitcoin.ninja Git - rust-lightning/commit
DRY the comparison blocks in `update_claims_view_from_matched_txn`
authorMatt Corallo <git@bluematt.me>
Wed, 7 Dec 2022 00:30:43 +0000 (00:30 +0000)
committerMatt Corallo <git@bluematt.me>
Wed, 7 Dec 2022 23:17:58 +0000 (23:17 +0000)
commit60f3c0a206bfdc851400bce7753db688b01b094e
treebe98e8bbd6b4288f5a6b0e8d5be087dad8b6597e
parent399b3eb3f74b266e3273af04748a1cad46181494
DRY the comparison blocks in `update_claims_view_from_matched_txn`

In `update_claims_view_from_matched_txn` we have two different
tx-equivalence checks which do the same thing - both check that the
tx which appeared on chain spent all of the outpoints which we
intended to spend in a given package. While one is more effecient
than the other (but only usable in a subset of cases), the
difference between O(N) and O(N^2) when N is 1-5 is trivial.

Still, it is possible we hit this code with just shy of 900 HTLC
outputs in a channel, and a transaction with a ton of inputs.

While having to spin through a few million entries if our
counterparty wastes a full block isn't really a big deal, we go
ahead and use a sorted vec and binary searches because its trivial.
lightning/src/chain/onchaintx.rs