Support for hacking...

[rustyrussell]

@ZmnSCPxj @practicalswift @jb55 have all been making serious contributions, and I wanted to make sure you had information and support you need.

@cdecker and I are happy to do a regular IRC/Slack/hangout if you want, just to discuss specific issues or general ideas and directions. I realize that @ZmnSCPxj probably doesn't pass the Turing test, though?

Other option is to simply ask questions here and I'll try to type answers here or on the source code.

[ZmnSCPxj]

A rough guide to the daemons would be nice. It seems a peer connection has one of gossipd, openingd, or channeld handling it at any one time. I am uncertain what exactly closingd and onchaind do (other than go read the code).

I think I have seen mentioned that secret keys get passed around when in principle all secrets should be in hsmd, can you expand on that?

[jb55]

Other option is to simply ask questions here and I'll try to type answers here or on the source code.

I'm not sure if these exist or if there are any plans for these, but here are some of the things I found myself wanting while using c-lightning: 1) Tools/commands for introspecting the current state of channels Right now if a channel gets stuck or switches to a state, it would be great if it showed the related transaction id and other diagnostic information. More onchain information in general would be useful in most of the commands. 2) More insight into onchain transactions Relating to the first point, I would also like to see a list of all my current active, onchain funding and closing transactions. I would also like to see unilateral transaction ids, cheating transactions ids, etc. afaict there is nowhere to see this information for the RPC? Hacking wise, I have found the codebase quite nice to read and understand! Things are slowly starting to make sense, I'll make sure to pop any questions in here when I am confused.

[ZmnSCPxj]

Another question, this time regarding the c-lightning project on github: There are two active milestones, v0.6 and v0.6.1. When looking through issues I prioritize as below:

1. v0.6
2. v0.6.1
3. no milestone specified

Is this correct? Is that what everyone else follows? My idea is that v0.6 will be next release, which is why issues with that milestone should be prioritized.

[cdecker]

A rough guide to the daemons would be nice. It seems a peer connection has one of gossipd, openingd, or channeld handling it at any one time. I am uncertain what exactly closingd and onchaind do (other than go read the code).

closingd and onchaind are used for collaborative and unilateral close respectively, so you'll only see them during a breach or very briefly during the close.

I think I have seen mentioned that secret keys get passed around when in principle all secrets should be in hsmd, can you expand on that?

Ideally every secret that may spend funds is kept only in hsmd, we currently keep some keys in the respective daemons, just to make it easier for now. We will eventually migrate them to be only in hsmd.

Is this correct? Is that what everyone else follows? My idea is that v0.6 will be next release, which is why issues with that milestone should be prioritized.

That's right, the last pre-spec release was 0.5.2, and we're trying to get 0.6 out the door eventually, so we're trying to assign all critical issues to that milestone. Everything else ends up with 0.6.1 or later.

[cdecker]

BTW @rustyrussell I like your choice of the gossip tag for this discussion xD

[jb55]

I'm also interested in how routing currently works. What's the current state and what's planned.

• lnd has autopilot, is that something we want in clightning or would that be a higher level feature?

• Is onion routing working right now? If so how do I test it?

• How are routing fees determined? I have been hearing from lnd people that clightning sets really high routing fees compared to lnd, is there a way to configure those?

Thanks!

[ZmnSCPxj]

lnd has autopilot, is that something we want in clightning or would that be a higher level feature?

I believe it is indeed so planned to have. Personally I think it would be better as a higher-level feature for a separate program that controls c-lightning, but well. However this is not yet here.

Is onion routing working right now? If so how do I test it?

Do you mean using onion construction for payment routing? If so yes, the standard specifies this and if payment routing already works at all then indeed onion construction for payment routing works (since that is what is used, there is no other way to route payments).

Do you mean using a node as a TOR hidden service? If so no, but the spec allows nodes to be TOR hidden services so should be implemented at some point.

How are routing fees determined? I have been hearing from lnd people that clightning sets really high routing fees compared to lnd, is there a way to configure those?

--fee-base and --fee-per-satoshi.

[jb55]

Great! Thanks ZmnSCPxj.

[rustyrussell]

OK, so with lguest I did a very simple literate programming thing, where you could extract the comments and the code into a kind of code tour. This works well when the codebase isn't constantly in flux, and maybe one day we'll get there.

But meanwhile, I'll try to write up a nice summary at the top of each daemon at least.

[Saibato]

as regards to tor I already run and use main and testnet LN with hidden services for LN and the nodes in Tor (Tor(tor(... )))) with a modified version of this cruft i need some time for testing the test yesterday on mainnet I folowed from inside outside and I have the same problems. With frees and get the blocks mined.
Maybe hidden services work better with LNC than BTC I think about a kind of insurence swaps if thing go wrong. But fast execution as in early btc times is essential.but I dont like big block coins as they provide some realy mean ways of fraud.

[ZmnSCPxj]

Rant: There is a struct peer on lightningd/peer_control.h, and a different struct peer on gossipd/gossip.c!

p.s. and yet another struct peer on channeld/channel.c!!

[jb55]

btw I have not disappeared, but am working on a new property-based test suite for c-lightning. My goal is to have it randomly generate minimal-failing black box tests. Might take a couple weeks to get it working...