How will cope with Bitcoin improvements?


It was known for some time that Bitcoin was slow. This is mainly related to the size of each transaction block being artificially restricted to 1 MB containing a small number of transactions. Normally, each block is created in 10 minutes interval. When a new transaction enters a block, it is considered to have received its first confirmation. Subsequent blocks add to the number of confirmations. Sometimes the speed of incoming transactions can outpace the production of blocks resulting in huge delay in confirming of transactions. In May, a large number of transactions (> 165,000) were pending resulting in transactions being confirmed only after 3 days. Such delays could be catastrophic for our Tap & Pay users who might expect their fiat balances to be updated in minutes not days.

At a technical level, two competing approaches were proposed to improve Bitcoin’s transaction capacity, the first one was to change and improve the format of the transaction by removing and storing coin signatures outside of the blockchain so that more transactions can be packed within each block, this is also called Segregated Witness (SegWit/BIP 141). The second approach, also referred to as SegWit2x, went further and doubled the size of each block to 2 MB but at the cost of being incompatible with SegWit and further risked a network split/hard fork because its activation method was different. To make both these approaches compatible and avoid a split, BIP 91 was proposed.

Implementing any of these solutions means getting a majority of the nodes in the network to adopt them, especially those with hash power i.e. miners who compute the blocks. Although miners generally don’t resist such changes, sometimes it could hurt their profitability or advantage (e.g. ASICBOOST) contributing to stalling tactics. To force miners into action, Bitcoin users suggested a soft fork implementation for SegWit (BIT 148 UASF) with 1 August as deadline. However, the good news is that this forceful approach is no longer necessary because 97% of miners (inching toward 100%) have locked-in and signalled their intention to activate software changes proposed in BIP 91. While in theory this drastically reduces the risk of a Bitcoin hard fork, in practice what might happen is anybody’s guess. Fig.1 shows a timeline of events (source: Bitcoin-Magazine):

Figure 1. SegWit Timeline. Source:

Implications for PlutusDEX

In order to track Bitcoin deposits, PlutusDEX relies on a component called blockchain-tracker (see 4 in Fig. 2). This component interacts with Bitcoin network through a dedicated node to track and then confirm each transaction (upto 3). When BIP 91 is activated, it is likely to impact blockchain-tracker and indirectly influence the ability of PlutusDEX to fulfil open orders. Here some potential issues are explored with detailed plans and suggestions to mitigate risks.

Figure 2. Role of Blockchain Tracker in PlutusDEX

(i) Network split or hard fork: In the event of a hard fork, confirming transactions will be difficult or even impossible, therefore users are advised to proactively keep themselves informed on such incidents, usually notified by crypto-exchanges, wallet providers, forums and other other news outlets. Although, will aim to notify and suspend processing of Bitcoin orders in the event of a hard fork, the responsibility for securing Bitcoins and transactions solely rests with the user.

(ii) Network instability: Activation of software changes might not always lead to hard-forks but sometimes they could temporarily render the network in an unstable condition resulting in pending transactions or transactions not entering a block, which again has a direct impact on deposit confirmation. To mitigate this risk, trust of confirmations will be increased by reconfiguring the blockchain-tracker to confirm deposits only after a minimum of 6 confirmations (instead of current limit of 3).

(iii) Misconfigured Bitcoin node: A node acts as a gateway to the Bitcoin network and is a critical component of the PlutusDEX architecture. It is therefore important that software updates are not only correctly administered but also quickly recover from a node failure. foreseeing such risks to node maintenance and availability, in its architecture incorporates 3rd party dedicated nodes that are highly reliable and available, supported by a team of Bitcoin engineers. Thus, blockchain-tracker is shielded from secondary changes and refactoring (if any) to accommodate the new format of transactions. Nevertheless, the blockchain-tracker will be tested thoroughly for any abnormality.

Support for Bitcoin Cash

In addition to existing confusion surrounding Bitcoin improvements, it appears that a small number of users and businesses have deliberately exploited the current situation by hard-forking Bitcoin to create their own alt-coin i.e. Bitmain cash or Bitcoin cash (BCC). Although, this alt-coin may contain Bitcoin transaction history, it will be incompatible with Bitcoin Core because they plan to implement a block size of 8 MB and without SegWit. As of now has no intention to support other alt-coins including Bitcoin Cash.

In conclusion… is doing its best to keep abreast with the fast moving developments of Bitcoin and has contingency plans in place to mitigate potential risks arising from implementing Bitcoin improvements. will keep the user community informed about changes to services and products as and when it is necessary. As of now is well prepared to face the upcoming challenges to Bitcoin.

Further reading

  1. Bitcoin announcements and updates
  2. Securing your Bitcoins if a hard fork happens
  3. Why nothing will with Bitcoin happen on August 1
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.