Takeaways from the Lightning Hackday in NYC

New York City – at the cutting edge of innovation! Not at the New York Stock Exchange – but right next to it, in an ad hoc hackerspace dedicated to the Lightning Network. The place where crypto magic happened! We joined a bunch of reckless geeks working on a P2P payment processing revolution.

This is the technical part of a 2 part series. Read part 1 if you are looking for a lighter read.

Note: This is not an introduction to the workings of the Lightning Network but a rather advanced and technical post. If you would like to learn about the basics, please check out this website and DYOR.

Since the release of “The Bitcoin Lightning Network” paper in early 2015, the Lightning Network has been hailed as a solution that could finally bring sustainable scalability to Blockchains which are often described as hard to scale. The community around this “second layer” for cryptocurrencies has been growing at an astonishing pace, particularly after the fee crisis in late 2017, when the urgent need for a higher Bitcoin transaction throughput became evident. The Puzzle ITC Lightning team joined the 4th Lightning Hackday in NYC to mingle with the core of this very community.

Read on, fellow Lightning pioneer, and relive this geeky Hackday with me! In this Blogpost, I write mostly about the insights I gathered from talking to people in the Lightning community. It’s worth it to share these fascinating topics because they could be helpful to other developers, too.

Learn more about some of the promising projects and savvy ideas happening at the cutting edge of innovation. ⚡

A Brief Overview of the Talks

In addition to the presentation our team gave about Java PoS (you can watch our video here), there were a number of other Hackday speakers. All the talks were interesting, but here’s a list of my favorites in case you don’t find the time to watch them all:

You can watch all of the talks here: day 1, day 2. If you need even more Lightning stuff, I’d recommend the videos from Chaincode Labs’ Lightning Residency which also took place in NYC right before the Hackday.

Insight #1: Creating inbound channel capacity

At the moment, the Lightning Network only allows for single-funded channels. That is, if you want to create a channel, you have to pay the whole channel yourself. Once established, all the funds will be on your side of the channel. In other words, you will only be able to spend money over the Lightning Network, but you can’t receive any money as long as no other node is willing to open a channel with you and thus give you inbound capacity. This is a rather annoying situation if you want to create a shop since a shop mainly needs to be inbound capacity, right? Luckily, both-sided channels is one of the hottest topics in the LN protocols development and are probably soon to come. Until then, do we have other options than to wait for somebody to finally open a channel with us? Well, that’s what I discussed with Alex Bosworth.

Here’s what you can do: On zigzag.io you can send a Bitcoin over the Lightning Network and receive it back as an on-chain payment. It’s that easy. You now have inbound capacity.

Note: This is a custodial solution –> you have to trust zigzag.io that they will actually send you money back. With Submarine Swaps you can essentially do the same thing but in an atomic way. This way, either both transactions go through or none of them. No trust needed. … Ya gotta love that good ol‘ crypto magic!!

Insight #2: Tor bitcoind, Tor LND, Tor everything!

Privacy is a basic security necessity for Lightning nodes. After all, what your node is broadcasting to the whole world sounds something like this: “Hey there! I am storing X Bitcoin right here [IP Address]! And you know what? I plan to leave that money here for a long time. If I weren’t, why would I have locked it in in the first place! So, take all the time you need coming up with a sophisticated attack. Once you’re set, just come here and pull it off. You know where you can find me (and my Bitcoin)!”

No need to point out that this is dangerous. Tor can help you at least obfuscate the where. With Tor, the message your node broadcasts sounds more like, “I am storing X Bitcoin for a long time, but I’m not going to tell you either where I store it or who I am!
So, I recommend you use Tor for both your Bitcoin as well as your Lightning node. Note: There is no such thing as perfect privacy. With Tor you may enhance your privacy but it is far from perfect. Furthermore, your real identity could be uncovered on other levels too. For example, through Blockchain analysis.
Let me elaborate on the pros and cons that come with running your node over Tor:

  • Enhanced privacy (as already stated above)
  • NAT punching. You run your node behind a router on which you cannot implement port forwarding and probably even behind a firewall that blocks all inbound connections? Tor will help you to circumvent both of these issues.
  • Dynamic IP addresses. They’re evil. Your nodes should have a static IP address to run smoothly. If your ISP wants to charge you extra for this, however, you might want to use Tor. It will run your node as hidden services and attribute a static .onion address to them.


  • Network latency increases massively (more crucial for Lightning node than for Bitcoin node)

