wallet: add bwatch-backed output and transaction tables

[sangbida]

Overview

This is the third PR in the bwatch series. It introduces two wallet tables:

• our_outputs, replacing outputs
• our_txs, replacing transactions

Existing wallet data is backfilled into the new tables during migration. The wallet then uses these tables as its primary data source for transaction and UTXO state.

Compatibility and bisectability

The legacy tables remain in place for at least one release so users can downgrade without requiring a rescan.

During this transition, writes are mirrored to both the new and legacy tables. This keeps every commit in the PR series bisectable and ensures that a database written by a newer binary remains usable by an older one. Reads, however, are routed through our_outputs and our_txs.

Much of the apparent duplication in this PR is intentional and will be removed once the compatibility window closes.

Wallet scriptpubkey watches

This PR also adds persistent scriptpubkey watches for wallet addresses.

At startup, the wallet registers watches for its generated address forms. When bwatch finds a payment to one of these scripts, the wallet:

• records the transaction in our_txs;
• records the received output in our_outputs;
• installs an outpoint watch to detect when the output is spent; and
• handles watch reverts during chain reorganizations.

Longer-term direction

A later PR will stop updating the chain-topology-owned legacy tables, including:

• blocks
• transactions
• outputs
• utxoset
• tables whose foreign-key dependencies require blocks

[cdecker]

I have rarely seen a PR that is as well structured and pleasant to review as this one, kudos @sangbida 🤩

I have little to no comments on the code itself, but I have some questions that arose during my reviews, and it shows I did not review the previous chunks of the bwatch work, apologies if this is repeat information for everybody else, but I was hoping you could bring me up to speed quickly. I have the following things I am watching out, that I'd need help with:

• It looks to me like the watches are disabled after the first hit they encounter. What would be the outcome if an attacker were to anticipate an address or a spend that we are watching for, and frontrun it with a bogus payment? I.e., we expect a channel funding with a given script, and the attacker just does not broadcast the actual TX we are waiting for, instead sending a tiny fragment to the address. Does this disarm the watch and we'd be missing the actual funding for example? I know, not incentive compatible, as the attacker is hurting themself, but deviations need to be handled.
• One thing we faced in the old watcher code, was the "transitive infection" of watchers, i.e., due to raciness between the handlers and the block processing, we had to add new watches to any output that was spending a watched output, so that we'd follow the spend DAG, just in case we needed to know any of the later outputs. How does bwatch handle this?

Either way, this PR should be good to go 👍

[cdecker]

Notice that the REPLACE variant with blockheight=0 may inadvertently uncomfirm an existing tx, which may or may not be intended. It might be better to make that a conditional update here:

1. First insert and on conflict do nothing.
2. Then UPDATE SET blockheight = ?, txindex = ? WHERE txid = ? AND blockheight = 0;

The WHERE guard allows us to ensure we don't accidentally touch any confirmation (updating a confirmation should only be done if we set it to 0 inbetween I think). Then we can also check how many records that UPDATE changed, and if it was 0 and blockeheight != 0 we have a clear signal of such an unintended downgrade.

[cdecker]

blockheight > 0 would be a bit more self-documenting I think ;-)

[cdecker]

The ++ prefix skips index=0 if I'm not mistaken, is that intentional? Also the iteration stops one after maxindex.

[sangbida]

• It looks to me like the watches are disabled after the first hit they encounter. What would be the outcome if an attacker were to anticipate an address or a spend that we are watching for, and frontrun it with a bogus payment? I.e., we expect a channel funding with a given script, and the attacker just does not broadcast the actual TX we are waiting for, instead sending a tiny fragment to the address. Does this disarm the watch and we'd be missing the actual funding for example? I know, not incentive compatible, as the attacker is hurting themself, but deviations need to be handled.

Watches are not disabled after the first hit they encounter, watches have to be explicitly unwatched using an unwatch handler before we forget about them. We don't have an unwatch handler for our wallet scriptpubkey watches because they are perennial watches. I'm imagining you're talking about a case like this:

• Node arms a watch for script S (funding address or wallet address).
• Attacker sends a dust payment to S first.
• Watch fires once, then is deleted.
• Real funding arrives later → nobody is watching → miss.

This is what happens instead:

• Node has BIP86 keyindex 7. It derives the internal key and builds the P2TR script S, address like bcrt1p….
• Startup arms a perennial watch: owner wallet/spk/7/p2tr, script S, start_block = UINT32_MAX.
• Attacker anticipates that address and sends 546 sats to bcrt1p…. That tx confirms.
• bwatch sees output script S, sends watch_found for wallet/spk/7/p2tr.
• wallet_watch_spk records the dust UTXO in our_outputs and arms a spend watch wallet/utxo/<dust_txid>:0.
• The wallet/spk/7/p2tr watch is not removed. It stays in bwatch’s scriptpubkey table.
• Later the intended deposit of 1 BTC lands on the same bcrt1p… address and confirms.
• bwatch matches S again → second watch_found → second UTXO recorded under keyindex 7.

We still haven't implemented the bwatch logic to look for the funding tx to do the channel open so from this PRs view we are still relying on channel_funding_found to confirm the funding tx only if x pays exactly funding_sats to S at the expected txid:vout.