Topic: [ANN][MOTO] Motocoin - page 50. (Read 178273 times)

Uh, if everyone would have a bot they didn't program, then MOTO is not even much of a "botting research" coin anymore, heading closer to good old CPU-mining power.

It would be good if someone released it but we have only had one released and it doesn't seem to work.
Even if someone just released their really crappy bot, it would be good. *cough*Please?*cough*

Unfortunately people can just change their IP's with some simple software. It would be good if they couldn't but they can.

"Hey, what if we just made a captcha to stop the bots?  I understand where you're coming from on this, but I always try to defer to education before exclusion."

Hi guys. I'm certainly not technical so do not mind simple line of thought. I do like to read your posts and the discussion of how to move forward. It seems so complicated and perhaps it is. A simple captcha is all I could come up with way earlier in the thread but it was easily waved, figured the solution was too simple. On page 45 you answered yourself so why now come up with this as a solution or was it a joke. It makes me think that you yourself may be botting and do not like to implement for your own sake:

Why not make a captcha style with simple questions to answer, like 'what color is an apple'. This should be asked by the game only if a block is solved. After the user types 'green' he gets his coin. Perhaps then there should be a part where miners MAKE new questions so that they stay original and cannot be botted by collecting answers. If you had typed 'blue' then the coin will not mint at all so bots cannot try all the possible answers. There should not be a way to bypass the verification. Ofcourse there also shouldn't be double possible answers, an apple could be yellow or red too (I prefer the yellow ones).

I hope you guys can continue in peace to make MOTO better and human minable again. If this is not going to work then perhaps it's better to release easy-to-install bots to others so everyone can have a go at this. The longer it takes that only a few people can mine it, the less credible the coin gets. Another option could be to release a new project around the motor-theme where MOTO's can be used, earned and spend so that people are willing to support the price and invest in it. I'm sure most will agree MOTO is a unique project so everyone likes to see this one fixed and survive.


Can't we just ban the bots? IP-ban or some other way of closing the connection. The MOTO system should recognize bots and exclude them from participation. Or limit the amount of maps one can try to play within a certain timeframe.

Yes, and this is why I chose to add the work deficit payment "per-map" specifically.  Even if they totally defeat the bike riding part it will just result in taking a really long time to look at even one map.


At the moment humans are actually much better at this, given the same map and time constraint.

I've been meaning for some time now to make a video showing the interactive mode on my current bots.  It is really eye opening as to just how primitive the current bots are, and how easily they get confused by the most trivial of things.


One problem here is that a better map filter for a human is also a better map filter for a bot.  However, I think that this solution is still "telling" as an indication that the "cyborg" players utilizing the best aspects of all approaches will likely win on a slightly longer curve.  (I can make significantly more blocks when actively directing my bots than I can with unattended bot mining.)


A third approach is, as I've said before, to increase modal aspects of the challenge.  This is subtly different from just increasing the difficulty of traversal.  The more "operational states" that a bot might have to be in to succeed the less likely an AI is to perform.

There's also a "probably best left unsaid" fourth option, which would involve some form of secure multiparty computation for (pseudo)real-time  shared secrets, so that the challenge wouldn't have to be a perfect information game.  The technical difficulty of pulling that off would be very high, so let's not even consider it for now.



Another option is to "punt" and layer in a proof-of-work for securing depth, and not rely on the game itself.  Or, in other words, revert to the HUC model.  This is obviously less than ideal.


Erm, how?  We've pretty much established both in discussion and in practice that our current TT adjustment doesn't accomplish this, and that the block interval isn't really constrained in either direction right now.

We could just literally enforce a constant slowdown, like "you have to run 100k rounds of sha for each perlin control point seed" or require a constant minimum work be paid by collision, but I highly doubt this would be a popular solution with either bot miners or human miners, and likely wouldn't be adopted.

First, I'd just like to say that I feel this was your most reasonable post to date. 


It was obvious to me because it says in the log for that step that it failed to scp the dangling motogame symlink.  It's ok, I call it a bug in gitian.  Let's just agree to blame them. 


Well, at a glance it appears you're not wrong.  (Although there are some constraints that you didn't enumerate, I won't bore people with it.)  This is true both with and without my patch, though, and is not exactly the same as DeepCrypto's version.  (Do you at least agree that my patch resolves the original attack vector?)

GetBlockWork is "broken" (for some definition of broken) it even almost says so in the comment, heh.

The problem is that this curve isn't really indicative of anything useful, it certainly isn't a relative measure of how much effort is required to solve a block - which is the intended function.

