Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DRAFT] channeld: allow fundee dip into funder reserves, once. #3501

Conversation

rustyrussell
Copy link
Contributor

This is an alternative to #3500, but it requires acks from the other implementations before I'd consider releasing it into the wild.

The spec does NOT prohibit the fundee from adding an HTLC if the funder can't afford the fee, (due to races, it cannot!) though implementations try to avoid it. We do too, but this code skips that check if this is the only HTLC we're adding, so we don't get stuck.

Not sure how other implementations will respond to this, so waiting for discussion around lightning/bolts#728

This is inspired by @m-schmook's ElementsProject#3498
except this is simply a two-channel version which probes for the amount.

Signed-off-by: Rusty Russell <[email protected]>
Extract out num_untrimmed_htlcs() from inside fee_for_htlcs(), and
remove unused view arg.

Signed-off-by: Rusty Russell <[email protected]>
… reserves.

We try not to push them into HTLCs they can't pay for without hitting
their reserve, but allowing a single one through avoid channel lockup
(without requiring them to keep additional reserves).

Signed-off-by: Rusty Russell <[email protected]>
@m-schmoock
Copy link
Collaborator

m-schmoock commented Feb 12, 2020

I think this will be a much cleaner solution, as it does not add iffy fee-based magic number margins that are not 100% reliable.

@ZmnSCPxj
Copy link
Collaborator

Let us consider the case where the channel is small enough that the fee for a single HTLC is a substantial fraction of the reserve.

In that case, the funds of the funder after the HTLC is instantiated might end up below the dust threshold, and the funder, in the latest commitment transaction(s), has 0 funds.

The funder might now costlessly steal by publishing old state; even if punished, it has no fees in the channel anyway.

Now, we might consider that the funder, if it were to fulfill or fail the HTLC, would be able to recover the fee in a future state anyway. So it is not accurate to say it has absolutely 0 funds --- it is simply that the funds it has are now reserved for onchain fees in case the latest commitment transaction is dropped onchain.

The problem is when the fundee that offered the HTLC then goes offline with the HTLC not resolved either way. In that case, the funder now has a temptation-to-cheat. The fact that the fundee went offline is as well evidence that increases the funder estimate that the fundee might not ever come online again.

So I am wary of dipping into the funder reserves for this, unless we have a check that it does not in fact cause the funder output to go below the dust threshold.

@rustyrussell
Copy link
Contributor Author

Spec consensus was for the other solution, so closing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants