Bitonic App
Download from Google Play
Download from the App Store
From 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 socalled 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
It was interesting to see that eight members of the panel discussion about mining hold 90% of the Bitcoin hashpower:
The 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’ selfinterest is in accordance with that of Bitcoin.
Pieter 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:
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 multisignatureaddresses. 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.
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 transactionid. If the signature is kept out of the transaction itself, it won’t have any influence on the transactionid.
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 softfork.
Sheets presentation Pieter WuilleBitonic 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 opcode.
Lastly, Segregated Witness is desirable for the best kind of Lightning Network; with Segregated Witness it becomes possible to issue nonconfirmed 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.
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.
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:
As mentioned before, nodes check and verify whether rules of the Bitcoinprotocol 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:
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.
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 pointofnoreturn, 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.
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.
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/
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/
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!
”An invitation only developer event for hacking together on Bitcoin-Core and related projects.” Bitonic levert een bijdrage als sponsor: http://coredev.tech
The following Core Developers were present:
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.