Push transactions in invalid blocks

[Kixunil]

This is a feedback on the presentation on BH2022, I didn't manage to catch you afterwards.

I believe it's better to push transactions in invalid blocks to the network because it benefits the user of the watchtower (gets whole channel amount) and all else being equal a selfish user will choose to use a watchtower that does this.

[sr-gi]

This is a bit tricky since I believe it heavily depends on the block source, but I'm open to suggestions/comments.

In the current implementation (using bitcoind) we only get blocks that are appended to the best chain. I'm not aware of any way of polling all received blocks, even the potentially invalid / reorged.

The state machine goes as follows:

If we see a tx that breaches a channel, we will send the penalty and monitor it until it is irrevocably resolved (reaches 100 confs). If there is a reorg we behave depending on whether the penalty and the commitment were reorged out. In the former case, we simply repush the tx to make sure it remains in the mempool. In the latter, we will try to rebroadcast both. If the commitment is rejected this will be flagged as untriggered and we will start from the beginning (wait until we see a breach again).

Honestly, there is no much more we can do. But again, I'm open to suggestions.

[Kixunil]

From the presentation my understanding was that you intend to have a Core-free block source eventually. If they will be abstracted using a trait it should be possible to have slightly different implementations for the two.

Although now that I think about it it may be tricky to rebroadcast without Core because broadcasting an invalid tx could result in ban.

[sr-gi]

Yeah, one of the reasons we chose Core instead of other implementations was to make sure that we stick to the Core policy, otherwise, the transaction may never reach a miner.

All in all, I think it is worth considering alternative block sources as future opt-in feature, will leave this open to have it in mind.

[Kixunil]

Something that could be interesting (and perhaps a source of income for TEOS): have a service that provides test mempool accept API for a few sats. It guarantees to never ban you as long as you pay. Then people could run a lightweight version which still checks POW so it's expensive to sabotage them and runs the paid check just in case to avoid bans.

[sr-gi]

Umm, this sounds interesting, but also a potential huge privacy leak. What type of transactions would the API be receiving?

[Kixunil]

Not too big privacy leak if you intend to publish the transaction after the check returns true. You could connect over Tor and pay with LN (LSAT). The API would be literally cores testmempoolaccept

[sr-gi]

So would the use case be:

• A "lightweight" tower decrypts a certain penalty and needs to broadcast it
• It first queries the API to make sure the tx will be accepted by the network
  • If true the tx is broadcast, if false it won't?

If so, I think you should need some sort of a quorum of "towers" providing such a service (picked by the user), otherwise, the service can always (or randomly) return false and DoS the "lightweight" tower.

Even more, if the tower providing such a service is queried a transaction that it is also monitoring, the incentive for the service provider is to return false and fulfill the job itself (assuming there's a bounty attached to it).

[Kixunil]

Indeed. In the case of bounty, the bounty already has to go to predefined recipient. It'll be taken by miners otherwise.

[sr-gi]

Indeed. In the case of bounty, the bounty already has to go to predefined recipient. It'll be taken by miners otherwise.

Sure, but I don't mean the service-provider tower stealing the requester bounty (from its transaction) but returning false so it can keep its own bounty (from a similar penalty that has a bounty with a different recipient). The thing goes a follows:

• T is a tower that provides the service you described and also regular tower services
• LT is a lightweight tower that hires T for the described service
• A is a user that hires both T and LT

If LT queries T with a penalty txp_0 that spends from a given commitment txc, T can know that he also has a penalty for txc: txp_1, so it would benefit more from returning false to LT and preventing a potential race condition between txp_0 and txp_1.

[Kixunil]

Good point, though I think for lightweight towers it makes more sense to run my own on RPi Zero or something and in that case I don't need T. If I'm hiring a tower it may as well be a full node running one (it needs to also accept payments among other things).

[sr-gi]

@Kixunil kind of tangential to this, bet we ended up implementing lightweight towers on top or Core in #130