[ANN][MOTO] Motocoin

[radi324]

What's the reason for adding "now dominated by bots" in the ANN title? It's a childish move, scares away investors and shows the Dev's lack of commitment to the project if he gives up easily at the first noticeable problem

[WilliamLie2]

What's the reason for adding "now dominated by bots" in the ANN title? It's a childish move, scares away investors and shows the Dev's lack of commitment to the project if he gives up easily at the first noticeable problem

People must know about current situation. Do you want lie to everybody that it is currently human-mineable?

[radi324]

What's the reason for adding "now dominated by bots" in the ANN title? It's a childish move, scares away investors and shows the Dev's lack of commitment to the project if he gives up easily at the first noticeable problem

People must know about current situation. You want to lie to everybody that it is currently human-mineable?

At least be more prudent about the whole situation. There are members of the community who have invested in this project fully believing in it, and you, as the person who has spent most time on the project, should value your own efforts more highly. The sell orders on c-cex are extremely thin, 2 BTC would get us back to where we were before. As long as another exchange does not add MOTO and in the meantime the necessary fixes are implemented, everything should be back to normal. It's still a very young project - if everyone were to give up in the first few days whenever a new coin is created, the crypto-world would have long since died

[Spiky]

And what about adding some computationally intensive randomness to physics (like computing many many hashes each tick and adding it to velocity). This will make bot's speed comparable to normal human playing speed. And without careful planning bots will definitely lose.
Along with 4x sized map it will knock out bots for at least a couple of months.

[c-cex]

Hello!
Being the only exchange for MOTO at the moment I would like to ask You for some feedback of our service.
Are You satisfied? Maybe something to improve? Any suggestions?
Thanks in advance.

I'v got only one answer. Maybe anyone else could give several words for our platform?

[radi324]

Hello!
Being the only exchange for MOTO at the moment I would like to ask You for some feedback of our service.
Are You satisfied? Maybe something to improve? Any suggestions?
Thanks in advance.

I'v got only one answer. Maybe anyone else could give several words for our platform?

Deposits were quick and easy, overall it was good. The interface however needs a lot of improving, for example: the value graph needs to be a bit more streamlined in my opinion

[HunterMinerCrafter]

How blocks will be mined? You seed the map only with already mined blocks but how will you be able to mine new ones?

Yes, as I said there are quite a few fatal problems with my original plan.  I have two rough directions that I'm thinking now... either allowing the last N blocks to be used for seed (so when you win a new block you might not necessarily actually be securing the current block, but adding security to any of the last N blocks.  This would, however, mean that people would need to wait N times as many confirmations to be confident in their coins... I still think this is fraught with problems, however, and I probably won't continue exploring it much further.

Another path that I am looking down is using something along the lines of the proof-of-activity proposal to allow user to collect up proof of stake data, and mine against that data to create blocks.  Stake data would have to carry some "freshness" metric to avoid replay withholding, and manual human miners might only be able to mine coinbase TX in their blocks (unless they accept a map reset) but otherwise I'm thinking that it might work.

Currently, each block gives you infinite set of maps, not 2^32 but infinite.

Ok, I was assuming people were "playing fair" on their timestamp, as well.  (My bots don't do any timestamp manipulation, they just take the "***Work" block that the client spits out.)  Even with the timestamp the block count isn't quite infinite (there's an limit on timestamp drift allowed by the network ofc) but this does make the search space so large that, pragmatically, it may as well be infinite.

You propose to add some other method for actually mining blocks and leave game just for fun and for generating/distributing coins?

No, not at all!  What I'd like to get to is a state where bots can mine without affecting human miners, and human miners can still solve blocks to win coins, and the two still compete not directly "block for block" as currently but instead compete only on TargetTime thresholds.  Under this scenario the network is maximally secured (by the large computational effort of the bots) and still human mineable.

At launch we had a very insecure network that was great for human miners of all skill levels.
Right now we have an exceptionally secure network that very very few humans are able to mine on.
The goal is to keep the network as computationally strong as it is now, but with a possibility for (ordinary, sane) human miners to continue to compete for coinbases. (EDIT to clarify: I mean secure the network without just punting and adding hashing based PoW like HUC does.)

[HunterMinerCrafter]

DOMOB you are awesome.

In general, I think that the idea to have a coin like this (or even Primecoin) to "fund AI research" is nice.

Yah!  I'd love to see something that is explicitly for such a purpose...  evolutionary computation based PoW maybe? Proof-of-annealing?  (Would be nice to have a proper "quantum hard" chain, too, as currently I don't think there are any? (Yah yah, I know, quantum just breaks security of addrs and the merkle chaining anyway...))

  But one has to keep in mind that the actual use of PoW in blockchains is to make them secure against 51% attacks.  So if the "AI thing" is used as the main PoW (as opposed to Huntercoin, for instance, where the security comes from hardware PoW and the "human-mining" is just an extra for "fun"), then I see a big problem here:  When someone makes a "break through" in research of bot strategies (or mathematics backing prime numbers in some way for XPM), then they may very well be in a position to easily 51% or even 99% attack the network (as HMC has stated above for himself).

This is no different whether the "hashing function" is sha, scrypt, blake, x11, moto racing, raytracing, sat solving, or anything.  The first sha asics could have 51%ed bitcoin.  If I go make an X11 fpga array tomorrow I could 51% attack a lot of networks for awhile.  If someone made a raytracing based coin and someone else devised some new crazy fast raytracer math they'd be able to 51%.  If there were a 3SatCoin and I found some crazy new lower bound on general NP solution... well you get the drift.

You just have to hope that the people who make the technological breakthroughs are inclined toward using them to the benefit of securing the network (instead of to the detriment of the network's users) and that competition quickly causes others to procure and adopt the same new technologies, so the network remains secure.  As I said before, I personally intend benevolence.  Any of us botters could have already actually killed motocoin any time now, by just 51%ing c-cex just enough to where the exchange decides to remove the listing because of the losses.  As each new botter comes online (btw, hello botter number 4-or-5(-we're-not-sure-yet), welcome to the game!) such an attack becomes more difficult/unlikely as you have ever increasing hashing strength from the other botters to compete against.

  I. e., I don't think that it makes sense to use such mining techniques for PoW in a blockchain - at least, if it is not just about the fun of it but also to create an actually secure crypto-currency.

I think it is fine to use such techniques as long as they are actually computationally hard (an open question for moto... I'm so far unconvinced that there isn't a direct linear regression solution allowing deterministic constant time block solution at any difficulty) and are allowed to continue to actually *secure* the network!  (Meaning the bots are allowed to do their thing and strengthen the consensus history with their ever increasing ramp of energy spend commitments.)

The hard part ofc is doing it in a way that it doesn't just degrade into nothing more than a really convoluted sort of alternative hashing function, so you don't end up with "just another altcoin" that might as well be just another x11 ltc fork.  That, as I see it, is the open problem.... how to achieve machine-scale driven network security around consensus and still leave room for human competition for coinbases.  I suspect it is possible, but I'm afraid that I don't have all of the answers just yet.

[c-cex]

Hello!
Being the only exchange for MOTO at the moment I would like to ask You for some feedback of our service.
Are You satisfied? Maybe something to improve? Any suggestions?
Thanks in advance.

I'v got only one answer. Maybe anyone else could give several words for our platform?

Deposits were quick and easy, overall it was good. The interface however needs a lot of improving, for example: the value graph needs to be a bit more streamlined in my opinion

Thank You for feedback. What else in interface could be better in Your opinion?

[HunterMinerCrafter]

Hello!
Being the only exchange for MOTO at the moment I would like to ask You for some feedback of our service.
Are You satisfied? Maybe something to improve? Any suggestions?
Thanks in advance.

I'v got only one answer. Maybe anyone else could give several words for our platform?

Deposits were quick and easy, overall it was good. The interface however needs a lot of improving, for example: the value graph needs to be a bit more streamlined in my opinion

Thank You for feedback. What else in interface could be better in Your opinion?

My only complaints about the interface are
A) Night mode: just plain doesn't work right.
B) Updating:  MOTO Charts freeze constantly, and it is often not clear if the buy/sell list you are looking at is currently up to date or not.

[WilliamLie2]

How blocks will be mined? You seed the map only with already mined blocks but how will you be able to mine new ones?

Yes, as I said there are quite a few fatal problems with my original plan.  I have two rough directions that I'm thinking now... either allowing the last N blocks to be used for seed (so when you win a new block you might not necessarily actually be securing the current block, but adding security to any of the last N blocks.  This would, however, mean that people would need to wait N times as many confirmations to be confident in their coins... I still think this is fraught with problems, however, and I probably won't continue exploring it much further.

If you are mining new block and secure some transactions with it then we say that these transactions belong to that block. If you say that they were part of previous block but wasn't secured by it then this is just a game of words, because you are that guy who secures them and you deside which transactions will belong to previous block, not the one who mined previous block, so it is still the same as if you added these transactions to your block. Each block includes hash of previous block, therefore currently all previous blocks are used for seed.

Another path that I am looking down is using something along the lines of the proof-of-activity proposal to allow user to collect up proof of stake data, and mine against that data to create blocks.  Stake data would have to carry some "freshness" metric to avoid replay withholding, and manual human miners might only be able to mine coinbase TX in their blocks (unless they accept a map reset) but otherwise I'm thinking that it might work.

I'm not quite sure what you mean here. If they mine only coinbase then this is just a method to distribute coins, not to secure the network, right?

Currently, each block gives you infinite set of maps, not 2^32 but infinite.

Ok, I was assuming people were "playing fair" on their timestamp, as well.  (My bots don't do any timestamp manipulation, they just take the "***Work" block that the client spits out.)  Even with the timestamp the block count isn't quite infinite (there's an limit on timestamp drift allowed by the network ofc) but this does make the search space so large that, pragmatically, it may as well be infinite.

You don't need to change time, you can just change your address for coinbase transaction. With some other tricks you can have even more insanely larger set of possible maps.

At launch we had a very insecure network that was great for human miners of all skill levels.
Right now we have an exceptionally secure network that very very few humans are able to mine on.
The goal is to keep the network as computationally strong as it is now, but with a possibility for (ordinary, sane) human miners to continue to compete for coinbases. (EDIT to clarify: I mean secure the network without just punting and adding hashing based PoW like HUC does.)

Yeah, it is exceptionally secure. And you can perform 99% attack any time you wish, sounds very secure.

And what about adding some computationally intensive randomness to physics (like computing many many hashes each tick and adding it to velocity). This will make bot's speed comparable to normal human playing speed. And without careful planning bots will definitely lose.
Along with 4x sized map it will knock out bots for at least a couple of months.

Remember that physics is calculated not only while playing but also when other nodes check blocks for proper proof-of-play. Right now I can check about 60 blocks per second in one thread on my Core i7-3770. With 4 threads I will probably be able to check 240 blocks per second but many people have much slower processors. With your proposal physics simulation will become much slower and to really harm the bots we will need to make it at least 100 or 1000x slower. This will make block checking very slow, on some computers it will take several seconds to check one block, some probably would check new blocks slower then they are generated, inital synchronization with network will take days or even months, botnets will perform spam attacks sending a lot of invalid blocks and nodes will use 100% of their CPU time to check these blocks.

[HunterMinerCrafter]

If you are mining new block and secure some transactions with it then we say that these transactions belong to that block. If you say that they were part of previous block but wasn't secured by it then this is just a game of words, because you are that guy who secures them and you deside which transactions will belong to previous block, not the one who mined previous block, so it is still the same as if you added these transactions to your block. Each block includes hash of previous block, therefore currently all previous blocks are used for seed.

You would still attach the PoW to a new block with new transactions, your map seed would just reference older data.  Yes, when you solved this map it would do nothing to confirm the integrity of those transactions at that time (instead adding confirmation only to the blocks up to where your seed block was) but in the next N blocks when someone else solved against your block (or any block after it) it would serve to secure those transactions.  This is why I say it would require N times as many confirms to be sure of a transfer.

(EDIT to clarify: Really I think there are a lot of problems and potential problems with this approach anyway, particularly related to the extra confirmation delay and "S.E. attacks," so it should probably be considered as a nearly-last resort approach.  I think something based on proof-of-activity(/stake) blocks is likely a much more viable solution.)

You don't need to change time, you can just change your address for coinbase transaction. With some other tricks you can have even more insanely larger set of possible maps.

Good point.  Still finite, but for all intents and purposes it might as well not be.

Yeah, it is exceptionally secure. And you can perform 99% attack any time you wish, sounds very secure.

Yes, granted, right now we (botters) "own" the network, and there are only quite few of us.  My point stands, however.  The network would be difficult to attack by anyone "not us" now.  Presumably there will be more and more of "us" with each day, both adding strength to, and decentralizing that ownership of, the network.

Remember that physics is calculated not only while playing but also when other nodes check blocks for proper proof-of-play.

Right, just adding computational effort to the path is not a good solution.

Right now I can check about 60 blocks per second in one thread on my Core i7-3770.

OUCH if this is just PoW checking time something is very wrong, then.  You should get significantly better performance than this.

With 4 threads I will probably be able to check 240 blocks per second but many people have much slower processors. With your proposal physics simulation will become much slower and to really harm the bots we will need to make it at least 100 or 1000x slower. This will make block checking very slow, on some computers it will take several seconds to check one block, some probably would check new blocks slower then they are generated, inital synchronization with network will take days or even months, botnets will perform spam attacks sending a lot of invalid blocks and nodes will use 100% of their CPU time to check these blocks.

Yup.  Not to mention the "clincher" here which is that the bots could simply run their solutions without this "added legwork" and then re-run their path against the "full physics" once a solution is found to verify that it will be accepted by the network.  This would just hamper normal users a LOT and the bot heuristics very very little.

[Spiky]

And what about adding some computationally intensive randomness to physics (like computing many many hashes each tick and adding it to velocity). This will make bot's speed comparable to normal human playing speed. And without careful planning bots will definitely lose.
Along with 4x sized map it will knock out bots for at least a couple of months.

Remember that physics is calculated not only while playing but also when other nodes check blocks for proper proof-of-play. Right now I can check about 60 blocks per second in one thread on my Core i7-3770. With 4 threads I will probably be able to check 240 blocks per second but many people have much slower processors. With your proposal physics simulation will become much slower and to really harm the bots we will need to make it at least 100 or 1000x slower. This will make block checking very slow, on some computers it will take several seconds to check one block, some probably would check new blocks slower then they are generated, inital synchronization with network will take days or even months, botnets will perform spam attacks sending a lot of invalid blocks and nodes will use 100% of their CPU time to check these blocks.

Maybe some one-way function can be used. For example client can be required to search for some nice hash each tick or second of playing so it will slow down playing, but checking solution will be very fast.

[WilliamLie2]

If you are mining new block and secure some transactions with it then we say that these transactions belong to that block. If you say that they were part of previous block but wasn't secured by it then this is just a game of words, because you are that guy who secures them and you deside which transactions will belong to previous block, not the one who mined previous block, so it is still the same as if you added these transactions to your block. Each block includes hash of previous block, therefore currently all previous blocks are used for seed.

You would still attach the PoW to a new block with new transactions, your map seed would just reference older data.  Yes, when you solved this map it would do nothing to confirm the integrity of those transactions at that time (instead adding confirmation only to the blocks up to where your seed block was) but in the next N blocks when someone else solved against your block (or any block after it) it would serve to secure those transactions.  This is why I say it would require N times as many confirms to be sure of a transfer.

You still don't understand what I'm talking about. If you just attached some transactions to your block without securing them then no one cares about them. Realying nodes may change them while relaying and next miner can just ignore them and add there any transactions he wants.

Yeah, it is exceptionally secure. And you can perform 99% attack any time you wish, sounds very secure.

Yes, granted, right now we (botters) "own" the network, and there are only quite few of us.  My point stands, however.  The network would be difficult to attack by anyone "not us" now.  Presumably there will be more and more of "us" with each day, both adding strength to, and decentralizing that ownership of, the network.

Centralized banking system is also difficult to attack by anyone "not them". But the whole point of cryptocurrencies is that no one should have any large control.

Yup.  Not to mention the "clincher" here which is that the bots could simply run their solutions without this "added legwork" and then re-run their path against the "full physics" once a solution is found to verify that it will be accepted by the network.  This would just hamper normal users a LOT and the bot heuristics very very little.

Yes, I didn't thought about it, this makes it almost useless as protection from bots.

[Spiky]

With 4 threads I will probably be able to check 240 blocks per second but many people have much slower processors. With your proposal physics simulation will become much slower and to really harm the bots we will need to make it at least 100 or 1000x slower. This will make block checking very slow, on some computers it will take several seconds to check one block, some probably would check new blocks slower then they are generated, inital synchronization with network will take days or even months, botnets will perform spam attacks sending a lot of invalid blocks and nodes will use 100% of their CPU time to check these blocks.

Yup.  Not to mention the "clincher" here which is that the bots could simply run their solutions without this "added legwork" and then re-run their path against the "full physics" once a solution is found to verify that it will be accepted by the network.  This would just hamper normal users a LOT and the bot heuristics very very little.

I think it's not true, this is the type of game in which every minor difference in speed or position can lead to huge and unpredictable trajectory changes, so bot will have to use real physics and not "fake" one.

[HunterMinerCrafter]

You still don't understand what I'm talking about. If you just attached some transactions to your block without securing them then no one cares about them. Realying nodes may change them while relaying and next miner can just ignore them and add there any transactions he wants.

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?

Centralized banking system is also difficult to attack by anyone "not them". But the whole point of cryptocurrencies is that no one should have any large control.

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, I didn't thought about it, this makes it almost useless as protection from bots.

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!

[HunterMinerCrafter]

I think it's not true, this is the type of game in which every minor difference in speed or position can lead to huge and unpredictable trajectory changes, so bot will have to use real physics and not "fake" one.

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

[WilliamLie2]

You still don't understand what I'm talking about. If you just attached some transactions to your block without securing them then no one cares about them. Realying nodes may change them while relaying and next miner can just ignore them and add there any transactions he wants.

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?

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.

[HunterMinerCrafter]

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

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!

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.

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? 

[DeepCryptoanalist3]

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.