How to survive the Bull Run: climb with Bitcoin

[This article is a translation of the original written by Alberto de Luigi]

Will the cyclicality dictated by the halving make us all rich?

Maybe, but will the Bull Run be in favour of a progressive and healthy adoption, or will Bitcoin have to run away from the unleashed bulls?

• Contents:

• INTRODUCTION TO MADNESS

• HIGH FEES AND NO MASS ADOPTION DURING THIS CYCLE

• THE TAXONOMY OF GOOD NEWS

• THE TOP LAYERS:

1. CUSTODIANS: CENTRALISED TOP LAYER

2. FEDERATION (LIQUID SIDECHAIN): PARTIALLY DECENTRALISED TOP LAYER

3. LIGHTNING NETWORK: DISTRIBUTED TOP LAYER

• THE BLOCKCHAIN:

1. CAPACITY UPGRADE: INCREASE OF THE BLOCK SIZE AND SEGWIT

2. EFFICIENCY UPGRADE: BECH32 AND SCHNORR

• 2.1 BECH32

• 2.2 SCHNORR

3. ORGANISATION: BATCHING, COINJOIN, CHANNEL FACTORIES

• 3.1 BATCHING

• 3.2 COINJOIN WITH SCHNORR AND SIGNATURE AGGREGATION

• 3.3 CHANNEL FACTORIES

• CONCLUSION: LOOKING FOR ANSWERS IN THE CHICKEN’S ENTRAILS

INTRODUCTION TO MADNESS

Many long-standing holders and speculators expect the price of Bitcoin to respect the cyclicality dictated by halving, exactly as it has occurred in the last 8 years with the halving of 2012 and 2016. The famous logarithmic price graph, which correlates the bull and bear phases with the four-year halving cycles, is, in fact, the most logical and constant pattern that can be recognised among the roller coasters of the Bitcoin price. According to that projection, the price of Bitcoin will reach the previous All-Time High (ATH) next summer, and then rise even more and create another bubble. Although no one can predict the future, it is also true that, compared to the technical analysis of the fortune teller, a projection based on this pattern has an essential element that can have an impact on the price: the monetary expansion of Bitcoin is halved every 4 years.

In spring 2020, the monetary expansion of Bitcoin, defined as the new issuance on the existing monetary base, will go from about 3.7% to 1.8%. Every year 328,500 Bitcoins will be produced instead of the current 657,000. In addition, to date there are about 17,770,000 Bitcoins, in the summer of 2020 the figure will rise to 18,400,000, getting closer to the limit of 21 million. The bull market is calling.

These figures may well be a source of joy for you evil speculators, who with the dribble in your mouth are already rubbing your hands at the thought of how much money you will make, but in reality, for us idealists with a pure heart who believe in friendship, love and Bitcoin, these FOMO figures are only a source of gloomy thoughts. That’s right, I can see it already: we with the Lambo in Portofino, in our 800-foot yacht, while on deck they are looking for us to bring us an aperitif of oysters and Armand de Brignac, well, we will remain closed in the dark, in the bathroom. They call us, but we don’t respond. Curled up, introverted, holed up in a fetal position in the darkness, our expression astonished and empty, we will only be able to concentrate all our energy on the fundamental question, the one that corrodes us inside, consuming us in the spirit:

“will Bitcoin scale or not?”

Because with the bull market, a tsunami strikes the crypto economy, and the merry-go-round starts again. TV news and newspapers will bomb us every day. Everybody wants to try these Bitcoins. There’s traffic in the network and the commissions per transaction go up, up, up, up.

The first genetic mutations in the population occur in some specific classes.

On the first day, insurers reinvent themselves as hipsters with market expertise: the CV says AXA and Generali, but they boast 20 years of forex trading and 6 months of Blockstream internship. By day two, mutagens affect consultants, banks, marketers. Saruman appears to be repeatedly making new scammers at the Uruk-hai factories. The worst seems to have come, but from the third day the mutants of a new phenotype appear: those who don’t want to scam you, they just want to drain your guts. Even the know-it-all who until yesterday repeated, once again, the most mentally retarded phrase in the world, the one we’ve heard, like 7 billion times: “blockchain yes, Bitcoin no…”. Now, he’s stopping you on the street, coming out from behind a column as if by chance, to ask you if it’s better to buy on Kraken or Coinbase Pro.

In short, the people go crazy, it’s the zombie apocalypse. You see them running hungry through the streets of FOMO with their brains fried by the market and cocaine, shouting the most senseless nonsense about any fact for and against Bitcoin. And if in doubt, they’ll buy.

On the seventh day of ATH reported by the TV news, the devil went as far as to approach even the old Mrs Moore next door. Now the encounter in the hall has become disturbing. She doesn’t smile at you as she did before. You used to be the good young nerd who helps with the water bottles and takes out the trash, and her smile was sincere, disinterested, almost maternal. Today, in that smile, there is something left unresolved, a prolonged silence, a moment of embarrassment. You know Mrs Moore wants to say something, but she doesn’t. Is she waiting for the right moment? Does she think she’s inappropriate? Will she be brave only tonight after the umpteenth headline on the national news? You’re suspicious, you’re walking on the edge of the walls now, you can expect it from anyone. And behind that apparently innocent smile, in the hall, here it is, you see it, you recognise it, that sparkle in the eyes. That malignant aura of greed has taken her too! In the end, the mask falls and there are no more doubts: “Hey, how can I get me some bitcoin”.

Mrs Moore is also possessed.

HIGH FEES AND NO MASS ADOPTION DURING THIS CYCLE

