“Но ведь все знают, что небольшая инфляция полезна для экономики, а дефляция приводит к стагнации” — это утверждение настолько распространено, что большинство людей (в том числе экономистов) даже не задумываются над его справедливостью.

Я нисколько не претендую на звание эксперта в этой области, но считаю что стоит как минимум знать о существовании альтернативной точки зрения на этот вопрос.

Определение

Итак, инфляция — это когда цены на товары и услуги увеличиваются, дефляция — когда уменьшаются.

Сильно упрощая, в большинстве случаев инфляция и дефляция напрямую связаны с монетарной политикой центральных банков. Еще сильнее упрощая, они связаны с тем, насколько активно центральный банк печатает новые деньги.

Интересный факт #1. Раньше инфляция и дефляция напрямую определялись как увеличение/уменьшение общего количества денег в циркуляции. Но банковская система настолько усложнилась (гуглите “fractional reserve”), что эмиссию денег теперь оценить точно практически невозможно.

Традиционный взгляд

Традиционная Кейнсианская школа экономики придерживается взгляда, что небольшая инфляция необходима для экономики.

Растущие цены приводят к тому, что людям и корпорациям выгоднее не хранить свои деньги, а тратить и реинвестировать их, стимулируя таким образом спрос. Спрос стимулирует предложение, производство растет, экономическая машина работает.

Если же вдруг случается дефляция, то наступает коллапс экономики. Цены падают, люди тратят меньше денег, производство падает, безработица растет, цены падают еще сильнее, и так далее.

В качестве примеров негативного влияние дефляции обычно приводят Великую депрессию США в 1930-е годы и дефляционную спираль Японии в 1990-е годы.

Интересный факт #2. По самым осторожным оценкам, за последние 50 лет американский доллар потерял более 85% своей стоимости за счет инфляции.

Альтернативный взгляд

Но существуют еще другие школы экономики, например Австрийская, и они придерживаются других взглядов, которые при ближайшем рассмотрении оказываются вполне разумными.

В частности они утверждают, что уменьшающиеся цены не приводят в общем случае к сильно драматичному уменьшению спроса. Разумеется, люди не перестанут покупать еду и другие обязательные товары. Но они также не перестанут полностью покупать и предметы роскоши.

Например, в технологическом секторе сейчас наблюдается локальная дефляция: новый телефон, который в этом году стоит 1000 долларов, через два года будет стоить 800. При этом люди все равно очень активно покупают новые телефоны.

Но это, конечно, анекдот, а не наука. Что же будет, если погрузиться глубже непосредственно в данные? Оказывается, что в этом случае “типичный” пример Японии выглядит очень даже нетипичным.

Экономисты Atkeson и Kehoe провели исследование периодов дефляции и экономической депрессии в разных странах за последние 180 лет и выяснили, что из 73 периодов дефляции 63 не приводили к снижению экономической активности, а из 29 периодов депрессии 21 приходился на период инфляции, а не дефляции.

Здоровая дефляция

Никто не спорит с тем, что большая дефляция действительно приведет к коллапсу экономики. Последствия будут ничуть не лучше, чем в случае гиперинфляции (кстати наблюдаем намного чаще, чем дефляционную спираль).

Но небольшая дефляция или нулевая инфляция в идеальном случае приведут к вполне вменяемым последствиям, с которыми рыночная экономика должна отлично справиться сама.

— Ценность денег не будет размываться инфляцией, люди и компании смогут сохранять свои заработки.

— Станет сложнее отдавать долги (а следовательно и брать в долг); Те, кто набрал очень много долгов — объявят себя банкротами и уйдут из бизнеса; Многие долги будут рефинансированы на более выгодных условиях.

—Государствам придется функионировать на налоговые деньги, а не на напечатанные; Меньшее количество долгов приведет к более плавному развитию экономики (меньше возможностей для образования пузырей).

Интересный факт #3. В конце семидесятых годов в США была реальная угроза гиперинфляции: государство печатало деньги для стимуляции экономики, но производство только замедлялось. Тогда федеральный резерв США принял ряд мер направленных на достижение дефляции. Было сложно, кратковременно выросла безработица, многие бизнесы разорились, были протесты, но в течении пары лет экономика полностью реабилитировалась.

Кто виноват?

Почему же все центральные банки так старательно избегают дефляции?
 — Во-первых потому, что все государства погрязли в долгах.
 — Во-вторых потому, что печатать деньги проще, чем увеличивать налоги.
 — Во-третьих потому, что монетарные политики все-таки до какой-то степени эффективны для стимулирования (и регулирования) экономики (по крайней мере в краткосрочной перспективе).

По факту все конечно намного сложнее, но говоря очень грубо: с каждым новым напечатанным долларом (евро/рублем/франком) государства все больше загоняют себя в инфляционный тупик, из которого они сами уже не могут выбраться.

А при чем тут собственно биткоин? Он работает вне государств и центральных банков, его нельзя “напечатать”, ему все равно сколько у кого долгов. Биткоин предлагает альтернативу текущей системе.

Критика и комментарии приветствуются! Материал подготовлен для телеграм-канала https://t.me/cryptohodl.

If you want to accept payments through lightning network or to properly balance your channels — your node needs to have sufficient inbound capacity. This article describes what that is and practical ways to get it.

Update(July 2021): three years after it was written, this post is still mostly accurate, but some ways of getting inbound liquidity are missing or outdated. The services I mostly recommend nowadays are: lightning loop, lightning pool, lnbig.com, lightningnetwork.plus, t.me/theRingsOfFire and ln2me.com.

The problem

Payments over Lightning Network (LN) work differently from how on-chain bitcoin transactions work. My previous post describes beautiful cryptographical magic behind LN, below are just few practical points.

• Lightning network consist of two-sided channels, and all the coins are locked in these channels.
• The total amount of bitcoins locked in a channel is called channel capacity.
• The amount on your side of the channel is called local balance. The amount on the side of the peer is called remote balance.
• When you open a new channel — all your balance is local (here we omit dual-funded channels and pushed amount for simplicity).
• The capacity of a channel always stays the same (here we omit splicing for simplicity) and roughly equals to your local balance plus the remote balance (roughly because of commit fees).
• When you pay — the balance flows from your side of the channel to the remote side. When you receive payments — the other way around.

Which brings us to one of the biggest culprits:

In order to receive payments, your node needs to have sufficient inbound capacity: sufficient number of open channels with sufficient remote balance (otherwise the balance cannot flow to your side).

To increase inbound capacity means to somehow get channels with large remote balance. And for small new nodes it can be very-very tricky. And if that is not enough, there is one more aspect to this:

Not all inbound capacity is the same. It can be more useful or less useful. A channel from a well-connected and balanced node will connect your node to hundreds of other nodes. A channel from a new non-public node will not.

Confused about how to get it right? Fear not, there are ways!

Solution 1: Spend

This is the obvious one, but it needs to be said. When you use a channel to spend coins, they are written off the local balance and added to the remote balance. The more you spend — the larger your remote balance, the more inbound capacity you have.

Of course this approach does not solve all the problems for everyone. But if you have a choice to pay via LN — use it and you will have less troubles with incoming payments in the future.

Solution 2: Ask for incoming channels

This is probably the best option for most nodes: if you need inbound capacity — ask for incoming channels. If you are a merchant — ask your clients, if you know someone running a node — ask them.

But by far the easiest way is to use channel opening services. To the best of my knowledge — there are currently only three out there.

1. Thor — a service by a lightning-enabled merchant Bitrefill. They can rent you a private channel with capacities from 0.003 and up to 0.16 BTC, which they promise to keep open for 30 days. Depending on the capacity it will cost you anywhere from a dollar and up to more than 20 bucks (update: the price is much higher nowadays).
2. Y’alls — a service by Alex Bosworth, which allows you to pay less than a dollar for a 0.02 BTC channel (update: the price is much higher nowadays). And while this may seem cheaper than Bitrefill, beware that Y’alls sets higher than usual routing fees (which your clients will have to pay).
3. LNBig.com — a large liquidity provider that will sell a channel to your node for a reasonable fee.
4. ln2me.com (LightningTo.Me) — my personal and non-profit hobby project that will establish a balanced channel of up to 0.1 BTC for free. And yes, it also sets very low routing fees.

There are also nodes such as Lightning Power Users that promise to open a channel to your node if you first open a channel to their node. Beware that this will not always work with nodes running c-lightning, which allows only one channel between two nodes.

(no longer working as of November 2020) Another interesting idea is a market place for channels. Two examples you can check are glowsat.com and jolt.market. These services allow owners of LN nodes to buy and sell channels.

Solution 3: Custodial exchange lightning bitcoins to on-chain bitcoins

This may seem ridiculous to some, but that is actually a thing: you can exchange bitcoins for bitcoins. In a way, this is also a form of spending: you spend lightning bitcoins and buy on-chain bitcoins.

I hope that soon enough many large exchanges will enable lightning deposits, but for the moment there are not so many options. I will just mention some links: bitfinex.com, zigzag.io, fixedfloat.com, sideshift.ai, hodlhodl.com, southxchange.com, btcduke.com, coinplaza.it, ln.zone, lightningconductor.net.

Please beware that exchange services are not always very reliable. Do your own research and immediately withdraw your coins once exchanged.

Solution 4: LOOP and POOL

Loop by Lightning Labs. Similarly to the previous solution, inverse submarine swaps implement an exchange from lightning (off-chain) bitcoin to on-chain bitcoin. But this solution is better than the previous one, because it is non-custodial (does not require trust). It is currently not very user-friendly and more oriented towards developers, so I will just mention it briefly here. Please refer to the intro blog post or go directly to the github repository.

Pool by Lightning Labs. This is a non-castodial marketplace for users willing to sell and buy liquidity. Also not very user-friendly for the moment, but please refer to the intro blog post and the github repository.

Solution 5: Use custodial storage

This is an even more dangerous way, because it requires you to trust a service for a long period of time. Doing your own research here is even more important than in the previous case. Essentially, these services allow you to deposit your money into their custody and promise to give it back when you need it.

Examples include various custodial wallets: BlueWallet, Wallet of Satoshi or Bitlum. For these everything is quite clear: you deposit lightning bitcoins from your node to theirs, freeing up local balance of your node.

But if you are creative enough, you can also make use of other services. For example, you can send yourself a large tip via tippin.me. This way you will store some portion of your funds on their node.

Solution 6: Keep your node online

If you simply keep your node always online— you will most probably get some incoming capacity. Open channels to random well-maintained nodes (I would appreciate if my node will be one of them), make sure that your node is publicly advertising its IP address, check that the ports are open, and setup monitoring to ensure that LN software is running 24/7.

First, people like nodes with at least some connectivity that are always online, because these nodes are more likely to root their payments. Second, some nodes are running on autopilot, and if you are online — you may get a channel from these nodes just by pure chance.

Conclusion

Accepting Lightning payments is trickier than accepting on-chain payments, but do not be discouraged, use some of the tips above. When your node matures — it will not be a problem at all.

Do you have any comments? Did I forget something? Please do not hesitate to share your thoughts! Let’s keep improving this post and help Lightning grow. Oh, and follow LightningTo.Me updates on twitter!

Practical solutions to inbound capacity problem in Lightning Network was originally published in LightningTo.Me on Medium, where people are continuing the conversation by highlighting and responding to this story.

And here is also the photo album for easier scrolling (photos are geotagged and you can join the album to stay updated):

Zurich street art

We started looking for street art as a way to enliven our walks. Turns out it is much more exciting than I thought it would be. It is fun and (I would even dare to say) educational, but it is also a great way to explore the city. Bonus: it can be done with a stroller :)

To the best of my knowledge this is the only (or at least the most comprehensive) map of Zurich street art pieces. You can add the map to your phone and enjoy the exploration (or join at the album first to find something you like). If you want some pointers to get you started — please read further for my personal highlights:

• legal walls of Zurich,
• massive murals by One Truth,
• volumetric art by Redl,
• world-famous stencils by C215,
• playground by various local artists and kids,
• squat building at Kernstrasse 14.

Also check out this great blog post by Dror Hadadi from Tel Aviv!

Legal walls of Zurich

Ok, this one is obvious, but it needs to be said. There are multiple areas in Zurich open for artists to try their skills.

If you walk around Rote Fabrik and further along the lake, you can see tons of works by both beginners and experienced artists, sometimes sprayed one over another. This often looks like a mess, but it also makes the scene very dynamic and alive.

Other large area for legal street art is along the Limmat, close to Oberer Letten. There are also various temporary walls, usually along some construction sites.

Massive murals by One Truth

One Truth is one of the most prominent studios in Zurich, you can find their works all over the city, here is just a sneak peak.

Probably the most famous work by One Truth is spread over more than 10 walls. You can find it at Rötelstrasse 98, not far from Bucheggplatz.

The highest mural in Switzerland (over 20 meters, 8-story building) is at Wehntalerstrasse 312 in Affoltern.

My personal highlight is a very-very long millipede (70 meters) in the end of Sihlpromenade (close to Bederstrasse). Update October 2020: this particular piece was replaced by “Dog Heaven”.

Volumetric art by Redl

Patrick Redl Wehrli is one of my favorite artists based in Zurich. He is a master of fine details, bright colors and realistic shadows. Many of his works play with perspectives and look differently depending on where you stand.

Check out large and beautiful mural called “Melody” at Limmatstrasse 291. Or a very colorful girl with a lizard at Schaffhauserplatz. Or another girl with a dragonfly at Fischers Fritz. Or futuristic animals at Neugasse 81. Or a work that is all about your point of view at Badenerstrasse 141.

World-famous stencils by C215

C215 (Christian Guémy) is a very famous french artist. I mean like almost Banksy-level famous. His paintings are all over the world, including Zurich.

We have managed to find two large pieces by him. The first one is the cat at Brauerstrasse 126. The second one is a beautiful stencil of a mother holding a child at Köchlistrasse 19.

There are also lots of small pieces on various post boxes. You can find at least four in the neighborhood of park Bäckeranlage.

By the way, Brauerstrasse 126 is also a home to Starkart Urban Art Gallery. They hold various street art exhibitions, and some of the works are publicly displayed on the house itself. Definitely worth checking out.

Playground by various local artists and kids

This playground is well hidden in one of the courtyards in the city center. The entrance is right next to Josefstrasse 42.

It was sprayed by various local artists: ELF, Taina Thoma, Eulen Heulen and probably others I missed. According to Street Art Archive instagram, it was done with help from kids, which makes it even more fun to explore.

Squat at Kernstrasse 14

Kernstrasse 14 is a very interesting building. One could call it a squat, but the website describes this place as a “self-organized social meeting point”.

People organize various activities in this building: theater, reading, open presentations, dancing, martial arts lessons and even cooking.

But more interesting part is purely ideological. This place is all against repression and isolation, against exploitation and borders, against sexism, racism and authoritarianism.

This ideology is perfectly represented by the art pieces on the walls of this building. The works there are not signed, and probably only few people know the authors, but it does not make the works themselves less appealing.

Another squat with some notable street art is Kochareal on Rautistrasse 22.

Bonus: probably the oldest piece in Zurich

This street art was sprayed in 1978 on the walls of University of Zurich. This piece is called “Undine”, or a “Mermaid” — a work by a controversial artist Harald Naegeli.

The story of the artist also known as a “Sprayer of Zurich” is fascinating. He was sentenced to nine months in jail and a fine of CHF 206,000 for his work. He fled to Germany, was evicted, served his jail sentence, but later was recognized by Swiss authorities and was rehabilitated.

You can find his works all over the city, some pieces are from eighties, and some are bright new.

P.S.

Street art is cool, because it is very dynamic, vivid and often surprising. I am pretty sure I missed lots of great spots. If you want to share your favorite pieces, contribute to the map, or just have questions — please write in the comments or reach out directly to me via d@laptev.ch.

First, we discuss why we need it (part 0) and describe an idea of payment channels and Lightning Network (part 1). Then we introduce required building blocks (part 2) and see how these blocks can be used to create payment channels (part 3). We then finally build Lightning Network, discuss its properties (part 4), and sum it all up (part 5).

Disclaimer. I consciously omit/simplify some of the technical details. And also I am not an expert, and can be simply wrong.

0. Why?

Bitcoin blockchain is a kind of decentralized database that stores every bitcoin transaction ever made. Here “every transaction ever” is a fundamental part of the protocol design. For system to be truly distributed and to prevent any mistakes, thousands of network nodes need to constantly double check each other and to record all the transactions.

Of course, this does not help scalability at all. Blockchain requires tens of gigabytes of hard drive storage, blocks are full, fees are rising, people are angry and fork bitcoin. Because of all that, alternative solutions are currently being developed. And one of these solutions is Lightning Network (LN).

Jameson Lopp on Twitter

Q: When will the Lightning Network be rolled out? A: The rollout has already begun. This is an iterative distributed learning process; it's unlikely there will be a single point in time at which we say LN is "deployed" because it will grow organically. Software is never finished.

1. Idea

The idea of the Lightning Network, which belongs to a broader set of second layer solutions, is actually quite simple.

💡 Instead of storing and verifying all the transactions in the blockchain, let’s conduct most of the transactions “off-chain”. The main blockchain will mostly be used to synchronise the balances from time to time and to resolve conflicts. And as usual, this will all work using cryptomagic.

This sounds intriguing, but absolutely unclear how…

1.1. Payment channel

Let’s start with simplifying the lives of two people (Alice and Bob), who often transact between each other. The following scheme is proposed.

1. Alice and Bob send deposits to a special address. This address is jointly controlled by both of them using their two private keys.
2. Both Alice and Bob create a special smart contract transaction (yes, there are smart contracts in bitcoin, but more about that in the next part). This transaction is valid, but not yet recorded in the blockchain.
3. At first, the transaction contains information that Alice and Bob can get their deposits back.
4. When Alice is paying to Bob, they both by mutual agreement update the information in these transactions. Alice agrees to get less than her initial deposit, Bob — more. One can say for the sake of analogy that they are exchanging debt acknowledging documents (IOU, I owe you). But unlike most IOUs issued by banks, LN payments are fully secured and guaranteed to be immediately redeemable.
5. Like this, they can exchange small amounts (within the limits of their deposits) with each other, for as long as they both want.
6. At any moment in time any party can decide to square their balances. Then Alice (or Bob) just records the final version of their transaction to the main blockchain and they both get their deposits back (taking into account all the intermediate payments).

Points 1–3 in these plan are called opening the payment channel. Points 4 and 5 — using the channels. Point 6 — closing the payment channel.

👍 Only two transactions are recorded in the main blockchain: sending the initial deposits (to open the channel), and the final transaction (to close the channel). All the intermediate payments are conducted without blockchain synchronisation. This makes payments within channels free and instant.

1.2. Network of payment channels

Payment channels between two people per se are not super useful. Ultimately, we do not transact regularly with most people. But…

💡 When multiple payment channels form a network, any two people in this network can transact between each other. If there is a path between two nodes in the network, they can pay each other, even if they are not directly connected. This is the main idea of Lightning Network.

Basically, analogous to TCP protocol, most people will need to have only one open channel to transact with anyone else.

Of course, there are many open questions left: how to find a path between two people, and how to motivate nodes to process payments. But let’s start with the main issue: the problem of trust.

1.3. The problem of trust

As it often happens in cryptography, the system of payment channels is easy to imagine when all the parties trust each other. There is no need in deposits, keys, special transactions. We can all just write down who owns whom and how much.

The question is: how to implement a payment channel and a network of payments channels without trust. There are going to be three main issues.

1. Both Alice and Bob store their deposit in a joined wallet. If Bob refuses to sign transactions, then how will Alice ever return her deposit?
2. When transacting over the payment channel, Alice and Bob create many versions of IOU transactions. Assume Alice is mostly paying Bob. Then in the last version of the transaction Bob should receive more than his deposit. But Alice can cheat and submit the very first valid transaction, pretending that she never owed Bob anything. What shall Bob do in this case?
3. Assume Alice is paying Bob through Victor in the network of payment channels. How can they be sure that Victor will indeed pass the money, and not just steal it?

We will call these issues, respectively: “the problem of a joined deposit”, “the problem of the last transaction” and “the problem of intermediary”.

All of the mentioned issues can actually be resolved using only a couple of tricks. But let’s not get ahead of ourselves. First, we will introduce some required building blocks…

2. Smart contracts

Bitcoin supports a simple smart contract programming language, called Script. Every bitcoin transaction has a special field that contains a small script in this language. This script checks under which conditions the output of the transaction can be spend.

“To spend the output of transaction A” is in fact just a more technically correct way of saying “to spend bitcoins from address/wallet K, to which these bitcoins were delivered using transaction A”.

☝ In comparison with ethereum, capabilities of smart contract in bitcoin are much more limited. This is because of the fact that Script is not a Turing-complete language. E.g. Script does not allow cycles/recursion, and does not allow creating variables (there is no memory).

See the the link below to read a bit more about transactions structure and using scripts.

Bitcoin: transactions, malleability, SegWit and scaling

Let’s have a look at a couple of important operations of bitcoin scripts.

2.1. Authorisation

Perhaps the most standard part of every transaction is signature verification. Let transaction A fund some address K with some number of bitcoins. In order to later spend these bitcoins from K, one needs to prove that they have the key. This is checked using operation OP_CheckSig.

But we can additionally check something else. For example, we can check that a person has a secret number, the hash of which is equal to the given value. For that we need two operations: OP_SHA256 (computes the hash of the provided parameter) and OP_EqualVerify (checks equality). In part 4 we will discuss why would anyone need that.

2.2. Cooperation

Another common example of simple bitcoin smart contracts is based on the operation OP_CheckMultiSig. This operation allows to spend funds from an address only when signed with multiple keys.

This principle is used for so-called multiple signature (multisig) wallets. It works approximately like a bank deposit box closed with two locks. One key belongs to a client, the second one — to an employee of the bank.

2.3. Timing

Since quite recently bitcoin also supports an operation called OP_CheckSequenceVerify, which allows to spend the funds only after some fixed number of blocks.

For example, this can be used to discipline people unable to save money. Blockchain works better than any piggy bank: if someone decides to freeze the savings for some time, the money will be securely frozen.

But beyond this scenario, OP_CheckSequenceVerify and other components are actively used for payment channel implementation.

3. Payment channel implementation

Now with all the building blocks ready, we can describe how payment channels actually work.

In reality, there exists a whole variety of different payment channels, and the first one was proposed by Satoshi him/her/them-self. We will approximately follow the specification called Poon-Dryja payment channels (named after the two authors of the Lightning Network paper).

3.1. Opening the channel

1. Alice and Bob create a transaction/transactions transferring their money to a joined deposit address O. Assume that Alice transfers X bitcoins from her wallet, Bob transfers Y bitcoins. The funds from this joined deposit can only be spent when signed with two keys from Alice and Bob (OP_CheckMultiSig).
2. The first trick is that they do NOT yet sign the transaction and do NOT yet submit this transaction to the blockchain. Otherwise Bob can refuse to cooperate and Alice will lose access to her money forever.
3. Instead, Alice and Bob create two new refund transactions (A1 and B1 respectively). The input of these transactions is the money from the joint account (the output of transaction O). There are two outputs: X bitcoins is to be transferred back to Alice, and Y — back to Bob. In reality everything is a bit more complicated, but we’ll discuss it later.
4. Then Bob signs the transaction A1 and gives it to Alice. Alice signs the transaction B1 and gives it to Bob.
5. And now the initial deposit transaction O can be safely recorded in the main blockchain. No one is going to freeze anyones money. If Bob refuses to cooperate, Alice will just sign her transaction A1, record it in the blockchain and will return her deposit.

Now “the problem of a joint deposit” is solved. The channel can be opened without any trust to the second party.

☝ An interesting fact. Just half a year ago (before the SegWit activation) signing an output of an unconfirmed transaction (point 4 above) was much harder, because of transaction malleability problem.

3.2. Using the channel

Payments within a channel are in fact implemented by rewriting transactions A1 and B1 with the new transactions.

1. Alice is paying Bob for a cup of coffee that costs C.
2. Alice agrees that when closing the channel, she will receive not the original amount X, but X’=(X-C).
3. Bob agrees to receive Y’=(Y+C).

New transactions A2 and B2 will look exactly the same as A1 and B1, but with new amounts. Any party can close the payment channel at any time, submitting the last version of the transaction to the blockchain.

How to make sure that Alice will not submit transaction A1 instead of transaction A2? This is solved with the second trick.

1. Every time Alice and Bob create new transactions, they also select a one-time private key. This key can be used by one party to collect the deposit of another party (OP_CheckSig).
2. With every new payment i, Alice is revealing to Bob her previous private key AK(i-1) and creates a new key AKi. Bob does not accept payment without the previous key.
3. If Bob knows Alice’s key, he can spend all the Alice’s money. But only if Alice decides to record an incorrect transaction to the blockchain.
4. This scheme insures that Alice is always motivated to record only the last transaction to the blockchain.

Last small modification. To dispute the transaction Alice submits to the blockchain and to provide her key, Bob needs time. Because of that Alice is not going to get her deposit immediately after she closes the channel, but after some number of blocks T (OP_CheckSequenceVerify). For example, she may need to wait for 48 blocks, which is approximately 8 hours.

If Alice signs one of her transactions (they are already signed by Bob) and submits this transaction to the blockchain, two scenarios are possible.

1. Alice submits her last transaction => Bob does not know the last private key AKi. This is a valid closure of the channel, everyone should get their unspent money. Alice will get hers after some time.
2. Alice is trying to record her older transaction instead of the last one => she is trying to cheat. In this case Bob knows Alice’s key and he can use it to get all the Alice’s money. Obviously, Alice is not interested in this scenario.

So, “the problem of the last transaction” is also solved. Payment channel between two people is ready. Now it also becomes clear, what are the advantages and disadvantages of using payment channels.

👍 Advantages: 1. payments are instant and free, they do not create a burden on the main blockchain. 2. two parties do not have to trust each other.

👎 Disadvantages: 1. deposits are blocked for the whole time while the channel exists. 2. both parties should from time to time go online (at least once in T blocks).

👌 In practice, both disadvantages are important for payment channels between two people, but much less important in the context of Lightning Network. First point stops being a disadvantage when one channel can be used to pay to various different people.

Second point is also basically non-existent in LN, because one can outsource correctness verification to a third party. If Bob is not online when Alice is closing the channel, and some random David discovers that Alice is cheating, then both Bob and David can split Alice’s confiscated deposit.

One more small note before we move further. You may think that operating a payment channel requires a lot of bookkeeping: tracking and signing different versions of transactions, exchanging signed these transactions and also temporary keys. And you will certainly be right. Good news is: when properly implemented, this will be all happening behind the scenes, the users will just send the money and receive them.

4. Lightning Network

4.1. Payment channel though an intermediary

Let’s now assume that Alice and Bob do not have a payment channel between each other, but both have an open channel with Victor. Alice can safely transfer money to Victor, Victor can safely transfer money to Bob.

But how to make sure that Victor, once he receives the money, will indeed pass them further to Bob?

The idea here is going to be quite similar to the previous trick. But instead of one-time private keys, they will use a secret number.

1. When the payment is initiated, Bob selects a secret number S, computes a hash of this number HS, and transfers this information to Alice. HS can also be used as a virtual receipt.
2. Alice creates a transaction AV that transfers the money to Victor, but only in case Victor shows a secret number S. For that she uses a script checking the hash of the provided number and comparing it to the value of HS (this is where we need OP_SHA256 and OP_EqualVerify).
3. Victor is creating a similar transaction VB transferring money to Bob, but only if Bob provides a secret number S.
4. Bob sees that he will be able to get the money from Victor and shows him his secret number S.
5. Now Victor can prove to Alice he transferred the money and successfully receive transaction AV.

There are couple of scenarios possible.

1. First, it does not make sense for Victor to cheat. By design, if he does not pass the money to Bob, he will not get the money from Alice.
2. But Bob can decide to cheat and not to reveal the secret key to Victor. To get the money Bob will need to close the channel with Victor and to submit transaction VB to the blockchain. But to actually spend the money, Bob will need to show his secret number anyway. And as the blockchain is public, Victor will also see it.

There is a couple of non-trivial technicalities with selecting the right timeframe for Alice, Victor and Bob to resolve possible conflicts. But these technicalities are way out of scope of this introductory article. If interested — google Hash Time-Locked Contracts (HTLCs).

4.2. Routing

In practice Alice and Bob can be connected through any arbitrary number of unknown/anonymous intermediaries across the whole world. The problem of finding the most optimal path of intermediaries in a graph of network nodes is called a routing problem.

The routing problem is in fact an area of active research at the moment. Optimal path depends on many dynamic factors: the availability of nodes, network topology, channels throughput, intermediaries fees.

Without going into too many details, finding the path and passing the payments in LN is currently done based on Onion routing — a technology for anonymous peer-to-peer routing, which is also used, for example, in Tor.

Everything is decentralized, the traffic is encrypted. No intermediary knows from whom the bitcoins come and where they go. One more advantage follows from this.

👍 Advantages: Lightning Network is much more anonymous than bitcoin itself. First, an absolute majority of the transactions are never recorded in a public ledger, these transactions are only visible to a handful of nodes. Second, even among the nodes involved in routing, only the first and the last node knows the source and the destination of the payment.

4.3. Fees economy

Only two major questions left.

Question number 1: why would an intermediary node process any payments from someone else?

First of all, because good connectivity allows them to use LN more efficiently. Second, because they receive fee: usually very small, but motivational enough.

At the moment the network is mostly supported by enthusiasts and the fees are almost zero: 1 satoshi, or ~0.01 cents for every intermediary node.

👍 The “bandwidth” of payment channels is a much less valuable resource than the block size. Channels are cheap and easy to open. Because of that fees in LN are orders of magnitude smaller than the fees in the main bitcoin blockchain.

Question number 2: and what about the miner fees payed on the main blockchain to open/close payment channels?

Indeed, these fees can be quite large, reaching sometimes tens of dollars. Therefore, payments are going to be cheaper if the channels are open/closed rarely.

This in turn motivates people to open channels with larger deposits, and to use channels bi-directionally: not only for outgoing payments, but also for incoming ones.

Example: I open a channel and fund it with 1000 dollars to use it for only outgoing payments. The turnover in the channel over the lifetime will be exactly 1000 dollars, and I will pay ~20 dollars in fees to open and close the channel. This results in 2% fees. Slightly lower than visa and mastercard, but still not as low as I would like.

The situation changes dramatically when the I start using Lightning to the fullest: deposit larger amounts and also start receiving money through channels. Then, depending on the proportion of spent/received money, the channel can be open forever and the fees will be converging to almost zero in the limit.

4.4. Criticism

It is easy to find lots of criticism of second layer solutions in general and of Lightning Network in particular. Some points actually deserve attention, some are outdated myths. Here is a couple of examples.

1. Using LN leads to centralization: users benefit from connecting to large hubs, and few of these hubs can control all the traffic.

This is a valid concern and deserves attention, but the risks are not huge. First, it is economically profitable and very simple to run a new node bypassing large hubs. Second, routing algorithms should balance the traffic among all the possible paths. And third, at least for the moment we do not see this centralization happening. Going forward, I hope the optimal topology is going to be encouraged by wallet software itself.

2. Low channel throughput will result in LN congestion, fees rising, and the situation will be as bad as in the main bitcoin blockchain.

Again, as soon as this starts happening, people will have larger economic incentives to run their own nodes. Unlike the block size, the number of nodes/channels is almost unlimited.

3. Efficient and effective routing on large number of peer-to-peer nodes is impossible. Especially when accounting the cost of opening new channels.

These problems are far-far-far into the future. But the research in this direction is already happening (example). The community will come up with something.

4. Channels need to be often opened and closed. Fees spent on that will be high, and LN will become more and more expensive.

Actually, this is an outdated myth still circling around. Early proposals of payments channels indeed were uni-directional and could last only for a fixed time. Now these problems are both solved.

5. You need to be online to use LN.

Partly true. Unlike early LN implementations, there is no need to be always online: other participants can monitor my open channels and verify that no one is cheating. But you indeed need to be online to send/receive money. This is of course a limitation, but a much less significant one.

6. LN is not compatible with cold storage.

This is a very good point and valid concern. Funds locked in payment channels are controlled by the wallets being online (hot wallets). So additional security for nodes will be required to protect against hackers.

7. LN transactions are not as safe as on-chain transactions.

LN payments are indeed more risky than on-chain transactions. But only in case of a successful 51% attack. The risk of it is very-very small.

5. LN today

The most important thing you need to know: Lightning is already here and it really works.

More than a thousand nodes in bitcoin testnet and more then three hundred nodes (growing every day) in mainnet are already processing transactions and testing different software today.

elizabeth stark on Twitter

@TraceMayer @Blockstream @coinbase @BitPay @adam3us Bug testing should be on testnet, not mainnet. Especially when the devs are still losing money. 🙃 https://t.co/QYx94V0vpR

As for software, there are three main implementation: lnd from Lightning Labs, c-lightning from Blockstream, eclair from ACINQ. These teams have been working for years to create standard specifications for nodes interactions called Lightning Network Specifications (BOLTs). And recently, in the end of 2016, they performed massive successful payment testing. All three implementations proved to be compatible.

At the moment, you can pay with real bitcoins using LN in only three or four online shops. But this is a whole three or four shops more than just a month ago, so this is already a great success 😊

Of course, the moment of ubiquitous transition from on-chain bitcoin payments to off-chain payments is still far away. A huge work should still be carried out by developers of wallets, payment gateways, exchanges, online stores. And, of course, by users themselves.

The most interesting in this story is that faster, cheaper and more anonymous transactions — is only the beginning of the story! Soon we will see even more anonymity, atomic swaps, decentralized exchanges and many more cool things. The future is exciting! ⚡

More technical details about LN: 1, 2, 3, 4, 5.

This article in Russian (статья на русском).

Please do comment, criticize, ask questions, subscribe. More about the author: http://laptev.ch.

Lightning Network ⚡🕸 was originally published in LightningTo.Me on Medium, where people are continuing the conversation by highlighting and responding to this story.

Same article is also available in English.

В части 0 посмотрим, зачем это надо. В части 1 обсудим поверхностно общую идею платежных каналов, Lightning Network и проблемы. В части 2 введем необходимые строительные блоки. В части 3 наконец-то опишем более строго детали работы платежного канала. В части 4 по-быстрому построим Lightning из платежных каналов, расскажем про критику и комиссии. В части 5 немного подытожим.

Дисклеймер. Я сознательно опускаю/упрощаю некоторые технические моменты. А еще я не эксперт, и могу банально ошибаться.

0. Зачем?

Блокчейн биткоина — это своего рода децентрализованная база данных, в которой сохраняются все транзакции сети. При этом “все транзакции” — это довольно фундаментальная часть определения протокола. Чтобы система была по-настоящему децентрализованной и чтобы при этом не допустить ни одной ошибки, нужно, чтобы тысячи узлов сети перепроверяли и сохраняли все транзакции.

Это, разумеется, совсем не способствует масштабируемости: блокчейн занимает десятки гигабайт на диске, блоки переполнены, комиссии растут, люди ругаются и форкают биткоин. Поэтому в данный момент активно разрабатываются альтернативные решения. Одним из таких решений являются Lightning Network (далее LN).

Jameson Lopp on Twitter

Q: When will the Lightning Network be rolled out? A: The rollout has already begun. This is an iterative distributed learning process; it's unlikely there will be a single point in time at which we say LN is "deployed" because it will grow organically. Software is never finished.

1. Идея

Идея решений второго уровня (second layer solutions), к которым и относится LN, звучит довольно просто.

💡 Вместо того, чтобы записывать и верифицировать все транзакции на блокчейне, давайте будем проводить большую часть платежей вне сети (off-chain), а на главный блокчейн будем время от времени по желанию синхронизировать балансы и разрешать на нем конфликты. А работать это будет как всегда с помощью криптомагии.

Звучит интригующе, но совсем непонятно как…

1.1. Платежный канал

Начнем с того, как можно упростить жизнь двум людям, Алисе и Бобу, которые часто расплачиваются между собой. Предлагается следующая схема.

1. Алиса и Боб отправляют депозиты на адрес, который управляется ими совместно с помощью двух приватных ключей.
2. Каждый из них создает специальную транзакцию — смарт-контракт (да, в биткоине есть смарт-контракты, об этом в следующей части). Эта транзакция корректна, но пока не записывается в блокчейн.
3. Изначально транзакции содержат информацию о том, что Алиса и Боб могут забрать свои депозиты обратно.
4. Когда Алиса расплачивается с Бобом, они по обоюдному согласию обновляют информацию в этих транзакциях. Алиса соглашается получить меньше изначального депозита, Боб — больше. По сути эти транзакции представляют собой долговые обязательства (IOU, I owe you). Но в отличии от большинства банковских долговых обязательств, LN платежи 100% обеспечены и могут быть реализованы в любой момент.
5. Так они могут обмениваться небольшими суммами (в пределах их депозитов) друг с другом, хоть до бесконечности.
6. В какой-то момент любая сторона может решить рассчитаться окончательно. Тогда Алиса (или Боб) просто записывают одну финальную транзакцию в главный блокчейн и получают суммы депозитов с учетом всех промежуточных платежей.

Пункты 1–3 в этой схеме называются открытием платежного канала (payment channel, канал микроплатежей). Пункты 4 и 5 — использованием канала. Пункт 6—закрытием платежного канала.

👍 В блокчейн записывается всего две транзакции: перечисление депозитов для открытия канала и финальная транзакция (закрытие канала). Все промежуточные платежи осуществляются без синхронизации с блокчейном, поэтому проходят они бесплатно и мгновенно.

1.2. Сеть платежных каналов

Сами по себе платежные каналы между двумя людьми — вещь не особо полезная. В конце концов, с большинством людей мы не проводим частых регулярных транзакций. Но…

💡 Когда платежные каналы выстраиваются в сеть, появляется возможность проводить платежи между любыми участниками, между которыми есть путь в графе этой сети (даже если они не связаны напрямую). Это и есть основная идея Lightning Network.

В принципе, аналогично протоколу TCP, простому человеку достаточно иметь всего один открытый канал, чтобы проводить транзакции с кем угодно.

Конечно, нужно еще искать оптимальные пути между двумя людьми, и еще нужно как-то мотивировать участников обрабатывать чужие платежи. Но начнем с основной проблемы: с проблемы доверия.

1.3. Проблема доверия

Как часто бывает в криптографии, систему платежных каналов легко себе представить, если все стороны доверяют друг другу. Нет необходимости городить огород с депозитами, ключами, специальными транзакциями. Можно просто записывать, кто кому сколько должен.

Дело за малым: понять, как можно реализовать канал платежей и сеть этих каналов без доверия. Основных проблем будет три.

1. Оба депозита от Алисы и Боба хранятся на общем кошельке. Если Боб откажется подписывать транзакции, то как Алисе вернуть свой депозит?
2. В процессе расчетов создается много версий долговых обязательств. Предположим, что в основном Алиса платит Бобу. Тогда в финальной версии транзакции Боб получает больше своего депозита, а Алиса — меньше. Но Алиса может схитрить и самовольно записать в блокчейн самую первую валидную версию транзакции, как будто Боб никогда и не получал денег. Что тогда делать Бобу?
3. Если Алиса и Боб передают деньги по сети каналов через Витю, то как они могут убедиться, что Витя действительное передаст деньги, а не заберет их себе?

Назовем эти проблемы соответственно: “проблема общего депозита”, “проблема последней транзакции” и “проблема посредника”.

Все перечисленные выше проблемы решаются с помощью буквально парочки трюков. Но обо всем по порядку: для начала введем несколько необходимых строительных блоков…

2. Смарт-контракты

Биткоин поддерживает простейший язык смарт-контрактов Script. В каждой биткоин-транзакции есть специальное поле, которое содержит скрипт на этом языке. Этот скрипт проверяет, при выполнении каких условий выход транзакции может быть потрачен.

“Потратить выход транзакции A” — это на самом деле более технически корректный способ сказать “потратить деньги с адреса/кошелька K, на который они были зачислены с помощью транзакции A”.

☝ В отличии, например, от этереума, возможности смарт-контрактов биткоина намного более ограничены. Связано это с тем, что Script не является полным по Тьюрингу. Например, в нем нельзя использовать циклы/рекурсию и нельзя создавать переменные (отсутствует память).

Про устройство транзакций и использование скриптов можно почитать по ссылке ниже.

Биткоин: транзакции, пластичность, SegWit и масштабируемость

Рассмотрим несколько важных операций этого языка.

2.1. Авторизация

Пожалуй, самая стандартная часть любой транзакции — это проверка подписи. Пусть транзакция A зачисляет средства на некий адрес K. Чтобы дальше потратить деньги с K, нужно доказать наличие ключа. За это отвечает операция OP_CheckSig.

Но при желании, можно также проверить что-нибудь дополнительное. Например, можно проверить, что у человека есть секретное число, хеш от которого равен заданному значению. Для этого нужно две операции: OP_SHA256 (считает хэш) и OP_EqualVerify (проверяет равенство). Зачем это нужно станет понятно в части 4.

2.2. Кооперация

Другой пример простейших смарт-контрактов на биткоине основан на операции OP_CheckMultiSig. Она позволяет тратить средства только при подписании несколькими определенными ключами.

На этом принципе построены так называемые multiple signature кошельки. Примерно как ячейка в банке, которая закрывается на два замка (один ключ у работника банка, второй — у клиента).

2.3. Сроки

С относительно недавних пор биткоин также поддерживает операцию OP_CheckSequenceVerify, которая позволяет тратить средства только через какое-то фиксированное количество блоков.

Например, это позволяет дисциплинировать людей, которые не умеют откладывать деньги. Блокчейн работает лучше любой копилки: если пользователь решил заморозить сбережения на какой-то срок, то они будут гарантировано заморожены.

Но помимо этого сценария, OP_CheckSequenceVerify и другие компоненты активно используются в реализации платежного канала.

3. Реализация канала

Теперь, когда все строительные блоки на месте, можно описать некоторые детали работы платежного канала.

На самом деле разновидностей платежных каналов довольно много, и первую из них предложил еще Сатоши. Я буду примерно ориентироваться на спецификацию, которая называется Poon-Dryja payment channels (по имени главных авторов статьи про Lightning Network).

3.1. Открытие канала

1. Алиса и Боб создают транзакцию/транзакции, которые зачисляют средства на общий адрес-депозит O. Предположим, что X биткоинов зачисляется с кошелька Алисы и Y — с кошелька Боба. Средства с общего депозита можно потратить только при подписании одновременно ключами Алисы и Боба (OP_CheckMultiSig).
2. Первый трюк заключается в том, что они пока НЕ подписывают и НЕ транслируют созданную транзакцию в блокчейн (иначе Боб может обмануть Алису и заморозить её средства навечно).
3. Вместо этого Алиса и Боб создают две новые транзакции возвращения депозитов (соответственно A1 и B1). Входом этих транзакций являются средства с общего депозита (выход транзакции O). Выходов у транзакций два: X уйдет обратно на адрес Алисе, Y — Бобу. На самом деле все немного сложнее, но об это чуть позже.
4. Дальше Боб подписывает транзакцию A1 и передает её Алисе. Алиса подписывает транзакцию B1 и передает её Бобу.
5. Теперь транзакцию зачисления депозитов можно смело транслировать в блокчейн, никто никого не обманет. Если Боб откажется кооперировать, Алиса всегда сможет подписать транзакцию A1, записать её в блокчейн и вернуть свой депозит.

Теперь “проблема общего депозита” решена. Открытие канала можно провести без доверия второй стороне.

☝ Интересный факт. Еще полгода назад (до внедрения SegWit) подписание выхода неподтвержденной транзакции (пункт 4) провернуть было намного сложнее из-за проблемы пластичности транзакций (transaction malleability).

3.2. Использование канала

Платежи внутри канала на самом деле осуществляются переписыванием транзакций A1 и B1 на новые транзакции.

1. Алиса платит Бобу за кружку кофе, которая стоит C.
2. При этом Алиса соглашается, что при закрытии канала она заберет не изначальную сумму X, а X’=(X-C).
3. Боб при этом получит Y’=(Y+C).

Соответственно, новые транзакции A2 и B2 будут выглядеть точно также, как A1 и B1, но с новыми суммами. Любая из сторон может в любой момент закрыть канал, записав последнюю версию транзакции в блокчейн.

Как убедиться, что Алиса не запишет в блокчейн транзакцию A1 вместо транзакции A2? Для этого есть еще один трюк.

1. Каждый раз, когда Алиса и Боб создают новые транзакции, они выбирают одноразовый приватный ключ, который нужен, чтобы забрать депозит (OP_CheckSig).
2. При каждом очередном платеже i, Алиса показывает Бобу предыдущий приватный ключ AK(i-1), и создает новый ключ AKi для новой транзакции. Боб не принимает оплату без предыдущего ключа.
3. Если Боб знает ключ, то он может потратить все деньги Алисы. Но только в случае, если Алиса решит записать неправильную транзакцию в блокчейн.
4. Таким образом, Алиса всегда заинтересована в том, чтобы записывать в блокчейн только самую последнюю транзакцию.

Последняя маленькая модификация. Для того, чтобы у Боба была возможность оспорить транзакцию Алисы и предоставить её ключ, Бобу нужно время. Поэтому Алиса будет получать свой депозит не сразу, а через какое-то количество блоков T (OP_CheckSequenceVerify). Например, через 48 блоков, то есть примерно 8 часов.

Если Алиса подписывает одну из своих транзакций (они уже подписаны Бобом), и транслирует эту транзакцию в блокчейн, то возможны два сценария.

1. Алиса транслирует финальную транзакцию => Боб не знает последнего ключа Алисы AKi. Это корректное закрытие канала, все должны получить свои деньги. Алиса получит их через какое-то время.
2. Алиса пытается записать старую транзакцию вместо финальной => Алиса пытается обмануть Боба. В этом случае Боб знает ключ Алисы и он может воспользоваться им, чтобы получить все средства Алисы. Разумеется, Алиса не заинтересована в этом сценарии.

Итак, “проблема последней транзакции” тоже решена и платежный канал между двумя людьми готов. Теперь также становятся очевидны некоторые плюсы и минусы.

👍 Преимущества: 1. платежи внутри канала мгновенны и бесплатны, они не создают нагрузки на главный блокчейн. 2. стороны не обязаны доверять друг другу.

👎 Недостатки: 1. депозиты заблокированы на все время существования канала. 2. обе стороны должны периодически появляться онлайн (как минимум раз в T).

👌 На самом деле оба недостатка важны для платежных каналов между двумя людьми, но не очень важны в контексте Lightning Network. Первый недостаток перестает быть недостатком, если один платежный канал может быть использован для транзакций с разными людьми.

Второй недостаток отсутствует в LN, так как проверку корректности может совершать любой участник сети (если Вася вскроет мошенничество Алисы, то он разделит с Бобом конфискованные средства Алисы).

4. Lightning Network

4.1. Платежный канал через посредника

Предположим теперь, что Алиса и Боб не имеют открытого канала между собой, но они оба поддерживают открытый канал с Витей. Алиса может безопасно передать деньги Вите, Витя может безопасно передать деньги Бобу.

Но как убедиться, что Витя, получив деньги, действительно передаст их дальше Бобу?

На самом деле идея немного похожа на предыдущий трюк, только вместо одноразовых ключей используется некоторое секретное число.

1. Боб генерирует секретное число S, хэш от этого секретного ключа HS и передает эту информацию Алисе. HS при этом может использоваться как виртуальный чек.
2. Алиса создает транзакцию AV, которая передает деньги Вите, но только в случае, если Витя предоставит секретное число S. Для этого она использует скрипт, который проверяет равенство хэша предоставленного числа и значения HS (тут как раз и используются операции OP_SHA256 и OP_EqualVerify).
3. Витя создает аналогичную транзакцию VB, которая передает деньги Бобу, но только в случае, если Боб предоставит секретное число.
4. Боб видит, что он может получить деньги от Вити, и показывает ему секретное число S.
5. Витя теперь может доказать, что он передал деньги Бобу, и соответственно он может обналичить транзакцию AV.

Тут есть несколько вариантов развития событий.

1. Во-первых, Вите не имеет смысла обманывать Алису. Он не может не передать деньги Бобу, потому что иначе Витя все равно не получит деньги от Алисы.
2. Но Боб может решит обмануть Витю и не передать ему секретное число. При этом он может закрыть канал с Витей и записать транзакцию VB в блокчейн. Но для вывода денег ему все равно придется показать свое секретное число, и тут-то Витя его и узнает.

Тут есть пара нетривиальных нюансов с тем, как выбрать время, в течении которого Алиса, Боб и Витя могут разрешить конфликты. Но эти более технические подробности выходят за рамки этой вводной статьи. Если интересно — гуглите Hash Time-Locked Contracts (HTLCs).

4.2. Маршрутизация

На практике Алиса и Боб могут быть связаны между собой не через одного общего знакомого Витю, а через несколько неизвестных/анонимных посредников по всему миру. Проблема поиска пути в графе узлов сети называется проблемой маршрутизацией.

Вопрос маршрутизации на самом деле является областью активных исследований на данный момент. Оптимальный путь в графе зависит от многих динамических факторов: наличия узлов, топологии сети, пропускной способности каналов, комиссии промежуточных узлов.

Не вдаваясь в подробности, поиск пути и передача платежей в LN реализуется на основе Onion routing — технологии анонимного распространения информации по peer-to-peer сетям. Именно так, например, работает Tor.

Все децентрализовано, весь трафик зашифрован. Никто не знает, от кого пришли деньги и кому они пойдут дальше. Отсюда еще одно преимущество.

👍 Преимущества: Lightning Network намного более анонимна, чем сам биткоин. Во-первых, промежуточные транзакции не записываются в публичный блокчейн, их видит всего несколько участников. Во-вторых, даже среди этих участников, только первый и последний человек точно знают, от кого и кому переводятся средства.

4.3. Экономика комиссий

Остается два очевидных вопроса.

Вопрос номер 1: зачем посредникам обрабатывать чужие платежи?

Во-первых, потому что им самим так проще пользоваться LN. Во-вторых, потому что они получают с этого очень маленькую, но все-таки комиссию.

На данный момент сеть поддерживают в основном энтузиасты и комиссия практически нулевая: 1 сатоши, или ~0.01 цента за каждого посредника.

👍 Пропускная способность каналов — намного менее ценный ресурс, чем размер блока. Каналы открывать просто и недорого. Поэтому комиссии в LN на порядки ниже комиссий в основном блокчейне.

Вопрос номер 2: а как же комиссия за открытие/закрытие канала?

Действительно, эта комиссия может иногда составлять десятки долларов. Таким образом, платежи будут тем выгоднее, чем реже придется открывать/закрывать каналы.

Это мотивирует людей открывать каналы с большими депозитами, и использовать каналы в двух направлениях: не только для исходящих платежей, но и для получения средств.

Пример: я открываю канал, зачисляю туда 1000 долларов, и использую канал только для исходящих платежей. Оборот в канале составит 1000 долларов, примерно 20 долларов уйдет на открытие и закрытие канала. То есть суммарно комиссии составят 2%. Немного лучше, чем виза и мастеркард, но явно больше, чем хотелось бы.

Ситуация кардинально меняется, когда я начинаю использовать Lightning на всю катушку: вкладывать большие суммы и получать деньги через каналы, а не только тратить их. Тогда, в зависимости от пропорции полученных/потраченных денег, канал может быть открыт вечно и комиссии в пределе будут стремиться к нулю.

4.4. Критика

В интернете можно найти большое количество критики решений второго уровня в целом и Lightning Network в частности. Какие-то пункты действительно заслуживают внимания, многие оказываются устаревшими. Приведем несколько примеров.

1. Использование LN приведет к централизации: пользователям будет выгодно подключаться к крупным хабам и эти хабы будут контролировать весь трафик.

Такой риск есть и стоит уделять этому внимание, но риск не очень велик. Во-первых, экономически выгодно и очень просто будет создать новый узел в обход больших хабов. Во-вторых, алгоритмы маршрутизации предусматривают балансировку трафика. В-третьих, пока что такой картины не наблюдается. В будущем, я надеюсь, топология сети будет оптимально выстраиваться алгоритмически.

2. Недостаточная пропускная способность каналов приведет к тому, что LN будет забита, комиссии будут расти, и вскоре ситуация будет такой же, как и в основном блокчейне.

Опять же, как только такое начнет происходить, у людей появится большая экономическая мотивация запускать свои узлы. В отличии от размера блока, количество узлов практически неограниченно.

3. Эффективная маршрутизация на большом количестве peer-to-peer узлов невозможна. Особенно с учетом сложности открытия новых каналов.

До этих проблем еще очень и очень и очень далеко, а исследования в этом направлении активно ведутся уже сейчас. Что-нибудь придумают.

4. Каналы нужно постоянно открывать и закрывать, комиссии, потраченные на это, будут огромны и LN окажется невыгодной.

На самом деле это проблема из прошлого, про которую почему-то до сих пор говорят. Ранние версии платежных каналов действительно были однонаправленными, а сам канал мог существовать только ограниченное время. Сейчас эти проблемы решены.

5. Для использования LN необходимо быть онлайн.

Опять же, в отличии от ранних реализаций LN, пользователю нет необходимости все время быть онлайн: другие узлы сети проверяют, что два владельца канала не пытаются обмануть друг друга. Действительно необходимо быть онлайн только для отправки и получения платежей, что безусловно является ограничением, но уже намного менее важным.

6. LN не совместимо с холодными хранилищами (cold storage).

Очень правильно замечание. Депозиты платежных каналов храняться в кошельке подключенном к интернету (hot wallet). Для защиты от хакеров необходимо будет очень серьезно подходить к безопасности.

7. LN платежи — это не безопасно.

LN платежи действительно чуть более опасны, чем платежи на основном блокчейне. Но только в одном случае: при успешной 51% атаке на блокчейн биткоина. Риск этого ничтожно мал.

5. LN сегодня

Самое важное, что вам нужно знать: Lightning уже реально работает.

Более тысячи узлов в тестовой сети биткоина и более двухсот узлов (число растет каждый день) в основной сети (mainnet) уже обрабатывают платежи и тестируют различный софт.

elizabeth stark on Twitter

@TraceMayer @Blockstream @coinbase @BitPay @adam3us Bug testing should be on testnet, not mainnet. Especially when the devs are still losing money. 🙃 https://t.co/QYx94V0vpR

Что касается софта, то есть три основных реализации: lnd от Lightning Labs, c-lightning от Blockstream, eclair от ACINQ. Эти команды уже не один год работали совместно, чтобы разработать общий стандарт взаимодействия узлов: Lightning Network Specifications (BOLTs). И вот буквально в конце 2017-ого года они провели полномасштабное успешное тестирование протокола платежей, все три реализации оказались совместимы.

Расплатиться реальными биткоинами используя LN можно пока буквально в трех-четырех онлайн-магазинах. Но это на целых три-четыре магазина больше, чем всего месяц назад, так что это уже большой успех 😊

Конечно, момент повсеместного перехода с on-chain биткоин платежей на off-chain платежи еще далеко. Огромную работу еще должны провести разработчики кошельков, платежных шлюзов, бирж, онлайн-магазинов. И, конечно, сами пользователи.

Самое интересное в этой истории, что более быстрые, анонимные и дешевые платежи — это только начало! На подходе еще больше анонимности, атомарные свопы, распределенные биржи и многое-многое другое. Будущее выглядит захватывающе! ⚡

Больше подробностей про LN по ссылкам: 1, 2, 3, 4, 5.

Комментируйте, критикуйте, задавайте вопросы, подписывайтесь! Авторский мини-канал про крипту в телеграме: https://t.me/cryptohodl. Больше об авторе: http://laptev.ch. По вопросам использования материала пишите на d@laptev.ch или https://t.me/x0100.

Итак, сообщество биткоина добилось своего: майнеры согласились на SegWit и он таки активировался сегодня в сети. Паника немного улеглась, цена подросла… Пришла пора разобраться, что же такое этот SegWit, почему все о нем говорят, и зачем он нужен.

Дисклеймер. Я сознательно опускаю/упрощаю некоторые технические моменты. А еще я не эксперт, и могу банально ошибаться.

Segregated Witness (SegWit) — это собирательное название для нескольких изменений в протоколе биткоин. Многие из этих изменений заслуживают отдельного внимания, но я буду фокусироваться на первом и главном: изменение того, как считается идентификатор транзакции.

Хотя в последнее время все говорят о SegWit только в контексте споров о масштабировании, изначальное предложение решало совсем другую проблему: transaction malleability, или, как принято это переводить на русский, пластичность транзакций.

Но обо всем по порядку: что такое транзакция?

Транзакция

Для простоты будем рассматривать транзакцию с адреса A на адрес B, с одним входом и одним выходом. Пример такой транзакции:

Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d1090db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG

• Previous tx — идентификатор предыдущей транзакции на адрес A;
• Index — номер входа (в этом примере один вход с номером 0);
• scriptSig — первая часть проверяющего скрипта (об этом ниже);
• Value — количество биткоинов, указанное в сатоши (один биткоин = 100 миллионов сатоши) — 50 биткоинов в примере;
• scriptPubKey — вторая часть проверяющего скрипта, которая также содержит адрес получателя B.

Транзакции всегда выстраиваются в цепочку (на самом деле в дерево, но это детали). Чтобы потратить биткоины с адреса A, нужно потратить выход каких-то транзакций на адрес A (за исключением coinbase транзакций, у которых ноль входов, но это тоже детали).

Чтобы проверить, что мы можем тратить выход предыдущей транзакции, мы должны:

1. Соединить scriptSig новой транзакции со scriptPubKey предыдущей транзакции,
2. Проверить, что получившийся скрипт (на специальном языке программирования Script) выполняется и возвращает True.

В самом простом случае (как в примере выше) scriptSig содержит подпись транзакции приватным ключем, а scriptPubKey просто проверяет совпадение публичного ключа и валидность подписи для данного адреса (основная операция: OP_CHECKSIG).

Не нужно изобретать отдельный язык программирования, чтобы проверять такие простые случаи. Но возможности биткоина намного больше. Например, с помощью такого механизма можно реализовать MultiSignature адреса, средства с которых можно потратить только при условии подписи несколькими ключами. Немного больше про это.

Пластичность транзакций

Что же конкретно содержится в поле Previous tx, спросите вы? Что это за идентификатор транзакции (transaction identifier, txid)?

txid — это sha256d хэш от всех полей данных транзакции.

Ключевым моментом является зависимость от scriptSig. Потому что scriptSig сама по себе как правило содержит данные о транзакции подписанные приватным ключем, включая txid. scriptSig зависит от txid, поэтому txid не может зависеть от scriptSig.

Любой держатель полной ноды биткоин (не только майнер) помогает собирать и распространять по сети данные о транзакциях. В процессе он может изменить scriptSig таким образом, чтобы скрипт подписи оставался корректным, результат транзакции оставался тем же, но txid поменялся.

Например, к любой подписи можно добавить операцию OP_NOP (не делает ничего), или для изощренности добавить две операции OP_DUP OP_DROP (первая дублирует подпись на стеке, а вторая удаляет верхний элемент стека). Подпись останется корректной, но txid поменяется.

И вот тут-то кроется проблема. Точнее две.

1. txid — плохой идентификатор

Такая изменяемость идентификатора не позволяет использовать txid по назначению: как идентификатор. Злоумышленник может перехватить нормальную транзакцию и распространить модифицированную версию по сети. С некоторой вероятностью майнеры могут включить в блок модифицированную транзакцию вместо изначальной.

Зачем это нужно злоумышленнику, спросите вы? В идеальном мире — особо незачем. Но в реальном мире люди любят использовать идентификаторы для уникальной идентификации. Это и произошло (по одной из версий) с биржей MtGox.

Злоумышленник выводил биткоины с этой печально известной биржи, перехватывал транзакцию, менял ей txid. Транзакция оставалась валидной, злоумышленник получал свои биткоины. Но биржа видела, что изначальный txid не вошел в блок и не уменьшала баланс злоумышленника.

2. Цепочки транзакций в одном блоке

Есть еще и вторая проблема. А точнее упущенная возможность.

Теоретически биткоин позволяет тратить выход транзакций, которые еще не были включены в блок. Я могу перевести средства с адреса A на адрес B. А потом, не дожидаясь подтверждения первой транзакции, перевести биткоины с адреса B на адрес C. И обе эти транзакции могли бы быть проверены и одновременно включены в блок, если бы не пластичность.

Если txid первой транзакции может измениться, значит Previous tx второй транзакции может измениться, а значит и подпись может измениться. А значит вторую транзакцию проверить нельзя, пока первая не будет включена в блок (тогда ее txid будет зафиксирован).

И это проблема больше, чем кажется на первый взгляд, но об этом в самом конце.

Segregated Witness

На самом деле теперь все становится очень просто.

SegWit предлагает: давайте вынесем всю пластичную информацию из транзакции отдельно (witness data), а txid будем считать без нее. Идентификатор станет уникальным, проблемы будут решены.

Элементарное решение, не правда ли? Но оно меняет определение транзакции (которое почти не менялось с самого начала), меняет механизмы валидации, требует переписать огромное количество очень стабильного кода. А еще неплохо было бы подумать про сохранение совместимости.

Поэтому (а также из-за политических игр, про которые я не буду здесь рассказывать) принятие SegWit заняло так долго.

При чем здесь масштабирование?

Оказывается, этот фикс имеет огромное влияние на масштабирование биткоина. По двум причинам.

1. Больше транзакций в блоке

Посмотрите еще раз на пример транзакции выше по тексту. Больше половины информации в ней — это scriptSig. Вынося эту информацию отдельно, мы по сути снижаем размер транзакции. И эффективно увеличиваем размер блока.

Конечно, это читерство, потому что подпись мы тоже будем хранить, хоть и отдельно. Но при вычислении размера блока эти данные не учитываются. Почему не учитываются? Не вдаваясь в детали, потому что только так можно было реализовать SegWit через soft fork. Чуть больше про форки.

Теоретически, в блок можно будет впихнуть в четыре раза больше транзакций. Практически — примерно в два раза больше. Вполне себе ощутимое масштабирование.

2. Транзакции вне блокчейна и lightning network

На данный момент абсолютно все транзакции хранятся в блокчейне. Тысячи компьютеров по всему миру хранят информацию о том, что я купил кофе за 0.0015 биткоина. Это дорого для узлов сети. Это дорого и долго для меня: каждый раз мне нужно ждать 10 минут подтверждения транзакции за кофе.

Один из вариантов решения этой проблемы — проводить небольшие транзакции вне основного блокчейна. И время от времени синхронизировать баланс на главном блокчейне. Общее название этого подхода — second layer networks (сети второго уровня).

Одним из рабочих решений в этом стиле на данный момент считается Lightning network. Работает это примерно так:

• два человека открывают между собой канал микроплатежей, у обоих блокируется по некоторой сумме;
• они совершают много небольших транзакций между собой;
• честное поведение гарантируется за счет умной криптографии, конфликты разрешаются из заблокированных средств;
• как только канал закрывается — на главном блокчейне появляется одна транзакция, которая синхронизирует балансы людей, замороженные суммы возвращаются.

Настоящая сила каналов проявляется, когда их много. Каналы формируют ребра в графе людей. Если между двумя людьми есть путь, даже через несколько каналов — они могут совершать транзакции.

Причем тут SegWit, спросите вы? Он действительно не обязателен, но делает имплементацию намного удобнее.

Не углубляясь в детали… Для работы канала микроплатежей необходимо создать транзакцию подписанную двумя сторонами (double-signed transaction). В самом начале на адрес с двумя ключами отправляются средства. Но чтобы предотвратить мошенничество, double-signed transaction должна быть подписана до того, как туда переведут деньги.

Но чтобы провернуться такое, необходимо собрать выходы транзакций, которые еще не были подтверждены на главном блокчейне. А это как раз тот сценарий, который на данный момент невозможен из-за пластичности транзакций (смотрите пункт “2. Цепочки транзакций в одном блоке” выше по тексту). И тут-то SegWit приходит на помощь.

Заключение

TL;DR. SegWit активирован. На самом деле он решает проблему пластичности транзакций, но еще оказывается полезен для масштабирования. Краткосрочно он позволит включать больше транзакций в блоки. Долгосрочно — открывает новые возможности масштабирования через off-chain транзакции. С нетерпением ждем, что из этого получится.

Комментируйте, критикуйте, задавайте вопросы, подписывайтесь! Больше интересных статей в телеграме: https://t.me/cryptohodl. Больше обо мне: http://laptev.ch.

Disclaimer. I consciously omit/simplify some of the technical details. And also I am not an expert, and can be simply wrong.

Segregated Witness (SegWit) is a cumulative name for a bunch of changes to bitcoin protocol. Many of these changes deserve exclusive attention, but I will be focusing on only the first (and the most important) one: a change to how transaction identifier is computed.

Despite the fact that recently all the talks about SegWit are related to a scaling debate, the initial proposal was solving a very different problem: transaction malleability.

But let’s move one step at a time: what is a bitcoin transaction?

Transaction

For simplicity, let’s consider a transaction from an address A to an address B with a single input and a single output. An example of such a transaction:

Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d1090db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG

And here is what it means:

• Previous tx — an identifier of the previous transaction to the address A;
• Index — input number (here we have only one input number 0);
• scriptSig — first part of the validation script (more about it below);
• Value — the number of bitcoins to send in satoshi (one bitcoin = 100 millions satoshi) — 50 bitcoins in the example;
• scriptPubKey — second part of the validation script, which also contains the receiver address B.

Transactions are linked in chains (well, in trees in fact, but this does not matter for now). To spend bitcoins from address A, one needs to spend the output of some transactions to address A (except of coinbase transactions rewarding miners for generating a block, these transactions have zeros inputs).

To verify that one can spend the output of the previous transaction, one needs to:

1. Combine scriptSig of a new transaction with the scriptPubKey of the previous transaction,
2. Check that the resulting script (written in a special language called, you guessed it, Script) is valid and returns True.

In the simplest case (like in this example), scriptSig contains a transaction signature (signed with a private key from this address), and scriptPubKey simply checks the equality of the public key and the validity of the signature (the main operation here is OP_CHECKSIG).

Of course, one does not need a special programming language just to handle these simple cases. But Script enables bitcoin to do much more. For example, using this mechanism, one can create a MultiSignature address — an address, from which one can spend funds only in case the transaction is signed by multiple keys from different parties.

Transaction malleability

To explain what transaction malleability is, we need to clarify one point: what exactly is transaction identifier or simply txid?

txid is a sha256d hash of all the fields of the transaction data.

What is relevant in this definition, is that txid depends on scriptSig.

Every full node in the bitcoin network (not only miners) helps to collect and distribute information about transactions. In the process, the node can mutate scriptSig in such a way, that the signature will stay valid, the transaction will have the same effect, but txid will change.

For example, one can add a OP_NOP operation (that does nothing). Or for some sophistication, one can add two operations: OP_DUP OP_DROP (the first one is duplicating the signature on the stack, and the second one removes it again). The signature is still valid, but txid changes.

And now we can see a problem. Two problems, in fact.

1. txid is a bad identifier

This mutability do not permit the usage of txid as it was intended: as an identifier. An attacker can intercept a normal transaction and distribute the modified version through the network. With some probability the miners will include this modified transaction instead of the original one.

You may ask: why would an attacker do that? In ideal world there is indeed not much of a point to do that. But in real world people like using identifiers for unique identification. And this is what happened to MtGox exchange in 2013 (this is only one of the versions, they could have simply stolen the funds themselves).

An attacker was withdrawing the funds from the exchange, intercepting the transaction, and changing its txid. The transaction was still valid and the attacker got the bitcoins. But the exchange saw that txid was never included in the block and did not decrease the attackers balance.

2. Transaction chains in one block

The second problem is rather not a problem, but a missed opportunity.

Theoretically bitcoin allows to spend the outputs of transactions even before they were included in the block. One can transfer funds from A to B. And then, without waiting for any confirmations, transfer bitcoins from B to C. And both transactions could have been validated and included in the next block, if not for transaction malleability.

If txid of the first transaction can change, the Previous tx field of the second transaction should also change. And it means that the second transaction can only be created when the first transaction is included in a block (and therefore its txid is fixed).

And this problem is bigger than one might think, but we will come to it later.

Segregated Witness

And now it becomes easy to explain what SegWit proposal is all about.

SegWit suggests: let’s separate all the malleable information from the transaction into a separate “witness data”. txid will be computed without it, the identifier will never be able to change, the problems will be fixed.

Easy, right? Yes, but it changes the transaction definition (that was not changed much since the beginning), changes the validation mechanisms, requires huge code changes. And on top of it, would be nice to make SegWit compatible with the previous protocol versions.

Because of all that (and also because of some political games, which I am not going to talk about), SegWit activation took so long.

What does it have to do with scaling?

Apparently, this fix also have a huge impact on the scaling of bitcoin. Because of two reasons.

1. More transactions in a block

Look once again at the transaction example above. More than half of the data is scriptSig. Separating this data, we essentially allow transactions to be smaller. And effectively enlarge the block size.

Of course this is cheating, because we still need to store all these signatures. But now this data does not count towards the block size limit. Why not? Without going into details: because this was the only way to implement SegWit as a soft fork, and not a hard fork. And nobody likes hard forks.

Theoretically, new SegWit blocks can include up to four times more transactions. Practically — about two times more. Quite a tangible scaling.

2. Off-chain transaction and lightning network

Currently, every bitcoin transaction ever made is stored in bitcoin blockchain. Thousands of computers around the world are storing information about me buying coffee for 0.001 bitcoins.

This is expensive for the nodes of the network. This is expensive and annoying for me: I have to pay large fees and wait for ten minutes for the confirmation of my transaction.

One of many possible solutions to this problem is to have some small transactions executed off the main chain, and then sometimes sync the balance. The common name for these approaches is “second layer network”.

One close-to-working implementation of this idea is Lightning network. It works approximately like this:

• two persons open a micropayment channel between each other, both have some amount of funds locked;
• they execute large number of small transactions between each other;
• honest behaviour is guaranteed by some very clever crypto-magic, conflicts are automatically resolved from the locked funds;
• as soon as the channel is closed — the locked funds are unlocked, the balances are synced to the main blockchain.

The real power of the payment channels is achieved when there are many of them. Channels form edges of the graph between people. If two people are connected, even indirectly — they can transact between each other.

What does SegWit has to do with that? It is indeed not necessary, but it makes the implementation much easier.

Without going into too many details… Micropayment channels rely on double-signed transactions to lock the initial deposits. In the beginning, the funds from both parties are sent to one double-signed address. To prevent cheating, the transaction should be double-signed before any funds are actually sent there.

But to do that, one needs to collect the outputs of transactions that were not yet synced to the main blockchain. And this is exactly the scenario not permitted because of transaction malleability (described above in “2. Transaction chains in one block”). And this is where SegWit comes to the rescue.

Conclusion

TL;DR. SegWit is activated. It solves the problem of transaction malleability, but it is also useful for scaling. Short-term is will permit more transactions in a single block. Long-term it will open new opportunities for off-chain transactions. Looking forward to the future!

Please do comment, criticize, ask questions, subscribe. More about myself: http://laptev.ch.

This article in Russian (статья на русском).

Bitcoin: transactions, malleability, SegWit and scaling was originally published in LightningTo.Me on Medium, where people are continuing the conversation by highlighting and responding to this story.