Interestingly it gets slightly less broken after the patch (just as a weird side effect, really) but you are correct that when combined with the target formula itself also still being not quite right (as I've said my patch makes no attempt to offer a better TT targeting, and I'm still hoping someone will come forward with a good suggestion there!) you do get to play on TT in this way.  I would be interested in seeing how the two attacks might be leveraged together.  It could be brutal.

This will take another round of discussion, probably some more arguments, and likely another drama-filled patch or two, but I don't see why this couldn't be resolved.  We'll likely need both another change to GetNextWorkRequired and a better definition of GetBlockWork.


This is just as true on bitcoin with only one head to the chain.  Any node can choose to ignore the most recent block and try to restructure those transactions, and mine a competing block.  Soft forks happen.

I've already said this could increase stales correspondingly to the N factor, and also already explained why it is not likely. (Bot operators who enumerate maps are most likely to use most recent blocks.)


You would only be forced to switch if you are already on your "Nth block round" in which case you have to switch when the new block comes in whether that new block agrees with your old chain or not.  In other words, if some new block comes in that doesn't agree with your old chain you are not forced to switch to it until it doesn't agree with your old chain N blocks ago.  Or, to put it yet another way, yes you are correct in some sense but it does not mean more map resets, it just means that both human and bot mining would be subject to the same increase in stale rates.


You can't just indefinitely "move all transactions to new block" just as you can't in bitcoin, and for the same reason... eventually (presumably very quickly) you can no longer catch back up to the chain you've diverged from.  (Well, assuming any more difficulty time warps we find get closed, anyway.  )  Since bot miners iterate maps and will generally want to  minimize stales they would rationally tend to mine the newest blocks, so forks will naturally tend to the short side.

Yes, some people might do silly things like make their mining pool point at N deep blocks "just because" but there is no additional incentive to do so, and this would be no different from doing something like broadcasting conflicting tx spends to the btc network... it might be a nuisance to see things blink in and out of existence in the gui client, but as long as people wait for the confirms they are supposed to it wouldn't cause any actual problems.  Am I missing something in this respect?


I'll put this in the same category as all the BS drama around the premine - who knows, who cares, water under bridges in any case.


Someone will inevitably create "drastically" better bots time and again, for some definition of drastically.  Our goal is to make it so that they can't usefully attack the network for any definition of drastically.



The current bots all appear to be more or less just differently "tuned" versions of minim1ner's architecture, now.  Everyone seems to be running a basic diagonal map filter on perlin height-map with annealing.

This certainly leaves quite a bit of room for algorithm improvement.

Much more likely to be of concern, though, is jumps in underlying infrastructure technology.  Although moto bots are not very well suited to GPU execution there are some other heterogeneous computing architectures that might have particular advantages.



It would not take much to disrupt MOTO right now.  Many devs probably have enough idle cloud servers to bring together to do it "for free."

Of more concern, if any 2-3 of those five decided to collude they wouldn't even need any fancy new attack to do it.

No, when it comes to a blockchain five is not several.


Huzzah! This is one of the main reasons that I said this is your most reasonable post to date.  This is the most rational and level headed thing you've done as developer of this coin since launch, and can put to bed a whole host of questions/concerns/rants that have been raised to me by a few certain community members.


If the miners don't agree with a patch they won't adopt the patch.  It is up to them, not devs.  Devs are just the "official suggester" to the miners, and support for the users.  We (miners) could've already forked at block 100k or 104k or any other arbitrary point that we all agreed to, and we just would've had some unhappy users for awhile.  Not a single block was mined on either hypothetical fork, to my knowledge, so no miner even dissented the tiniest bit from our collective decision to wait for you.  (If they had they would've rationally diverted some hash resource toward the fork, just in case they were not alone and were in fact even in the majority in the end.)  In other words, we "voted" 100% to continue to give you fair shot as lead.  Myself included.  I don't want to be lead, I just want the project to have a leader who does lead!  (I'll gladly lead or follow, but I will probably not get out of the way.)


Kudos.  I will not make a build alone, however, as I never want to have to ask that sort of trust of my users.  Let's "make official" the first build with three concurring hashes from three obviously-different people,  I would certainly hope to see you participate in this.

Listening to the majority is usually not very smart.
[/quote]

If that were true no-one would trust BTC.  The root premise of crypto-currency is that a sufficiently large, diverse, and anonymous/pseudonymous group majority consensus is the *only* thing you can believe in when it comes to cold hard cash!  (Anything else is probably trying to part fools and money, or will be trying to eventually)


Hey, what if we just made a captcha to stop the bots?  I understand where you're coming from on this, but I always try to defer to education before exclusion.


This is part of why I'm particularly unhappy that DeepCrypto hasn't responded, we don't have a ton of people in the community (even the other bot operators, which is funny to me) who can really critique our efforts in a useful way.

In any case, I think many (particularly any who are "still around" after all this drama and mess) understand more than you give them credit for, even if they cannot follow the code, logic, and intricate details.

Again, I apologize for lashing out at you, but your little list was unfair to me, at best.

Here is hoping that going forward our uneasy alliance can be just a little less uneasy.   

To give humans some mining power you need to find some thing where humans are superior to computers (or at least competitive). Motogame consists of two things:
1) Map search. Obviously computers are much better here.
2) Finding the necessary sequence of moves. Well, maybe humans are better here although I'm not sure.

