March 2019

Welcome to the March 2019 edition of the Spectrecoin newsletter. We have some important updates around changes in the release of Spectrecoin V3. We also have updates on some of the work that has been going on behind the scenes to optimise the code for ‘Stealth Staking‘ and making the transactions more private. This has resulted in some interesting discoveries and we had new challenges to optimise the privacy of the network. The complexity of Spectrecoin V3 and PoAS is starting to become apparent as we are testing and working on the code. As a result we are making some radical changes to the system and we are going to delay the public testnet for a few weeks. The release schedule for the production version of V3 is still valid and we will have it out by the end of May 2019. Read on and I will explain why and hopefully it will all make sense and you will see that this is fast becoming a unique privacy coin with practical, understandable functionality and privacy that makes sense.

Whilst our developers has been coding and testing of all the functionality of Spectrecoin’s V3 PoAS, the anatomy of the PoAS system revealed itself through running on the testnet. As a result of this testing, several rather interesting and complex issues presented themselves. So, in response to this our developers have been implementing new algorithms to negate these issues and we did not want to discuss this in public until we had a handle on it and we were able to present solutions to the various dilemmas we discovered.

One of the changes we are now making in Spectrecoin V3 is relation to block-time and staking reward that will in turn affect long term inflation rates to the benefit of ‘stakers‘ and investors. Additionally, this will reduce blockchain size and allow for greater processing time for ATXO related operations. The increase in the number of ATXOs in V3 will demand more processing so overall it means that the new PoAS protocol is running with greater efficiency and makes the overall system more secure. The effect on transaction time will be negligible.

(1) Block time will increase to 96 seconds. Currently the ideal block time / target block time is 64 seconds which makes for a very fast blockchain. With the introduction of a large number of ATXOs on the blockchain through PoAS, the processing of transactions will become an increasing demanding. This will be an issue as the V3 blockchain continues to grow. A 96 second block time is still a very fast blockchain and transactions are shown almost instantly in any case both for XSPEC and SPECTRE.

(2) Stake reward will be fixed per block. Currently the inflation rate for the network is 5% per year in relation to the total supply. This will change to fixed values as follows: for a block staked with SPECTRE (PoAS / ‘stealth staking‘), the reward will be 3 SPECTRE, and for a block staked with XSPEC (PoSv3), the reward will be 2 XSPEC. We are introducing a strong incentive for users to keep their coins as private SPECTRE and use the new PoAS protocol and we reduce the number of ATXOs created in each staking transaction. This ensures a slowing down of the relative inflation for the Spectrecoin network as the total supply of coins will increase at a slower rate into the future.

This is a significant change to the system but will give some clear benefits. As we can see from the graph, the inflation with the static reward system will fall gradually to align with the projected annual inflation rate of most western countries (around 2.5%) and then fall below that. Taken together with the fact that the maximum total supply is around 41 mill. in 20 years, Spectrecoin value is likely to increase over time. We still believe that a certain level of inflation is needed to incentivise network participation and allow for wider adoption.

Therefore, we believe that changing these parameters will serve Spectrecoin both in terms of transactional privacy and efficiency after the release of V3 and facilitate a migration of the majority of coins into private SPECTRE.

A ‘special‘ situation could occur where all the ATXOs available for a certain denomination are spent except for your own ATXO to be used in a transaction. We are referring to this situation as the ‘ALL_SPENT’ dilemma and although this appears to be a very low probability situation in V3 it could have dire consequences for privacy and compromise a number of ATXOs. Let’s first explain this dilemma in some detail:

A valid ring signature (assume ring size 10) needs: (1) An unspent ATXO of a certain denomination to be used/spent in the transaction, and (2) Nine (9) ‘mixins’ of the same denomination (spent or unspent).

These ‘mixins’ (ATXOs) of the same value as the one being spent provides ‘plausible deniability’ with regards to the sender. The sender could own any one of the ten ATXOs used in the ring-signature and an observer can not determine which one of the 10 ATXOs forming the ring-signature is being spent. This is at core of ring-signature privacy and needs to be preserved.

ATXOs of each denomination are “scattered” along the Spectrecoin blockchain and exists in various blocks where they were once created and they can all be used as ‘mixins’ in a ring-signature whether they have ever been spent or not. Each ATXO is a ‘unique unit of data’ identified by its associated ‘public key’. However, only the owner of an ATXO can determine if an ATXO value has been spent or not as this requires the corresponding ‘private key’.

The ATXO picking algorithm for a ring-signature selects 9 ‘mixins’ at random from the available pool of ATXOs. In each block there could be a number of ATXOs of different denominations (spent or unspent) that could be selected as the 9 ‘mixins’.

Any observer will be able to establish the following: (1) In each valid ring-signature on the blockchain there will be one and only one ATXO of a certain denomination being spent. (2) In each valid ring-signature there will be nine ‘mixins’ used of the same denomination. (3) The observer will be able to count the number of existing ATXOs for each denomination by scanning the blockchain. (4) The observer will be able to count the number of ATXOs for each denomination that has been spent by counting the number of valid ring-signatures where this denomination has been used.

As a result, if the ‘ALL_SPENT‘ situation occurs, i.e.:

(number_of__existing_ATXOs = number_of_spent_ATXOs)

An observer will be able to categorically determine that each of the ATXOs used as a ‘mixin‘ in the ring-signature has previously been spent. The sender’s privacy has been compromised as the ‘real‘ input ATXO can be identified, and we no longer have the ‘plausible deniability’ afforded by the ring-signature. It is important to point out the following regarding this issue:

• This only occurs when ALL the ATXOs of a denomination have been spent and a new transactions is created using the depleted denomination.
• The privacy of the transaction spending the last unspent ATXO, although creating an ‘ALL_SPENT‘ situation is not compromised.
• If the ‘ALL_SPENT’ occurs, it would only compromise transaction created after the ‘ALL_SPENT’. All the previous transactions would still retain their privacy.

Solutions

A range of measures are being implemented to negate the so called ‘ALL_SPENT’ dilemma. We realised that this is only likely to occur in a situation where there is a very limited supply of ATXOs and so the main approach is to make sure that there is always a sufficient supply of ATXOs of varying denominations. We have therefore introduced an advanced ATXO balancer algorithm. This algorithm will measure the number of ATXO existing for each denomination and either seek to consolidate ATXO values or split ATXO values as part of the staking transaction in PoAS. This will ensure that there are always sufficient supply of ATXO to act as ‘mixins‘.

In addition a new algorithm has been implemented to detect an ‘ALL_SPENT‘ situation and if this situation does occurs the network will ‘remember‘ the block height (block number) and the picking algorithm will no longer pick ‘mixins‘ from below that block height. This ensures that users get the full benefit of the privacy the ring-signature offers.

We can say that all the ATXOs that are created in the same staking transaction are part of an ‘ATXO_SET‘, i.e. they will forever be linked to each other as they were created at the same time and it can be assumed that they all belong to the same user.

In the previous PoSv3 scheme with a steady 5% / total supply reward scheme the block reward will always be a decimal number such as 2.27211635 XSPEC / SPECTRE and would generate a large number of smaller denomination ATXOs that would belong to a so called ‘ATXO_SET‘.

The following dilemma may then occur; the ATXO picking algorithm (as it is now) could select ATXOs from an ‘ATXO_SET‘ as ‘mixins‘ in a ring-signature and this could potentially compromise privacy by making the signature more susceptible to deductive analysis. In other words, an observer could be able to determine which of the ‘mixins‘ are fake.

Solutions

New algorithms have been created to negate these issues and strengthen the privacy of the network:

This way depending on the random pick of the initial ‘mixins‘ and the denominations to fill, there will be a random amount of ‘mixins‘ from the same transaction in the final transaction. It will also be ensured that each output is only used once as a ‘mixin‘ in one of the ring-signatures (vins). Something which is currently only ‘ensured’ by chance. Same ‘mixin‘ in different vins can only be fake.

(1) When the first 9 ‘mixins‘ for an output are chosen, it is completely random, but is ensured that all ‘mixins‘ come from different transactions.

(2) When ‘mixins‘ for the second ring-signature are chosen, there is a 33% chance that the algorithm tries to choose outputs from the transaction chosen as ‘mixins‘ for the first ring-signature. If no outputs can picked that way, a new random output is chosen and the corresponding transaction is added as new source of ‘mixins‘.

(3) Repeat.

TESTNET restart

In order to implement the changes detailed above and test it properly, we need to restart the testnet again before we will issue the public testnet wallets a little bit later than we thought. The public testnet wallets will be available from late March / early April 2019. This should not affect the final release schedule for Spectrecoin V3.

Once the public testnet is available we will make an announcement and issue some instructions for how to obtain test-coins and how to contribute to the testing.

We are introducing the first stage of our bug bounty program that will cover serious or critical bugs and we will later expand on this to include bounties for smaller bugs as well. We are putting up the bounties to make the Spectrecoin software better and more secure and we believe that active participation by the community will help to achieve this and benefit us all.

If you believe you have found a bug or a problem with the Spectrecoin software, submit a report (details below) and contribute to making Spectrecoin more secure. However, before you submit a bug report, please search our GitHub and other sources to see if the problem has already been reported / discovered. If the issue has not been described anywhere, then follow the instructions at the end of this document for how to submit the bug you have found. Please do not report critical vulnerabilities publicly.

Bug Bounties and Rewards

• £1000 – Deanonymise Spectrecoin (SPECTRE <> SPECTRE) transactions. (Proof that a protocol is not anonymous, i.e. a flaw in the implementation of ring signatures or the stealth address technology).
• £1000 – Deanonymise TOR as implemented in Spectrecoin and real IP address leakage. (Proof that you can identify a real IP address on the network). This relates to the implementation of TOR in the Spectrecoin software ONLY and not bugs in the TOR software.

The bounties will be be paid out in XSPEC to the equivalent value at the time of a submission.

All the bugs / errors found need to relate to and identify faulty source code (in the ‘master’ branch), not just reported issues that you experience without being able to relate this to specific code.

Contact the developers privately by sending an e-mail to xspec @ protonmail.ch (delete the spaces ofc) or DM the developers directly on Discord (@Tek or @Helix) with the details of the issue. Do not post the issue on GitHub or anywhere else until the issue has been resolved.

Ideally you would create a pull-request on GitHub in the proper repository with the necessary fix and make the developers aware.

Website: https://spectreproject.io/
GitHub: https://github.com/spectrecoin/spectre
Block explorer (V2): https://chainz.cryptoid.info/xspec/
Testnet explorer (V3): https://chainz.cryptoid.info/xspec-test/
Coinmarketcap: https://coinmarketcap.com/currencies/spectrecoin/
Crex24: https://crex24.com/exchange/XSPEC-BTC
Amsterdex: https://amsterdex.com/exchange?market=xspec
Livecoin: https://www.livecoin.net/en/trade/index?currencyPair=XSPEC%2FBTC
Discord: https://discord.gg/ckkrb8m
Twitter (official): https://twitter.com/Spectrecoin
Twitter (official): https://twitter.com/XspecRising
Bitcointalk: https://bitcointalk.org/index.php?topic=4434053.0
Reddit: https://www.reddit.com/r/XSPEC/
Telegram: https://t.me/spectrecoin
Facebook: https://www.facebook.com/spectrecoin/