Search content
Sort by
Showing 20 of 80 results by DeepCryptoanalist3
I think that it's better to solve difficulty time warp problem in the most obvious and simple way, that is to change the way required work is computed. Currently it is computed as 1/t, that is 15 sec target time is considered to be 4x more difficult (takes 4x more time) to find solution than 60 sec and this is probably not the case. You (and other bot operators) can do some experiments to determine how required time to find solution depends on target time, then we can construct some function that is good approximation of this dependency and use it instead of 1/t.
Another counter-measure is to add checkpoint, it will prevent whole chain forking.
Another counter-measure is to add checkpoint, it will prevent whole chain forking.
The map shall be enlarged anyway. The current state is ridiculous. Bots or humans they do not play the game but only falling through simple maps. That completely ruined the idea of a mining by play idea. Current state is not stimulating any AI research either.
I think DeepCrypto would agree that any meaningful solution will/must involve calculating difficulty (or difficulties) by some measure of both target time and block acceptance frequency, somehow, and must scale both.
Calculation difficulty shall prevent map preselection cheat. I am not sure that any other difficulty measure would be needed if map will be big enough to force competitors to actually play the game.
And yes. Time warp bug shall be closed somehow anyway. Time warp attack is not very relevant to anti bot measures.
it seems to me that all the maps being completed can be done by humans just as fast
I thought that some of current "bot owner" guys aren't even a bot owners. They have just made this easy map preselection cheat and riding that simple levels by hand. But then time between blocks have tightened to the target time. I am not sure about this now. A good prove that bots are actually exists can be the fact that time between blocks became significantly smaller than the target time. Is this the case now?
Anyway if the coin have been hacked in such a way then it should be abandoned. New version of the coin should have new genesis block. Those who play on this easy maps are went against the rules and they shall not receive the reward for this. If it will not be abandoned then it will be an indisputable sign that some of those cheaters are the coin developers themselves.
I'm not working on anything. Many proposals (including your proposal that we were discussing here) are flawed because people don't understand how it works.
Here are some good proposals that are at least possible but it is not clear how well will they protect us from bots:
1. Increase map size.
2. Add computational difficulty.
3. Add several coins to collect.
4. Change map generation algorithm to prevent fall-thru maps.
Here are some good proposals that are at least possible but it is not clear how well will they protect us from bots:
1. Increase map size.
2. Add computational difficulty.
3. Add several coins to collect.
4. Change map generation algorithm to prevent fall-thru maps.
But something should be done. While we a talking bot owners are mining. I am not very satisfied with the fact that we discussing the ways how to save the coin while bots are mining. It appears that we are now working to protect their wealth. This is not a normal situation.
Quote
Here are some good proposals that are at least possible but it is not clear how well will they protect us from bots:
1. Increase map size.
1. Increase map size.
We've already established that this will cut out the current generation of bots, but will do little/nothing in the long term.
On long term sha512 hash function is breakable. Enlarging map in 2 4 finally ten times will make generation of easy maps is not possible. The complexity of finding an easy map shall be bigger than enumerating 2^128.
But keep telling that this is not viable. Yep...
One thing I have been looking into for difficulty control is the possibility of setting the perlin function itself to scale with difficulty. Perlin complexity scales exponentially with dimension of the seed, so this might be a nice place to inject computational difficulty. I think that it would make more sense to increase complexity of frame calculation as opposed to increasing complexity of map generation (so that we never get into a situation where a user can't start a game because they don't have sufficient hardware to generate a map in reasonable time) but I'm not really sure if this is a better approach or not. I could imagine a similar situation where users' framerates are throttled to something annoyingly low simply because they can't calculate the perlin quickly enough to maintain.
What was that? I only see a bunch of words with no sense. Perlin function has no scale difficulty. What does it mean a "perlin complexity"? Perlin noise computation is not related to the map size it is always calculated from the 4 nearest points. And we aren't looking where to inject computation difficulty it is not a PoW currency.
New blocks will be mined at the edge of the accepted time, this will lead to many orphan blocks and network forks (probably short). Maybe more problems will arise, comparison with Bitcoin isn't applicable because in Bitcoin there is no reason for miners to set time to higher values and they just set it to current time and whole network accepts their blocks.
Blocks at the edge of accepted time will not be used by miners as base. Miners will be interested to mine starting from fastest blocks to be able to put their blocks in longer chain. Mining on already short chain pointing to the future is not practical. The same is with bitcoin now. The only real winning strategy is to use blocks who pointing to a moment in time which is closest to the genesis block among chains of the same length.
But the idea of a map enlargement looks also very interesting. This is very easy to implement right now and no need in such a deep analysis and looking for a pitfall. The map is not included into block and will not enlarge it. The size of a map will not affect emulation speed because collision detector needs to check only few closest blocks on every frame. And this solution will automatically kick off any map preselection cheaters. This is a very smooth way to go. Really. Lets remove the time threshold and let the map size be a subject for retarget.
I am not going to say that an individual block time shall be perfectly valid. The only restriction that the top of a main chain shall not end in remote future.
This is just the problem, "remote future" is effectively undefined because "current time" which it is relative to is effectively undefined. The allowed values for "remote future" would have to be quite remote, and quite broad. As such, I don't feel that this would accomplish what you think.
BitCoin is also using time paradigm to calculate thresholds. And it is also possible in bitcoin to form a huge chain pointing to the future and this chain will be declined because it is pointing to the future. The difference is not very big when we talk about the last block only. If some crazy miner will ignore this and will keep mining based on a block from the future he will finally end up with short chain when time will catch it up. This is not efficient all the gamers will try to use most recent blocks. Like in BitCoin.
You still didn't answer my question. How will you measure time interval between adjacent blocks? You are describing what you are going to do with it, but my question is how will you find it?
CBlockIndex structure already have nTime field in it. I am not sure who is filling it. Even if it is not a part of transferred block header then it can be added there. Miner can set this value while he broadcast a block he mined. "Like look guys I have a block started from that block, I used this time to mine it, and there is a solution that fit under the floating threshold, feel free to use it as the base for your mining". Other clients shall only verify that the time is lower than the current time say GMT it doesn't matter what global time will be taken in account the difference in few secs is not crucial for a single block.
It can still be interesting among miners to broadcast blocks from the future and start mining from that blocks to be the first one who continue the chain if no faster block will be found. But this is already up to miners what block to choose as the base yet no block from the future shall be considered valid by clients.
The whole point of a blockchain is basically the fact that you can't rely on wall clock time for anything at all. Other clients can't verify that time specified on a block is lower than "the current time" because for all participants "the current time" is actually just a (large) set of possible times, and is effectively undefined for most purposes. The one thing we very much do not (and can not) have consensus about is wall clock time. Our only reliable measurements of times are blockchain time which has a probabilistic constant frequency, assuming difficulty retarget is correct, and (in the special case of moto) bike run time which has arbitrary frequency.
No solution which requires some agreement about relative wall clock times can work.
I am not going to say that an individual block time shall be perfectly valid. The only restriction that the top of a main chain shall not end in remote future. There is no error accumulation issue then and perfect time synchronization is not critical. Even if some client will accept a block from future he will not be able to compete with miners who accepted and start mining from earlier blocks because his chain will be longer than their chain.
Now we have transaction acceptance criteria that it should be included in a chain longer than say 10 blocks. We can also add that those blocks shall not be from the future.
You still didn't answer my question. How will you measure time interval between adjacent blocks? You are describing what you are going to do with it, but my question is how will you find it?
CBlockIndex structure already have nTime field in it. I am not sure who is filling it. Even if it is not a part of transferred block header then it can be added there. Miner can set this value while he broadcast a block he mined. "Like look guys I have a block started from that block, I used this time to mine it, and there is a solution that fit under the floating threshold, feel free to use it as the base for your mining". Other clients shall only verify that the time is lower than the current time say GMT it doesn't matter what global time will be taken in account the difference in few secs is not crucial for a single block.
It can still be interesting among miners to broadcast blocks from the future and start mining from that blocks to be the first one who continue the chain if no faster block will be found. But this is already up to miners what block to choose as the base yet no block from the future shall be considered valid by clients.
We are already very far from original satoshi idea... so I propose to use a floating threshold. If no one is able to find a block in 2 mins then threshold will be increased. Or better say that new block threshold should be somehow linked not only to the previous 2000 blocks and separation between them but also to separation between this block and previous. It is hardly to find any hole in there... looks fine to me at first sight. It may introduce some kind of oscillation but I do not see any big flaw that can be used in attack. If you are issuing new block in just one second then your solution shall be shorter than say 5 second. If you are issuing next block after a five minute of game than your solution can be very slow and not optimal.
How can you reliable measure time interval between adjacent blocks? I don't think there is a way.The sum of block times in a chain shall be always smaller than the current time. It can be used to let miners to build chains where block will be accepted if it contains a solution passed the threshold deduced from a block separation from previous. For example if a new block is issued in K mins from previous then the solution shall be faster than the square of K. If you want to issue a new block in 10 sec then your solution shall be shorter than (10/60)^2 * 60 = 1,67 seconds, if you want to issue a new block in 30 sec then solution can be already 15 sec long. At one minute mark you will be able to issue one minute long solutions. Then to build a longer chain in the same period of time you will still needs to build it from rather optimal solutions. You wouldn't be able to make a long chain of block whose solutions are inefficient because floating threshold will prohibit it.
Only if they can overcome the production rate of the other bot miners, though. This is, after all, still a form of 51% attack.
Now there is no complexity growth in block solution task. Without this criteria solutions will become faster and faster. Now bots needs 3 sec to solve a level. With some optimization it will be a fraction of a second. Finally we will came to the point when bot owner will have no aim to share individual blocks among other miners because net lag will be bigger than the block generation time. Bot owners will build series of blocks like 10-100 in a row and throw them into network at once. This is crazy way to go. Complexity threshold should be fixed and tightened to the real time. It should be a race for better and more optimal level solutions.
I think you just answered your own question, sort of: simply don't decrease below the lowest threshold ever seen in a valid block. (Whether that block is in the main chain or otherwise!)
This is absolutely the same flawed idea as we have now. You can build a long chain started from the genesis block and each solution in a chain will be slow and far from optimal.
Nice. There is a vulnerability in motocoin that can be exploited by a bot owner to easily make a blockchain fork. Anyway this is too risky to invest money in this coin unless they close the bug.
How do you propose to fix that bug? You can't just decrease target time if there were no maps that were completed in time less than new target time because you may just accidently decrease it to a point when it becomes unachievable.We are already very far from original satoshi idea... so I propose to use a floating threshold. If no one is able to find a block in 2 mins then threshold will be increased. Or better say that new block threshold should be somehow linked not only to the previous 2000 blocks and separation between them but also to separation between this block and previous. It is hardly to find any hole in there... looks fine to me at first sight. It may introduce some kind of oscillation but I do not see any big flaw that can be used in attack. If you are issuing new block in just one second then your solution shall be shorter than say 5 second. If you are issuing next block after a five minute of game than your solution can be very slow and not optimal.
I'm still not convinced that this is meaningfully exploitable. Anyone care to demonstrate? 
How fast your bot can mine new blocks? Can it generate one block at least every few seconds? If so, just start to generate blocks right from the genesis block untill you will have more blocks then there are currently, then send all your newly mined blocks to the network, voila, and you will own all of motocoins except for my premine. This is just a 51% attack.No it is not a 51% attack because it is not involve much resources to accomplish. Because in motocoin threshold value is not linked to block issue time attacker can produce blocks whose solution is stupid and slow.
It is like producing a blockchain for bitcoin where eachblock have only one leading zero. This is not a 51% attack by definition because attacker can have far less resources than the rest of the net. He only shall be able to form blocks fast enough.
Quote
int bnNew = 2*Current - Median - (Current - Median)*nTargetTimespan/nActualTimespan;
then if Median is equal to Current... then bnNew will be equal to Current no matter what nActualTimespan is. Even if nActualTimespan is close to zero the new complexity threshold will not be changed.
Nice. There is a vulnerability in motocoin that can be exploited by a bot owner to easily make a blockchain fork. Anyway this is too risky to invest money in this coin unless they close the bug.
This is entirely what I'd expect, if the current rate is the same as the average rate then no adjustment is necessary. Are your proposing that if solution times remain consistent, we should retarget? Should we make the challenge easier or harder in such a case, and by how much, exactly?
The threshold is not connected to the speed of block issue and a chain length. You can build a 5000 block chain with solution time equal to 60sec and time separation between 0 and 5000 block issue times will be less than an hour.
This is not the case in bitcoin. Bitcoin threshold is linked to the block issue time. If you are building a long chain of bitcoin blocks then the threshold will grow up rapidly and complexity of a new block calculation will grow also. But here we see a strange situation when the block solution complexity will not be changed even if blocks will be issued very rapidly. This is what am I talking about.
There is one more idea I want to share.
If there is a bot owner who can produce a viable solution for every possible starting block that fit in say 60 sec threshold and require less than 60 sec for this... then this botowner is now probably building an alternate blockchain fork from 8000 block. And he will publish this blockchain shortly. His blockchain will be longer than the current blockchain because he can catch it up very quickly. If he can produce a solution in 5 sec then he needs a 5000 * 5 sec ~ 7 hours to produce a chain of 5000 blocks with solutions close to 60secs. Motocoin network will accept his new chain because his chain will be longer than the current one and it is done. This is not a 51% attack this is something different because attacker do not even need a lot of computation power to achieve this.
In other words. A bot owners can produce a blockchain fork as long as they want, each block in the forked chain will contain a solution close to 60sec. Bot owner needs far less time to achieve this than the sum of the thresholds for blocks in the chain itself. An actual block computation complexity is not connected to the threshold itself. This compromise the main idea of a blockchain. A blockchain fork attack complexity is very low now. Motocoin is literally compromised now. I am out.
What you describe is 51% attack. But you couldn't mine blocks just with 60 sec target time, if you want blocks only with 60 seconds target time then you need to ensure that average spacing between blocks is more than 60 seconds to prevent difficulty retarget to set target time to lower value; to produce longer chain this you will need to set time for some blocks far in the future and network will not accept such blocks.If there is a bot owner who can produce a viable solution for every possible starting block that fit in say 60 sec threshold and require less than 60 sec for this... then this botowner is now probably building an alternate blockchain fork from 8000 block. And he will publish this blockchain shortly. His blockchain will be longer than the current blockchain because he can catch it up very quickly. If he can produce a solution in 5 sec then he needs a 5000 * 5 sec ~ 7 hours to produce a chain of 5000 blocks with solutions close to 60secs. Motocoin network will accept his new chain because his chain will be longer than the current one and it is done. This is not a 51% attack this is something different because attacker do not even need a lot of computation power to achieve this.
In other words. A bot owners can produce a blockchain fork as long as they want, each block in the forked chain will contain a solution close to 60sec. Bot owner needs far less time to achieve this than the sum of the thresholds for blocks in the chain itself. An actual block computation complexity is not connected to the threshold itself. This compromise the main idea of a blockchain. A blockchain fork attack complexity is very low now. Motocoin is literally compromised now. I am out.
If I understand this line correctly https://github.com/motocoin-dev/motocoin/blob/e13a143890b9f6a035294dc27d729890641d2b0a/src/main.cpp#L1197:
Quote
int bnNew = 2*Current - Median - (Current - Median)*nTargetTimespan/nActualTimespan;
then if Median is equal to Current... then bnNew will be equal to Current no matter what nActualTimespan is. Even if nActualTimespan is close to zero the new complexity threshold will not be changed.