Report II Scaling Bitcoin workshops

A while ago part II of the Scaling Bitcoin Workshops took place and a lot has happened since then

Nederlandse Bitcoiners in HonkongFrom left to right: Aaron, Jouke, Corné & Niels

In this post we would like to not only refer to the Hong Kong event, but also to the events that occurred in the meantime. The topics discussed in this article are: the roadmap of Core Developers, the difference between a so­called soft forks and hard forks and the status of a number of developments, such as Lightning Network.

This article can also be found at: medium.com/@Bitonicnl

Scaling Bitcoin Hong Kong

It was interesting to see that eight members of the panel discussion about mining hold 90% of the Bitcoin hashpower:

Hashpower op het podiumThe mining panel, with AntMiner, Slush, FinalHash, BTCC & BitFury, among others

This obviously makes one wonder about the concept of centralization; we are generally opposed to any kind of centralization, but at the same time we don’t see the centralization of hashing power as a real issue, as long as the economic incentives for miners make sense, i.e. as long as the miners’ self­interest is in accordance with that of Bitcoin.

Segregated Witness, by Pieter Wuille

Pieter Wuille over Segregated WitnessPieter Wuille presents Segregated Witness

Segregated Witness ­ or: the decoupling of cryptographic signatures of bitcoin transactions ­ in our opinion is the most important and best solution to the scalability of Bitcoin at this point. These are the advantages:

  • Segregated Witness can be implemented by a so­called soft­fork. Later on in this article we’ll delve into the reasons why we prefer a soft­fork over a hard­fork;
  • Segregated Witness solves the problem of transaction malleability, a weakness of Bitcoin for which currently no solution exists;
  • Using Segregated Witness, the implementation of Lightning Network will become easier;
  • And most importantly, blocks with their current space of 1Mb will be able to deal with more transactions. The effect would be equal to a block size increase of 1.75 to 4Mb.

As many as 60% of the data in the blockchain currently consists of signatures, and this number will only increase because of the increasing use of multisignature­addresses. The graph below depicts this trend.

By implementing Segregated Witness a certain way, it is possible to separate signature data from the transactions, without the need of updating the nodes. Old nodes will still function the way they did, which means the old nodes will accept the current block size of 1Mb. New nodes validating new transactions will receive the signatures separately, and as such they will be able to allow more than 1Mb of data per block.

difference through Segregated Witness

With the signatures no longer making up a part of the transaction, transaction malleability would be solved as well; the largest source of malleability is adapting the signature and keeping it valid, while still having to change the hash of the transaction, also known as transaction­id. If the signature is kept out of the transaction itself, it won’t have any influence on the transaction­id.

The idea of Segregated Witness is not new, but the advantage of the way Pieter Wuille proposes to implement it, is the fact that the change needed to separate signatures can be implemented using a soft­fork.

Sheets presentation Pieter Wuille

Lightning Network

sponsoren van Scaling Bitcoin IIBitonic sponsors Scaling Bitcoin

In the report on the Scaling Bitcoin event in Montreal we already mentioned Lightning Network. In the presentation during the Hong Kong Scaling Bitcoin event Tadge Dryja talked about the functionalities needed to allow the Lightning Network to perform up to its full potential.

Initially, OP_CLTV (CheckLockTimeVerify) was needed as a basic form of the Lightning Network, in which channels between parties are opened temporarily, for a duration to be determined on opening the channel. CLTV is currently active on the Bitcoin network and this kind of Lightning Network is possible.

Additionally, OP_CSV (CheckSequenceVerify, also known as OP_MATURITY) is desirable, for a version of the Lightning Network in which channels between parties can stay open indefinitely. At this point miners are voting to implement this new op­code.

Lastly, Segregated Witness is desirable for the best kind of Lightning Network; with Segregated Witness it becomes possible to issue non­confirmed transactions reliably (since Segregated Witness solves the signature malleability). Segregated Witness has become a familiar concept by now and a consensus seems to have been reached that this is a good addition, and it is seemingly opposed by no one. We can therefore expect Segregated Witness to be implemented as soon as its development is completed.

Soft fork & hard fork

A ‘fork’ in software development occurs when source code is copied and modified by another party.

Imagine person X develops a software with a red background. Person Y can then ‘fork’ the source code of that software and turn the background to blue. People who prefer the blue background can subsequently continue to improve person Y’s software.

Within Bitcoin a fork is splitting the network into 2 or more directions, after which new blocks of one chain can no longer be exchanged with another chain.

The difference between a ‘soft fork’ and a ‘hard fork’

