We update to the latest lndclient that now requires a label when
publishing an on-chain transaction. Instead of just adding an empty
string, we use the proper labels added in a previous commit.
Previously labels with reserved prefixes were added to provide us
with a way to identify automatically dispatched loops. This commit moves
the validation of these labels to the rpc level so that it will only
apply to user-initiated swaps.
This commit bumps the current protocol version and integrates htlc v2
with loop in/out for new swaps, while keeping htlc v1 for any pending
swaps with previous protocol versions.
To allow users to specify differing confirmation targets, we store the
swap conf target per-swap. This makes us restart safe, so we do not
forget confirmation values for swaps that are in flight when we restart.
This commits adds an optional label to our swaps, and writes it to
disk under a separate key in our swap bucket. This approach is chosen
rather than an on-the-fly addition to our existing swap contract field
so that we do not need to deal with EOF checking in the future. To allow
creation of unique internal labels, we add a reserved prefix which can
be used by the daemon to set labels that are distinct from client set
ones.
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.
