In case of sending channel_reestablish message, we join
our current per_commitment_point and their highest revocation
secret we know about
We set data_loss_protect by default and adjust encoding_init
test in consequence
This carries a surprising amount of complexity despite only being
possible in the case where monitor updating failed during the
processing of funding_generated. Specifically, this requires
handling rebroadcasting funding_locked once we successfully persist
our monitor again.
As an alternative we could never send funding_signed when the
monitor failed to persist, but this approach avoids needless
delays during funding.
This avoids a crash where a channel with a duplicate id is created
immediately after another is closed, where the other still has a
pending funding generation event. Resulting in funding generation
being passed to the wrong channel (which isn't in an appropriate
state).
It suggested figuring something else out after #81, but the API we
settled on after #81 (which I think is just fine) doesn't allow for
anything cleaner, so this is fine as-is.
Let these values being used as default ones in UserConfig.
Also, reduce them to something more reasonable, for BREAKDOWN_TIMEOUT
from 1 week to 1 day, for MAX_LOCAL_BREAKDOWN_TIMEOUT from 2 weeks
to 1.
Honestly mostly cause we have progress on simplified_commitment in Core, but also our punishment transaction generation stuff is really coming along nicely.
We were previously using their_to_self_delay to regenerate scripts for
spending remote revoked htlc transactions, and that's a bug.
Their_to_self_delay is delay enforced by peer upon outputs returning
funds back to us.
Our_to_self_delay is delay enforced by us upon outputs returning funds
back to peer.
This simplifies chanmon_fail_consistency greatly and makes it a
tiny bit more realistic. It also sets us up for more
disconnect-relatex events without the complexity blowing up.
This removes the bulk of our reliance on the rand crate in non-test
envs, paving a way towards a syscall-less rust-lightning and WASM.
Since this is a breaking change for full_stack_target (and several
fuzz targets), go ahead and make other changes to make things more
distinct.
They were only used for ensuring generated keys were globally
unique (ie in case the user opened the same seed at a different
time, we need generated keys to be globally unique).
Instead, we let the user specify a time in secs/nanos, and provide
a precise meaning for the user to understand.
We use user config to decide to commit to closing script
in open_channel/accept_channel messages. We don't check
that other peer supporting the option as including
script without other peer public support is borne by
the protocol. If user opt-out, following protocol and
due to the fact we always signal, we provide a zero-length
script
Peer may send us a shutdown_scriptpubkey in open_channel or
accept_channel messages. Before to enforce this policy on channel
closing, we want to be sure that our peer has opt-in to it.
Extend LocalFeatures new method visibilty from crate to public
for fuzz tests
We must adapt our delay between two bumps of claim txn in respect
to the timelock encumbering the targeted outpoint. If HTLC or
revoked output is near to expire, we should try to get our claim
in every block. If it's reasonably in the future, we may give us
more latency to bump
Rename HTLC_FAIL_ANTI_REORG_DELAY to ANTI_REORG_DELAY because
we are going to rely on it also to remove bump candidates outpoint
from tracker after claim get enough depth.
Rename HTLC_FAIL_TIMEOUT_BLOCKS to LATENCY_GRACE_PERIOD_BLOCKS because
it's carrying more meaningfully that we are doing a favor to our
peer instead of ruthlessly enforcing the contract.
CLTV_EXPIRY_DELTA should be > to LATENCY_GRACE_PERIOD_BLOCKS +
+CLTV_CLAIM_BUFFER + ANTI_REORG_DELAY + LATENCY_GRACE_PERIOD_BLOCKS
When we reached height + LATENCY_GRACE_PERIOD_BLOCKS and we have pending
unsolved outbound HTLC, we fail onchain with
our local commitment tx. At this point we expect to get in chain in a
worst-case delay of CLTV_CLAIM_BUFFER. When our HTLC-timeout is
confirmed with ANTI_REORG_DELAY we may safely fail backward the
corresponding inbound output.
