For corp : Nexus Crypto inc and for " the product" : Nexus Niro, I think it's good

Some news about Core 2.0 ? and about new public Cuda miner ?

We are Nexus

 

http://nexusniropool.cestballot.fr/ CPU pool close. UP

I keep you posted but it's 2:52 AM here in france, provider support ticket open...
It's time to solo CPU mining
I'm really sorry about this problem.
I'll update the situation in real time Here and on IRC.

Edit 1: Provider switch cpu pool on new hardware realy quickly. Pool UP
But we have to way for more imformation about where is the real probleme

Edit 2: hardware probleme again, pool down ...

Edit 3:
pool Status : CLOSED TEMPORARILY
My provider (OVH) try to found a quick solution...

Edit 4: I don't have more news from OVH but it looks good now ...  but to be sure networks CPU diff don't decrease like this at 5.5, you can use Viz Beta CPU Pool too: 204.27.62.234:9549


We are Nexus

start of another week now. whens release?

Nexus Market: https://bittrex.com/Market/Index?MarketName=BTC-NIRO

Nexus 2.0: Introducing Final Testnet Release for nPoS
If all goes well and I see network functioning properly, then I can move to release. I'd say a good week's worth of data should sufficiently cover to my levels of veracity.

Let me recap what Nexus Proof of Stake has settled into as far as features:

A] Block Average Using Following Weighted Averages Equation. Total blocks to search back is 5.


B] Coinstake Transaction Marked with Fibonacci Byte Series

C] Coinstake Transaction cannot be produced independent of a block. This prevents the common issue in Proof of Stake with network forking and syncing issues related to Staking, as in with Nexus, Stake blocks will always be produced on the main chain.

D]Interest Rate Calculations using ln(x) function for Variable Interest:



The Interest Rates are exclusive to Trust Keys, which means, your interest rate is 0.5% when you do not have a trust key, it increases on following curve to 3% after 1 year of continued staking.




E] Block Hash Calculated by nNonce with Energy Efficiency Threshold Described by this equation:



This allows staking to find a hash that satisfies your current weight, and prevents anyone from having more computing power from having any advantage as if you try to search to quickly, your blocks will be rejected for not satisfying the energy efficiency threshold.

F] Weight is calculated into your target and determined by this Equation:



G] Goodbye Stake Modifier. This was in previous versions of Proof of Stake due to its aid in security dealing with the "loose" coinstake transaction that is produced independent of blocks by finding a "kernel" that creates a secondary hash to meet the stake difficulty requirements. Stake searching was done by searching back in time from coinstake/block timestamp to find a "hash" that meets difficulty.

H] Total Coins Staking doesn't just influence how easy it is to find a Proof of Stake hash, it also determines how low your energy threshold is. This means that if you have more Niro up to the "MAX_STAKE_AMOUNT", you can search with up to 8 nNonce Second which allows energy efficiency, and also regulation in the block production. The Required Energy Threshold is modeled from this Equation:



Your weight directly influences your required energy threshold, or exactly how quickly you are able to search for a block hash that meets the current difficulty. This is much safer than calculating it in the hash, as the hash even at consistent targets can vary in their difficulty to find, which means that regulating the time differences between different weights using the block hash is very inconsistent resulting in insecure staking, even under higher difficulty.

I] Trust Keys are established and stored in the "Trust Pool" which is a seperate memory-only structure I developed soley for use with trust keys. This allows this pool to add or remove blocks from a trust key to determine the age and root of the Trust Key.

J] Two Transaction Types for Staking, The Trust Transaction and the Genesis Transaction. The Genesis transaction is the very first transaction that the network has seen with given trust key. It must adhere to the rules of Genesis Transactions, and be accepted into the Trust Pool to create the Trust Key. Trust Transactions then must use the hash of the Trust Key which is combined from GenesisBlock (first block trust key created), nTime (time of block), vchPubKey (binary data of public key), hashGenesisTx (hash of the Genesis Transaction) as the first input previous output in order to verify that Trust Transaction is tied to given Genesis Transaction, so that it cannot be manipulated. The Genesis Transaction marks the root of the Trust Key to determine its age and interest rates.

