Bitcoin Forum
November 27, 2022, 03:30:00 PM *
News: Reminder: do not keep your money in online accounts
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »
  Print  
Author Topic: [ANN][ZANO] New Sources|1st ProgPowZ|PoW/PoS Hybrid|Scalable|Private|Contracting  (Read 36114 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (1 post by 1+ user deleted.)
gigabyted
Hero Member
*****
Offline Offline

Activity: 906
Merit: 500



View Profile
January 21, 2019, 11:17:49 PM
 #81

PoS can not be decentralized and can not be secure. You will never know if an opponent has taken control of all or part of the nodes, all nodes can be compromised or hacked.
There will be no greater security than just the PoW, there will actually be less.

I believe its easier to hack 2 or 3 pools in order to control a network over PoW (and often 1 pool has more than 50% of it, so a single target to hit) than hacking all the nodes of a network.  Pools also run more code than a node so attack surface is greater.

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?

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...
1669563000
Hero Member
*
Offline Offline

Posts: 1669563000

View Profile Personal Message (Offline)

Ignore
1669563000
Reply with quote  #2

1669563000
Report to moderator
BitcoinCleanup.com: Learn why Bitcoin isn't bad for the environment
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1669563000
Hero Member
*
Offline Offline

Posts: 1669563000

View Profile Personal Message (Offline)

Ignore
1669563000
Reply with quote  #2

1669563000
Report to moderator
1669563000
Hero Member
*
Offline Offline

Posts: 1669563000

View Profile Personal Message (Offline)

Ignore
1669563000
Reply with quote  #2

1669563000
Report to moderator
1669563000
Hero Member
*
Offline Offline

Posts: 1669563000

View Profile Personal Message (Offline)

Ignore
1669563000
Reply with quote  #2

1669563000
Report to moderator
Entusiasta
Member
**
Offline Offline

Activity: 108
Merit: 10


View Profile
January 22, 2019, 02:33:55 PM
 #82

PoS can not be decentralized and can not be secure. You will never know if an opponent has taken control of all or part of the nodes, all nodes can be compromised or hacked.
There will be no greater security than just the PoW, there will actually be less.

I believe its easier to hack 2 or 3 pools in order to control a network over PoW (and often 1 pool has more than 50% of it, so a single target to hit) than hacking all the nodes of a network.  Pools also run more code than a node so attack surface is greater.

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?

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...

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.
gigabyted
Hero Member
*****
Offline Offline

Activity: 906
Merit: 500



View Profile
January 23, 2019, 02:24:04 PM
 #83

PoS can not be decentralized and can not be secure. You will never know if an opponent has taken control of all or part of the nodes, all nodes can be compromised or hacked.
There will be no greater security than just the PoW, there will actually be less.

I believe its easier to hack 2 or 3 pools in order to control a network over PoW (and often 1 pool has more than 50% of it, so a single target to hit) than hacking all the nodes of a network.  Pools also run more code than a node so attack surface is greater.

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?

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...

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.

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! 
hashappliance
Copper Member
Newbie
*
Offline Offline

Activity: 51
Merit: 0


View Profile
January 23, 2019, 06:10:38 PM
 #84

PoS can not be decentralized and can not be secure. You will never know if an opponent has taken control of all or part of the nodes, all nodes can be compromised or hacked.
There will be no greater security than just the PoW, there will actually be less.

I believe its easier to hack 2 or 3 pools in order to control a network over PoW (and often 1 pool has more than 50% of it, so a single target to hit) than hacking all the nodes of a network.  Pools also run more code than a node so attack surface is greater.

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?

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.
cryptobtcnut
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
January 24, 2019, 11:47:35 AM
 #85

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?
crypjunkie
Full Member
***
Offline Offline

Activity: 193
Merit: 100


View Profile
January 24, 2019, 08:52:35 PM
 #86

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?

My personal estimations are -80% of BTC blockchain size via blockchain pruning, but TPS will be magnitudes larger than any other cryptonote @ present.
crypto_zoidberg (OP)
Hero Member
*****
Offline Offline

Activity: 976
Merit: 646



View Profile WWW
January 25, 2019, 10:16:06 PM
Last edit: April 23, 2019, 01:30:07 AM by mprep
 #87

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.




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?

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.

cryptobtcnut
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
January 27, 2019, 02:28:12 PM
 #88

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?

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! 

Do let us know the results.
onecryptoguy
Jr. Member
*
Offline Offline

Activity: 64
Merit: 2


View Profile
January 27, 2019, 07:57:34 PM
 #89

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...
Bowtiesarecool
Sr. Member
****
Offline Offline

Activity: 1050
Merit: 295


View Profile
January 28, 2019, 10:14:44 AM
 #90

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...
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
gigabyted
Hero Member
*****
Offline Offline

Activity: 906
Merit: 500



View Profile
January 29, 2019, 02:08:48 AM
 #91

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...
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

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).
Newton90
Sr. Member
****
Offline Offline

Activity: 463
Merit: 256


View Profile
February 01, 2019, 03:26:59 PM
 #92

any updates about launch month/date?
crypjunkie
Full Member
***
Offline Offline

Activity: 193
Merit: 100


View Profile
February 01, 2019, 10:07:18 PM
 #93

any updates about launch month/date?
No date yet, depends on testnet performance, best estimate is before the end of February.
Bowtiesarecool
Sr. Member
****
Offline Offline

Activity: 1050
Merit: 295


View Profile
February 04, 2019, 07:36:25 PM
 #94

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...
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

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).
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
crypto_zoidberg (OP)
Hero Member
*****
Offline Offline

Activity: 976
Merit: 646



View Profile WWW
February 07, 2019, 09:19:00 PM
 #95

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 Smiley

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.


onecryptoguy
Jr. Member
*
Offline Offline

Activity: 64
Merit: 2


View Profile
February 07, 2019, 09:38:29 PM
 #96

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!
zawy
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
February 07, 2019, 10:51:20 PM
 #97

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
versprichnix
Sr. Member
****
Offline Offline

Activity: 876
Merit: 291


View Profile
February 08, 2019, 12:34:15 AM
 #98

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.
crypto_zoidberg (OP)
Hero Member
*****
Offline Offline

Activity: 976
Merit: 646



View Profile WWW
February 08, 2019, 01:38:35 AM
 #99

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.

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.

MoneroCrusher
Jr. Member
*
Offline Offline

Activity: 88
Merit: 1


View Profile
February 08, 2019, 05:52:04 AM
 #100

I have an idea that I want to see implement in Monero because it has the same problem but on a smaller percentage scale (10-15% since May 2018)

Try a weighted average instead of a normal average
in the example of 720 blocks,
take the first 50 blocks and give them a weight of 50%
take block 51-100 and give them a weight of 25%
take block 101-360 and give them a weight of 12.5%
take block 361-720 and give them a weight of 12.5%

720 is not necessary though, cut it down to a smaller sample and keep the same ratio, i.e. you could do 360 blocks instead of 720, or even 180 blocks
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!