So there are two approaches to give humans some chance:
1) Make very good map filters so that people can spend time at what they are good at.
2) Prevent fast map enumeation and force both humans and computers to concentrate on search for move sequences.
Easy to see that both of these approaches are temporary and will work only until bots will improve their ability to generate the necessary sequence of moves. Or maybe they already are much better than humans here, in this case none of this two approaches will work.

If you find any thing where humans are competitive to computers then increasing their time can give them more advantage but this is secondary. What is primary is to find such a thing and make mining depended on it.

Instead of N-heads you can decrease block generation speed although this will make coins distribution less even.

Oh, I missed that fix. Issue with gitian build were obvious to you because you made that changes but not to me.

It is possible to generate 15 seconds blocks every 15 seconds. Such fork will be valued by client higher than 10 seconds block every 60 seconds because 4*1/15 > 1/10. You may start with last difficulty retarget and generate next block with much greater time to switch to 15 seconds target time and then continue to generate 15 seconds blocks with 15 seconds spacing until your fork will not contain more work (as defined by current GetBlockWork() function). Then just send your fork to the network.

I gave a lot of reasoning. As I said many times, the main issue with it is that you want to send blocks with unprotected (by PoW/PoP) info. Any single node can just change that info, although it doesn't give any profit, someone may do it just for fun because it is very simple. In that case network will split, some nodes will think that last block contains one set of transaction and others will think that it contains different set of transactions. It will not be a security risk because you will increase required number of confirmations but it will defeat the purpose of giving humans more time, say you are mining and try to add security to the previous block but then new block appears that has different previous block, in that case you will need to switch to new chain and that means new map. Another issue are fees. Because transactions in previous block are unprotected, miners will try to move all tranaction with fees to new block to get those fees, next miner will do the same, etc.

No. I don't know what in the code made you think that way. We really wanted to make human-only mineable coin.

Currently network works with no time deficit. To perform 51% attack you don't need to outperform all of the rest miners by very large margin, you just need to be slightlly faster then they all combined. There is no need to create time deficit.

I wasn't clear here, I said "relatively safe" without specifying "relative to what". Let's imagine that sometime in the future some changes will be made to constrain bots and to give humans at least some possibility to mine. That will mean that current bots will be bad and will have many possible ways for improvement. That means that someone may create drastically better bot and attack the network. Current bots probably cannot be improved to make them much faster. I'm not talking here about time warp, I'm just comparing current situation with theoretical situation described above.

I'm again talking here about situation when there is a way to make drastically faster bot, in that case high price will give motivation for it.

Maybe I'm wrong and you are right and there ways to highly improve current bots. You made a bot, I didn't, so you may know it better.

Isn't five being several?

I gave you access on github to the repo and website. I can even send you private key for sending alert to peers.

I don't want to give you the lead because I fear that you will try to make that N-heads thing or something similar that may have unpredictable consequences. But for this hardfork which seems fine to me I give you the incentive. Select new block for the fork, make patch and builds, upload them, update links on the website. I redirected link in OP to the website. I will also make builds if you want but you don't need to wait for me for your announcement. Show us how it should be done (no sarcasm here, I wish you will handle everything well).

Listening to the majority is usually not very smart. Many don't understand how it works and don't know how to write programs (this is confirmed by a lot of ridiculous proposals in this thread), their opnion is based on emotions and not on understanding and analysis of your proposals and technical disussion that surrounds them.

Sorry for the harsh rant but I'd already "called out" Will in pm, and he just ignored it entirely.  Now he posts a list of unjustified (and unproductive) claims about my efforts to fix his broken code.

Anyway we should probably pick a new fork block or something, eh?

Who else can build with gitian now?  I'd love to have at least 3 build hashes to compare.

Because someone could turn on some specialized hardware and rewind the entire chain.  A small handful of FPGAs could pump out 100k low difficulty blocks in hours. (Maybe even minutes.) Are we going to have to actually demonstrate this on live net to get you to start living up to your responsibility as dev?  I would hope not.


Some notice (instead of an empty promise to do something you apparently would have had no time for) would've been nice.

This also doesn't excuse your behavior in general.  It is not just your disappearance this weekend that is troubling, overall I think no-one is satisfied with your performance to date.


What bug?  The sync issue was fixed well in advance of the fork point that you decided on.  I even debugged and fixed your gitian build issues for you, despite it being quite obvious from the build log what the problematic component was, and that resolving it didn't even necessitate a code change.

Your community was ready to go and you were nowhere to be found *yet again.*


In what way do these patches not fully fix the difficulty time warp?  (If you feel there is a deficiency, you could have brought it up by now.)

If there is a remaining issue (I'm fairly confident that there isn't) let us address it and get it resolved, but you will certainly need to provide more details.


Not doing any development at all and disappearing at critical moments makes a bad impression.  I'm working on my own free time to do something to address the issues at hand, and all you are contributing is some bashing of myself and my efforts, which also makes an even worse impression.

If it seems that my patches are rushed and messy this is likely because they ARE rushed and messy.  They are rushed because I'm trying to get the network re-secured as soon as is possible.  (Why do you not seem to share this intent?)

