Topic: [ANN][MOTO] Motocoin - page 70. (Read 178259 times)

Are there going to be any fixes for this whole bot issue?

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.

This is precisely the same as a 51% attack.  To do it (probabilistic)  successfully you would need to not only be mining your new chain to catch up, but also keeping up with the real chain's pace of new production as well, so you need to have above 50% of the total hashing strength on the network. (the hashing strength to keep your chain in pace with the rest of the network as a whole, plus some extra to get ahead.)  This is still not different from the first fpga and GPU miners and later the early asic miners on BTC.

I could produce blocks well above 1 per 5 seconds, but why?  It would not be worth the energy spend to grab the couple of bucks on the buy side of the books, and it would certainly destroy the coin and any hopes of getting more than that in the future.  For anyone with the hashing strength the rational thing to do is just mine the coin normally to secure and strengthen the network and collect the subsidy.


I'm not sure I follow you.  How would this be different from any other coin, where someone holding an overwhelming majority of the hashing strength can rewrite tx history at will to a depth relative to their network dominance?


I think I've already beaten this horse to death, but they are directly connected.  Finding "any path that makes it to the coin" is quite a bit easier than finding a path that makes it to the coin with a target near the minimum bound on run time, for both bots and humans.  Try it yourself in ForFun mode. 


No, fork attack complexity is only very low right now.  It is, however, much higher than it was a week ago, and will be much higher next week, and so on.  This, too, is true of any successful crypto where difficulty increases steadily.


It is only compromised in the same way that the first FPGA and GPU miners "compromised" bitcoin, which is to say basically not at all in the long run.

There is only one specific difference in what we can say (so far) about the properties of moto's PoW, and that is that unlike partial-collision where we know that each added bit to target precisely doubles the computational effort we do not know yet what the resource requirement requirement curve for moto mining will be.  If that curve turns out to be something like a flat, constant line because someone does some clever math and can literally solve blocks at will then the coin is dooooooooooomed.  If someone reduces the whole challenge to a 3sat then I'd sell my wife and kids to buy buy buy because I don't expect anyone to break NP in reasonable ways any time particularly soon.


If this is true, then bitcoin doesn't work.  BTC difficulty is just a threshold number for a hash.


If this were true of moto because threshold isn't competitive, then it would be just as true for btc.


It is because right now that threshold is not really much of a challenge for anyone at all, human or bot.  In general, however, it still holds true.

You are half right, and half wrong.  They compete on both.

Game time is not really proportional to real time to either a bot or human miner, since both can speed or slow time as much as they'd like at will.  (Would anyone like a patch that makes the speed/slow of time step in different increments?  )  Fastest (run time clock) solutions should always dominate in the long run, bots or no.  The problem right now is that the vast disparity between the required target time and the time it takes for bot to meet that target time overwhelms the humans by quite a bit.  (Hence my attempts at proposals to give the humans the option of more wall clock time.)  There is, however, a minimum bound on run times, and if we approach those bounds the map reset frequency would drop again, giving humans more chance even if no change to the coin were made.  We don't really know yet how well bots would handle this, in general.  I suspect the current iteration of bots might not make the cut.

We don't know yet where the equilibrium is for humans or for bots, so we don't actually know yet how competitive humans/bots could be.  Only time will tell.  For the moment the bots still seem to be "winning."

Doublespend. Mine 300k motocoins. Sell them on c-cex for bitcoins. Build an alternative chain fork and sell them again. Then do this ntimes until they stop motocoin trading.

Who would do something like this and why?

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.

This is far from the original satochi blockchain idea. Threshold value by itself is not a subject for a competition. Finding a block that just fit above the threshold as quick as possible shall be the subject for a competition. I can't really understand how this can be achieved if bots can find a level solution that fits a threshold and requiring far less time than a threshold itself.

TargetTime is entirely independent from block rate... we will (and should) always be competing on TargetTime threshold!

Are you sure? There is no competition on a target time then. Bot shall solve the level below the time threshold but do it FAST. Bot owners will compete in speed of level submission to the network not a target time optimization.

Actually this is not the same for humans only because the game speed is proportional to real time. And only because of this. Fastest solutions were dominating because they were able to submit them faster than slow solutions. But this is not the case when we talk about bots.

No, just bot owners intentionaly limit their bots. When they will stop doing this, then retarget will set target time to very low value and bots will need to enumerate more maps, this will slow down them.

So now we have a competition of a fast but stupid bots? This will finally led us to the point when microseconds in level submitting time is counting. Faster network connection will be crucial not a gamer skill. This is ruining the concept of proof of work.

I think at this point we're pretty much all agreed that limiting map count is a total non-starter....

Heh, with all those bots average mining speed in last 2000 blocks was 1 block in 65.848 seconds. Target time was increased. But bots can mine much faster, I saw that insane race when blocks were mined in mere seconds with lots of softforks.

256 small maps is ok only if there will be no easy map among them. If it would always be possible to choose easy map among those 256 maps then this selection algorithm shall be included into game distributive itself. Also this preselection algo shall be fast enough to be used on an older hardware. A poor human player without any programming skill shall be able to compete on a par with programmer and a datacenter owner. Any preselection algorithms shall be either public and usable or there shall be no such algorithm at all by design of a map generation algorithm.

May be the map random seed be dependant only on previous block and some kind of stupid heuristic or a bot will be included into game distribution to make a viable map selection process deterministic. All the players will try to solve the same map.

Precisely, it would be as if the transactions in the most recent block are actually still in txpool.... not confirmed until they get some blocks behind!


Ah, no, this would not be the limit the search space... this would simply be a way to give humans more wall-clock time to find their solutions, at the cost of overall network integrity.  For example, if N is 4 then you need 4 times as many confirmations to be sure of a block, but a human miner then also has 4 times the average bot solution (wall clock) time in which to find their solution.  Forced map resets would be 1/4 of what they are currently.

The fact that we (arguably) drop the network integrity by 75% (really we just defer the generation of that integrity by an additional 4 blocks) is probably not much of a concern considering the bots will likely be adding hashing strength by a factor of at least this.

Finding the right balance for the value of N to make a good tradeoff between security and human-mining might be tricky.

This is not an ideal solution, but it is a relatively simple/straightforward one. (If it can be made to work, and if the community is willing to live with the extended confirmation times.)  I worry some about the fact that it certainly does weaken security, but I'm not sure if this is a rational worry: the current security threshold is practically "who knows" because it is not like we have good (or any) analysis of the integrity of "motohash" algorithm, so what exactly is 1/Nth of "who knows" security, and is 1/Nth good enough? 

In fact, this scheme doesn't change anything, miners still add transactions to block, but instead of saying that these transaction belong to block N we say that they belong to block (N-1). With all this discussion I forgot what is supposed benefit of it. If it should limit set of possible maps than it obviously won't work because miners can add arbitrary transactions (e.g. send funds to themselves) to previous block and change their seed as many times as they want.

It is very true.  Even now, already, in the current physics, there might be some such opportunities.  (Let's call this my "secret weapon" held back for when the bot race *really* heats up, hehe)

Yes, you will sometimes create a solution which is invalid against the networks' physics, but in most cases it will be rare enough that your natural stale rate is probably more concern anyway...

Sure.  And?  Transactions would be malleable and not considered confirmed at all until N confirmations.  Each additional N confirmations would offer what is currently 1 block worth of added integrity.  An N block fork would then be equivalent to what a 1 block fork is currently, and N block forks would become as common as 1 block forks are currently.  Other than "scaling the security factor down by N" what is the problem?


Yup... right now we botters are the ECB of the moto.  However, my point is that if 1000 people fire up bots it will add *far* more security to the network than if 1000 people human-mined.... in the same way that the first people to run asic on BTC basically owned the BTC chain for awhile, but now the btc chain confirmations have what you might call "ridiculously high integrity" because of those asics. (compared to the integrity afforded by CPU/GPU miners.)  Sure, they consolidated and centralized things more than we probably would've liked, but the network as a whole is much stronger for it, now.


Yes, and I think this applies generally to anything that is "added work" to the run calculation.  Adding work to map generation (like requiring 100 rounds of sha instead of 1 for each seed point, for example) "works" in some sense, but is mitigated by the early bailout factor that I mentioned earlier.  (I'm still not sure if this early bailout is avoidable either, at least not without a very significant change anyway.)

It is a very tough nut to crack, but I'm confident that between us we can find a good approach!