[ANN][MOTO] Motocoin

[HunterMinerCrafter]

HMC is this what you wanted? https://bitcointalk.org/index.php?topic=591724.msg12688630#msg12688630

I hope that is what you meant by formulas without numbers.

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?

[HunterMinerCrafter]

HMC, I've just reread your previous posts.

It seems that you completely forgot how hash table works.

Sorry, I thought you just wanted to play funny games with my brain.

?

[HunterMinerCrafter]

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?

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

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.

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.

[ElvenArcher]

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?

[HunterMinerCrafter]

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.

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.

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?

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?

[ElvenArcher]

Seriously, can we just let this go?

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.

[HunterMinerCrafter]

No we can't.

As you like...

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.

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?

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.

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?

[e1ghtSpace]

HMC is this what you wanted? https://bitcointalk.org/index.php?topic=591724.msg12688630#msg12688630

I hope that is what you meant by formulas without numbers.

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?

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.

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?

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.

[blockexperts]

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.

[e1ghtSpace]

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.

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

[HunterMinerCrafter]

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.

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.

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.

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.

[HunterMinerCrafter]

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

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

[e1ghtSpace]

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

[ElvenArcher]

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.

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

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

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?

[blockexperts]

Can someone provide me some nodes?

I want to explore the api set of this coin.

[e1ghtSpace]

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.

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

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

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?

Yes. I also mined a few more today with the bot.

[sparkster]

MOTO has pretty good block explorer on cryptopia: https://www.cryptopia.co.nz/BlockExplorer?coin=MOTO (not fully functional)

And HunterMinerCrafter one, of course: http://37.153.97.65:3000/ (does not work right now)

[e1ghtSpace]

Hey ElvenArcher (and/or HunterMinerCrafter), what do you think about this idea?

HMC is this what you wanted? https://bitcointalk.org/index.php?topic=591724.msg12688630#msg12688630

I hope that is what you meant by formulas without numbers.

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?

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.

I'm assuming you guys think this its a bad idea or I am annoying you with posts. Sorry.

[domob]

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?

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

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.

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.

Since the Ledger journal seems to impose a very strict length restriction (3,000 to 4,000 words only), I'll probably focus only on the Huntercoin ideas -- basically the post I wrote over there (which you commented on) with some additional explanation and more security analysis.

But if I have enough space to mention proof-of-play or human-mining in the introduction in a general discussion, I will definitely point out the two different systems and compare them briefly.  The other idea is (as already written above) to write both the paper about game channels and another one giving more like a review of proof-of-play in general.  There, I (or we if you are interested) could go into more details of the general ideas and their differences.

[ElvenArcher]

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.

There is absolutelly no difference between your solution and mine in this particular aspect (if I understand your solution correctly). If you just divide 10 moto from each block among all free solutions in last 10 blocks you will get almost the same result.

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.

In fact, what we are trying to do is to remove any of this "10 blocks" limits.

To stop that kind of attack we can just set the limit of free levels per block to some small amount (5 for example). Then adjustment of the target time will quickly decrease this amount to 1 free level per block on average.

Also, I think there is no way to allow 60 sec maps for humans anyway. Bots are incredibly good at solving 60 sec levels. In fact, human levels should have target time smaller than real blockchain levels.

It would also be very interesting if you try to solve the level with the same target time as you did before (27 sec) but without force restarts and compare how much easier it was. You can start the level and then unplug your internet connection to disable restarts (you will not get any reward of course).