More and more people are trying to transfer Bitcoin here and there, through onchain transactions, it seems almost out of spite. They fill our mem pools and we are forced to open up Lightning channels with millions of satoshi. And the doubt can plague even the purest minds: “but won’t it cost too much to open a Lightning channel for an ordinary user without a Lambo or a yacht?”

To be honest, after the famous collapse of the price in January 2018, the fees for Bitcoin transaction have fallen below the threshold of the euro and higher fees have been rare exceptions. Today, in July 2019, it is possible to get a confirmation in the first block by paying 5 cents commission. Services that base their business on onchain micro-transactions can still thrive peacefully. On average, a transaction weighs about 250 bytes and at the present state of the mempool it is convenient to set a fee of 2 satoshis per byte, therefore 500 satoshi, which is equivalent to 0.5 euros with a bitcoin price at 10 thousand euros. Those who are still not doing it should get used to making calculations in satoshis, because it will soon be the most used measurement unit in the cryptocurrency world.

However, even in the last year and a half, there have been short periods in which the traffic of transactions on the network has pushed the fees to peaks of 200 satoshis per byte, thus up to 5 euros (at today’s price). Since this March, these periods have become more and more frequent, and in the future, it will only be worse. Because even if the technology to scale is there, people do not use it, the right ecosystem has not yet developed, there is no real network of layer 2 payment channels (not necessarily Lightning Network, as we will see). In short, users do not have the means to use the technology or are not yet sufficiently informed. Almost everyone will be passing onchain until they stop transacting because it will be too expensive.

In short, the year 2021 may be epic for many reasons, perhaps it will be remembered as the year in which Benetazzo, at the squeeze of the umpteenth short, will prostrate himself at the feet of Barrai as a sign of final defeat, as did L before Kyra. Or it will be the year in which Marco Casario can finally pay for his holiday on a deserted beach even without selling a single trading course. You might think that this is certainly exciting, and you are right, but unfortunately, the fact remains that 2021 will not be remembered as the year of mass adoption. We’ll have to wait for at least one more cycle.

THE TAXONOMY OF GOOD NEWS

But there’s nothing to be pessimistic about. Those at the forefront are already using all the tools available in the right way. Bitcoin can scale and can technically support mass adoption, which is, however, a more cultural than a technological issue. As I said in the award-winning article with 7 Pulitzer and Zucco’s blessing “Bitcoin is freedom”, ten years is ridiculously few years for an epoch-making revolution like Bitcoin, whose usefulness is not even understood by the majority of the population. We have nothing to worry about, technology certainly precedes the cultural transformation of the masses.

It is often said that, even with a fully functioning Lightning Network, it takes a huge block compared to the current one to scale to tens or hundreds of millions of transactions per day (Visa processes 150 million of them), since the closing and opening of channels alone require a very high onchain throughput. It’s not like that. The strength of Bitcoin’s scalability lies not only in Lightning Network but in its evolutions into two distinct macro-areas, which in turn I have divided into three types, just for the sadistic thrill of giving you a headache with pseudo-scientific taxonomies.

One conceptual macro-area includes all the structures built on the Bitcoin blockchain (the famous layer 2, such as Lightning Network), the other macro-area is obviously the same blockchain technology, constantly evolving, and the use that is made of it at the ecosystem level (which can be more or less well organised). Below I report this taxonomy with examples that will be discussed point by point.

BITCOIN SCALABILITY TOOLS:

THE TOP LAYERS

BLOCKCHAIN

THE TOP LAYERS:

1. CUSTODIANS: CENTRALISED TOP LAYER

Decentralising, being independent, incensurable and being able to control one’s money at will are not necessarily incompatible with the use of (also) banks or, more generally, custodians such as exchanges, prepaid cards, or any financial intermediation service.

Recognising the shortcomings of the current monetary regime does not mean that it should be considered an act of shame to load money or bitcoins onto a debit, supermarket or PayPal card. After all, as long as the bulk of our savings are safe in a Bitcoin wallet, and as long as we can execute the transactions for which we need privacy, or those that would otherwise risk being censored, we can still use the intermediaries who are convenient for other payments. In fact, the greater the number and variety of these intermediaries on the market, the better.

Paying through a layer 2 solution is preferable to transacting onchain and thus clogging the mempool, especially if it is possible to do so without jeopardising our security and autonomy. If we are not able to use Lightning Network due to inability or impossibility dictated by the situation, the accounting books of a custodian can also constitute a good layer 2 solution, provided that a quantity of value no higher than that required to process their ordinary payments is deposited.

A custodian allows to scale because it performs the function of a clearinghouse, both internally (between accounts of users using the same custodian) and externally (channels between different custodians).

• Internally, because if A and B exchange bitcoins and the custodian holds in reserve funds of both, the custodian will only write on a database the accounts of the money transfer, thus being able to manage potentially endless transactions without the blockchain being touched. For example, moving money between accounts of Coinbase, Coinsbank or many other services is free and instantaneous.
• Externally, through two ways: 1) a simple contract between custodians, or 2) a layer above the blockchain that can be used by a custodian (e.g. sidechain like Liquid, but also Lightning Network). For example, two custodians can allow users to move funds from one to the other and track these movements only in their respective books, carrying out only one onchain clearing transaction – for example – at the end of the month. To date, these solutions are not very adopted (there is no news of significant cases), also because, for such a contract, a lot of trust is required between the two custodians, whereas there are more sophisticated layers that require less trust in a single counterparty, as discussed in the next paragraph.

2. FEDERATION (LIQUID SIDECHAIN): PARTIALLY DECENTRALISED TOP LAYER

Liquid is the sidechain created by Blockstream. This is just an example of such a layer, but it is certainly the most significant, having as partners and testers 23 companies including Bitfinex, BitMEX, XAPO, OKCoin and The Rock Trading.

The operation requires that each exchange freezes a certain amount of BTC on the Bitcoin blockchain, allowing the “BTC Liquids” on the sidechain to be unlocked. After a potentially infinite number of transactions using “BTC Liquid”, when an exchange wants to exit the sidechain it loses its “BTC Liquid” and regains possession of the BTC on the Bitcoin blockchain. In this way all the transactions that users make between one exchange and another can be processed by the sidechain instead of clogging the mempool and increasing traffic on the Bitcoin blockchain.

The sidechain is a blockchain stored at the nodes of the custodians. It has no proof of work, the “miners” who create the block are the exchanges/custodians themselves who agree to “sign” the next block by majority “vote”. In short, the sidechain is like the clearinghouse that processes payments between custodians, with the difference that it is not necessary to trust only one single counterparty, but the majority of participants who join the “federation”. The system continues to operate as long as at least n exchanges on m join the system signing the new blocks. There may be problems (e.g. funds are held at a standstill because the majority is corrupt or attacked), so custodians only join such projects if they think it is advantageous to trust the majority of a group of known companies rather than a single counterparty. Above all, however, the greatest advantage and that makes this tool much more effective for scalability is the fact that, in a federation, all participants can freely exchange among themselves offchain, rather than having to open a bilateral channel with a single counterpart.

So far we have talked about layers that from the point of view of decentralisation are worse than the onchain Bitcoin transactions, so it is fair to ask if an aggregate use of these layers can lead to problems at the socio-economic level. There is no doubt that, in a Bitcoin economy, custodians and federations do not have the destructive and distorting power of the production dynamics that is instead in the hands of banks and central banks of the regime in force with fiat currencies. In fact, for those who keep bitcoins it is much more difficult to practice fractional reserve in a non-transparent way and, consequently, monetary expansion. Bitcoins on the blockchain cannot be “duplicated” and a verification of custodians’ balance sheets (proof of reserve) is much simpler and more practical, as well as transparent to the public, than the verification of bank balance sheets and the calculation of monetary expansion made through credit activity, which creates fiat money out of thin air. On the other hand, layer 2 solutions are also completely transparent from this point of view, because they are created using a one-to-one “peg” with bitcoins on the blockchain (which applies to Liquid as well as Lightning Network).

In any case, even in a Bitcoin economy, using a custodian, as useful as it can be, should be done with caution: it is advisable to store most of one’s value somewhere else. The same is true for a federation of several custodians, which can be “decentralised”, from a geographical point of view and also of jurisdiction (companies that work in different continents, under different rules and “sovereigns”), but it cannot be excluded that mafia collaboration between states, tyrants or parasitic democratic majorities can undermine the integrity of the majority of these custodians, jeopardising the system.

3. LIGHTNING NETWORK: DISTRIBUTED TOP LAYER

The main solution is obviously Lightning Network, which is extensively discussed here (for the less technical) or here (for the more technical), as well as in the related glossary entry. The main criticism of Lightning Network is the fact that, although it allows transacting at exponentially higher levels than the blockchain, it still requires a very substantial increase in the size of the blocks.

To respond to these criticisms, it is important to first imagine a practical case of how a Lightning channel will actually be used in the case of mass adoption, and then draw the conclusions as to how much space is needed on the blockchain at the aggregate level.

In the described scenario we will not consider the impact of the LN technologies that are not yet working or not adequately tested: neither Atomic Multipath Payments (which allows a large payment to be divided between several channels) nor the Dual Funded Channels (which allows opening a channel through the funding of both counterparts instead of just one) nor, therefore, the Multi-party Funded Channels (the so-called Channel Factories that we will talk about later).

So what I am presenting here is my hypothesis of the operation of LN that is already possible today. The following scenario envisages the use of a technology which, although unripe in relation to potential developments, is nevertheless fully functional. We can, therefore, expect that when we get to the first stages of real “mass adoption” it will be well established, with user-friendly wallets accessible to all.

It’s a personal opinion, but unlike what can be read on the web, I think that the Lightning channels, in this first stage of adoption on a large scale, will be relatively large, with a value that reaches even a few thousand euros, or at least large enough to allow the transfer of an entire salary in a single channel.

Think of an employee, for example:

• To manage any ordinary income (salary), the user can use only one channel, the one opened with the employer.
• To manage the outputs (expenses), the user can also use the opened channel with the employer as the main router. Since an individual generally doesn’t spend more in a month than they earn in the same period, the channel will have sufficient capacity to cover any ordinary output.
• Generally, a user may have only one Lightning channel, or in any case a main channel that is the vehicle of almost all his transactions.
• Assuming that an employee saves a certain amount of bitcoin of his monthly salary each month, then he will have to integrate (or close and reopen) that one Lightning channel very rarely within a year.
• Based on hypotheses 1-4, a rule that allows estimating the frequency of use of the blockchain by such an employee is as follows: given “s” the salary and “c” the capacity of the channel, there will be a new transaction onchain in a period of time equivalent to the time in which the employee manages to save an amount of money m > c – s

This last point (5) is explained below with an example. If bored by technicality, the reader is invited to go directly to the last paragraph of this chapter, going on to the BLOCKCHAIN section.

Let’s assume we’re Bob, a skilled worker working for FCA (Fiat Chrysler Automobiles) with a salary of 2000 euros (in bitcoin). Let’s also assume that his average monthly expenses reach 1500 euros, so if one month he spends 1000 euros, the next month he spends 2000 euros and so on, returning to an average of 1500 euros. For simplicity, we will represent the value shifted to the Lightning channels in euro, but obviously, only bitcoins will be transacted.

Upon recruitment, FCA opens a €3,000 credit channel with the employee. Let’s imagine that the latter spends most of his salary on Amazon and Tesco. We can assume that FCA, Amazon and Tesco, as big companies, have several Lightning channels open and that there is at least one direct channel between them (which also helps us simplify the representation).

At the moment, the open channel between Bob and FCA has 3,000 euros, all in the possession of FCA. We represent him as follows, where “0” (zero) is Bob’s money on the channel, and “3” the three thousand euros of FCA:

Bob-FCA: 0 | 3

We then represent the initial state of the channel on the day of Bob’s first salary, when 2,000 euros are paid by FCA to the employee Bob:

Bob-FCA: 2 | 1 (Bob receives 2k euro salary)

Again on the basis of the same hypothesis, the channel between companies also amounts to 3,000 euros, of which 2,000 are held by the FCA in both channels.

FCA-Amazon: 2 | 1

FCA-Tesco: 2 | 1

During the first month, Bob does his shopping several times at Tesco, spending a total of one thousand euros, because he is very hungry. FCA acts as an intermediary channel, so at every expense, it takes money from Bob and releases the same amount to Tesco, in the respective channel, for a total of one thousand euros. We’re in State One.

STATE 1:

• Bob-FCA: 1 | 2 (Bob pays 1k euro)

• FCA-Amazon: 2 | 1

• FCA-Tesco: 1 | 2 (Tesco receives 1k euro)

Now the balance of FCA is unchanged as it holds a total of 5,000 euros as before (if we add up the availability of all its channels), but the distribution between channels has changed, due to the payment that Bob made to Tesco using the FCA channels as an intermediary.

At the end of the month, Bob has a saving of 1000 euros. The remaining €2000 is therefore sufficient for a new salary, allowing the Lightning channel to be used again.

The second-month passes and the FCA pays Bob his second salary:

STATUS 2:

Bob-FCA: 3 | 0 (Bob receives 2k euro salary)

FCA-Amazon: 2 | 1

FCA-Tesco: 1 | 2

We said Bob spends an average of 1500 euros. Having spent 1000 the previous month, this month he will spend 2000. This time he makes purchases both at Tesco and at Amazon, always using the FCA channel. At the end of the month the situation will be:

STATE 3:

Bob-FCA: 1 | 2 (Bob spends 2k euro)

FCA-Amazon: 1 | 2 (Amazon receives 1k euro)

FCA-Tesco: 0 | 3 (Tesco receives 1k euro)

He then perceives the salary of the third month:

STATE 4:

Bob-FCA: 3 | 0 (Bob receives 2k euro salary)

FCA-Amazon: 1 | 2

FCA-Tesco: 0 | 3

This month Bob will only spend 1000 euros, we assume at Amazon:

STATE 5:

Bob-FCA: 2 | 1 (Bob spends 1k euro)

FCA-Amazon: 0 |3 (Amazon receives 1k euro)

FCA-Tesco: 0 | 3

At the end of the third month, Bob exceeded the saving threshold of 1000 euros, having accumulated 2000 euros. The condition we stated was fulfilled: m > c – s. In the fourth month, FCA has no space in the open channel to pay a salary of 2 thousand euros to Bob, as it would exceed the limit sum for the capacity of the open channel with FCA. A new onchain transaction is therefore required, where FCA “reloads” the channel while Bob moves his savings, which he can transfer:

1. in another LN wallet via an offchain transaction, or
2. into a cold wallet via an onchain transaction.

The option (a) is the most interesting: having an open channel with yourself is convenient because it means having access to the “liquidity” of LN (ease of moving your money instantly, paying minimum fees) while not needing to monitor the channel via watchtower, nor periodically going back online to check the status of the network. In fact, in an open channel with oneself, no one can steal from you, unless there is a Tyler Durden hiding inside of you who instead of throwing punches enjoys messing around with the LN channels (spoiler alert: if you don’t know what I’m talking about, don’t google it).

As simplified as it may be, this scheme allows us to understand that a user like Bob can use LN by making all the ordinary payments he needs within a year, while very rarely transacting onchain. In the conditions presented in the scenario, the Bob-FCA channel must be renewed 4 times a year, thus representing only 4 onchain transactions, to which must be added the transactions used to transfer BTC from and to a cold wallet, for savings or for extraordinary expenses.

Since the model is very simplified, there are various clarifications to be made:

• FCA has a “cost” dictated by creating a channel with Bob for the fact that it acts as a provider of liquidity (at the opening the channel is 1000 euros higher than what is necessary for the payment of the first salary). However, there are two considerations to be made in this regard:

1. Keeping Bitcoin “frozen” has a rather low cost, given the deflationary nature of the currency. The incentive to get rid of one’s money as soon as possible is inherent in the inflationary currencies of the last century, not of a healthy economy.
2. The cost, however, is absorbed by the fact that FCA acts as an intermediary for Bob’s payments, earning a small fee on the routing of Lightning payments.
3. If point b is not enough, FCA could also calculate these costs within the contractual relationship with the employee.

• The fact that Bob spends everything alone at Tesco and Amazon is a simplification. What if he had to pay a small merchant? It is very likely that that merchant is linked by an LN channel with good availability at least with its most direct distributor, and that this distributor has direct or indirect channels with Amazon, Tesco or FCA, so in case of mass adoption it is difficult to think that worker Bob can not pay the merchant either by using LN or, perhaps, through the channels of a liquidity provider that both rely on (examples of such providers already exist, such as Bitrefill with the “Thor” service).

However, it can always happen that two users are not connected by any channel with sufficient availability, either directly or indirectly. If they do not even have a common custodian service, users will have to make an onchain transaction. We’ll see later how this can weigh on the blockchain.

• In the “State 4” of the channels, Tesco and Amazon have 3 thousand euros each on their side of the channel and FCA has zero. It would seem that an onchain transaction is required to continue using the channel if Bob wants to spend more money, however, it is likely that, as FCA acts as an intermediary for Bob, also Tesco and Amazon act as intermediaries for FCA: let’s think of an employee of Amazon who buys a Fiat car. Contrary to the extremely simplified demonstration presented here, the channels will, therefore, be balanced in both directions.

The LN network as presented here is already well distributed, but with a limited capillarity as users are accustomed to using almost always the same channels. It would, therefore, be an extremely simple and underdeveloped LN network, which would be possible already in the first years of mass adoption. That’s why the “big” channels are so popular. If the number of onchain transactions carried out by Bob in the scenario analysed above seems too low, we can also assume that Bob requires ten times as many. A tenfold increase does not move us, in this context, to such a different order of magnitude. If in order to satisfy Bob’s need to make onchain payments, we were to increase the blocksize from 1mb to 10mb, then it would certainly be a very impactful intervention, but as we will soon learn by doing some math, there is no direct proportionality between the number of onchain payments and the weight of the transactions.

So, to understand if this system scales enough to support a Bitcoin world economy, we need to see what the real capacity of the blockchain is, net of all the technological and organisational improvements that allow for an incredible multiplication of payments for the same number of transactions. Only at the end of this article will we draw the threads of the discussion, imagining what could be the result of the combination of all the innovations discussed here.

THE BLOCKCHAIN:

The Lightning Network scenario described above, as we have already said, is an optimistic simplification. There aren’t only the ordinary and expected expenses, with counterparts already connected by existing channels like in the model presented, nor are there only the transactions to refill the channels. There are also those made by mistake or for a wrong calculation of the usefulness and effectiveness of a certain channel that is opened (and which will then be closed), transactions to cold wallets, transactions that do not fall within the ordinary estimates, which means large movements of value, transfers to custodians and services, use of the blockchain for notarial purposes, users who create more “capillary ” channels and with much more limited capacity and therefore need more ” replacement “, etc..

Visa processes 150 million payments a day. Let’s assume we want to not only become like Visa but outperform it. Let’s say we get up to 500 million payments a day. To date, the blockchain has managed to process a peak of almost 500 thousand transactions per day (490 thousand). We do not know how many payments are made offchain, but if we want to get to 500 million we have to add three zeros to the number of onchain transactions. For each onchain transaction, there must be a thousand transfers made through Lightning Network, or within Custodians, Federations and sidechains. Is such a scenario feasible? Those who are sceptical will probably be surprised by the potential of the Bitcoin blockchain.

1. CAPACITY UPGRADE: INCREASE OF THE BLOCK SIZE AND SEGWIT

The best-known way to increase the capacity of the blockchain is to carry out a fork (an upgrade of Bitcoin) in order to increase the size of the block. SegWit, approved in August 2017, brought with it an increase in the block without touching the blocksize parameter, which remained at 1mb: since with SegWit, (Witness) signatures are divided (Segregated) by the blocksize and inserted into a new structure called blockweight, and since signatures account for a large part of the space occupied by a transaction, by transacting with SegWit it is possible to obtain a doubling of the capacity (an exact figure does not exist, since it varies greatly depending on the type of transactions carried out). To date, SegWit is used for less than half of the transactions, simply because many users or services have not updated their wallets yet.

So, if prior to SegWit we could only perform 100 transactions, after SegWit it’s possible to do 200 transactions, but today we’re still at 150. By the time everyone switches to SegWit we’ll reach the maximum capacity utilisation of the blockweight (exploiting about 25% of unused space). If you still have an old Bitcoin address (the ones starting with number 1) it is worth updating, also to pay fewer fees when transacting!

2. EFFICIENCY UPGRADE: BECH32 AND SCHNORR

2.1 BECH32

Currently, the most used SegWit addresses start with the number 3, as these were the first implemented on wallets and services. However, the real native SegWit addresses are the bech32, which are well recognisable because instead of starting with 1 or 3, they start with bc. For example, this is my public address:

bc1q46zj4w04hfz2jegympwfkd09wxe3nptchegk6

(by making a generous donation you can win magical discounts!!!)

The use of bech32 addresses alone allows saving at least 10% of the space on the blockchain compared to when using P2SH addresses (Pay To Script Hash, which start with 3, even the segwit ones). P2SH addresses occupy 1 more byte per output and 24 more bytes per input compared to bech32 addresses. On average a transaction weighs 250 bytes, so with a transaction of 1 input and 1 output, it is possible to save 25 bytes using bech32. However, this saving increases the total weight of the transaction if the inputs and outputs increase. In fact, while Ethereum transactions always have 1 input and 1 output, the Bitcoin blockchain is able to organise transactions in an incredibly efficient way. Often a transaction does not correspond to a payment, indeed today the average is almost 2 payments per transaction (an estimate of 700 thousand payments per day in 400 thousand transactions).

There are tools that allow scaling, but it is up to the users to start using them. In a nutshell, it’s not Bitcoin that scales by itself, it’s us who have to scale with Bitcoin. While Lightning Network is understandably still something rather complicated to use at the moment, which is why it is good to leave it to exchanges and services or to more geeky users, starting to use native segwit bech32 addresses is something that benefits not only the ecosystem, but also ourselves, as we would pay lower fees.

2.2 SCHNORR

Schnorr is a technology that can be truly revolutionary for Bitcoin. We’re talking about the future, but it’s not all Half Life 3-style vaporware: Schnorr exists not only in theory but also in practice. Just as SegWit was approved on Litecoin before Bitcoin, so Schnorr was also already approved on Bitcoin Cash. Since Schnorr has a heavy impact on the structure of Bitcoin, it is understandable that there is the utmost caution in performing a fork of this type. Coordinating a totally free market ecosystem towards such an upgrade is not an easy task. But what Schnorr allows to do is amazing in terms of scalability.

Today, when bitcoins are traded, the owner has to “sign” the transaction with his own private key. Each input must be signed, thus taking up space on the blockchain for each signature. For example, let’s assume that we have received 10 payments of 1 bitcoin each on one address. To move those 10 bitcoins you need to use 10 different inputs, which means you have to sign 10 times. Schnorr streamlines this mechanism.

A Schnorr signature weighs 8 bytes less than a traditional signature, which means a 3% space-saving per transaction with just one input. The more the inputs, the greater the discount.

But the true revolution will be the possibility of aggregating signatures (a technology that requires an additional fork, not yet implemented on Bitcoin Cash): that is, when a transaction has more than one input, the space occupied in the blockchain will be only that of a signature and a public key, and not one for each input. This means that, for the same type of transactions that are carried out today on the Bitcoin blockchain, we would gain 30% of space.

However, 30% is nothing compared to the real potential of this innovation. If wallets and services took advantage of this feature, organising transactions of a special type, the reduction in costs would be incredibly greater. This is where fundamental concepts such as batching, coinjoin and channel factories come into play.

3. ORGANISATION: BATCHING, COINJOIN, CHANNEL FACTORIES

3.1 BATCHING

When a user sends bitcoins from one custodian to another, for example from Coinbase to Bitfinex, from Kraken to Wirex etc., the custodian does not make the transaction immediately, unless there is a layer 2 channel open between the two companies. Instead, it waits for a series of requests of that type to accumulate and then starts all the transfers in a single aggregate transaction on the Bitcoin blockchain. This type of organisation of the transfers requested by its users is called batching and since 2018 it has been widely used by all (or almost all) the main services. Hundreds or thousands of payments can be processed with a single Bitcoin transaction.

Each transaction consists of several parts and obviously, in addition to input, output and signature (or signatures), has a “fixed” part. Combining many outputs in a single transaction, instead of executing as many transactions as there are payments required, allows saving costs on the fixed part, as this is present only once instead of being multiplied by the number of payments. Exchanges such as Kraken and Bitfinex have been able to greatly reduce their exit fees from the platform thanks to batching, which has thus benefited both customers and the entire ecosystem, due to the fact that the weight on the blockchain is considerably lower for the same result.

The more transactions you aggregate, the more you save. Aggregating only two transactions, the weight per payment is about 130 bytes. Aggregating 50, the weight for each payment is 34 bytes. The saving is enormous and the occupied space S, if x is the number of aggregate transactions, corresponds to:

S = (192 + x * 34 ) / x

This table shows the weight in bytes occupied by each payment per number of payments that are aggregated into a single transaction.

There are examples of transactions with thousands of outputs. The following transaction, for example, dates back to January 1st, 2016 and has 13 thousand outputs, weighing 445 kilobytes, thus half of the capacity of a block is occupied by this one transaction.

If all bitcoin transactions were like this, there would be about 2 million onchain payments per day, about three times as much as today. Also, if all addresses are bech32, there would be an additional saving of 16%. Obviously, it is absolutely unlikely to have blocks full of transactions with a single input and thousands of outputs like the one reported, so batching alone does not allow tripling the capacity of the blockchain, except in extreme cases. However, the combined use of batching and aggregation of signatures through Schnorr can achieve similar results. In this respect, an interesting case to consider is coinjoin.

3.2 COINJOIN WITH SCHNORR AND SIGNATURE AGGREGATION

Coinjoin is a solution that was originally designed to protect users’ privacy, however, by aggregating signatures with Schnorr it becomes the most powerful means of onchain scalability.

First, let’s see how Coinjoin works: let’s assume that Alice, Bob and Charlie live on three different continents, but all three have, for whatever reason, to do a 1-bitcoin transaction and are interested in hiding their identities as much as possible, so as to confuse those who use chain-analysis tools to track their movements.

Alice’s wallet, if it is sufficiently advanced to allow coinjoin (e.g. Wasabi wallet) will send the request to use coinjoin for a 1-bitcoin transaction to the network, and wait for other users to make the same type of request. When Bob and Charlie’s request to transact also arrives, the three wallets sign the inputs making a single joint transaction that has 3 outputs, each with 1 bitcoin. The recipients of these three outputs will be the respective counterparts of Alice, Bob and Charlie to whom they wanted to send 1 BTC. A, B and C don’t know each other, yet they have taken advantage of the matching interests (all three have to transact the same amount at the same time) to “mix their bitcoins” before they arrive at their destination.

The strength of this type of transaction organisation lies in the fact that it is a peer-to-peer system among users, and therefore not dependent on a service such as a custodian coordinating the execution of coinjoin. The more participants in the mixer, the greater the privacy. The system works only if at least one output for all three users corresponds to 1btc, otherwise, the chain-analysis operator could associate the quantity of bitcoin entered for each input with the quantity of bitcoin of the outputs, reconstructing the transactions. If, however, the focus was no longer on privacy, but on scalability, it would be possible to easily use coinjoin without paying attention to the identical outputs, so anyone in the world could combine their inputs with any other person who is transacting.

