onchaind should scorch-earth our penatly txes

[ZmnSCPxj]

We should resolve these transaction by bumping their fees up at each block they are not confirmed, to counteract atempts at bribing miners to not confirm them before timeout.

My reading of the current onchaind code is that we do not do so.

My plan is:

• Make steal_to_them and steal_htlc use 0xFFFFFFFD (RBF) nLockTime nSequence wtf.
• Factor out the transaction creation code from steal_to_them and steal_htlc.
• Write an alternative to propose_resolution which changes the tx and depth but does not install an existing proposal, just reuses it.
  • Re-proposal should broadcast tx as well.
• Whenever the depth of a transaction increases, if a tracked_output for that transaction is THEIR_REVOKED_UNILATERAL, we re-propose with a higher feerate depending on the to_self_delay[REMOTE] to_self_delay[LOCAL] to_self_delay[REMOTE] (because onchain_control.c swaps them already) because we impose our own to_self_delay on the counterparty. The easiest is just to double the feerate each time.

It seems to me that since the output tracking code of onchaind already needs to be resilient to changing feerate estimations, that should be sufficient to implement scorched-earth policy.

Thoughts?

[ZmnSCPxj]

One of the effects here is that we can generate a transaction with high fees, possibly violating the "high fee" limit imposed by bitcoind.

Unfortunately the API for sendrawtransaction was changed in 0.19.0.1:

• sendrawtransaction and testmempoolaccept no longer accept a allowhighfees parameter to fail mempool acceptance if the transaction fee exceeds the value of the configuration option -maxtxfee. Now there is a hardcoded default maximum feerate that can be changed when calling either RPC using a maxfeerate parameter. (#15620)

I think what we can do would be:

• Add a allowhighfees parameter to the bcli sendrawtransaction.
• If the allowhighfees parameter in bcli is true, add a second parameter that is simply 1.
  • pre-0.19.0.1 would interpret this as allowhighfees=true. No, they would error this, they want true or false when done via bitcoin-cli.
  • post-0.19.0.1 would interpret this as maxfeerate=1 BTC / kB, which should be much higher than any feerate we would emit.

The above is a bit too hacky for my taste though. In particular, wumbo channels that are being stolen might end up having to scorch the earth with most of the wumbo channel value, possibly achieving 1 BTC/kB... sigh.

Basically, in pre-0.19.0.1 we want the second parameter to be 1 (allowhighfees=true) but in post 0.19.0.1 we want the second parameter to be 0 ("ignore maxfeerate").

A slightly less hackish solution would be to do a getnetworkinfo at bcli startup and parse the returned "version". If it is greater than 190000, set the second param to 0, else set it to 1. We could replace the echo command in wait_for_bitcoind with getnetworkinfo and save the version in a global variable. But I have doubts on the reliability of this. Sigh.

[ZmnSCPxj]

A more minor point is that we normally keep transactions that onchaind wants to broadcast and rebroadcast those until they confirm at least once.

However, if we do scorched-earth, then the rebroadcasting would be done by onchaind anyway, with a higher feerate.

So I think I need to add new onchaind->master message, onchain_broadcast_rbf_tx. This will call into broadcast_txwith a no-op callback, which will prevent the tx from being rebroadcast (on the logic that onchaind will RBF the transaction later anyway).

---

I want to design a function like below:

static struct amount_sat
compute_penalty_output_amount(struct amount_sat initial_amount,
                              u32 depth, u32 we_lose_depth);

We store the initial output amount of the first created penalty transaction, which we feed as initial_amount. depth is the depth of the transaction we are penalizing, while we_lose_depth is the to_self_delay we negotiated from the counterparty. Then the function outputs an amount less than initial_amount, which is the amount we want to set as our output (with the remaining put into fees).

Then we can separately argue what is the best function for scorching the earth.

Using the above, we can regenerate a new transaction that outputs the given amount, and rebroadcast it. If the above function returns below the dust limit, we create a capstone: the output is to a 0-length OP_RETURN output, because it is better to pay to miners then let thieves win (and we should probably output 0 or near 0 at depth == we_lose_depth - 1).