Once we have revealed our preimage to the world with a sweep attempt,
we can safely push our preimage to the server to speed up on chain
claim.
Rather than rely on the server, we use the state of our invoice in lnd
to determine whether we should continue trying to push the preimage to
the server.
This commit extends SwapResponse and SwapStatus with np2wsh and p2wsh
htlc output addresses to support both nested and native segwit htlcs
in loop-in.
Furthermore the commit adds support for native segwith loop-in htlcs.
When the htlc is paid internally, as of this commit we'll use NP2WSH,
otherwise users are free to select whether to pay the NP2WSH or the
P2WSH htlc.
This addresses an issue where using a sweep confirmation target greater
than the default would result in most cases not revealing the preimage
due to the default confirmation target yielding a higher fee than the
max miner fee backed by the confirmation target provided.
This commit fixes a possible exploit by the loop server, where
- in a loop out - the server could claim money off-chain, without
publishing an on-chain swap htlc.
The server could do this by responding with a regular invoice, whose hash
is different than the hash in the NewLoopOutSwap request. To prevent
the exploit, we validate that the hash of the swap invoice is equal to the
hash the client generated.
In this commit, we introduce a delta from the on-chain HTLC's
expiration. Since clients are now able to specify a confirmation target
for the HTLC sweep, it's possible that the sweep doesn't confirm within
the intended target in the event of an increasing demand for block
space. Once the delta from the HTLC's expiration is reached, we'll begin
to use the default sweep confirmation target when sweeping the HTLC,
which should provide a timely confirmation. This is needed because if
the preimage has already been revealed, then we need to make sure we
sweep the HTLC before the server does.
This commit adds the required code to persist loop in swaps. It also
introduces the file loop.go to which shared code is moved.
Sharing of contract serialization/deserialization code has been
reverted. The prepay fields do not apply to loop in, but were part of
the shared contract struct. Without also adding a migration, it wouldn't
be possible to keep the shared code.
In general it is probably more flexible to keep the contract
serialization code separated between in and out swaps.