If you feel my patches are not up to project standards (Do we have some commit guidelines somewhere that I've missed?) then don't accept the patches.  I've already committed to making a cleanup pass over them, which seemed to be enough for you at the time, so why pick that scab now, anyway?  You should be reviewing, testing, and commenting on patches that you feel aren't up to snuff.  If the syntax formatting is that critical to you, then reject the patches (instead of blindly merging them) to create urgency on my part to clean and resubmit them.  It is your responsibility as merge master to gate the official repository, and accept/reject contributions on merit.  If you're not going to live up to that responsibility don't go blaming your contributors.

Is this your first time leading an open-source project?


You still have not given any reasoning as to either why it would not work, or why it would not increase margin for humans.  It seems pretty self-evident to me that it would not only work fine but would give us an inflection point to give *arbitrary* margin back to humans. You may not believe this to be true, but until you can offer any explanation of that belief I think you stand alone there.

(EDIT: It was pointed out to me that it will not really give "arbitrary" inflection on this, which is of course true as there is a constrained range of total seignior margin available to begin with.  I guess I should have said "arbitrary margin relative to bots" or something.)

If we give humans a sufficient multiple of wall clock time to solve, how does this fail to increase their margin by that multiple?


It certainly will not be if the developer makes no efforts (and rejects third party efforts) to do so.  I'm starting to suspect that you don't wan't to fix this mess you've left.

From digging through more context around the code and the launch of the coin, I'm even starting to suspect that one or more of the original devs have actually been bot operators since genesis, and may be the "silent" bot operator - the only one who has not either been vocal on the thread or come forward and contacted me in pm. (It really appears there is only one such "silent miner" judging by block submission sources, assuming no-one is pooling yet, and I think that is a pretty safe assumption.)


With the difficulty time warp patch in place even a "total solution" bot which could generate constant complexity solutions in trivial time could not 51% attack unless they also overcame work deficit.  (Granted, right now our adjustment interval for the work deficit is very long at 2k blocks, and should probably be shortened to further constrain any such risk.)  At best, they could revert the whole coin to a traditional PoW scheme, but could not 51% attack unless they controlled 51% of this work deficit effort also.

Further, I'm not sure why you don't seem to understand that without the bots the network is inherently insecure anyway.  The goal here should not be to "stop the bots" as all this accomplishes is putting the safety of the network's tx selection entirely back into the hands of the few extremely skilled and dedicated players.  We need to stabilize and secure the network so that a bot operator with specialized resources cannot revert the chain, and then we need to promote bot mining to maximize the decentralized security of the network with a broad contribution of bot resource.

Finally, I really do not understand at all your reasoning that a higher price leading to more miners is somehow not an advantage to the network, and is even disadvantage.  We *want* more people mining, as much and as broadly distributed as possible.  What argument can be made for the opposite?


You need to explain and justify what you see as risk because, again, you seem to be standing alone on this.

The current state of the network is not at all safe.  With a resource spend of only a few thousand USD an attacker has not-one-but-two options for utterly destroying this coin in a blink.  They could either difficulty time warp with low difficulty solutions or they could halt the chain with high difficulty solutions.  Unless you can provide reasoning to the contrary, both of these issues should be closed after my patch.  So far you've claimed reasoning to the contrary but have not shown it.  If you know something we don't, please do tell!

The current (second wave) bots aren't "quite good" they are just more aggressive on TT than the first wave bots.  Third wave bots will likely produce even lower TT solutions in lower wall-clock time as well.  It will not take many more iterations on the "bot AI" before we may be looking at producing a natural work deficit again!

Further, I wouldn't say that there are "several people" mining.  We have every indication that there are FIVE people (or "point of presence" entities, anyway) mining.  I do not consider a resource contribution of a few dozens of CPUs total to be nearly sufficient to call the network secured.


Yes, I'd gladly post gitian build hashesh, and further I propose that we establish a consortium of project maintainers to create and cross-verify all builds, so users can have confidence that their binaries are not tampered with, and will not expose their assets to risk.

Also, I think that even if you are not willing to step down as development lead (and everyone speaking up certainly seems to think that you should at this point) you should at least establish secondary compensatory controls over the repository and site so that they can have continuity even if you were to disappear for an extended time.  As things stand right now, you "hold the keys to the kingdom" as they say.  Imagine what would have happened to HUC if snailbrain had not had access to those resources when Mikhail "thecoder" passed.

Our approach of this uneasy alliance may work for the moment, but it is not sustainable.  Fix it.  "Lead, follow, or get out of the way."  It is time to pick which you are going to do.

Yes, I wasn’t working on this coin in recent time but I don’t understand why we need some rush here with this hardfork. I didn’t have time as I was moving from one apartment to another.

Here are some notes:
1. If I made builds in time we would now have builds with serious bug.
2. These patches does not fully fix time warp problem. Well, it’s hard problem that isn’t easy to fix.
3. His patches make very bad impression - improper indentation, unnecessary code duplication, a lot of commented code. Though it doesn't mean that they are internally bad but it makes them harder to read and gives bad impression.
4. HunterMinerCrafter wants to give humans some advantage with his N-heads approach but it is obvious that it won't work and even if it could work it would be almost useless for humans. Do you really want this coin to be controlled by someone who doesn't understand some basic things about how blockchain works?
5. This coin will probably never be human mineable again. Originally I thought that this game is hard to bot but this was proven to be false. Current coin was botted in weeks. With some changes it can be made harder for bots but there is a contradiction here - the more popular this coin is and the higher the price - the more people will make bots. Because this game is used as a way of securing the network it will pose the whole network at risk of 51% (or even 99%) attack if new well-made bot will appear. I think that current network is relatively safe from this as current bots are quite good and there are several people mining (although we may never know, maybe it is mined by just one person) but if we will start to make changes to protect game from bots then we will have the risk described above.

Nevertheless, I’m ready to make builds (starting hardfork with new block of course) if there are no new obstacles such as some bugs. HunterMinerCrafter, will you want to also make a build, so that we can bitwise compare them?

I think it would not prevent those things, all it does is waste time and a bit of funds by being a needless obstacle. Come on William, you can do the right thing, let HMC take over and the community will still appreciate and forever credit your innovation foremost, and you will keep credibility which can be your ground to stand on if you decide to work on another project in the future. Otherwise all you accomplish is purposefully inconveniencing the community and possibly force us to rebrand the coin.

Exactly!
The dev is just wasting out time right now. We need him to pass it over to HunterMinerCrafter otherwise we won't have bot protection or anything.

Seeing so much promise in this concept, even with bots...
What I don't understand is - if the original developers have no interest or stake in the coin anymore, why don't they pass the control of key assets such as master GitHub control and motocoin.org website to the person who is now voluntarily coding the fixes this coin needs?

Don't sell this cheap, MOTO can go so much higher just cancel sellorders everyone. 

Yeah, this is really annoying. I think maybe he has given up. I was waiting for him to reply but he hasn't.
I hope he makes his decision soon.

Edit: Wow, still no reply!

@WIlliamLie2  We're rapidly approaching block 104k, do you have builds?

Are we forking at 104k?

EDIT: I'm taking that as a no...

We really need the dev to either step up or give up.  This "maybe I will maybe I won't" behavior is getting tired.

The gitian error seems to be related to the testnet-box setup, and is arguably a bug in gitian itself.  I'm going to revert that commit, since it will only be useful to a small handful of people anyway (mostly just people doing dev on the coin itself) and will just keep it on a separate branch for people to use.

In the interim, if you want to build, just remove the testnet-box related files.

I've made this change on my branch and the wallet now syncs correctly again.


You would likely need to build through gitian for the resultant binary signatures to match up.