Topic: Nexus - Pure SHA3 + CPU/GPU + nPoS + 15 Active Innovations + More to Come - page 170. (Read 785514 times)

I have been looking at different coins and this one is one of the best I have encountered, you offer a lot of features in this project that other coins with millions of dollars marketcap don't have, I think this project could make it in the long term, just a few things that I would like Videlicet to answer when he is available to do so.

1 - If this project is going to make it global and have mass adoption there is a feature that I haven't seen here and that is fungibility - Dash - coinjoin kind of function or anonymity like Monero. One of the mayor problems that will have to be solved on Bitcoin is the pseudo-anonymity that it has as transactions can be traced on the blockchain, the best option that I have seen is Monero, as the Dash "Darksend" asks you for 1000 coins to do your coin mixing and people just wants the easiest and quickest way to operate their crypto in a secure way. I think bitcoin is going to implement BIP47, what are your thoughts on that?, and how Nexus will fix this?, because is going to pop up in the future of Nexus.

2- im not a programmer or have knowledge about computing but in the podcast Videlicet said  Nexus is multi-threaded, I was reading the specs of Bitshares and they are going heavy on single-thread crypto. here is the link    https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/   and go to "Embrace the Single Threaded Reality of Blockchains"  , after reading this the question is what is better for a crypto?, to be single or multi-threaded? and Why?
 
3-Blockchain size, if you see the bitcoin blockchain size charts you'll see is groing quite fast, still is not a problem with 50gb at the moment but as they plan to increase the block size, in a couple of years the blockchain will be massive, so the average Joe wont have it on his laptop to secure the network, it will need special data centers for containing the blockchain which will lead to centralization, how is Nexus planning on fixing this bitcoin issue, as again if Nexus makes it and becomes a mayor crypto this will be a problem in the years to come.

Sorry for my English guys is not my native language, I hope Videlicet answer this issues and we can plan the best crypto for the future which hopefully will be Nexus.

Now that the recyclers will not be absorbing sh*tcoin economies, I agree a different name is needed.  Unfortunately I have no suggestions for names atm.

Just listened to the podcast, very interesting vision for the future. Following this project closely.

All with same start weight ?  and who and when will delegate this keys ?

Well there are 13 recycler and 13 dev fund addresses, but as mentioned it could be possible to require multiple keys for each.

All this sound interesting. How do you decide how many of these keys (controllers/ambassadors / developer keys) should have ?
This is fixed numbers of keys or not ? and correlations between ?
 This is like parliament ?

That is right along the lines of what we are thinking.  We do envision those with Trust Keys to be voters.  This is why we are going to fix the Trust Key expiration in the next update.  Rather than an expiration, it will simply decay in weight.  So, that if your node goes offline for a few weeks, you may not completely lose your key but rather you will lose some weight that the key carries.

This is why I referred to the recycler keys as "delegate keys" or "ambassador keys" because those who control them will be ambassadors for Niro and also delegated power by voters.  The ambassadors could have voting capabilities for example, to appoint the developer keys, among other powers and benefits.

Perhaps some of our early community such as yourselves will become controllers/ambassadors of these keys.  In fact, we see this as a big incentive to our early community members.  Participants such as CestBallot, BitSlapper  would be prime examples of people who could be rewarded recycler and/or developer keys.  It is possible someone could have both a recycler key and a developer key

We would also like to decentralize the developer keys over time as well, but this is a different subject as right now Videlicet and CestBallot are the primary developers and maintainers of the Nexus infrastructure.

Let's tackle the recycler/ambassador keys first.  

Also, if anyone has a better name for these keys, we would like to hear it.  These keys ultimately will provide businesses with incentive to maintain crucial infrastructure related to Nexus in the future and become part of a "governing system" so as to ensure long-term decentralization but also maintenance of the infrastructure.  It's feasible these keys could even be put into multisig accounts where they are controlled by trusts or individual communities, whereupon each community had a recycler key.

I'll jump in early with a suggestion regarding the recyclers though I am not a coder so I am unsure if it is at all practical or even possible. I suggest the recyclers be controlled via a voting mechanism using trust keys which are not associated with any of the recycler addresses. Not exactly sure how it could work but something along the lines of recycler addresses being multisig and some how requiring one of the inputs required to unlock them being generated from a vote by trust key holders.

