Reserved address pool

[dangeross]

This PR:

• Adds addresses allocated to swaps to a reserved pool of addresses until the swap expires
• Gets the next unused address from either an expired reserved address or the next index from the cached derivation index
• Caches the last used derivation index
• Associates a magic routing hint address to the reverse swap, which then when paid via this address, is linked to the reverse swap (if the address is unused, it will be reallocated after expiry)

TODO:

• Adjust the payer_amount_sat and receiver_amount_sat if paid via magic routing hint to set the payment fees to 0 (both should equal tx amount)
• Patch LWK to allow an "up to index" full scan to prevent gap limit errors

Fixes #523

[ok300]

Adds addresses allocated to swaps to a reserved pool of addresses until the swap expires

Associates a magic routing hint address to the reverse swap, which then when paid via this address, is linked to the reverse swap

What happens when a Receive Swap is paid via the MRH Liquid address after the swap expired? Will this also be associated with the swap?

Also what happens multiple payments are made to the MRH Liquid address, i.e. address re-use? Will those payments be associated with the same swap?

[roeierez]

What happens when a Receive Swap is paid via the MRH Liquid address after the swap expired? Will this also be associated with the swap?

Since the magic hints is an internal mechanism hidden inside the invoice clients should parse the invoice in order to pay. The expected behavior by clients is to return error (invoice expired) immediately and not continue to pay so there should not be payments after the swap has expired. If clients other than the sdk do not behave this way then yes worst case we might have multiple payments associated. I think associating the first one only is reasonable.

[dangeross]

Also what happens multiple payments are made to the MRH Liquid address, i.e. address re-use? Will those payments be associated with the same swap?

The first one is associated while the swap is ongoing, then any following ones are stored as separate payments

[dangeross]

What happens when a Receive Swap is paid via the MRH Liquid address after the swap expired? Will this also be associated with the swap?

Like Roei said, the first step should be to check if the invoice has expired, then extract the MRH (I'm not sure if Boltz returns the BIP21 address if the swap is expired, need to check this). But to answer the question, the it won't be associated as the swap is no longer ongoing and therefore will be a separate payment.

[roeierez]

Looking good.

[roeierez]

Almost good to go, one comment.

[ok300]

NIT: Not sure what's the best way to delete data in the context of real-type sync.

IMO DELETE statements could lead to edge-cases when 2 SDK instances sync, one has the data (here, the reserved_address row) and the other doesn't. Depending on the ordering and timing, it could be that one or the other is treated as "the truth".

In contrast, sync would be more resilient if we delete by setting a flag, i.e. reserved = false. Any such conflict during synchronization could then be resolved simply: if any of the two have reserved = false, then its false.

@roeierez @hydra-yse what do you think, does this matter? Or it makes no difference for real-time sync?

[dangeross]

The reserved address table currently only stores MRH addresses used in receive swaps. These are the two cases where a delete would occur:

• A pay to the MRH address is seen while there is no swap progress.
• The reserved address block height expires and the address is reused for another purpose (claim, refund, MRH, direct address). In the MRH case it is re-added to the reserved address table with a later expiry.

Also to note is that the last_derivation_index from the cache needs to be synced.

Maybe it's best to add this as a task of the real-time sync tracking issue

[ok300]

Looks good.

The only remaining NIT is the question related to real-time sync, but IMO it can be handled separaately if necessary.