Implement payment revocation whenever a lightning payment occur

AcidBunny21requested to merge
gh-8d0098b3/434/unknown/refs/pull/434/head into master

Closes https://codeberg.org/ark-bitcoin/bark/issues/364

This PR introduce a mechanism to revoke a failed lightning payment.

When Server cannot perform the lightning payment (for various reason), he can now notify the client, which then asks for revocation. This part looks like an Arkoor payment to self, which unique input is the LN payment's HTLC VTXO.

Using the A+S keyspend path on that VTXO, Server and Alice can collaborate to revoke the lightning payment. Alice will ask Server to cosign an Arkoor that spends the HTLC output of the HTLC tx (previously created during the LN payment process) to an address owned by Alice. Only when Server successfully cosigned that payment, Alice knows the payment was revoked. In the current implementation, fees are sent back to the Alice, but the payment still costs her 2 dust anchors (one for the htlc tx and one for the arkoor one).

This PR introduces the notion of a VTXO that cannot actually be exited unilaterally. Bolt11Htlc is indeed the only variant that cannot be unilaterally exited by the user. It is done like that because the HTLC cannot at the same time be safe for the Server and include an exit clause. So it must only be a transitional VTXO that must be spent to an actual Arkoor to be considered owned by Alice.

This new notion implies some changes at the core of the VTXO model, including making VTXO spks more flexible. In addition to the current exit_spk which will now be one variant of all possible VTXO spks, this PR introduces an htlc_spk to be used in the Bolt11Htlc VTXO variant.

Notes:

  • One case that is not handled by this PR is one where the client ask for a revocation, but ASP refuses or doesn't respond. In this case, client should go onchain.

Merge request reports