Recycler keys and developer keys are currently controlled by Videlicet.  We are going to discuss the ideas to decentralize these in a podcast, and we want feedback and help from the community.  I was hoping to have a podcast with Colin done this last Sunday discussing the future of Nexus and bringing new ideas to Bitcoin, but a snowstorm prevented me from getting home that day, and then I had to pack and move the following day.  Right now I'm on the road.  

There are some very interesting developments going on which we hope to share with everyone soon.  Hopefully after the next podcast, we can clarify many things for everyone and give people a better sense of the vision of Nexus.  As soon as Colin and I can get this recorded, it will be posted here.  This is a priority for both of us but we are currently both swamped.  I should be able to devote a lot more time to Nexus and the podcasts in a few weeks. 

Thank you

We are Nexus.

So who controls the recycling addresses or is it done in some decentralized manner?

The scroll right bar in the Github is way at the bottom and doesn't show unless you scroll all the way down   It isn't well thought out.  Those are the correct wallets.

"2Qp1rHzLCCsL4RcmLRcNhhAjnFShDXQaAjyBB9YpDSomCJsfGfS" : 35391.74348000
"2SFx2tc8tLHBtkLkfK7nNjkU9DwvZZMNKKLaeX4xcG8ev4HQqVP" : 35244.26989700
"2SawW67sUcVtLNarcAkVaFR2L1R8AWujkoryJHi8L47bdDP8hwC" : 35184.04282300
"2QvzSNP3jy4MjqmB7jRy6jRGrDz6s6ALzTwu8htdohraU6Fdgrc" : 36980.32435500
"2RxmzQ1XomQrbzQimajfnC2FubYnSzbwz5EkU2du7bDxuJW7i2L" : 37759.47942300
"2S2JaEbGoBFx7N2YGEUJbWRjLf35tY7kezV8R9vzq9Wu1f5cwVz" : 42164.93178000
"2S9bR5wB6RcBm1weFPBXCZai5pRFisa9zQSEedrdi9QLmd5Am8y" : 36688.28805600
"2S6NjGDuTozyCWjMziwEBYKnnaC6fy5zRjDmd2NQhHBjuzKw4bg" : 36572.88080200
"2RURDVPFD14eYCC7brgio2HF77LP22SdN5CeAvwQAwdSPdS95dT" : 37384.28376000
"2SNAEJ6mbmpPXbP6ZkmH7FgtWTWcNnw2Pcs3Stb4PDaq3vH1GgE" : 35660.01451000
"2SDnQuMgW9UdESUUekrrWegxSHLQWnFWJ2BNWAUQVecKNwBeNh5" : 39581.36551200
"2SCLU4SKxh2P27foN9NRoAdtUZMdELMvBpfmVER98HayRRqGKFx" : 35820.32380500
"2SLN8urU2mERZRQajqYe9VgQQgK7tPWWQ1679c5B3scZKP2vDxi" : 37877.08702900

Looks like part of these addresses has been cut-off on github due to formating issues, so I'll assume i found the correct ones.
Total of 482309.0352 or 1.53545363% of current supply.

Here is the link to the code with the wallet addresses for the developer commission.

https://github.com/Nexusoft/Nexus/blob/ea9aa220b4e2d079ee9f18ea8f72ee61fa796015/src/core/global.cpp#L129-L142

You will also see the recycler addresses I posted previously located at:

https://github.com/Nexusoft/Nexus/blob/ea9aa220b4e2d079ee9f18ea8f72ee61fa796015/src/core/global.cpp#L113-L126

Developer Commission
•Built into the protocol levels, gives a small decayed amount to developer addresses every block [~1 Niro] over 10 years amounting to a total of ~2.5% after 10 years, and starting at ~1.5% as a way to bring the benefits of pre-mines, without the risk to investors. This means developer account has no control over the currency as it will never be of a high enough %, but it allows funds to be distributed to development removing need for corruptible foundations such as the Bitcoin Foundation which was spawned to cover developmental costs.

I'd like some clarification on this one, 2.5% of what? And if the developer does not control the funds who does??? A few post back I calculated the total of the recyler addresses posted at around 19% of current supply. Is there a different developer address and if so can you please post it.

Same man.  Glad there is a fix in the works.

The layout demonstrated by merc above is much easier on the eyes.

Top half of revised op is great and as good as others.  2nd half just needs some attention as suggested. It looks a bit like an essay as it stands, content is all there.

ETA: Just lost another trust key by about an hour