This is a coinjoin transaction between 98 users who used Wasabi wallets. It is a mix of 113 inputs and 211 outputs, for a total of 98 payments and 23kB of space occupied (56kB of blockweight).

To date, the sole purpose of Coinjoin is privacy, as there is no advantage in terms of scalability in aggregating transactions. If a Bitcoin block were to be occupied entirely with transactions of this type, there would be about 40, therefore 4,000 payments per block, 576,000 payments per day. Compared to today there is basically no advantage … until Schnorr is used.

If we combine Schnorr with coinjoin, as well as a soft fork that allows the aggregation of signatures and public keys, more than 100 bytes of signatures and pubkeys would be saved for each input (see the part of the signature in a transaction). If we then aggregated the signatures of the inputs for transactions like the one above (for about 100 payments), there would be about 80 in a block, thus 8,000 payments (~1.1 million per day). The more users (and payments made) participate in the coinjoin, the more efficient the mechanism becomes, as fewer signatures are included in the onchain transaction (one for all participants). If we had to imagine a coinjoin transaction as large as possible (to cover the entire block), we would have enormous cost savings. With such large numbers, it is also likely that, simply by chance, several of the outputs will match exactly in the amount of bitcoins transacted thereby still obtaining a mixing effect as a beneficial “side effect”.

A single coinjoin occupying a whole block of 1mb would weigh 70 bytes per payment, up to about 14 thousand payments in a megabyte of blocksize, so over 2 million onchain payments per day.

We have seen that it is possible to achieve a much higher capacity of the blockchain by simply better organising the ecosystem (in the case of batching), or by combining the organisation of wallets and services with Schnorr and aggregation of signatures and pubkeys. Without adding a single byte of capacity to the blocksize. If the capacity of the blockchain is tripled for the same amount of space, it also means that any possible future increase in blocksize is three times more efficient.

3.3 CHANNEL FACTORIES

Now that the aggregation of payments is clear, the last step is missing, i.e. to understand how this type of aggregation can be applied to Lightning Network as well. An improvement in the performance of the blockchain leaves more room for transactions of opening and closing channels, but this is only one side of the coin. The real benefit is that the same Lightning transactions of opening channels can be “aggregated”, in a mechanism called Multi-party funded channels. This concept first appeared in the paper Scalable Lightning Factories for Bitcoin and then evolved into Scalable Funding of Bitcoin Micropayment Channel Network which is an incredibly simple and graphically clear paper.

We already anticipate that the channel factories are the real killer application, the one that makes the small block purists hope that the blocksize parameter will never be changed.

The mechanism of operation is very simple: instead of opening a channel between just two users, several users combine the funds in a “funding”, which is actually the only output of a single large transaction, containing as input the bitcoins from each user’s wallet. No user should trust others because at any time they can decide to unlock those funds themselves, since the transaction is created with the same multisig and checksequence mechanism typical of Lightning Network, simply extended to more people.

Starting from this output blocked onchain, all channels between users are built offchain: it is possible, but not necessary, that each participant opens a channel with each other user (as in the illustrative graph below, with only three users). These channels can be closed and reopened without ever going back onchain, provided, of course, that the money movements do not exceed the quantities injected into the original funding. In a nutshell, funding is a layer 2 Lightning Network channel, while the real Lightning bilateral channels are a kind of layer 3 that is built on top of it.

In the example in the figure, let’s assume that A, B and C share 1 bitcoin each in funding, for a total of 3 BTC (the three coloured balls). Each channel will be opened with 0.5 bitcoins on each side, so for example, 1 bitcoin of A (the light green ball) will be divided so as to create one channel with B and one with C.

A will have 0.5 BTC in the channel with C and the other 0.5 BTC in the channel with B. Each channel will have a total capacity of 1 BTC, so the capacity of the A-C channel will be 1 BTC, of which half will belong to A and half to C:

A-C: 0.5 | 0.5

If A pays C half bitcoin, the balance in the channel will change to be:

A-C: 0 | 1

Normally in Lightning Network, this means that tomorrow A will no longer be able to pay another 0.5 BTC to C, as it would mean passing on the C side of the channel as many as 1.5 BTC, which would be impossible for two reasons:

• A does not have that availability in the channel with C
• The maximum capacity of the channel, calculated by adding the funds of A and C in AC, has already been reached, as it is limited to 1 BTC

Yet A has 0.5 BTC available in the channel with B. Due to the fact that all these channels are on a “layer 3”, A can close the channel with B and C and this operation remains offchain, since the FUNDING onchain output is not touched. The funds in FUNDING are only “reshuffled” when creating new channels so that A can open a new A-C channel using as much as he previously owned in the A-B channel. The result will be:

A-B: closed channel (no onchain transaction required)

A-C: 0 | 1.5 (reopened with 0.5 BTC extra capacity, no onchain transactions)

This system is great for three reasons:

• It is possible to open and close channels on layer 3 endlessly without ever transacting onchain

• The transaction fees for the onchain creation of the original funding are divided among all participants in the channel factory

• Original funding aggregates the “channel opening” transactions of many users, saving an incredible amount of space on the blockchain

Think of 10 users who combine their funds in a single funding and from here create 45 channels between them, making sure that each user has a direct channel with all others and can close and reopen channels, as needed, with any of these 10 other users.

Note: for 10 users (from A of Alice to L of Lyon) the minimum number of direct channels is 45, according to the mathematical formula m = n(n-1)/2; with m = number of channels and n = number of users. To count them a less elegant, but more intuitive, way, we would proceed as follows:

A opens a channel with B,C,D,E,F,G,H,I,L (9 channels)