There’s another annoying drawback to using Tor for Lightning nodes: Non-Tor nodes cannot establish connections with your node. In other words, you have to establish all the connections to these nodes. Once the connection is established, however, the connected node could open channels with your node by themselves.
I learned from Christian Decker that you can even run SSH over Tor. After he told me this, I got it running on my RaspiBolt. With this trick, I have now shutdown all the inbound connections to my RaspiBolt. Even though it sits behind a NAT and has a dynamic IP address, I can SSH to it from anywhere in the world. It also runs both bitcoind and LND seamlessly.

Insight #3: Running a Lightning enabled Point of Sale offline

That’s right! You can run a Lightning enabled shop without it having any connection to the Lightning Network whatsoever! But how in the world … ?!

Let’s take a step back and talk Bitcoin first. Bitcoin offers this neat feature (standardized in BIP32) that allows for so-called extended public keys. What it essentially allows us to do is derive public keys in a deterministic way from a given ext. pubKey. While the public keys may be derived from a computer A, you may have the corresponding extended private key on a computer B, which can be used to derive all the corresponding private keys even if computer A and computer B are completely isolated from each other.

In other words, computer A could generate all your Bitcoin addresses, but it could not create any corresponding privKeys and thus not spend any of the received Bitcoin. This feature can come in handy as a protection for your private keys. Let’s say you run a web shop. You could generate all your Bitcoin addresses in that web shop while generating all the corresponding private keys on a separate, offline computer. So, if somebody were to break into your web shop, they could still not steal your Bitcoin because there are no privKeys to be found.

Now, back to Lightning. I learned from René Pickhardt how you can pull off a similar trick on Lightning. In Lightning, if Alice wants to pay Bob, Bob will have to create a (usually randomly generated) secret that we will henceforth call preimage. He will then hash this preimage and send it to Alice. The inner working of the Lightning Network is such that Alice will only learn about the preimage as soon as her payment goes through. The payment is atomic in such a way that if Bob were to withhold the preimage from Alice, the payment would not go through. Conclusion: If Alice knows the preimage, the payment went through.

Here’s the hack: What if we created the preimage in a deterministic way? We could separate the Lightning node from the Point of Sale while creating the exact same invoice (using the same preimage) on both systems. The payment would still be handled by the Lightning node, but the PoS would serve the hashed preimage (i.e. the invoice) to the customer. Afterwards, the PoS could also prove that the payment went through by simply requesting the preimage from the customer.

For the preimage derivation scheme, we propose the use of a reverse hash chain:

Note that with this solution, the Lightning node needs to be aware of each product’s price. If not, an attacker could manipulate the invoice and pay a much smaller price than what actually was demanded from the PoS, yet still receive the preimage thus convincing the PoS that the product is paid.

This can get a little tricky if you have multiple products and the Lightning node does not know which product the customer is paying for. In this case, you could hash some information into the preimage on the PoS. The Lightning node could then later on find out what product the customer chose by trial and error (bruteforce).
Here’s what a solution could look like:

As soon as the lightning node receives a hashed preimage, it would then try to find out what product the customer bought by iterating through the product ids. To make this task easier, you could provide the product id as a payment message. Note that a payment message alone is not failproof since this information could be changed by malicious customers.

We are considering implementing this solution on our PoS for both removing complexity from it and increasing its security. The main sticking point is that with this solution, it is not sufficient to only have information flowing from the PoS to the customer’s device. That information also needs to flow in the opposite direction.

Insight #4: Sending a payment without invoice

René furthermore explained how you could send a payment over the Lightning Network without the need for any invoice at all. If you want to know more about this, check out his video about it.

Please sir, when moon?


As the Bitcoin community and cryptocurrency space is increasingly undermined by greed and get-rich-quick schemes, the Hackerspace provided a two-day retreat from all the noise. We did not once hear anything about the Bitcoin price! Instead, we witnessed people sharing clever ideas and tinkering on solutions with tremendous potential to shape a promising future for mankind.
That being said, I’m sorry, sir. I don’t know when we’ll see lightnings on the moon. But, I’m pretty positive that Earth will get struck by Lightning quite a bit ;-).


If you have any feedbacks, questions or just something about to share about this, please contact me so we can have an exchange.

Kommentare sind geschlossen.