Simply put, it can be stated that with a soft fork in Bitcoin the rules in the protocol become more strict and with a hard fork they are loosened. This may sound contradictory, but this is how it works:

  1. Nodes check whether the rules of the Bitcoin protocol are complied with. Examples of such rules are: no more than 21 million bitcoins should enter the system; the speed at which a hash is calculated; the reward for miners; the inputs and outputs of a transaction; and so on.
  2. These rules can be modified. Strictly speaking modifying the protocol would generate an alternative version of Bitcoin (altcoin) , unless all Bitcoin stakeholders (nodes, miners, users, wallets, exchanges) accept these new rules.
  3. In case of a soft fork the rules become more strict, i.e. less is permitted than the previous situation. An example could be implementing a block size of 1Mb, in 2011. In the previous situation there was no block and as such the protocol became more strict with this rule.

  4. Old nodes that don’t upgrade to the new version, won’t have any issues with the new situation, because the new rules don’t impose a conflict with the old rules. This is a soft fork.
  5. If the block size would be modified from 1 to 2Mb, the rules are made less strict, because more will be allowed. If nodes do not upgrade, however, they will not be able to operate under this new rule of Bitcoin and they will therefore get stuck in the old alternative version. This is a hard fork.
  6. As an exception to what is stated in item 5 above, the very old nodes would be able to handle the new situation of the increased block size, but the number of these old nodes are insignificantly small.

Why is a soft fork desirable?

As mentioned before, nodes check and verify whether rules of the Bitcoin­protocol are complied with. Generally, if a node encounters a transaction or a block with contradictory rules, it will not accept the transaction or the block and, as a consequence, no entry in the Bitcoin Network is created. In case of a soft fork the new rules would be more strict and the nodes would therefore allow this automatically. An exception are the miners, who would still be able to make blocks with the old software that are no longer valid after the soft fork. This is shown in Figure 1:

schematische weergave Figure 1: diagram of a soft fork

In case of a hard fork, i.e. in case of a new situation using less strict rules, a node would not allow this. This automatically means nodes will not allow “new” situations unless the software is updated for a full node. As a result, one node will accept the new situation while another node will still be tuned to the old situation. In others words: hard forks are not backward compatible. This would in effect create 2 different Bitcoin networks, as shown in figure 2. This situation is clearly undesirable.

Apart from nodes, some wallets also check transactions in the Blockchain. These wallets would also encounter problems if the rules are modified and would therefore need an update too. In order to prevent the existence of conflicting software, it is important to reach the consensus of one single system. In the figure below a diagram of such a conflict is shown.

schematische weergave Figure 2: diagram of a hard fork

As illustrated, implementing a soft fork does not require an update of nodes and thus allows all current nodes to stay functional. And the amount of full nodes is a measure for the degree of decentralization. The more nodes in the world, the safer the network. Figure 1 shows that in case of a soft fork, the new situation will accept both the old and the new rules.

<

p> An additional advantage of the backward compatibility of a soft fork is that less miners will stay behind. In the proposed upgrade of the protocol forks will be implemented if 75% of the miners support the change. A support percentage of 95% is considered the point­of­no­return, at which old versions will be refused (See: Github BIP34 . In practise, this means that in case of a hard fork 25% of the miners will be left behind, whereas in case of a soft fork this percentage will not exceed 5%. That means a group 5 times smaller will be left behind in case of a soft fork.

The current state of affairs

  • Status Lightning Network

Rusty Russell, employee at Blockstream and a Linux developer veteran, is working on a test version of Lightning Network. The code can be found here: https://github.com/ElementsProject/lightning

In Bitcoin Testnet the concept of Segregated Witness already functions and as such implementations of Lightning can be tested.

  • Status Amikopay

Corné Plooij is also developing a version of Lightning network, in Amiko Pay. On this webpage a clear overview of the roadmap and the status can be found: https://cornwarecjp.github.io/amiko-pay/

  • Hot off the press...Thunder, by Blockchain.info

Blockchain.info has also presented a version which uses Payment Channels and which is based on the concept of Lighting Network: https://blog.blockchain.com/2016/05/16/announcing-the-thunder-network-alpha-release/

  • Segregated witness

OAt this point Segregated Witness is in its last test phase. During the last months a number of core developers have been working on integration, testing and optimization of BIP141, in which they Segregated Witness is described. Several necessary requirements have already been fulfilled and the integration is considered to be on schedule. See also the roadmap of Core. In the meantime there was a second meeting in Hong Kong, where developers got together to discuss the next steps in Bitcoin: Weak blocks and IBLT, Lightning ...

We’ll keep you posted!

COREDEV ZURICH 20–22 MAY 2016

”An invitation only developer event for hacking together on Bitcoin-Core and related projects.” Bitonic levert een bijdrage als sponsor: http://coredev.tech

    Topics on the agenda were:
  • R review & improve the p2p net refactor
  • Discuss P2P-layer end to end encryption
  • Review & Test Segregated Witness — “If it’s already merged or ready for production before the meeting, we could focus on improving segwith further, writing wallet adoption guides, etc.”

The following Core Developers were present:

CoreDevs

Earlier messages

News archive

Live Chat Consent

The live chat is a service provided by MessageBird B.V. which is (a.o.) subject to the EU General Data Protection Regulation (GDPR) and states they do not use your data for commercial gain. In order to load the Live Chat we ask you to consent to the processing of any data shared with us using the chat. By closing this window without giving consent the chat will not load and no data will be shared.
For more information please review the MessageBird Privacy Policy.