Explicitly specifying fwdinghistory start_time of 0 causes lnd to use start_time of -24h #3357
Comments
|
I'll start on the fix for this; I'll start with option A as I outlined above. |
tyzbit
added a commit
to tyzbit/lnd
that referenced
this issue
Jul 31, 2019
Fixes lightningnetwork#3357. When start_time isn't specified, its default value is 0. This meant when users explicitly specified a start_time of 0, we would incorrectly set start_time to 24 hours in the past. Now, n0 means n0.
tyzbit
added a commit
to tyzbit/lnd
that referenced
this issue
Jul 31, 2019
Fixes lightningnetwork#3357. When start_time isn't specified, its default value is 0. This meant when users explicitly specified a start_time of 0, we would incorrectly set start_time to 24 hours in the past. Now, n0 means n0.
tyzbit
added a commit
to tyzbit/lnd
that referenced
this issue
Jul 31, 2019
Fixes lightningnetwork#3357. When start_time isn't specified, its default value is 0. This meant when users explicitly specified a start_time of 0, we would incorrectly set start_time to 24 hours in the past. Now, n0 means n0.
tyzbit
added a commit
to tyzbit/lnd
that referenced
this issue
Jul 31, 2019
Fixes lightningnetwork#3357. When start_time isn't specified, its default value is 0. This meant when users explicitly specified a start_time of 0, we would incorrectly set start_time to 24 hours in the past. Now, n0 means n0.
tyzbit
added a commit
to tyzbit/lnd
that referenced
this issue
Jul 31, 2019
Fixes lightningnetwork#3357. When start_time isn't specified, its default value is 0. This meant when users explicitly specified a start_time of 0, we would incorrectly set start_time to 24 hours in the past. Now, n0 means n0.
13 tasks
Closed
PierreRochard
added a commit
to PierreRochard/lndash
that referenced
this issue
Sep 2, 2019
tyzbit
added a commit
to tyzbit/lnd
that referenced
this issue
Oct 3, 2019
Fixes lightningnetwork#3357. When start_time isn't specified, its default value is 0. This meant when users explicitly specified a start_time of 0, we would incorrectly set start_time to 24 hours in the past. Now, n0 means n0.
matheusd
pushed a commit
to matheusd/dcrlnd
that referenced
this issue
Oct 15, 2019
Fixes lightningnetwork#3357. When start_time isn't specified, its default value is 0. This meant when users explicitly specified a start_time of 0, we would incorrectly set start_time to 24 hours in the past. Now, n0 means n0.
matheusd
pushed a commit
to matheusd/dcrlnd
that referenced
this issue
Oct 16, 2019
Fixes lightningnetwork#3357. When start_time isn't specified, its default value is 0. This meant when users explicitly specified a start_time of 0, we would incorrectly set start_time to 24 hours in the past. Now, n0 means n0.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
Caused by #3246 馃槉
When explicitly specifying
--start_time=0, instead of looking for forwarding events since the Unix epoch, LND sets the start time to -24h:https://github.com/lightningnetwork/lnd/blob/master/rpcserver.go#L4641-L4643
Some options:
A. Make 0 always mean the unix epoch, whether intentionally set or not.
B. Make no change, inform users not to use 0 for start_times, instead use 1.
I like option A, but open to discussion
Your environment
lnd- v0.7.1-betauname -aon *Nix) Linuxbtcd,bitcoind, or other backend bitcoind 0.18.0Steps to reproduce
lncli fwdinghistory --start_time=0Expected behaviour
Shows forwarding history since the unix epoch.
Actual behaviour
Shows forwarding history since 24 hours ago.
The text was updated successfully, but these errors were encountered: