Due to exploits found in KGW, I've implemented a new difficulty retargeting algorithm called DarkGravityWave. You guys might be interested, it's a major improvement over KGW and a complete rewrite.
What is DarkGravityWave? It uses multiple exponential moving averages and a simple moving average to smoothly adjust the difficulty. This implementation is far more simplistic and better suited to adjust difficulty than KGW and also fixes all known exploits.
Check out the source if you're interested:
https://github.com/evan82/darkcoin/commit/07c99052edc617975cdcbe4482e02c52e2d1fbf5
Topic: delete (Read 34069 times)
Please follow through with this and be successful. Auroracoin is a stupid, scammy coin with a stupid plan for stupid people.
Yeah, Bitcoin is safe because 2016 blocks is longer than the ~5 blocks or so that the median-of-last-11 blocks rule allows anyone to jump backward. You can play silly buggers with timestamps but the effect of it will be small enough that it's pointless. The fix proposed above is for cryptocurrencies that have introduced a vulnerability by retargeting every block.
The only true security against any difficulty and/or tw exploits is multi-peta hash rate.
~BCX~
When does the action start? St Patty's Day?
Keep in mind, anything that is limited to the cpu level of mining will totally owned by the botnetters as soon as any coin becomes profitable.
I made a killing with XPM.
I made a killing with XPM.
Not "anything". Just things that can run well on the average hardware and stay under the radar.
A proof-of-work system that uses 4+GB of memory will send the vast majority of botnet computers into swap-hell, resulting in
1) negligable hashing power
2) their owners realizing something is very wrong
Even at that, botnets are keeping the chain secure and getting paid for it, just like regular miners. The fact that they're stealing the compute power and electricity to do it doesn't directly affect the altcoin itself.
It is kinda scummy though.
It is kinda scummy though.
Keep in mind, anything that is limited to the cpu level of mining will totally owned by the botnetters as soon as any coin becomes profitable.
Damn, you're right. Idiots run Windows boxes and continually get Pwned by botnets.
It may be possible to implement consensus based p2p checkpoints as some people mentioned previously.
Irrelevant to the AUR test I know, but I've been considering using AES256 as the basis of a "hash" function for the altcoin, because AES256 is built into hardware on most modern CPUs and so you could easily create mining software to take advantage of the capability. Instead of incrementally building up to ASIC miners, we'd be starting with everybody having ASIC miners (with only as much parallelism as the CPU, but still significant).
GPUs can do AES in parallel, but they don't have it built into hardware so even in parallel they're still not as fast as an 8-core CPU at it. The eventual custom ASICs would build that massive parallelism, but I think an altcoin could be well established before they arise and inevitably centralize mining.
GPUs can do AES in parallel, but they don't have it built into hardware so even in parallel they're still not as fast as an 8-core CPU at it. The eventual custom ASICs would build that massive parallelism, but I think an altcoin could be well established before they arise and inevitably centralize mining.
BTCX, as dev of a not-yet-released altcoin, I admire your work on examining and revealing security flaws in altcoins.
If/When I release, I'd really like you to have a crack or two at mine, just to make sure if I got it right and, if no breaks are found or if every break found is quickly fixed, increase long-term confidence.
The multi-petahash hash rate of Bitcoin is indeed excellent assurance against any "reasonable" attack. But as you have said, most people who thought they could "improve" on the design have instead demonstrated why the design is more robust than their improvements.
The fact that ASIC mining rigs have reached the current standards for high-performance chips at 28nm also means that Bitcoin is relatively safe from further very rapid advances in mining rig speed or exploits by people who take advantage of higher tech. The hash rate from here grows as fast as people acquire more machinery and as fast as computer hardware in general advances, rather than with the overwhelming advantage of faster machinery becoming available much more rapidly because people apply increasingly advanced process to it.
But the fact that those rigs exist is deadly for altcoins on SHA256; people with multi-Ghash mining rigs jump on and off of altcoins mining low difficulties with machinery that would, if it mined steadily, result in considerably higher difficulty. Also the 51% attack -- even straight up with no exploits due to stupidity like the time warp attack -- is very hard to defend an altchain against. So that's a real quandary for altcoin devs. With an altcoin you can't take advantage of the SHA256 infrastructure because people who've invested $millions in hashing hardware have the ability to instead take advantage of you.
I keep looking at some variation on proof-of-stake, but the current implementations of PoS are all flawed (and all in more or less the same way) because people can use their stake to mine more than one branch of a chainfork simultaneously instead of committing to one or the other.
If/When I release, I'd really like you to have a crack or two at mine, just to make sure if I got it right and, if no breaks are found or if every break found is quickly fixed, increase long-term confidence.
The multi-petahash hash rate of Bitcoin is indeed excellent assurance against any "reasonable" attack. But as you have said, most people who thought they could "improve" on the design have instead demonstrated why the design is more robust than their improvements.
The fact that ASIC mining rigs have reached the current standards for high-performance chips at 28nm also means that Bitcoin is relatively safe from further very rapid advances in mining rig speed or exploits by people who take advantage of higher tech. The hash rate from here grows as fast as people acquire more machinery and as fast as computer hardware in general advances, rather than with the overwhelming advantage of faster machinery becoming available much more rapidly because people apply increasingly advanced process to it.
But the fact that those rigs exist is deadly for altcoins on SHA256; people with multi-Ghash mining rigs jump on and off of altcoins mining low difficulties with machinery that would, if it mined steadily, result in considerably higher difficulty. Also the 51% attack -- even straight up with no exploits due to stupidity like the time warp attack -- is very hard to defend an altchain against. So that's a real quandary for altcoin devs. With an altcoin you can't take advantage of the SHA256 infrastructure because people who've invested $millions in hashing hardware have the ability to instead take advantage of you.
I keep looking at some variation on proof-of-stake, but the current implementations of PoS are all flawed (and all in more or less the same way) because people can use their stake to mine more than one branch of a chainfork simultaneously instead of committing to one or the other.
Yeah, Bitcoin is safe because 2016 blocks is longer than the ~5 blocks or so that the median-of-last-11 blocks rule allows anyone to jump backward. You can play silly buggers with timestamps but the effect of it will be small enough that it's pointless. The fix proposed above is for cryptocurrencies that have introduced a vulnerability by retargeting every block.
1. Mine blocks to the future getting 10% lower diff every block.
2. When you are at the lowest diff, stay on that time by jumping forward-backward-forward-backward..
For this to sucess, one must be able to generate blocks without going forward on time while keeping diff low. So jumping forward- backward has to generate higher diff/block than going forward only.
Edit: Not sure but I think this scenario would not work; he would get 10% lower diff every time he goes forward, but 20% higher when backward -> he would end up very high diff shortly.
Exactly. When you jump backward in time you undo any lowered diff you got by going forward in time. And because backward is a negative interval, it counts as shorter than the minimum interval to get a maximum upward difficulty bump. So the sequence is
Forward (lowers diff by 10%)
Backward (undoes that, and raises diff by 10%)
Forward (lowers diff by 10%)
Backward (undoes that, and raises diff by 10%)
etc...
If you do the forward/backward thing, you raise the difficulty by 10% each time you jump backward, so you rapidly get to the point where the main chain is producing blocks much faster than you.
Actually, the original bitcoin still has this vulnerability! However, I doubt any entity would be able to use it.
scenario:
- Miner has 10% of the total mining power
- He starts isolated mining with timestamps 25% over the normal, ie 12.5 minutes
- He continues 2 weeks (his blochaintime, would be 20 weeks realtime!), and gets 25% easier diff
- He continues next 2 weeks, gets again 25% easier diff
- repeats until diff is very low
- now he starts mining 5 blocks forward with 12.5 min interval and one block backward to the same moment (or 1 sec more). This keeps his diff low!
He continues this until real blockchain is on the same time. (might take years....)
He publishes his blockchain.
Edit: Would not work. The last step won't keep his diff low. Difficulty is retargeted every 2 weeks, so he will get 25% higher diff after every 2016 blocks. If retarget time is >= (mediumblocks-1)/2, it won't work.
If this is due to being able to produce blocks in the future or the past the fix can be applied to the coin code to limit the acceptable difference in time between the blockchain and the block. Feathercoin saw massive time warp attacks pushing blocks on from yesterday. They coded for this and I have chosen to include this code in the coin I am launching tomorrow which uses KGW. The problem is that most coins leave the little code that manages time the same as where they forked it from but make block time and retargets quicker making them more exposed to attack.
So if KGW has this exploit, shouldn't all KGW coins put up a bounty for getting it fixed asap? Which coins have already fixed it btw?
1. Mine blocks to the future getting 10% lower diff every block.
2. When you are at the lowest diff, stay on that time by jumping forward-backward-forward-backward..
For this to sucess, one must be able to generate blocks without going forward on time while keeping diff low. So jumping forward- backward has to generate higher diff/block than going forward only.
Edit: Not sure but I think this scenario would not work; he would get 10% lower diff every time he goes forward, but 20% higher when backward -> he would end up very high diff shortly.
Exactly. When you jump backward in time you undo any lowered diff you got by going forward in time. And because backward is a negative interval, it counts as shorter than the minimum interval to get a maximum upward difficulty bump. So the sequence is
Forward (lowers diff by 10%)
Backward (undoes that, and raises diff by 10%)
Forward (lowers diff by 10%)
Backward (undoes that, and raises diff by 10%)
etc...
If you do the forward/backward thing, you raise the difficulty by 10% each time you jump backward, so you rapidly get to the point where the main chain is producing blocks much faster than you.
Here is a simple fix for the exploit.
When a block has an earlier timestamp than the previous block, its difficulty adjustment needs to be based on the difficulty of the most recent block its timestamp is later than rather than on the block immediately prior in the block chain.
For example, if a block has a time earlier than the last four blocks then it should start its difficulty calculations with the difficulty as it was before those four blocks.
I think that this makes every instance of the time warp exploit impossible.
And it's a simple adjustment to whatever difficulty algorithm you're using. Kgw included.
When a block has an earlier timestamp than the previous block, its difficulty adjustment needs to be based on the difficulty of the most recent block its timestamp is later than rather than on the block immediately prior in the block chain.
For example, if a block has a time earlier than the last four blocks then it should start its difficulty calculations with the difficulty as it was before those four blocks.
I think that this makes every instance of the time warp exploit impossible.
And it's a simple adjustment to whatever difficulty algorithm you're using. Kgw included.
Hmm.. One scenario where this would not work.. and maybe also that fix which would allow jump back 1 block:
1. Mine blocks to the future getting 10% lower diff every block.
2. When you are at the lowest diff, stay on that time by jumping forward-backward-forward-backward..
3. Repeat that until your block's time is in the real time window and publish it
For this to sucess, one must be able to generate blocks without going forward on time while keeping diff low. So jumping forward- backward has to generate higher diff/block than going forward only.
Edit: Not sure but I think this scenario would not work; he would get 10% lower diff every time he goes forward, but 20% higher when backward -> he would end up very high diff shortly.
I am a little confused on how someone can flagrantly flaunt the idea of purposely crippling a network and not be in prison. Calling it a "stress test" or not doesn't mean it is any less or more legal.
You will end up picking a fight with the wrong person eventually...
You will end up picking a fight with the wrong person eventually...
AFAIKT it is all just braggadocio and posing. There is no evidence anywhere (other than anecdotal) that he has done, or is capable of doing, any of the things he claims or threatens.
~~^^^~~
really?
you're lazy or just stupid? there's this function called "search", and look at past few years.
BCX basically killed plenty of coins and pools.
when he/she/it will do something, it will happen.
Simple rule. You go back to the most recent block that is timestamped earlier than the current one. Whether or not the previous block is also backward in time it's later than the current one or we wouldn't be calling the current block backward in time.
As for a modified block with a fake timestamp, that can't happen because it would not match its hash. Nobody would mistake that for a valid block.
As for a modified block with a fake timestamp, that can't happen because it would not match its hash. Nobody would mistake that for a valid block.
Here is a simple fix for the exploit.
When a block has an earlier timestamp than the previous block, its difficulty adjustment needs to be based on the difficulty of the most recent block its timestamp is later than rather than on the block immediately prior in the block chain.
For example, if a block has a time earlier than the last four blocks then it should start its difficulty calculations with the difficulty as it was before those four blocks.
I think that this makes every instance of the time warp exploit impossible.
And it's a simple adjustment to whatever difficulty algorithm you're using. Kgw included.
When a block has an earlier timestamp than the previous block, its difficulty adjustment needs to be based on the difficulty of the most recent block its timestamp is later than rather than on the block immediately prior in the block chain.
For example, if a block has a time earlier than the last four blocks then it should start its difficulty calculations with the difficulty as it was before those four blocks.
I think that this makes every instance of the time warp exploit impossible.
And it's a simple adjustment to whatever difficulty algorithm you're using. Kgw included.
That sounds good. But I just thought of one scenario: What if the most recent block IS a block with a modified earlier timestamp?
Here is a simple fix for the exploit.
When a block has an earlier timestamp than the previous block, its difficulty adjustment needs to be based on the difficulty of the most recent block its timestamp is later than rather than on the block immediately prior in the block chain.
For example, if a block has a time earlier than the last four blocks then it should start its difficulty calculations with the difficulty as it was before those four blocks.
I think that this makes every instance of the time warp exploit impossible.
And it's a simple adjustment to whatever difficulty algorithm you're using. Kgw included.
When a block has an earlier timestamp than the previous block, its difficulty adjustment needs to be based on the difficulty of the most recent block its timestamp is later than rather than on the block immediately prior in the block chain.
For example, if a block has a time earlier than the last four blocks then it should start its difficulty calculations with the difficulty as it was before those four blocks.
I think that this makes every instance of the time warp exploit impossible.
And it's a simple adjustment to whatever difficulty algorithm you're using. Kgw included.
Jump to: