Topic: [ANN][MOTO] Motocoin - page 4. (Read 178177 times)

Can someone provide me some nodes?

I want to explore the api set of this coin.

Ok, I'm happy now. We can leave that hash table behind and proceed with 24h solution.


Wow that was entertaining.

Unfortunatelly, target time would be much more severe if there were 1000 bot miners instead of 10.

P.S. You mined 12 blocks in half an hour on 08.04.2015, did you mine them with public bot?

If anyone thought Human Mining was not possible, well, you're wrong!

I have successfully mined a block! It took around 40 minutes, but I did it!

I have uploaded the video to youtube:
https://www.youtube.com/watch?v=aCPHtSjqNI0

It is still up, but for some reason it gets confused talking with the daemon and has to be restarted often.  We could probably use a better suited block explorer anyway.  (Something that could show levels and their solution paths would be great.)

I understand what Archer means now, I think.  What he intends could be done without being vulnerable to an attack on the complexity, he is correct there.  However, there is still a bit of a potential problem in that it increases complexity at all.  We would still need to be able to quantify this increase in block validity checking time.


I'll have to refresh my memory on a few fine details, but I seem to recall this not being a stall condition for the network.

One of our developers, HunterMinerCrafter had a block explorer, but took it down. (I think?)

I really like this coin.
Do you guys want me to setup a block explorer ?

I can setup and host a block explorer for 0.10 BTC per year.

The "number of blocks to average" would always be a specific value such as 10.

The advantage over a small fixed amount is that it will encourage humans to mine (by giving them a higher reward) when few are mining and a lower reward when lots are mining. This will then also allow us to control the money supply better. Otherwise if hundreds of humans started mining the moneysupply would increase dramatically.

If we also make it so that a human must solve their map within 10 blocks of their map being first generated then it stops people from this attack:
Someone uses a bot to create 100 "human" mined maps and then releases them all in one block. Unless they have a really fast bot of course...

Ideally humans should only have 3 blocks to solve their map to stop this kind of attack. I find it quite easy to solve a 60 second map in 2 minutes.

Maybe he is thinking that the miner will check if they have duplicated the map. But that doesn't make any sense... I'm probably wrong.
Edit: Actually no, rereading his response I have no idea what he means either.

Also, technically, at one point, every single possible level will have been generated, stopping the whole network... But I don't think anyone in the world needs to worry about that.

As you like...


In such a case I don't understand the need for constructing such a table at all, then.  My understanding was that the table would be kept to check if a miner is trying to submit the same level solution twice.  If this hashtable is some "personal use only" thing then I don't understand what it is used for, and further I don't understand what (if not this history) prevents a miner from submitting the same level solution more than once.

Can you clarify these two points for me?


What I am arguing is not any impossibility, but a (potentially unacceptable?) added complexity to block verification.  I thought this was rather clear by this point.  Since it seems that what you are talking about can't have anything to do with block verification (but is instead just some "personal use" thing, although I don't yet understand what use...) we must be arguing about two different things, anyway?

No we can't.

If there is such level of misunderstanding between us we can't go further.

That hash table will be constructed upon wallet synchronization for PERSONAL use only. It will be just an auxiliary data structure just for searching for duplicates. Nothing more. It will not be a part of a blockchain. It will use random salt and nobody will ever show this table to anyone else.

Yes this is inconvinient and I'm not suggesting to use it in moto but I don't understand why you keep arguing that it is impossible in principle.

As am I.  The one is derived from the other, so the miner's ability to select the one implies the miner's ability to select the other.  If you look carefully at my last post, you'll see that I already elaborated this.


Not Ok, this doesn't change anything about the problem.  Everyone else still needs to verify the levels against this table, so "spoiling" their own table still drives complexity of checking their submissions as valid or not up for *everyone* as they all need to search the table.

Seriously, can we just let this go? (It is obvious that you are not going to be convinced, as you seemingly can't even admit that the zero point does necessarily exist "somewhere"...) Let's just stick to solutions that do not require such a duplication check, so that the question does not even arise in the first place?

Oh, that's hopeless. You even don't want to try to understand.

I'm not talking about salt and hash that are used to generate levels.

I'm talking about salt and hash used for hash table itself.

Hash tables use hash functions to guarantee uniformity. That is why they called "hash tables" and not simply "tables". The fact that you want to store hashes in it doesn't automatically transform table to hash table if it does not calculate hashes of that hashes.

Every user will have different hash table. Miner will be able to spoil only his own hash table.

Ok?

For you I'd be happy to help in whatever way I can!

One thing that might be nice to touch on, if only briefly: the differences between proof-of-play for tracking game state across blocks only (as in huc) versus proof-of-play for chain security (as in moto) and the trade-offs involved in such decisions.

?

In this what is "number of blocks to average?"  Just an arbitrarily selected constant?

Can you elaborate on what the advantage would be over a small, fixed amount being distributed, with a percentage going to the "real" block miner?

I really do understand this.  It doesn't make a difference, because the user chooses their salt, their address, and which hashes to generate levels from or not... so they control their *own* hash selection.  It has nothing to do with other miners, other wallets, other anything except for the hashes the users mine into this list/tree/hashtable/whatever state history.


They do know the state of the table at any given moment, and for any given hash can determine if adding that hash would make that state more or less degenerate, if it would drive complexity up or not.

 If they can affect this distribution of the hashes along a sort order, then they can affect the complexity of future searches by selectively completing hashes that `fall into the sort` in a way that leads to a degenerate complexity.  (In other words bail out of the work function after "just" the sha hashing to generate the level if the level does not hash to something within some selected deviation of some desired statistical distribution.)

In other words, they can choose to make their mining work over time "push" away from the average case by working toward building particular non-uniform distributions into their hashes, and "build out" structure that tends toward worst case.  As such, we *do* have to consider both average case and worst case in such an index.  It is the only way that we can answer "how bad *can* it get under attack?" to know if it would likely kill the network in a day of attack, a year of attack, decades of attack, or more.

Can we at least agree that there is a zero point at which the size of the set would overwhelm average block time, even if we could only show that time as being eons from now?  Can you understand why I would ask you to establish what that timeframe would be before enacting the change?

Of course at the end of the day it is somewhat of a moot point.  You have >51% of the network and can effectively do whatever you want with your chain.... so make a patch, put it out there for the world, and start mining on it.  We'll see what happens?  


Generating the table per-address probably makes the problem slightly worse, because then the miner doesn't have to worry about anyone else affecting the state of his hashtable's distribution as he works on extending it out to be increasingly degenerate.


Yes, I think this much we can agree on!  Putting known finite bound(s) on things often obviates questions of complexity in this way. (Shameless plug for tauchainzennetcointhingy, heh...) So let us just go ahead and put the "check for duplicates" based approach behind us, and leave the complexity concern of level duplication checks as an academic exercise for the reader?

Thanks for the offer - I've take a closer look, and apparently the journal restricts articles to max. 4,000 words.  That's very tight -- so I'll have to see what to focus on.  Maybe I just include the new ideas I have without going into detail for either Motocoin nor Huntercoin (although I'll be sure to mention them).  I'll post a preview of the article in any case, of course.

We could also try to work together on another, more review-like article describing the existing systems in addition.  But that would be something for the future, not immediate for me.

Try 37.153.97.65:13107


I could check this article to ensure that it doesn't contain any serious mistakes about botting. But I'm not a native speaker and also do not know as much as HMC about target time calculation, anti-warp feature and the history of MOTO...

Something completely separate:  I'm planning to write an academic paper describing human-mining and gaming on blockchains.  This paper could be submitted to the Ledger journal or some other publication.  I want to describe some ideas in a technical way, but there won't be too much mathematics or cryptography (more about ideas of system design).  So far, I'm only aware of Motocoin's proof-of-play and Huntercoin's decentralised game world that would fall into this category.

Of course, my own perspective is mostly on Huntercoin.  I also have ideas for a few new concepts I want to publish in the paper that are not yet implemented in Huntercoin, but interesting research.  If someone from the Motocoin community is interested in a collaboration, I would welcome this.  Ideally, you should write a section or two about Motocoin, proof-of-play and the issues as well as proposed solutions related to botting -- and, of course, be co-author of the paper.  Is there any interest in that?

Did you stop your bot? Because I can't connect to any nodes.