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

Update funding timeout fundee #1692

Merged
merged 3 commits into from
Feb 19, 2021
Merged

Update funding timeout fundee #1692

merged 3 commits into from
Feb 19, 2021

Conversation

t-bast
Copy link
Member

@t-bast t-bast commented Feb 17, 2021

Our previous timeout was based on timestamps, mostly because blockCount could be 0 on mobile using Electrum until a new block was received. Now that we're diverging from the mobile wallet codebase, we can use block heights instead which is more accurate.

See lightning/bolts#839

I've done some E2E tests on regtest for the "migration" code. There is one edge case where a channel in WAIT_FOR_FUNDING_CONFIRMED will not be automatically cleaned up: if the peer never connects back to you, the channel will stay in OFFLINE and won't check for funding timeout. I think this edge case is quite harmless and can be ignored (I don't think it's worth adding more code to fix it).

@t-bast t-bast requested a review from pm47 February 17, 2021 10:09
Our previous timeout was based on timestamps, mostly because blockCount
could be 0 on mobile using Electrum until a new block was received.
Now that we're diverging from the mobile wallet codebase, we can use block
heights instead which is more accurate.

See lightning/bolts#839
goto(OFFLINE) using data
if (funding.waitingSinceBlock > 1500000) {
// we were using timestamps instead of block heights when the channel was created: we reset it to use block heights
goto(OFFLINE) using funding.copy(waitingSinceBlock = nodeParams.currentBlockHeight)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't update the db we'll push back forever:

Suggested change
goto(OFFLINE) using funding.copy(waitingSinceBlock = nodeParams.currentBlockHeight)
goto(OFFLINE) using funding.copy(waitingSinceBlock = nodeParams.currentBlockHeight) storing()

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 4019b66

@pm47
Copy link
Member

pm47 commented Feb 19, 2021

Related: #723

@@ -335,7 +335,7 @@ class ChannelCodecsSpec extends AnyFunSuite {
// let's decode the old data (this will use the old codec that provides default values for new fields)
val data_new = stateDataCodec.decode(bin_old.toBitVector).require.value
assert(data_new.asInstanceOf[DATA_WAIT_FOR_FUNDING_CONFIRMED].fundingTx === None)
assert(System.currentTimeMillis.milliseconds.toSeconds - data_new.asInstanceOf[DATA_WAIT_FOR_FUNDING_CONFIRMED].waitingSince < 3600) // we just set this timestamp to current time
assert(System.currentTimeMillis.milliseconds.toSeconds - data_new.asInstanceOf[DATA_WAIT_FOR_FUNDING_CONFIRMED].waitingSinceBlock < 3600) // we just set this timestamp to current time
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comparison still valid ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will still do that "trick" for upgrades from old eclair nodes, but it will then be changed again in Channel.scala to use a block height. I thought about directly using currentBlockHeight in the legacy codec, but it requires changing a val to a def to pipe the blockCount which was messy...

@pm47
Copy link
Member

pm47 commented Feb 19, 2021

How about, the following backward compatibility code? I think we can leave it like that (since this happens before the channel restore, where you handle the timestamp->blockheight migration).

("waitingSince" | provide(System.currentTimeMillis.milliseconds.toSeconds)) ::

("waitingSince" | provide(System.currentTimeMillis.milliseconds.toSeconds)) ::

@t-bast
Copy link
Member Author

t-bast commented Feb 19, 2021

How about, the following backward compatibility code? I think we can leave it like that (since this happens before the channel restore, where you handle the timestamp->blockheight migration).

I agree, this is related to #1692 (comment) and I think we can leave it like that.

@t-bast t-bast merged commit 0835150 into master Feb 19, 2021
@t-bast t-bast deleted the funding-expiry branch February 19, 2021 13:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants