Topic: [ANN][ZANO] New Sources|1st ProgPowZ|PoW/PoS Hybrid|Scalable|Private|Contracting - page 23. (Read 36422 times)

Can you clarify what you mean by "advantage" here?
What I am doing is trying to protect relatively small miners, against big miners which can do these greedy mining policies.
But actually it's not about big or small miners, it's about fast and stable adaptation to conditions I guess.

Small instances should have an advantage, for example a miner with 50% of the hashrate has a disadvantage of 50%, a miner with 90% of all hashrate has a disadvantage of 90%, a miner with 1% of all hashpower has a disadvantage of 1%. Very small miners do not have any disadvantage in this case.

The CN algo problems are why most of the clones switched to my LWMA

https://github.com/zawy12/difficulty-algorithms/issues/3

LWMA gives linearly more weight to more recent blocks. It's commonly used in stock plots. I got the idea from Tom Harding who was looking for idea to help BCH 1.5 years ago.  The method you're using is a mild form of the LWMA, giving double weight to the 200 most recent blocks.   It does not look aggressive enough.  Most of the current LWMAs are using N=60 due to my recommendation, but it might be better to use a slower value like N=200. That would give more stable results, but be slower to respond.  If LWMA is used with N=720, then it will rise about 3x faster and drop about 6x faster than the original CN if there is a big on-off miner, but it will have the same stability if hashrate is constant.

Balkan is a typical example of the improvement seen when switching from the original CN to LWMA:

https://user-images.githubusercontent.com/18004719/39790727-a7ef67fa-5305-11e8-9e55-b645d4db639d.png

Stellite showed how bad things can get with it:

https://user-images.githubusercontent.com/18004719/37669926-639d8e4e-2c3e-11e8-84da-5c3dd2ee9b79.gif

And the improvement when switching to LWMA

https://user-images.githubusercontent.com/18004719/39750127-6bb43078-5282-11e8-8011-5202bb651393.png

I'm not an expert, just a simple miner, and what I see seems much better... the difficulty adjustment responds faster to hashrate changes up and down the curve, so this is very promising. Good job, CZ!

Hi folks!

I've been doing some research on difficulty adjustments function and want to share results and ideas, analysis and critics are very welcome.

Motivation.
Some miners were doing one of the typical "greedy mining" strategies - abruptly raised hashrate, keep mining until difficulty get adjusted, and then dropped all hashrate, leaving a network stuck with one blocks/hour or even worse. For miners/pools this strategy is profitable because it let them get "cheap" blocks(mined with low difficulty), but this is definitely a problem for cryptocurrency - in such situation transactions confirmations takes hours, and other fair miners are quitting because mining on high difficulty is getting unprofitable.
I want to remind that at the early days Boolberry was suffered from this, and I've decided to take this historical data as "real-life" example for testing new difficulty adjustment.

Analysis.
1. Boolberry blocks history was reviewed and picked up a representative period, where hashrate was raised and dropped in this typical manner. Then, using difficulty associated with the blocks and their timestamps estimated hashrate was derived. Here what I've got:



That was a first week of June 2014, and as it seen on marked areas - there was a hard time for the network, blocks were coming once per hour and i had to ask loyal miners to make some blocks even though it was unprofitable. Ok, drama is over

Then, using this hashrate numbers associated with time became possible to calculate estimate blocks flow with timestamps and difficulty values progression, and this simulation had been run for bunch different variations of adjustment functions.
At this graph showed original cryptonote adjustment function(the blue one), couple variations with “adjustment window”, and currently preferred version(green one):



It calculated as combination of original adjustment functions for two different periods:

D = (D720(historical_data) + D200(historical_data))/2

Where:
 - D720 - function which calculates difficulty based on 720 blocks window with 60 / 60 cuts
 - D200 - function which calculates difficulty based on 200 blocks window with 5 / 5 cuts

Conclusions.
As seen on the curve this adjustment algorithm adaptation is definitely better by correction of D200, at the same time this still protected from timestamps manipulations due to the heavy influence of D720.

This function still a draft, we gonna make more simulations to check possible fluctuations, performance problems. Simulation is pretty naive, it doesn’t do absolutely realistic conditions, but it gives a pretty clear picture of adjustment function behaviour.


Would love to see some feedback&critics.

Thanks mate! That suddenly puts a lot of things and perspective and completely alters the way I've been looking at some MW blockchain branding. Almost feeling like a dupe for falling for some. Looking forward to further info from the team though. Seems like one just can't stop learning in this industry

No date yet, depends on testnet performance, best estimate is before the end of February.

any updates about launch month/date?

I guess team will come with a better answer and more official as well.   But to what i've heard, MW is mostly a layer 2 it can be added to pretty much any other layer 1 tech out there.  So it's not really comparable like 2 different layer 1 projects would be.  

I guess the team will come out with a more official statement because this question is asked a lot lately (and with reason).

Spot on mate. Been waiting for a "tell-me-like-I'm-5yo" delivery of the differences between these MW implementations. Wouldn't mind having it delivered as an infographics or table of comparison. Handy for quick consultation and sharing

For a non-technical reader, what are the practical differences between Mimblewimble projects (Grin, Beam) and what Zano brings to the table, especially regarding the main 2 aspects: privacy and blockchain size?
I mean from a users point of view...

Do let us know the results.

Hi folks!

A few days ago we've launched first public testnet, we just put there new PoW hash(WildKeccak2 Alpha version) and made a bunch of changes.
We still have tons of things to do, but we decided to open it for those who want to take a look into it.

https://medium.com/@zano_project/zano-testnet-c92723087d09

Feel free to write bug reports on github: https://github.com/zano-project/zano/issues


PS: This is testnet, don't get crazy, please don't do a lot of mining and don't rise difficulty - this testnet will be killed, and we'll run bunch of next testnets before we'll get ready for production main net.

---

This question is very important actually, and as soon as we got stable testnet and finished with urgent improvements we'll run stress test's on testnet and see exactly how it act on hight load.

Performance is one of our priorities! 

---

Oh, and I almost forgot, we finally got a brief history of the Boolberry project for those who have not followed it since 2014:

https://medium.com/@BoolberryBBR/a-brief-history-of-boolberry-c4048d692272

Enjoy!

PS: Just to clarify - Zano project had been derived from Boolberry codebase.

My personal estimations are -80% of BTC blockchain size via blockchain pruning, but TPS will be magnitudes larger than any other cryptonote @ present.

What would be the size of Zano blockchain if it contained all BTC transactions. BTC is around 200 GB atm, how much does Zano improve this aspect?

How many transactions per second is Zano capable of?

From our whitepaper:

You can download the full whitepaper here: https://zano.org/


1.2 Zano’s PoS Implementation

Ring signatures allow the transaction creator to provide a set of possible public keys for signature verification, thus keeping their identity indistinguishable from other users. The concept of an anonymous, secure PoS mechanism seemed to be unachievable.

The basis of PoS is a so-called kernel, which is a data structure that depends on the transaction output and includes:

• Current timestamp with 15-second granularity.

• Key Image, which corresponds to each transaction output. A keyimage is comprised of 32 pseudorandom bytes derived from the key in such a way that it is impossible to reconstruct the key, given only its image.

• Stake Modifier. An additional 64 pseudo-random bytes derived from the last PoS and PoW blocks, which disallows any predictability of the stakemodifier in the blocks ahead.

During mining, a user is allowed to sign a block, if Hash(kernel) < CoinAmount ∗ PosTarget, where CoinAmount is the amount of coins in a particular output, and PosTarget is an adaptive parameter that works to keep the block creation rate constant.

The PoS miner iterates the timestamp (within the allowed boundaries) for each of their unspent outputs (UTXO) and checks to see if they possess a UTXO that’s keyimage satisfies the PoSTarget formula above. In the event of a ”winning” result, they spend this particular output, anonymously, with a ring-signature.

Note: The signature includes the keyimage (used in the kernel), but not the key itself, which is why it does not compromise anonymity. The miner signs both the transaction and the block and broadcasts the new block to the network.

With zano if im not mistaking you would need 51% of hashrate and 51% of all coins to attack it, but dont take my words for it, check with team for confirmation! 

If a pool double spends it will lose all its miners, so it can not "control a network over PoW"; yes, it can do all kind of things with that node but not with the network. With PoS you will never know if a malicious actor has sabotaged all or part of the nodes. There is not solution to 51% PoW attack because PoW is the only solution to Byzantine Generals Problem.

The cryptocurrency community must accept the risk of 51% PoW attack, unless wishes to renounce decentralization and privacy.

Not sure how much you have mined, but miners provide power to pools, pool is running the node so it can double spend and do all kind of things with that node, as long as the pow algo is the same miners don't know much about what they really do...

No surprised that everyone is worried about pools that owners near large chunk of bitcoin network...

Network can not be controlled "over PoW" by hacking pools, because hashing power is in hands of miners not pools itself. I don't know how a PoS network can be secure and how a PoS based coin can guarantee privacy, because PoS is inherently centralized.
Maybe privacy is not intended for zano?