Closed ZmnSCPxj closed 4 years ago
Thanks for that; is there a way to quiet the deprecation warnings when running tests ?
is there a way to quiet the deprecation warnings when running tests ?
Did not #2681 fix?
Sorry, I am not python expert, maybe @cdecker can field this question.
Some of them but some are from the dependencies (cheroot
, jinja2
), they might be resolved soon but until then I wanted to know if there is a way to avoid the endless scroll on pytest error.
EDIT: as of now the last pytest
version fixed most of the DeprecatedWarnings
Is there an official API reference for lightning-cli ? Or is the README on this repo the main one?
The README was helpful and I was able to set up my node easily with it. The main draw back is that it is not great as a full reference doc because it switches between different command lines tools, such as bitcoind, bitcoin-cli, and lightningd
They are in the docs
directory; every docs/lightning-*.txt
file describes a command. If you make install
they should be available as man
pages e.g. man 7 lightning-pay
@ZmnSCPxj Hi, when I study the route, I meet a question.... In this test: https://github.com/ElementsProject/lightning/blob/04a780c7158655ddc7c391c726c4839b55aa8481/tests/test_pay.py#L82-L104
For my understanding, this pay attempt will generate a piece of routehint
, that includes the channel from l2
to l3
?
So why not 3 attempts here?
One for normal attempt, one excluding the channel between l1 and l2, and one with the routehint
?
For this test, I find there are 2 attempts, one is the normal attempt, and another one is exluding the channel from l2 to l3.
So...my question is if there's an error? Because we should exclude channel l1->l2 other than the channel l2->l3?
I find the find_worst_channel
interface in pay
plugin may be wrong, but I'm not sure...
I am uncertain myself --- I have not looked deeply into the pay
plugin very much yet. I will try to check some time "soon", possibly, for some definition of "soon".
I have a question regarding https://github.com/ElementsProject/lightning/pull/3217. I struggled to recover the to_remote
output to me, after an unilateral close from remote and a dataloss from my side, before I notice that it was actually not possible without the first_per_commitment_point
from the other side.
(without option_static_remotekey
)
How comes that we derive the remotepubkey
, for the to_remote
output, from OUR commitment point ? It means that in order to recover a to_remote
output to us we need to know the peer per_commitment_point
(at least the first one) .. Would it not make more sense to derive the remote_pubkey
from the remote's per_commitment_point
?..
The old #614 was already hopelessly buried in page 8 of issues.
So, I remake this thread here.
For those contributing now, if you have any questions about the architecture of
lightningd
and so on, please feel free to post them here.@m-schmoock @darosior @trueptolemy @niftynei @bisoge