Weight for a Genesis Transaction Versus a Trust Transaction Follow These two curves. You can see that the Genesis Transaction Weight takes up to 90 days to reach full, as to where a Trust transaction builds your weight up in your Trust Key, to be maintained as long as the trust key doesn't expire. Genesis Transaction weights reset every new Genesis Transaction.



Note the Green is Trust Weight, and the Blue is Genesis Weight. Genesis Weight Expires after Genesis Transaction, Trust Weight Builds every Trust Block created by given Trust Key.

K] Trust Transactions cannot be created before Minimum Interval, or what this means is that a Trust Transaction can only be produced every X blocks (5 blocks for this testnet) in order to be validated by the network. This prevents the Trust Key holder from being able to create a chain comprised solely of Trust Blocks, or to attempt to build up Genesis or Trust Weight in order to attack as they will find their limitations after the Genesis Transaction.

L] Trust Weight and Trust Interest builds the longer you stake, and expires after the given trust key reaches its expiration time. This means that a Trust Key must continue to service the network to maintain their trust and therefore the benefits of having that trust. This testnet has the Trust Key Expiration set to 1 Day.



Following will list additional features in Nexus 2.0 on top of Nexus Proof of Stake:
A] Transactions Require 3 Confirmations.

B] RPC commands available "dumprichlist", "getaddressbalance", "getglobaltransaction"

C] Fast Sync Enhanced [to be even faster]

D] Block Signature using Signature Hash generated from extra fields in block header to seal all block data into the block and signature.

E] Addresses are displayed for Mined, Trust, and Genesis Transactions rather than previously displayed (n/a).


Make sure to mine with port 8325
http://nexusniro.com/binaries/testnet/Nexus-2-0-testnet.zip

If you notice any stability issues send me your debug.log files please

Thank You,
Viz.

Thank you my friend Been a lot of work, but to see it come together so beautifully makes it worth it for me. About 700 lines of new code for Nexus Proof of Stake 

Kindly,
Viz.

Hi,
I'm also running (and mining to) two nodes and both of them generated a genesis block then multiple trust blocks. Meantime running without any problem. Transferred some coins also between wallets, and all looks good. I will continue to play with them.
Excellent work Viz.

If you could run your nodes with debug=1 in your config file and paste your genesis transaction here I would appreciate it. This way I can see how quickly the Genesis Transactions form at the current difficulty.

Thank You,
Viz.

Second Wallet:

Alright I'm satisfied with the Security of Genesis Transactions and Genesis Weight, difficulties, trust keys.
Last thing I noticed could be a problem is the weighting for Trust Transactions.

Think like this: Trust Weight builds towards maximum in 30 days, coin weight builds in 90 days. Now if a user tried to keep aged coins as extra inputs to add to Trust Transactions this won't go over the weight threshold, but it defeats the purpose of the Trust Weights as that is designed to give stake eventually to honest nodes by them carrying the most weight.

I'm satisfied with security, but not with the "little guys" getting their stake, as the coin age was added into the weight equation to allow stakers to eventually build enough weight to get their next Trust Blocks, this could be easily exploited if I lower required threshold beyond design to allow coin age to push weight above threshold, so I am resolving this with a mechanism to increase your Trust Weight not only by the Time you are servicing the Network, but by also increasing weight as the time increases from that key's last Trust Block, or in other words, weight builds to Trusted Stakers with slower block production, as they would need weight to get their production to the level of the rest of the network.

This will enable in the future when staking difficulties get higher, for smaller coin holders to build their Trust Weight the more they don't get blocks, to enable them to utilize time securely as another method of investment to get their interest payments. This will also maintain security as it will give weight to the nodes that need it to ensure block production is spread across as many nodes as possible.

Expect one more Testnet Binary tomorrow, let it run the weekend, and Release Next week.

Thank You,
Viz.