Pages:
Author

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

member
Activity: 68
Merit: 10
October 17, 2015, 04:46:33 AM
Can someone provide me some nodes?

I want to explore the api set of this coin.
newbie
Activity: 37
Merit: 0
October 17, 2015, 04:10:51 AM
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?
legendary
Activity: 1540
Merit: 1001
Crypto since 2014
October 17, 2015, 01:53:41 AM
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
sr. member
Activity: 434
Merit: 250
October 17, 2015, 01:41:05 AM
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.)
sr. member
Activity: 434
Merit: 250
October 17, 2015, 01:36:56 AM
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.

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

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.
legendary
Activity: 1540
Merit: 1001
Crypto since 2014
October 16, 2015, 06:52:00 PM
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?)
member
Activity: 68
Merit: 10
October 16, 2015, 05:54:07 PM
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.
legendary
Activity: 1540
Merit: 1001
Crypto since 2014
October 16, 2015, 05:11:22 PM
HMC is this what you wanted? https://bitcointalksearch.org/topic/m.12688630

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.

Quote
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. Smiley
sr. member
Activity: 434
Merit: 250
October 16, 2015, 02:58:20 PM
No we can't.

As you like...

Quote
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?

Quote
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?

newbie
Activity: 37
Merit: 0
October 16, 2015, 02:24:07 PM
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.
sr. member
Activity: 434
Merit: 250
October 16, 2015, 01:32:44 PM
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.

Quote
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?

newbie
Activity: 37
Merit: 0
October 16, 2015, 12:14:47 PM
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?
sr. member
Activity: 434
Merit: 250
October 16, 2015, 11:43:12 AM
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.
sr. member
Activity: 434
Merit: 250
October 16, 2015, 11:39:44 AM
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.

?
sr. member
Activity: 434
Merit: 250
October 16, 2015, 11:39:15 AM
HMC is this what you wanted? https://bitcointalksearch.org/topic/m.12688630

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?
sr. member
Activity: 434
Merit: 250
October 16, 2015, 11:34:16 AM
Ok, if you really don't understand: all wallets will use some strong cryptographic hash to determine the index of an entry of that table. They will hash the item along with some big random salt (unique for each wallet).

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.

Quote
They will NOT use first bits of plain item data as an entry index.

Miner will NOT be able to select specific levels for degeneracy attack cause he will in fact not know what hash function each node use for that table.

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?   Wink

Quote
The only problem is that those hash tables will not be interchangable between different wallets. Is that a problem?

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.

Quote
Anyway, limited time (24 hours) solution will be simpler and enough and I'm absolutely not insisting on using that hash table.

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?

legendary
Activity: 1135
Merit: 1166
October 16, 2015, 05:57:44 AM
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.
newbie
Activity: 37
Merit: 0
October 16, 2015, 04:40:21 AM
Did you stop your bot? Because I can't connect to any nodes.

Try 37.153.97.65:13107

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...
legendary
Activity: 1135
Merit: 1166
October 16, 2015, 02:36:44 AM
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?
legendary
Activity: 1540
Merit: 1001
Crypto since 2014
October 16, 2015, 02:27:43 AM
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.
Did you stop your bot? Because I can't connect to any nodes.
Pages:
Jump to: