Support for hacking...

[ZmnSCPxj]

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]

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

[ZmnSCPxj]

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]

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]

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]

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]

@ZmnSCPxj Hi, when I study the route, I meet a question....
In this test:

lightning/tests/test_pay.py

Lines 82 to 104 in 04a780c

	def test_pay_limits(node_factory):
	"""Test that we enforce fee max percentage and max delay"""
	l1, l2, l3 = node_factory.line_graph(3, wait_for_announce=True)
	# FIXME: pylightning should define these!
	PAY_ROUTE_TOO_EXPENSIVE = 206
	inv = l3.rpc.invoice("any", "any", 'description')
	# Fee too high.
	with pytest.raises(RpcError, match=r'Route wanted fee of .*msat') as err:
	l1.rpc.call('pay', {'bolt11': inv['bolt11'], 'msatoshi': 100000, 'maxfeepercent': 0.0001, 'exemptfee': 0})
	assert err.value.error['code'] == PAY_ROUTE_TOO_EXPENSIVE
	# It should have retried (once without routehint, too)
	status = l1.rpc.call('paystatus', {'bolt11': inv['bolt11']})['pay'][0]['attempts']
	# Excludes channel, then ignores routehint which includes that, then
	# it excludes other channel.
	assert len(status) == 2
	assert status[0]['strategy'] == "Initial attempt"
	assert status[1]['strategy'].startswith("Excluded expensive channel ")

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]

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]

I have a question regarding #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 ?..