The long awaited Amethyst release marks the start of a new stage of Bytecoin development. The Bytecoin development team has overhauled the platform following a long period of testing and refinement. Here is an extended technical description of the changes that were made, compiled by the Bytecoin devs.





Deterministic wallets

Case:

When a bytecoin wallet is created a set of random private keys is created and stored in a wallet file (the same as with Bitcoin). If a wallet file is lost, the funds sent to the wallet addresses are lost forever. Bitcoin solved this problem by using mnemonics and deriving private keys in a deterministic way quite some time ago. If the same mnemonic is used to restore a wallet as was used to create it, the same private keys will always be derived and the funds can be retrieved.

Solution:

The Bytecoin Team has adapted Bytecoin’s key mechanics to align with Bitcoin’s - Bytecoin is now using the BIP32 industry standard as a derivation scheme for new wallets. New Bytecoin wallets can now be backed up and restored with a 24 word mnemonic.





Unlinkable addresses

Case:

The original CryptoNote paper, which was first implemented by Bytecoin, required each address to have a pair of independent keys - a view key and a spend key, unlike Bitcoin which required just a spend key. The receiver would apply the view key to all transactions in blockchain to find the funds that belonged to him. This operation requires lots of complex computations for each view key, but CryptoNote developers assumed each user would have just a couple of addresses.

A typical exchange may have hundreds of thousands of users, and it turned out that modern computers can only process around 1000 view keys in real time. So two interim solutions emerged - the first one was the so-called Payment ID, the second one - Shared view keys. These solutions were designed to combine the anonymity of Bytecoin technology with performance of modern day exchanges.

Payment ID was just a random string of characters a user would have added to a dedicated field in their transaction, so that the exchange could identify which user account should be credited when it received funds. Essentially, an exchange would have a single address for all its users. Payment ID has been deprecated and is now maintained for the integrators that have not updated yet. It will be removed soon.

The other approach was Shared view keys - sharing view keys between addresses of an exchange, effectively creating addresses with a common part.

Both of these approaches aided performance, but were not as anonymous as using a standalone Bytecoin Desktop wallet. The Bytecoin devs knew there was a way to combine unlinkability and performance for large-scale application.

Solution:

Cryptography research and development has allowed Bytecoin devs to create addresses that are completely unlinkable. That is, a group of addresses sharing the same view key in a way that outside observers cannot cryptographically prove if two addresses are derived from the same keys. Stay tuned for future articles about the technology behind this.





Implicit Wallet History

It turns out the sender (and only the sender) of transactions can restore destination addresses from the transaction data by adding just a single byte per output (<0.5% increase in transaction size) to the blockchain. So the transaction history does not need to be stored in the wallet at all, because it is implicitly stored in the blockchain, available only to the original sender.

In addition, the Bytecoin devs have found a way to enable these changes for legacy addresses, unifying address properties, and getting rid of transaction public keys altogether.





Auditable view-only wallets

New cryptography in the Amethyst release has prompted the devs to redesign Bytecoin’s current functionality, resulting in Auditable Wallets. This is an audit-compatible solution for observing BCN. In addition, during the view-only wallet export, original wallet owners can decide whether auditors will be able to see transaction destination addresses by sharing special transaction derivation secrets.





Blocksize adaptation

Case:

Previously, there was a degree of uncertainty regarding the performance of the blocksize adaptation algorithm. First of all, increasing block size could only be done by forfeiting part of the block reward; secondly, increasing block size was only possible in very small increments, even if miners worked on it.

Solution:

In Amethyst, the Bytecoin devs have decided to employ a different approach with direct voting - here each miner, looking at the memory pool, decides upon the block size they prefer, then includes their vote in the coinbase transaction extra. The median of the gathered votes determines the max block size.





Signature pruning

Case:

Signatures are by far the largest part of the blockchain (from 70 to 80%). They are not actually checked (unless Bytecoin is run with a dedicated --paranoid-checks switch) beyond the last checkpoint (a kind of “save point”, beyond which there is no need to check the blockchain; it is updated with every software release), because checking signatures requires a great amount of computations. At the same time, transaction hashes include signature bytes, so if signatures are thrown out, transaction hashes cannot be calculated.

Solution:

So as part of Amethyst the team started to calculate the transaction signatures as a hash of two hashes: a hash of transaction prefix and a hash of transaction signatures. That way signatures can be pruned and replaced with a single hash per transaction.

Turns out this solution plays well with the new block size voting algorithm (see above), because it does not require knowledge of the original block size.

More than routine upgrades, these changes have set the stage for the new uses of this technology to manifest themselves. While the platform has been improved, the points of improvement are more akin to portals of exploration that have been opened for members of the community to branch out into the expanded spaces of this realm. You can experience all of them after the Mainnet hardfork, estimated to occur around March 6th, 2019.



