From the Fields of Lightning: Kyiv Bitcoin Lightning Network Meetup

20.05.2016

As ForkLog reported earlier, last week Kyiv hosted Bitcoin Lightning Meetup featuring the Lightning Network team speaking about what their system may give to the cryptocurrency world.

The event took place on May 12 at IDF Reforms Lab under the auspices of BitFury and Distributed Lab, so many thanks go to them.

One of Lightning Network team members, Joseph Poon, commented on the event:

“The Bitcoin community in Kyiv is amazing. It’s a large community of thoughtful people who are making amazing things. I really enjoyed the meetup, it was a pleasure chatting with a group of people who are passionate about Bitcoin’s potential. It’s places like Kiev which have a combination of a high amount of technical knowledge and the developing opportunities which may allow for Bitcoin to have a huge impact,” he said.

The Discussion

Opening the presentation was Pavel Kravchenko of Distributed Lab. He introduced the developers of Lightning Network and spoke about how the meetup became possible:

“I met them in New York, and they said they’re going to Kyiv. I said, that’s super, let’s make a meetup.”

Pavel reminded the meetup’s attendees that it would mostly concern Lightning Network, and offered to ask questions as soon as they arise over the course of the presentation.

During the presentation, the Lightning Network team spoke about the ways their solution may help in bitcoin network scaling, and what opportunities it may provide apart from that. In particular, speaking about bitcoin’s inherent problems, Thaddeus Dryja said:

“People know may be there are problems with bitcoin. The idea of Lightning Network is to make bitcoin faster and more scalable. Actually, you know, many more people can use it. So, we started thinking, ‘ok, many more people can use it’, but also people are interested because you don’t have to wait ten minutes. So, with bitcoin today you make transaction, send money and then you must wait 10 minutes or 20 minutes, or 30 minutes and then it’s confirmed. With this it could be much faster, like one second. It doesn’t go onto the blockchain, only a very small amount of information goes to the blockchain, most information stays between the computers, that send and receive it.”

Dryja also compared blockchain’s throughput capacity to WiFi networks:

“If you know how bitcoin works, it’s every transaction goes to every computer, so if you’re running bitcoin on your computer, if you run bitcoin QT, maybe 70 gigabytes [is needed] for the data. And it goes up million megabytes a few weeks, because every 10 minutes one megabyte of transaction comes up. Bitcoin is kind of if the whole world uses the same wifi access point. You know, if you go to [common space] you see that WiFi is not so good. May be it’s fast wifi and fast Internet, but hundreds of people are trying to use the same WiFi, so everyone’s crowding. It’s important that bitcoin works this way, it’s very important that everyone agrees on how much money everyone has. If we don’t agree it’s not really money.”

The team believes that the need to agree on the amount of money everyone holds may become a reliable solution, which, however, becomes inefficient in terms of speed and general network load in case everyone has to know everything â€” just as if everyone used the same WiFi network. One might certainly increase the network’s throughput capacity by increasing data transfer frequency, but the solution has its own limits as well.

“It’s faster, but maybe two times faster, five times faster. Five times faster is still pretty good, but it’s not a huge difference. You can never have the whole world use bitcoin if you just keep increasing the blocksize. If you have two times as many data, you can have two size as many users and transactions. Usually with the network you want to segment it, sort of chop it up into pieces. So like with the Internet you don’t have all everyone on WiFi, but you plug into different switches and routers,” Dryja further explained.

Essentially, the Lightning Network’s solution is about bitcoin users holding some amounts in bitcoin’s blockchain for a while, writing down their moves, and then seeking for an agreement as to who owes whom and how much. As opposed to Ripple, which implies some trusted nodes, or InstantX, which relies on masternodes, Lightning Network is totally trustless, meaning the system is designed in a way preventing other parties from stealing your funds, and may maintain the system’s security by providing some sort of receipts concerning the overall amount.

“In terms of the difference between Lightning and Ripple’s system, it’s not just about the lack of a trusted node. As I mentioned at the meetup, with Ripple, you’re issuing an entirely different asset, which is not something that LN enables. For example, if I want to issue EUR Ripple assets, I must actually hold the EUR and redeem it back to people, which of course is entirely based on trust. With Ripple, XRP is the only non debt-based asset, and all others require trust in the issuer. LN only ever works using real transactions of a given blockchain (or between chains using real transactions from each),” Lightning Networks’s team member Elizabeth Stark explained to Forklog.

Among the system’s other important features is the option of using microtransactions. This would decrease potential profit for a dishonest counterparty while keeping risks of losing trust the same. The system also incorporates additional features, eg. you have to wait a given amount of time (say, a day or two) after publishing the receipt in the blockchain if the counterparty goes offline, and then you can get your funds back. So, if the counterparty went on vacation in Antarctica to hang out with penguins, their ability to confirm or decline a transaction significantly drops. However, if they’re still available, they will have enough time to challenge the published receipt by publishing another receipt outdating the previous one.

More details on the solution are available in the video footage of the presentation and the Q&A session (courtesy of Mykhaylo Polyakh):