Contents
Leading up to Mainnet.
Why did we build this new staking engine? What actually is staking?
Post-launch and the forking forks.
V1.0.0
V1.0.1
V1.0.2
V1.0.3
What’s coming up next?
Wen Bitmart?
What else are we busy with?
“Success is not final, failure is not fatal: it is the courage to continue that counts.” - Winston Churchill
Leading up to Mainnet:
In the days leading up to mainnet we did a lot of testing and refinement of a new staking engine.
The purpose of this newly designed staking engine was to refine the way that staking is done and to allow people to be on a more level playing field.
So why this new staking engine?
What is staking?
So, let’s answer the last question first. What is staking and how does it work?
Staking – in PoSV3 – is a method by which coins in a wallet are “locked” away in what’s called a utxo.
Utxo (unspent transaction out) is what BTC and most altcoins use as the name for any unspent transaction.
By locking away these utxo’s the wallet sets the amount in those utxo’s as the staking amount and that allows the network to calculate the weighting (number of lottery tickets).
Utxo’s win staking rewards, not the wallet. The wallet is paid by the network depending on the address that owns that utxo. Also when that utxo wins a staking reward it must go into a waiting cycle – usually 100 confirmations of the reward – in order to prevent long-range attacks and nothing at stake attacks.
What this would mean is that if you had 10M staking in a single utxo, when you win a reward, the entire 10M goes into a waiting cycle. This is completely normal in all staking chains.
Now for the first question – Why did we build this new staking engine?
When the minimum staking amount was introduced by the community vote this presented us with a challenge: What if a user has a total of (for example) 1.8M coins and none of their utxo’s are above the 400K minimum? Without coin control, they wouldn’t be able to stake. But I want to stake! Why can’t I stake? Bad DAPS!
This led to a long user story being created about how to tackle this problem and also how to allow users to stake 100% of their balance without needing coin control and with the wallet able to do this automatically.
The solution was simple: Break the user’s spendable balance into multiple equal utxo’s totaling over 400K. This means that the 1.8M would be broken up into 3 x 600K utxo’s.
This not only meant that the user would be able to stake 100% of their balance, but also because utxo’s were closer in value, it would mean that the 2M guys could compete with the 100M guys, but also that if a user’s utxo won the reward, like our 1.8M holder, he’d still have 2 more utxo’s in the game that could mint the next block and get the reward.
This seemed like a win for everyone.
Post-launch and the forking forks
V1.0.0
As previously mentioned we had built what we believed was the ultimate staking solution and almost a DPoS on steroids.
We tested it across 10 nodes, 20 nodes, 30 nodes and it was stable and worked great.
What we couldn’t take into account was the effect that having several thousand nodes with multiple differing amounts and all the hundreds of thousands of staking utxo’s all on a level playing field trying to a bite at the reward cherry.
What this caused was the difficulty of the chain became so low – because everyone guessing was on the same level – that immediately forks started appearing right out of the gate. Initially they were small forks that were quickly abandoned by the network, but as more and more people fired up staking wallets, the problem became exacerbated.
The forking forks also caused some havoc with the masternodes going missing or being collateralised on a fork and hence when everything came back to the main chain, it was gone.
V1.0.1
One oh one as we called it attempted to redress the staking issue and forking. By this time, we were hearing from everyone how much they were loving getting so many rewards, but also a lot of questions about the masternodes and daemons in general.
This version also addressed some changes that were requested by TxBit and Stex regarding some clarity around the data returning from RPC calls in the daemon. More specifically they wanted to be able to quickly identify whether a transaction was a deposit or a withdrawal.
We also attempted a fix to see if we could slow down what we came to call “The Runaway Chain”.
Essentially at this point the chain was running as 6 times the speed it should’ve been.
V1.0.2
This release brought about a few changes, mainly to the way the wallets handle transactions on forks and the balance problems people were seeing again because of the forks.
It successfully handled a majority of the issues we were seeing and brought a little bit of stability to the wallets, but not the network, which was still running too fast and forking everywhere.
One of the unanticipated side-effects of all the forks was the exchanges – Stex and TxBit – reported issues with funds appearing and disappearing and issues with creating withdrawals.
V1.0.3
This was the big daddy, we had had enough time to analyse what was actually taking place in chain, where we had gone off course, how we got to where we were and how we going to get it back on track.
At this point we had noticed that there were a few forks that were actually trying to be malicious, we had recognised that this incredible staking engine we had built was to blame.
We had tried to build the ultimate cutting-edge staking engine and instead of it being the grand beautiful vision we had dreamt of; it became our nightmare and the source of most of our issues.
1.0.3 Ripped the guts of the staking engine out and replaced with a more contemporary engine.
It still had the ability to automatically generate utxo’s on behalf of the user, but this time it combines to them into a single utxo.
This means that we have gone back to a standard staking model. This increased the difficulty to a normal level. What this meant is that the chain slowed down to what it was always meant to be. The glory days of a reward every 10 seconds were gone and now it was back to a reward per minute and the weighting of the staked amount being calculated across a single utxo instead of multiple smaller ones.
We also added what are known as checkpoint blocks. We had to add these to the chain parameters for the simple reason that people syncing their wallets were often ending up on long forks that had either been abandoned by the network or were 1 of the malicious forks.
Checkpointing allows the wallets to bypass these forks and get onto the main chain faster.
We also brought in a few fixes that allowed Stex and TxBit to open their doors. These included better management of orphaned transactions, better decoy selection to mitigate an issue where the decoys were thinking they were spent and causing the double-spend error to trigger.
We updated the synchronisation methodology, stabilised the daemons and added in a faster rescanning of transactions.
One of the biggest changes we also made in this version was to soft fork. A soft fork is done by selecting a future block as the fork point and forking from there. We also decided that for the fork to work completely and not be influenced by older wallets using the older staking rules, older wallet versions would be force disconnected by 1.0.3 wallets so as to not pollute the chain going forward.
This would mean that all those users and service providers that upgraded to 1.0.3 would have a cleaner chain, less forks and the older wallets would end up on their fork that is not and cannot ever be the main chain. This has led to a lot more chain stability, yes it means rewards are now what they always were meant to be, but we had to do this for the longevity of the chain.
The difficulty of the chain has gone from averaging 0.04 to 24 000 000. This tells us 2 things:
We have a lot of stakers.
The chain is running exactly as it is meant to.
Please note that these numbers do not indicate the amount of coins needed to stake. It is a mathematical equation that creates this number. It represents the difficulty of guessing the next block hash.
What’s coming up next?
As always the team is working 24/7 and tackling challenges by priority levels.
Wen Bitmart? UPDATE: This is now completed and Bitmart is up and running.
As many of you know we are currently working on a module for Bitmart.
Bitmart – unlike many other exchanges – has an extensive and very good security system in their backend systems.
Essentially, they do not trust online nodes to be secure. In their opinion online nodes are insecure and they do not want a “hot” node to be the holder of any private keys and as such they also do not want hot nodes to be generating transactions.
Their reason for thinking is quite simple. In a multi-layer network such as theirs, if the hot (online) node is compromised, no transactions can be carried out on it because it does not have the private key of the privacy account and therefore no funds can be stolen. An attacker would have to gain access into their even more secure back end systems in order to get to the cold (offline) node and then generate a transaction from there and then pass it to the hot node.
This level of security is miles ahead of some other exchanges.
The challenge we face – as a pure privacy coin – is the ability to have a node still accepting incoming transactions and be able to decrypt them without having the private key on the node.
Also, in order to generate transactions with RingCT, we need decoys to mix in with the actual transaction. This is particularly difficult when the cold node does not know about any transactions because it is not connected to the network.
We can’t go into too much detail as it would not be right to divulge too much information about what the requirements are as that could put security at risk. We are 80% to 90% complete with the development of this module and are hoping to be able to provide it to Bitmart within the next day or 2 so that they can test it and make sure it's fit for their purpose. Again, though as with any new software, they may ask for changes or find bugs.
What else are we busy with?
Quite a few upstream fixes from PIVX and Bitcoin mainly to do with memory management and transaction writing to the wallet.dat file
Refactoring of the history page in QT wallets
Fixes to IPV6 masternode communications
Fixes and re-organised hardware architecture for the block explorer
Further refactoring of information with regards to staking
Showing of orphaned blocks in history
Fixes to the windows notifications about transactions
Multisig wallets – as soon as it’s ready we will assist Grant Thorton with the swap of Cryptopia DAPS tokens
