Legacy Update: The Trust Update

8 min readSep 11, 2018

Wow, what a long week it has been. Let’s start off this blog covering everything that has happened since last week. There has been a lot going on, and a lot going into this recent update. Let’s do our usual git pull origin master to see all the new fresh code:

As you can see, there are over 2840 lines of new code, some replacing old outdated code which was in the range of 1762 lines. This is 1078 lines of fresh code for our good ole’ Legacy client.

What’s been happening under the hood?

Some of you have obviously noticed there being some attacks happening over the recent months. These attacks started on the proof of stake channel, and worked their way around to different areas that the attacker seemed to target. We had block mutation attacks, proof of stake attacks, and of course lovely DoS attacks. These have been very well thought out and targeted attacks on specific Nexus features, but in the right attitude, I say — thank you attacker, for revealing areas Nexus needed to get stronger in. This release 2.5 is that response, so let’s dig into what it includes.

Decoupled proof hash from block hash
Energy Efficiency threshold locked with stake hash
Intelligent coin weighting to threshold for easier stake
Trust Scores rather than Expiring trust keys
Clock re synchronization

There’s more details between these lines, but we will keep it at just that. Let me start by explaining the necessity for each:

Decoupled proof hash from block hash

The general proof of work / proof of stake hash has been regarded as the hash that is chained to the next block. This has some positive benefits, but also some negative ones. Let me explain how Bitcoin works:

A miner has to find a winning hash with a header that meets the difficulty requirements. A conventional bitcoin header includes these variables:

In nexus terms, these items are slightly different. We include more data in the header such as channel (which proof channel) and height (the height of the block). Now one thing that is different about us, is that the timestamp of the block is signed into existence when found and broadcast, not when the block itself was created, or the miner changes it. In Bitcoin, since their allowable clock drift is 7200 seconds in the future, this isn’t as big of a deal for a miner to iterate the timestamp as an extra Nonce, but for us, since our tolerance is 1 second maximum, we like having our timestamps extra accurate.

Now in versions prior to 2.5, the timestamp is not a part of the block hash, but is included in a special hash called the SignatureHash that the block finder signs when the block is found. This prevents anyone from tampering with this timestamp during transit and appending to the chain, but as we have seen it does not stop an attacker from signing two different timestamps and broadcasting both blocks to the network. The result? Well, if your node happens to be unfortunate enough to get the timestamp block that was invalid, your node would get stuck or go off on its own chain. This is not our most desired result in the wild, so here is how we resolved this:

The block hash is calculated and signed after it is found, while the proof hash is what is used to prove that one did whatever work was required.

This decoupling provides our network new benefits besides protecting against block mutation attacks, but it also helps us secure the weighting system further on the proof of stake channel. I’ll let that statement lead into the next section.

Energy Efficiency threshold locked with stake hash

This was a fun one to resolve, as many I’m sure remember the proof of stake channel attacks from back in Spring, in which a new “Soft Ban” technology was developed to swallow malicious blocks into the abyss, to protect good actors from being pushed out of the way from malicious ones.

Though this worked quite well, I thought it would be proper and all with us having a time-lock activation to secure this beyond just our fun “Soft Ban” rules. The result? You read it: Energy Efficiency threshold locked with stake hash.

Let me attempt an analogy to help you understand.

Think of staking as trying the lottery — the higher your weight, the more lottery tickets you are given as guesses. This means that you have a number of these guesses available to you every second, so naturally playing the probabilities game you will end up with a winning number faster playing more tickets per second. This is part in how the staking system works. Now, as you have seen above, the block hash being the “end all be all proof” was not the best way for us to move forward, so being decoupled now I had the freedom to select some variables that couldn’t be manipulated to try and cheat and get more guesses. These variables ended up being:

Version — the current block version to designate rule switches
HashPrevBlock — the previous block in the chain
Channel — the current proof mechanism being used
Height — the height of the block
Bits — the current difficulty for this block
Key — the trust key finding this block
Nonce — the guess to find proof hash

All these values above are static for the time it is until another block is found. This is useful now, because a user is required to guess with their Nonce, and have no other guesses then allotted to them by time and weight. This makes the energy efficiency threshold much more secure than it was previous, eliminating any more of this kind of attack… Hooray!

Intelligent coin weighting to threshold for easier stake

Now onto our next change, weighting intelligently…. Hmmm, whatever could this mean? In non-geek terms, it means a weighting formula that makes your staking experience much more pleasant. This means that you will get stake easier, meaning it will be much easier to maintain a trust key, leading to you getting to that desired higher interest rate. Now onto the larger part of this update.

Trust Scores rather than Expiring trust keys

Yes, I said it. Trust keys will no longer expire! This has been a long time coming, I know. And last year, this is what people thought Tritium was meant to be, aren’t we glad we waited? Anyhow, lets get on to how this new trust system will work and how it can operate without you ever fearing losing your trust key.

Trust is built up by the total seconds of time you stake within 3 day, and it is lost by three times the seconds you take after the 3 days.

Ah lovely Fibonacci proportions. You know, some athletes are told that if they stop training for a month, then they lose 3 months worth of their skills. Interesting how life can be modeled into our mathematical reflection. So with that being that, your trust blocks will need to be in before the 3 days are up, otherwise you incur a penalty. This penalty will reduce your total score by the time it takes you past this three days.

This breaks down into 1 year of staking gets lost in 4 months of not staking. 3 months of staking gets lost in 1 month of not staking, and so on. This number is quite fitting, and works very well in finding that perfect balance between your tireless challenge to build up trust and value it, versus your frustration of feeling you have lost it for false reasons. This has been the trust update that many have been waiting for, and with decoupled proof hashes needing to happen sooner rather than later, I figured it would be fitting to include in 2.5 as we roll up to the conference. Whew!

Clock re synchronization

As many of you have most likely noticed, the time is a bit off on the network. 8249 seconds to be exact. The reason for this? Clocks got thrown off back in the days of 2016 when there was a seed node that went rogue and threw the time seed off. It eventually settled at the 8240 second mark, keeping the network secure (since unified time gains its security by clocks being the same, not always being right). But — being in the spirit of coding legacy again over the last week, I figured it would be worth setting a one time adjustment to reset the clocks back to 0, giving us a more accurate “universal time”, and still retaining the integrity of the Network. So, post block version 5, every ten minutes, all clocks will rewind 1 second. This being 8249 times, this process will be slow and take approximately 55 days to complete. But in the end, we will see times more synchronized to our local clocks, instead of having to deal with timestamps that aren’t aligned.

Time-Lock

Since we have such drastically different processes and code, we activate our network differently. If anyone remembers back in the 2015 days since our last major activation, we use what is called a time-lock. This means that at this time in the future the network will upgrade to block version 5. In simple terms, make sure to update to 2.5 by:

Unified Timestamp: 1536977460

Human Timestamp: 09/14/2018 19:11:00 GMT — 7

The other boring stuff…

There’s a lot more that went under the hood this update, such as how trust keys are indexed, sequence numbers, previous trust blocks, recycled keys, prime miner minimum search hash, and more; but I’ll spare you the details. But before I conclude, I’ll share the last rule change with slight detail:

Transaction limits will no longer be 1M NXS, but 50M NXS as requested by the community.

You can find the update on github here, Enjoy!

https://github.com/Nexusoft/Nexus/releases/tag/2.5.0

Until Next Time…

I’d like to extend a thanks to everyone for being such a great community, and Nick Earl for helping test and deploy the binaries today. As always, keep posted for new updates, keep safe, and I look forward to seeing those of you coming to the conference.

Cheers,

Viz.