Remove amount-based confirmation scaling

[t-bast]

We previously scaled the number of confirmations based on the channel capacity: however, this doesn't really work with splicing, as shown by the following attack scenario:

• a malicious node opens a very large channel
• we thus wait for more confirmations to protect against reorgs
• they then send lightning payments until all of the balance is on our side of the channel
• we splice-out to shrink the channel to a minimal size
• if we thus us a smaller number of confirmations (because the channel is now small), the malicious node can perform this small reorg and publish one of their revoked commitment

There are more involved variations of this attack, which show that the real amount at stake is potentially much more than a single channel's current capacity. Instead of trying to find a complex solution that would likely have subtle edge cases, it's a lot simpler to always use a static number of confirmations that is large enough to protect against reorgs entirely.

Let's try to roughly quantify the cost of a reorg for a malicious attacker.
Let's assume that an attacker has h% of the network's hashrate and a probability p of creating a reorg of d blocks.
This probability p can be obtained from h and d using Optech's online reorg calculator: https://bitcoinops.org/en/tools/reorg-calculator/
By mining honestly instead of trying to perform the attack, the attacker would have earned d * h * block_reward / 100 (ignoring transaction fees).
So as long as the amount at stake multiplied by p is much smaller than the honest block reward, we should be safe from reorgs.

If we use h = 25% and d = 8 blocks, we obtain p = 2%.
With the current block reward of 3.125 btc, the attacker would earn at least 6.250 btc when behaving honestly.
Even though the analyis above simplifies is just a rough estimation of the attack cost, it should be pretty safe for most node operators to use the default min-depth = 8.
Nodes that have a very large amount of bitcoin at stake may consider increasing it if necessary.

[pm47]

LGTM. I'm glad to see those minDepth*() helpers gone 🧹 💨

[luke-jr]

Only issue is your h is too small. In reality, 16 blocks are needed to be secure against Foundry, and 800+ against Bitmain.

[t-bast]

Only issue is your h is too small. In reality, 16 blocks are needed to be secure against Foundry, and 800+ against Bitmain.

What's your suggestion for a default behavior? Our previous scaling mechanism wasn't protecting us against 800-blocks reorgs either...

I don't think random small node operators will be targeted by large block reorgs: nodes that have more funds at stake and are afraid of being targeted can (should) increase the default min-depth-blocks parameter accordingly, but I don't see how we could have a satisfying one-size-fits-all policy here?