Lightning: 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...

[practicalswift]

@jb55 Excellent news! Sounds very interesting!

[ZmnSCPxj]

Would just like to share, that if you are comparing two struct short_channel_id, you should use short_channel_id_eq and not the generic structeq.

This is because struct short_channel_id uses bit-widths for its members and it is likely on most architectures that the structure will not be able to align the members properly, leading to putting padding. For reference, structeq does not work if the structure has any padding.

[jb55]

Unfortunately I can't continue working on the testing project since I quit my job into a bear market. I was hoping to coast on my Bitcoin savings for awhile but I can't really do that anymore due to market conditions (mortgage to pay, kids to feed, etc :[ ). Good luck guys!

[ZmnSCPxj]

@jb55 can you at least provide the repo for the property-based test? I would like to take a look at it as I suspect c-lightning is insufficiently tested (the past week, my larger pull requests ran afoul of about 3 bugs each while testing). I hope it is Haskell-based?

(you have 403 repositories, so it is a little hard to figure out which one it is)

[Saibato]

@ZmnSCPxj asgard ?
@jb55 its guys like you that make some difference and from time to time im sure you will have the torch its often dark and foggy in asgard but someone has to have the light
Maybe you know now why we old zeros keep such a low profile. The problem with testing you figured exactly out.
Had a lot of fun at sticker day good luck young yedi
Keep the hsm from the 18 I will try to use your funding addr for donations were ever I can .
And if you have figured out mimbelwimbel do as we do HODL

[practicalswift]

@jb55 Thanks for your contributions so far! I hope you'll get paid for Lightning work in some form during 2018! That would be awesome for Lightning.

I would imagine the demand for Lightning competence will far outweigh the supply during the coming months!

[jb55]

"ZmnSCPxj, ZmnSCPxj jxPCSmnZ" [e-mail] writes:

@jb55 can you at least provide the repo for the property-based test? I
would like to take a look at it as I suspect c-lightning is
insufficiently tested (the past week, my larger pull requests ran
afoul of about 3 bugs each while testing). I hope it is Haskell-based?

I only got as far as to re-implement some of the python test stuff, such
as the bitcoind/lightningd runner and RPC:

https://github.com/jb55/asgard/tree/master/src/Test

https://github.com/jb55/asgard/blob/e83565994a1bd225bf90731e974957cd3fac9e27/src/Test/Lightning.hs#L147

I was going to use the Hedgehog for the proprety based tests, which is
similar to QuickCheck except they have an experimental mode for testing
state machines. I was still learning that and only just started:

https://github.com/jb55/asgard/blob/master/src/Test/Tornado.hs

So there isn't much there yet :(

[cdecker]

@jb55 sorry to see you go, but this isn't goodbye, thanks for all of your great contributions so far, and I really hope to see you soon again.

[practicalswift]

Echoing @cdecker – hope to see you soon again @jb55!

[practicalswift]

@jb55 Did you see that Coinbase are looking for developers to fund for full-time work on open source projects in the crypto currency space? Lightning was mentioned specifically IIRC.

[jBarz]

I have been learning about lightning the past few weeks and would like to contribute. If there are issues that a beginner could look at, I would be glad to help out :-)

[ZmnSCPxj]

@jBarz #718 #711 #636 #590

[icota]

Do we use the bitcoin daemon only to monitor the blockchain, send tx, estimate fees, etc.? No funny business with wallets? I ask cause I have a working setup where c-lightning connects to a full node over the internet and want to know how exactly risky this is. Thanks!

[ZmnSCPxj]

Yes, although we also use it to tell us if our coins are getting spent and so on. This means we tell the bitcoind our addresses and UTXOs (so it can monitor them for us), a privacy leak if you do not own the full node or if someone else could be snooping on your RPC channel to bitcoind. Private keys to those addresses are held completely by c-lightning.

[cdecker]

As a small side project I have started jotting down some of the things that may be interesting for new hackers in the sphinx-doc branch (not related to the onion routing protocol :wink:) It autogenerates the webpage at http://lightning.readthedocs.io/ which I hope will become the one-stop-shop for new developers and eventually host the user docs as well. Currently keeping it on a separate branch, merging it once we have enough material :-)

Any contributions are welcome :smiley:

[icota]

I have a somewhat theoretical question. I'm dogfooding c-lightning on Android which got me thinking of some scenarios where mobile nodes might communicate directly via NFC (or wifi, infrared, smoke signals, you get the point):

1. Two offline nodes already have a funded channel between them. Couldn't they just exchange the payment hash and preimage?

2. Say one node is always online and the other is currently not - but the latter knows the network topography. Couldn't the offline node force-route through the online one provided it presents its id? I'm looking at getroute's {fromid} option.

What am I missing? :smiley:

[ZmnSCPxj]

Two offline nodes already have a funded channel between them. Couldn't they just exchange the payment hash and preimage?

Maybe you could try running the protocol on top of NFC (or wifi, infrared, smoke signals, you get the point)? You can run the protocol on top of any TCP-like bidirectional byte stream.

Say one node is always online and the other is currently not - but the latter knows the network topography. Couldn't the offline node force-route through the online one provided it presents its id? I'm looking at getroute's {fromid} option.

The {fromid} option of getroute might return a path to a node you do not want to pass through. Suppose the online node is A, the offline node (that is paying) is B, and there is another online node C that B cannot access via smoke signals right now, and a final online node D that is the payee. And we have a topology:

A <--> B
^      ^
|      |
v      v 
D <--> C