B opens a channel with C,D,E,F,G,H,I,L (A-B already exists, so 8 more channels are opened)

C opens with D,E,F,G,H,I,L (A-C and B-C already exist, therefore another 7 channels are opened)

…and so on.

If we analyse the weight of a channel factory that brings together 10 users compared to the creation of 45 bilateral channels, each with a specific onchain transaction, we note that space saved on the blockchain is 90%. If Schnorr was used, it would be as much as 96%.

This means that the channel factories increase the possibility of the blockchain to host Lightning channels by more than 20 times for the same space occupied (only 10 times without Schnorr)

In addition, Layer 3 channels built in a factory are much more “useful” than typical Lightning channels, since they can be recombined at will, opening up new transaction options between all users involved.

The problem with this solution is only one: the more users there are, the more likely it is that only one of them will want to close the factory. If only one chooses to close (or if only one user is to be added to an existing factory), it is necessary to transact onchain, and each layer 3 channel must be closed. The good news is that all participants who remain in the factory can rebuild layer 3 channels with the same closing transaction as the channel (which closes the factory excluding the user who wants to leave, reopening it for all others).

On the other hand, it is also true that the greater the number of participants (the larger the channel and its capacity), the greater the incentive to stay in it for each participant, since the bitcoins in Lightning are more liquid (spendable at lower cost in terms of time and fees) than the bitcoins onchain. One can imagine a future Bitcoin network made almost entirely by channel factories of user groups, where all the main bitcoin movements occur almost exclusively on a third layer of Lightning channels.

The more users there are, the more money can be saved. But even with only 10 users, a channel factory weighs 985 bytes, with Schnorr 435bytes (these are all approximations). It means that in 1mb block it is possible to create 2.300 transactions of this type, that is 23 thousand users who create 103 thousand channels. Counting 6 blocks in one hour and 144 per day means that every day 3 million people can create almost 15 million channels.

CONCLUSION: LOOKING FOR ANSWERS IN THE CHICKEN’S ENTRAILS

With the full adoption of SegWit, it is possible to gain 25% of additional space in the block. With bech3 10% per transaction can be saved and this increases as the inputs and outputs increase. With Schnorr, it is possible to save another 3%, which increases with more inputs. With the batching of transactions the weight of each payment drops to 34 bytes (with a single input), with a saving of more than 80%, while with the aggregation of signatures and public keys with Schnorr each payment would weigh about 70bytes, with a saving of 65%. These improvements greatly reduce the space taken up by all the typical onchain transactions: high-value payments, clearing transactions between custodians, sending money between users and custodians or savings placed in cold wallets.

Meanwhile, those who rely on custodians and custodian federations (sidechains like Liquid) can move funds potentially indefinitely without impacting in any way on the capacity of the blockchain.

Excluding notarisation/timestamping transactions, that essentially represent the only function of the blockchain as an alternative to the monetary one, all the remaining space will be used to create and close Lightning Network channels.

By leaving the blocksize at 1mb and implementing all the innovations on layer 1 (blockchain) described above, we can get to 2 million payments onchain. Even increasing the current network throughput from an estimate of the current 700,000 onchain payments to 1 million, we would have significant space for the Lightning Network channels with still low fees, let’s say 500,000 bytes per block. It means being able to open 2,500 Lightning channels, 360 thousand a day, 130 million a year (without channel factories, which for the moment we are excluding from the calculations).

We’ve seen that a user can “live” using just one Lightning Network channel for months without doing any more onchain transactions, and 130 million channels a year may seem like a lot, but let’s not get too excited: the comparison with Visa is still losing. If a channel has a life of 3 months and it takes at least 4 months for each user per year, it means that only 30 million people will be able to transact with LN on a daily basis.

An average American citizen makes about 40 electronic payments per month (70 total payments, 60% of which are electronic). If these consumption habits remain unchanged, it is likely that users will not use LN for more than 40 payments per month, so no more than 480 transactions per year. Multiplied by 30 million, they result in 15 billion transactions per year.

There are 780 million Visa credit cards processing 150 million transactions a day, with 55 billion transactions a year, compared to the hypothetical 15 billion on LN. Even if each of the 130 million channels per year has the potential to handle more transactions, reaching Visa would require more channels to reach new users, but there is no room to create more. And our estimate of space was already optimistic.

The calculations have been made with the starting hypothesis and the various predictions, but in this approximate race, Visa seems to win against Lightning Network. This does not necessarily mean processing more Bitcoin transactions. In fact, we would still have the role of custodians and federations that, potentially, can completely bridge the gap. And it would be enough to double the blocksize to achieve a far more than proportional gain.

Hold it, though. Is it really necessary to involve custodians and the increase in blocksize? We are still talking about billions of transactions per year with LN alone. There is no doubt that it can be defined as mass adoption. At that point, one can expect a much higher number of researchers and programmers to work on Bitcoin technologies. In such a historical moment, it would be naive to think that the Lightning Network technology will not implement some other innovation born from the minds of cypherpunks.

If the calculations were to be remade, this time with channel factories, everything changes: with 500,000 bytes of space (half a blocksize, assuming that the other half is used for other types of transactions) we could carry out 1150 transactions from 10 users each, for a total of over 50 thousand channels. That’s 7 million channels a day, 2.5 billion channels a year. There are 7.5 billion of us on earth, including old people, children, North Koreans, Amish and flat earthers. So can Bitcoin reach adopt…?

Yes.

Bye

Follow the daily updates on the facebook page: https://www.facebook.com/albertodeluigi.news

Subscribe to the blog newsletter to be notified of each new article published