ElementsProject / lightning

Core Lightning — Lightning Network implementation focusing on spec compliance and performance
Other
2.84k stars 901 forks source link

Support for hacking... #2665

Closed ZmnSCPxj closed 4 years ago

ZmnSCPxj commented 5 years ago

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

darosior commented 5 years ago

Thanks for that; is there a way to quiet the deprecation warnings when running tests ?

ZmnSCPxj commented 5 years ago

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.

darosior commented 5 years ago

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

jdabs commented 5 years ago

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

ZmnSCPxj commented 5 years ago

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

trueptolemy commented 5 years ago

@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...

ZmnSCPxj commented 5 years ago

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".

darosior commented 5 years ago

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 ?..