getroute given a {fromid} of node A (the online node that the offline node B has smoke-signal protocol to) can validly return the route A->B->C->D (not likely of course, but imagine if the A<->D channel was ridiculously expensive). I suspect a missing part of getroute is a {avoidnode} argument, an arrray of nodes to avoid routing through.

[icota]

Thanks @ZmnSCPxj! I guess it didn't occur to me to simply run the protocol on top of smoke signals because I saw being offline as a temporary state as opposed to the connected state where we know the "global" topography.

In a practical scenario where node B temporarily has only a smoke signal connection to an online node A what exactly happens? Do we still retain the full topography or do we rebuild according to our new circumstances, via the only node we're connected to? The latter seems expensive if it's only temporary.

[ZmnSCPxj]

Assuming you somehow make the smoke signal connection "seamless" to the node (i.e. the node is unaware it is using smoke signals rather than normal TCP/IP, all it sees is a bidirectional byte stream) then there is no change in topography. The node may find itself unable to communicate with other nodes it has a channel to, but that is handled by pay retrying routes that fail (if routing goes through those nodes it will fail due to first peer not being ready, mark them as temporarily unuseable, and then proceed to try other routes; eventually it will find the node connected by smoke-signals and run the protocol over that). Assuming you have a "seamless" TCP/IP to smoke signals bridge, you can keep using normal pay RPC.

[icota]

That is awesome! So in that scenario I guess it would make sense for the offline node to {avoidnode} itself and {fromid} the online one. This way we avoid the retries and we can get the payment out quicker, hopefully just "tap" our phone like people do with cards nowadays. :credit_card:

[cdecker]

The transport layer is completely exchangeable, and we could for example use mail or SMS to communicate between two peers :-)

[jb55]

Hey ZmnSCPxj, Rusty:

I was looking at structeq.h today and I remembered this note from ZmnSCPxj:

"ZmnSCPxj, ZmnSCPxj jxPCSmnZ" [e-mail] writes:

Would just like to share, that if you are comparing two struct short_channel_id, you should use short_channel_id_eq and not the
generic structeq.

This is because struct short_channel_id uses bit-widths for its
members and it is likely on most architectures that the structure will
not be able to align the members properly, leading to putting padding.
For reference, structeq does not work if the structure has any padding.

I was looking at structeq.h[1] and I saw this comment:

• structeq - are two structures bitwise equal (including padding!)
• @a: a pointer to a structure
• @b: a pointer to a structure of the same type.
  *
• If you know a structure has no padding, you can memcmp them. At
• least this way, the compiler will issue a warning if the structs are
• different types!

According to this, structeq should work with padded structures. Is this
wrong or is there something else going on?

[1] https://github.com/rustyrussell/ccan/blob/ac8694de3ef34483ce02811c1ba45096ee547a5f/ccan/structeq/structeq.h#L7

[rustyrussell]

@jb55 The routine does compare padding, which is a problem because it's usually undefined: it should skip it when comparing.

This made me revisit the rewrite, see #1661

[jb55]

It does compare padding, which is a problem because it's usually undefined.

Ah that's the part I was missing. This makes sense. An alternative to
complex struct equality macros would be to ensure that all structs are
memset to 0 when initialized? Not sure if that's any easier though.

Thanks!

[cdecker]

An alternative to complex struct equality macros would be to ensure that all structs are memset to 0 when initialized? Not sure if that's any easier though.

It would be easier (talz does exactly that) but then we lose the uninitialized warnings from valgrid.

[jb55]

Good morning jb55,

Welcome back to c-lightning development....

On July 4, 2018 12:34 AM, William Casarin [e-mail] wrote:

Hey ZmnSCPxj, Rusty:

I was looking at structeq.h today and I remembered this note from ZmnSCPxj:

"ZmnSCPxj, ZmnSCPxj jxPCSmnZ" [email protected] writes:

Would just like to share, that if you are comparing two struct short_channel_id, you should use short_channel_id_eq and not the

generic structeq.

This is because struct short_channel_id uses bit-widths for its

members and it is likely on most architectures that the structure will

not be able to align the members properly, leading to putting padding.

For reference, structeq does not work if the structure has any padding.

I was looking at structeq.h[1] and I saw this comment:

• structeq - are two structures bitwise equal (including padding!)
• @a: a pointer to a structure
• @b: a pointer to a structure of the same type.
• 
  
  
  
  • If you know a structure has no padding, you can memcmp them. At
  
  
• least this way, the compiler will issue a warning if the structs are
• different types!

According to this, structeq should work with padded structures. Is this

wrong or is there something else going on?

[1] https://github.com/rustyrussell/ccan/blob/ac8694de3ef34483ce02811c1ba45096ee547a5f/ccan/structeq/structeq.h#L7

It compares them "including padding", meaning differences in padding become significant.

Semantically, the data in the padding can be garbage, i.e. proper structure equality is equality of its fields, and not in the padding between fields.

Padding could be garbage if for example you used some memory packed/unpadded, loaded it with random data, then freed it. Then you allocate a padded structure and the allocator gave you the previous memory block. You write to the fields of the padded structure but the padding will contain the garbage from its previous life.

Thus, when "including padding", it is no longer semantically-correct structure equality (which is what nabbed me that time).

Probably better to be clear in the comments that "(including padding! this means your structures must be unpadded (which can be target- or compiler-dependent) or contain only a single POD or array of POD or else strange behavior will occur)"

Regards,
ZmnSCPxj