XBC Soft Fork

With the latest release of the BitcoinPlus 2.7.0, BitcoinPlus (XBC) has been dragged well and truly to the forefront of blockchain technology. This release includes the Bitcoin Improvement Proposal 65 (BIP65). BIP65 relates to CHECKLOCKTIMEVERIFY (CLTV). BIP65 is a Soft Fork to the BitcoinPlus Network. 

Live Tracker for XBC Soft Forks

 A soft fork is a backward compatible method of upgrading a blockchain. In other words, a soft fork is a software upgrade that is backward compatible with previous versions of the software. 

Previous Versions of the software may not be able to make use of the new features but will still be able to initially support the network. 

The network may reject blocks from those older clients once a certain percentage of newly mined blocks have signaled support for the soft fork. The change brought in by the soft fork will only activate if fixed criteria is met. For BIP65 once at least 75% of the last 1,000 blocks in the XBC Network is using Version 2.7.0,  then the soft fork will activate, allowing the network to make use  of CHECKLOCKTIMEVERIFY. Once the network is at 95% of the last 1,000 blocks any block with a version less than 2.7.0 will be rejected.

CHECKLOCKTIMEVERIFY (CLTV) Explained


On the surface CHECKLOCKTIMEVERIFY is not particularly exciting, it is a new opcode that prevents a transaction from being spendable until some time in the future, however we had this already in the form of nLockTime, the problem with nLockTime is that it could not prove that it was impossible to spend an output until that output could be spent. CHECKLOCKTIMEVERIFY improves nLockTime, by using both we can verify that the output is unspendable until the block height or time as specified in the time lock has been reached.

This has a few applications other than simply locking funds till later, you can use this time lock with multiple signature transactions creating a reliable escrow between two or more parties, non-interactive time-locked refunds, two-factor wallets where you hold one key and the service holds the other, if the service disappears the funds can be moved once the time lock expires and payment channels.

A Spillman style payment channel can be set up between two parties, one transaction creates a time locked fund and a second transaction releases that fund, a refund transaction can be created so that the payor can get their funds back if the payee disappears. This type of payment channel was vulnerable to the malleability issue that famously affected MtGox and caused them to go bankrupt, the malleability issue is that transaction hashes could be changed. The refund transaction in a Spillman style payment channel was vulnerable to the malleability issue, invalidating the refund transaction and making this no longer a trustless payment channel, as the customer would then have to rely on the merchant to refund if needed.

CHECKLOCKTIMEVERIFY does not solve the malleability issue directly but does allow for new style of payment channel where it is no longer a concern. In this new type of payment channel the merchant gives the customer their public key, the customer uses this key with their own to create a P2SH address, both parties are required to sign any transaction from the P2SH address and just the customer can sign transactions to spend the P2SH transaction but only after the locktime has expired. The customer than generates the deposit transaction to the P2SH address. Both parties can now sign to move the funds or the time will expire and the funds can be spent by the customer. If a refund transaction is created and suffers from malleability, then the customer can use their own private key to create a new transaction to move those funds, this type of payment channel was not possible before CHECKLOCKTIMEVERIFY.

This feature has been used by decentralised exchanges to allow users to trade between each other without having to rely on a central service, but by using native blockchain software features to create transactions between users that can either be fully committed if both parties fulfill the requirements, or refunded if one or both fail to meet them. There are now several exchanges making good use of this features and once XBC activate the CHECKLOCKTIMEVERIFY soft fork it can participate on these exchanges

0 Comments
Nov 11, 2018 By xbcadmin