 Show Posts
|
|
Pages: [1] 2 »
|
|
I only know about difficulty algorithms and timestamps. This lets us know the attacker spent less than $1 to get the 567,000 blocks. The important question remains. Why were nodes rejecting the public chain for the attacker's chain that had less work? Simply saying the attacker spun up a lot of nodes for a Sybil attack is not sufficient. The whole point of POW is to prevent that kind of problem. What did Verge change in BTC's node communications or most-work tip selection that makes this attack possible?
|
|
|
|
|
My point about the Sybil attack on peer time is that if the attacker used it to corrupt node databases, then their own chain can get mined on top of by miners who do not have another option, even though the attacker's chain has less work. The attacker's chain seemed to have very little work because the difficulties I saw were like 0.000044 for most of them instead of 50,000 or something. A simple attack would start back in July like they did because they can fake a long time between block timestamps to get difficulty really low in a small number of blocks, then just assign timestamps 1 normal block time apart so difficulty does not increase. So a 1% hashrate miner might be able to get 560k blocks in only 1 day. A more advanced attack would use what I call the "timespan limit attack" (the nTargetTimespan/3 stuff above) that does not need to go back to July and could advance the chain a large number of blocks with a really low difficulty. That would also take a small miner maybe a day. In both cases, they normally only work if the attacker has >51% HR. So the peer time attack (or something similar) would have to be used for a smaller miner to succeed.
|
|
|
|
jwinterm recommended I take a look, but I only glanced at the white paper. Instead of changing chain work to motivate alternating, why not change the difficulty? It seems like this would reduce the number of orphans. Another idea for combining POS and POW is to let block wins be proportional to (% network HR) * (% network stake) but give a reward that's only proportional to the HR. I'm more interested in new types of PoS (Casper, Dfinity) where the stake is at risk if there is a double spend. The ideal POW is to require all your miners to purchase equipment that is only useful for mining your coin and no other equipment can compete with it. It would also not use any electricity and it would not depreciate. This way the staked equipment / non-staked equipment ratio is a max. But instead of them actually possessing the equipment, you use a POS system that simulates the existence of the equipment. To do it correctly, the virtual equipment stake must be at risk as real equipment would be devalued if you attacked a coin too much and force devs to switch POW. Although I have not thought through the problem of old stakers giving away keys to old block wins. Yes, LWMA with N=60 will vary +/- 20% many times a day as the link below shows for the coins I follow http://wordsgalore.com/diff/N=144 will give it more stability. I have historically been biased towards faster response because response time is a function of N while stability is a function of SQRT(N), so you get more bang for your buck in a sense by keeping N low. But N=144 would certainly look more friendly and I think it will have enough speed in the vast majority of coins. Edit: or LWMA with N=720. It would probably look good bit like your last simulation, as jwinterm said. arto in the link above is using a 24 hour LWMA. It looks too smooth. BTG is using N=45 and it looks just as stable as N=60, but it does have a lot higher hashrate than the others. Wownero is going to use N=144 (1/2 day at their T=300 To clarify, I assume your POS block come in very regularly, otherwise I don't know how it has a difficulty algorithm like the POW blocks. Assuming that's the case, by "changing difficulty instead of chain work" I mean to drastically raise and lower difficulty for the POW block by a similar rule and leave POS as is. Your cumulative difficulty would then flow automatically from the difficulty. |
|
|
|
For example, a miner with 50% hashrate mines only half of the expected mining reward. A miner with 90% of the total hashrate would mine only a tenth part of the normal expected mining reward. I believe it would dezentralize and stabilize the hashrate, but I cannot say, if it is technically solvable.
No, it's not technically solvable. You have the right idea, but you're touching upon the deep problem of forming a consensus which is the core of keeping cryptocurrencies out of central control. POW achieves this goal only if you're the largest coin for the type of equipment being used for the coin, so that miners are forced to not attack the coin so that their equipment remains profitable and worth something. Hashrate is automatically stable because they don't have something else to mine. In effect, the miner's equipment investment becomes their stake in the coin. If they attack, their stake loses value. Keeping the staked equipment / non-staked equipment ratio above 50% is the source of POW security which is how good POS systems works. There's no way to stop 51% of the miners from colluding to take value from the other 49%. So POS and POW work by making the miners put up a stake and have that stake at risk if they hurt the coin, so it does not matter if they collude because it does them no good. I'm working on a coin design to use this and other ideas. Most POW+POS are centralized instead of putting the stake at risk. |
|
|
|
The CN algo problems are why most of the clones switched to my LWMA https://github.com/zawy12/difficulty-algorithms/issues/3LWMA 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:  Stellite showed how bad things can get with it: https://user-images.githubusercontent.com/18004719/37669926-639d8e4e-2c3e-11e8-84da-5c3dd2ee9b79.gifAnd the improvement when switching to LWMA  |
|
|
|
Well, I have read through the code changes in https://github.com/Pigeoncoin/pigeoncoin/commits/master and find nothing about DoS issue fixes, but I see only a "false" changed to "true" and it suppose to be "true" as I found in bitcore source code, so seems like pigeon dev forked from a buggy source code that cause the issue. The fix to BTC was just as simple: change the false to true. |
|
|
|
|
The ideal cryptocurrency characteristics you listed are only the result of a characteristic that is the basis of all of Nick Szabo's charactersitics: constant value. Constant value means a certain amount of available (Gibb's) free energy (see Schrondinger's corrected "What is Life?" paper where he detailed what he meant by "negative entropy"). Since it is also a measure of control of other people, constant value is an amount of free energy per person.
Examples: if the real GDP of a marketplace increases, there is more free energy coming under control. In order to keep constant value so that prices, wages, and all other contracts in a marketplace to remain valid and enforceable to a common legal tender, the currency must expand and contract with the size of the "GDP". The best measure of "GDP" might be the free energy producible by the commodity infrastructure that uses the currency. It must also expand and contract inversely with the population that falls under its control. If there are too many people, employees become less valued so those holding the currency have more control of more people. The great problem is determining how to "fairly" or "properly" issue new coin (or destroy it) when it needs to expand or contract. "Properly" expanding and contracting probably means "in whatever way will lead to more free energy production in the future". That requires a governing intelligence above (controlling) the "invisible hand" on the macro scale. The marketplace is just micro solutions to the macro goal. One recent macro goal that has worked well (in terms of its ability to replace other systems) is more even distribution of wealth via democratic governing that subverts the marketplace by robbing from the rich to give to the average via progressive tax laws and equal rights that supply "welfare" such as roads, police/military/fire, education, and social security to all. (Marketplaces otherwise always evolved towards very unequal distribution of wealth and rights). Commodity-based coins of "old" like Bancor and William Graham's ideas were an attempt to partially solve the problem in a reverse manner: expand and contract the free energy via massive commodity storage and release when prices and wages started changing.
|
|
|
|
Hi, When you implemented my new LWMA difficulty algorithm ( https://github.com/zawy12/difficulty-algorithms/issues/3), you were supposed to change DIFFICULTY_WINDOW_V2 from 17 to 60 so that length = 60. You will need to fork to fix it. With N so low, difficulty can jump up and down a lot and you won't know if it's a real hash attack or random variation. But one thing's for sure: you currently have the fastest responding difficulty out of all coins. Difficulty jumped 30x in 20 blocks which caused a 4-hour delay, and now it's back down to 1/10 in 6 blocks. That's probably a record jump and fall. Do not limit the rise and fall of the difficulty. Just increase DIFFICULTY_WINDOW_V2. |
|
|
|
Qwerty and Bitsum say they are using one of my difficulty algorithms, but in looking at their charts, the difficulty changes really slow like they are using the default Cryptonight algorithm. It's not one of mine. Can someone enlighten me as to what's going on? BTW, here is my newest algorithm that Monero clones are switching to: https://github.com/zawy12/difficulty-algorithms/issues/3 |
|
|
|
|
Thanks for letting me know you implemented the LWHM difficulty algorithm. I developed it in November based on Tom Harding's wt-144 to try to provide the most protection to small coins by trying to discourage big miners from coming in and getting blocks, then leaving your dedicated miners stuck with a high difficulty. Masari is the only other coin using it. They've done a pull request on Monero (or Cryptonote?) to let others know about it. But I think your code is more correct. I designed and tested about 15 different algorithms in the past 18 months before settling on this one. It's better than any other algorithm I know of.
Since you began it yesterday, your delays and hash attacks have less than all but 7% of the previous days, and most of those "good days" were the result of issuing blocks a little too quickly (none of the solvetimes were this accurate).
In running the simulations again, I can see the adjustment factor I gave you is a little bit too high, which is why your average solvetime the past 24 hours was 176 seconds instead of 175 seconds, so I've adjusted the algorithm to be a little more precise for future coins. Your long-term average will be 175.5 seconds.
|
|
|
|
|
Has anyone used difficulty to get constant-dollar developer or node fees? Difficulty is exactly proportional to network hashrate, and network hashrate is closely proportional to coin price.
Say a coin is currently $1.23 and someone wants to get a fixed income from the coin like $0.01 each time something occurs. To achieve this they could use a constant that is multiplied by the difficulty:
fee = 0.0123 / difficultyat$1.23_per_coin * current_difficulty =~ $0.01
Dollar value here is constant-value relative to when the ratio was determined (when difficulty was at $1.23). If hash power is not able to keep up with coin price (which is a temporary effect), the value would be larger than expected. Otherwise, the real-world value slowly decreases as hashing efficiency increases, which may be a desired effect if it is for dev fees because software gets outdated. But Moore's law has gotten very slow for computers. Hashing should get closer to being a constant hardware cost per hash.
Also, electricity is more than half the current cost of hashing and could soon be 3/4 or more of the cost. Worldwide electricity cost is very stable and possibly the best single-commodity measure of constant value.
|
|
|
|
I'm trying to evaluate the difficulty algorithm, so I installed masari this morning, but it is not letting me get new blocks past 63507 (7 blocks after the changeover?). All it says are things like this: 2017-12-04 14:36:45.897 [P2P0] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:302 [50.17.174.202:38080 OUT] Sync data returned a new top block candidate: 63507 -> 63879 [Your node is 372 blocks (0 days) behind] SYNCHRONIZATION started 2017-12-04 14:37:30.716 [P2P5] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:302 [103.28.22.111:40256 INC] Sync data returned a new top block candidate: 63507 -> 63879 [Your node is 372 blocks (0 days) behind] SYNCHRONIZATION started 2017-12-04 14:37:32.781 [P2P8] INFO global src/p2p/net_node.inl:258 Host 34.234.145.76 blocked. Miners simply changing coins in pursuit of best price/difficulty ratio is desired behavior, but it is also an "attack" or "unfair" to your dedicated miners who are not as efficiently selfish. In one sense dedicated miners are merely whining. But the coin should take interest because they protect against 51% attacks by adding consistent diversity and because they are less likely to sell the coin. If difficulty algorithms could be perfect, the "attack" would not exist. They can't be perfect because the only way to know current hashrate is to collect and calculate it from recent solvetime and difficulty data, so there is a delay in response. If price changes a lot and the difficulty is slow, then big miners come in and get coin at low difficulty when the price jumps higher, and then leave when difficulty catches up, leaving constant miners with higher-than-appropriate difficulty for the length of the averaging window. But if the difficulty is made to respond fast, it has to base the calculation on fewer data points, so it will naturally vary more statistical "accidents" on the small N window. Historically I have pushed for low N, less than 30. But after seeing BCH do exceptionally well on keeping a low number of delays by using a large with N=144, I am having a change of heart. Coins have told me cryptonote's original code is effectively an N=300 and they have had to fork to get away from it. The problem (presumably) is that there is a good price increase so they get a lot of mining, but then it suddenly drops and no one want to mine it and it's going to take 300/2=150 blocks to get half-way back down to where it needs to be. I have not yet looked into cyrptonote code and data from coins to see exactly what the problem is, but that makes me afraid of N=144 for small coins. I have also been told BCH seems to be depending on Chinese pools actively deciding to not harm BCH. Zcash and its clones have done well with Digishield v3 with N=17 which is effectively an N=63 algorithms. For this reason I considered N=60 to be safe, and larger like I was seeking, but not risky like N=144. The weighted nature of this algorithm makes it respond faster to hashrate changes, which also means it will overshoot and undershoot more than Zcash which means big miners will see more opportunities to jump on when price/difficulty ratio looks good (by more accidentally lower difficulty). However, as it responds faster quicker, they will not be able to stay on and get as many blocks as they normally do on Zcash and its clones. On Zcash they get about 20 "cheap-difficulty" blocks about 3 times a day, a "loss" of about 10% of Zcash coins, as the difficulty accidentally goes low about 3x per day. So constant miners have to pay an excess difficulty of 10%. For Masari's WWHM N=60 algorithm, I expect twice as many price/difficulty opportunities per day than if Digishield v3 N=17 ("N=63") code were used, but only 1/2 as many blocks stolen per opportunity. I see this in testing. I do not know if not being able to get as many blocks "per attack" makes attacks less appealing, but I hope so. Also, the digishield v3 does not adjust for 5 or 6 blocks after a sudden hashrate change begins. This may cause some minor oscillations in Zcash. Although "blocks stolen" at "cheap-difficulty-cost" might be the same, testing indicates post-"attack" delays will be 1/3 as much in Masari as Zcash. Review the following chart to see "state of the art" difficulty algorithms. I have learned a lot in the past few days. I just found two levels of improvement over what Masari is using (which is what I recommended), but I have been expecting the WWHM that Masari is using to be the best algorithm. For EMA and Dynamic EMA details (the two new improvements) see http://zawy1.blogspot.com/2017/11/best-difficulty-algorithms.html Someday in my blog i'll write an "all things difficulty" article to cover everything.  |
|
|
|
how would you go about creating a decentralized system that agrees on the current time?
Preferably not Proof of Work.
Preferably not Proof of Work. Your question stops being interesting when you start removing the only known solution for strong decentralized consensus— even in the proof of work model an effort to do consensus time probably fails for incentive reasons, but no one knows how to do decenteralized consensus absent the expenditure of work. I have a solution gmaxwell hasn't thought of. By looking at the stars with a camera to periodically calibrate, time can be an objective fact computers can determine for themselves without consensus. Honest nodes would reject dishonest transactions and blocks that do not have the correct time, within some error. With this solution, mining and blocks are not needed. It would be a simpler "transaction chain". Nodes would share transactions and reject spends of the same coin if they occur within say 1 minute of each other, or reject any second spend that occurred more than 1 minute after the 1st one. |
|
|
|
I asked that because when you click in the invite link from the website it's showing in MAINTENANCE
Is that okay?
There's some problem with a redirect from their web page. Go straight to the slack channel: https://myhush.slack.com |
|
|
|
Hi guys, I have a question. I have seen post where you all discuss how this coin is better then the other zcoins, but what would be the difference between HUSH and a coin like KORE, tech wise? KORE is not related to Zcash and HUSH. Why do you think it has strong security, privacy, or anonymity? It's not even a POW coin anymore. Are the devs people you know and trust or are you familiar enough with the technology that you can trust it? Zcash and HUSH seem to have much better technological pedigrees. |
|
|
|
|