Mining Channels
•Each channel reinforces each other to prevent 51% attacks on one channel forcing attacker across multiple channels.
Hashing
•SK-1024, SK-576, SK-512, and SK-256 used in all hashing. Pure SHA3 using Skein and Keccak.
SK-1024
•Using Skein-1024 and Keccak-1600 for GPU PoW to produce a 1024 bit output hash used for the block hash providing the highest security.
Prime
•Searching for Dense Prime Clusters as CPU PoW, finding these clusters of numbers that are ~308 digits to verify prime density in large numbers.
Keys
•571 Bit Private Keys compared to 256 bit in other currencies. Using NID_sect571r1 as the algorithm.
Difficulty
•Calculated with time overlaps and true % over bounds, using weighted block average over past 5 blocks.
LLP
•Lower Level Protocol as a template protocol to allow any protocol to be created with ease without need for repeated network programming.
Core LLP
•Protocol responsible for time keeping as an advancement to NTP, keeping clocks on the network synchronized within a few seconds of one another. Maximum clock drift for Nexus is 10 seconds.
Mining LLP
•Dedicated Mining Protocol outside of JSON-RPC Server to allow the greatest performance for mining. Protocol can handle 5k + connections allowing solo mining of any magnitude.
No Reward Halving
•Rewards are calculated along an exponential decay curve to slowly reduce the value of each block rather than shock both miners and the market with block reward halving which acts as a rudimentary decay model.
Released Reserves
•Decayed Amounts are deposited into the Reserves for each channel, preventing a miner from being able to mint more than the projected amount while difficulty is compensating to their amount of computing power.
Fractional Rewards
•When reserves are below given thresholds, the mining reward is then based off of the time it took to create a block preventing a miner from ever being able to deplete the reserves.
Decentralized Checkpoints
•All blocks must root from the most recent checkpoint which is declared by fitting into a timespan. This allows checkpoints to be automatically created every hour, without the need for any master node or checkpoint broadcast.
Trust Keys
•Interest rate is increased the more a node services the main chain giving incentive to active stakers. This also increases the cost of an attack for in order to attack with a trust key it requires time to get it to the same threshold.
Nexus Proof of Stake
•Proof of Stake system based on the Peercoin protocol heavily recoded from the ground up utilizing energy efficiency threshold, trust keys, and logarithmic weights to create the fairest and most stable Proof of Stake system to date.
Developer Commission
•Built into the protocol levels, gives a small decayed amount to developer addresses every block [~1 Niro] over 10 years amounting to a total of ~2.5% after 10 years, and starting at ~1.5% as a way to bring the benefits of pre-mines, without the risk to investors. This means developer account has no control over the currency as it will never be of a high enough %, but it allows funds to be distributed to development removing need for corruptible foundations such as the Bitcoin Foundation which was spawned to cover developmental costs.

Had some free time so I re-organized and formatted some of the OP I think it looks clearer but you may disagree... also edited a small typeo which is underlined  
Edit: Underlined another typeo  

Thanks it is a work in progress, but I think it provides most of the relevant information.  The last two sections weren't meant to be final, but thought it was best to get this out as a start.  Can you provide an example of an OP that meets your requirements?  Though not perfect, this is better than many.  

Current Format

1. Mining Channels: Each channel reinforces each other to prevent 51% attacks on one channel forcing attacker across multiple channels.
2. Hashing: SK-1024, SK-576, SK-512, and SK-256 used in all hashing. Pure SHA3 using Skein and Keccak.
3. Keys: 571 Bit Private Keys compared to 256 bit in other currencies. Using NID_sect571r1 as the algorithm.

Suggested Format

Mining Channels: Each channel reinforces each other to prevent 51% attacks on one channel forcing attacker across multiple channels.

Hashing: SK-1024, SK-576, SK-512, and SK-256 used in all hashing. Pure SHA3 using Skein and Keccak.

Keys: 571 Bit Private Keys compared to 256 bit in other currencies. Using NID_sect571r1 as the algorithm.

Maybe use bullet points...  change the font / font sizes ...   something needs to be done.  Maybe the double spacing is too much for the quantity of information that needs to be displayed, but in the current format, everything is smashed together.  Nothing stands out.


No offense, but if you really don't see what I mean about it being jumbled, maybe you shouldn't be in charge of its implementation (not that I'm stepping up to the plate).  It's very difficult to read and the organization is terrible.

Thanks.  We have established that the font size is too large and will be updated.  Please provide examples of how you think the organization could be changed.  I'm not sure what you mean about it being all jumbled.  The sections are clearly labeled with a divider.  Are you referring to the spacing in the Current and Planned features section specifically?