Fetch the Spend transaction from the Coordinator, apply Spend policies

[darosior]

The annoying part is designing the plugin interface for that.

[danielabrozzoni]

Unassigning me as I don't have time to work on it, sorry 😢

[edouardparis]

I am suggesting to move

Field	Type	Description
new_attempts	array of [Vault resource]	Vaults that were just un-vaulted
successful_attempts	array of string	Outpoints vaults that were spent (defined as an Unvault being spent after the timelock expired).
revaulted_attempts	array of string	Outpoints of the revaulted vaults

To:

Field	Type	Description
new_attempts	array of [attempt resource]	Spending attempts that can be canceled
successful_attempts	array of [attempt resource]	Outpoints vaults that were spent (defined as an Unvault being spent after the timelock expired).
revaulted_attempts	array of [attempt resource]	Outpoints of the revaulted vaults

with attempt resource:

Field	Type	Description
candidate_tx	string or null	hex encoded Spending transaction (maybe null in that case the attemps must be in revaulted_attempts)
vaults	array of Vault resource	Vaults concerned by the candidate_txs
blockheight	integer or null	Block height of the transaction if confirmed else null

• new_attempts items cannot have no candidate_tx, in that case, the watchtowers already started to revault the vaults and filled instead the revaulted_attempts
• new_attempts items cannot have two candidate_tx with vaults list overlapping, in that case the watchtowers started to revault the vaults and filled instead the revaulted_attempts

---

Long term thinking

What if the lists (especially successful attempts) grow to much over time ? Maybe coordinatord stop share the attempts after a very long time calculated by the total of confirmation block ?