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.
Topic: [ANN][MOTO] Motocoin - page 5. (Read 178273 times)
HMC is this what you wanted? https://bitcointalksearch.org/topic/m.12688630
I hope that is what you meant by formulas without numbers.
I hope that is what you meant by formulas without numbers.
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).
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.
The only problem is that those hash tables will not be interchangable between different wallets. Is that a problem?
Anyway, limited time (24 hours) solution will be simpler and enough and I'm absolutely not insisting on using that hash table.
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.
The only problem is that those hash tables will not be interchangable between different wallets. Is that a problem?
Anyway, limited time (24 hours) solution will be simpler and enough and I'm absolutely not insisting on using that hash table.
Considering that the miner picks their seeds there is nothing to prevent degeneracy, so what we have here is primed for a potential DoS attack, as well, where a bot miner picks clustered level hashes to solve in order to drive this search time up toward O(N).
So you want to use hash table without calculating hashes at all? Of course every node will have different random salt. You can attack only if you know it (And you will be able to attack only this particular node, it can detect it easily and change the salt, but if someone have access to other's moto folder wouldn't it be more sane to steal the wallet instead of this almost useless salt).
Errr.... huh? I have no idea what you're on about here.
The attack that I was referring to has nothing to do with targeting any specific miner.
I was referring to the fact that when the miners make their own hash selections, they could choose to only use hashes that increase the degeneracy of the set, to push the complexity of searching this set toward the O(n) limit. They would not need to compromise any particular other miner to do this, it is an attack against the network as a whole. They would only need to churn hashes and ignore (not even try to solve) the ones that are well distributed relative to what is already in the set, instead working only on solving the ones that increase the degeneracy in the set after they would be added to it.
Quote
Quote
Your check would need to somehow be O(1) and it just simply can't be...
You can tell controversial things about something that nobobody can really prove. But it is mindless to do such thing in this particular case when everybody can go to wikipedia and see that O(1). If you was able to write your bot and make patches for MOTO you obviously know how to program and I'm pretty sure that you are aware of all basic algorithms.
Errr... proving this is not hard. Try it yourself in a testnet with a couple of nodes: just add a simple progressive slowdown into the block validity check, like usleep(blockdepth) or even usleep(log(blockdepth)) and then run out a lot of low difficulty blocks, and see how many it takes before the time to check one block becomes significantly large to start to cause fragmentation of consensus. Then continue running it to see how many blocks it takes before the time to check one block exceeds the average block time.
Quote
But first you tell us that you don't see any solution at all except checking every block. Then you tell us that there are in fact some algorithms that can be used but they will require Log(n) time.
This log solution and this "checking every block" solution are the same solution....
Quote
If you are uncomfortable with that hash table or if you think that it is unnecessary waste of HDD you can simply tell us that.
As I said before, the concern is not with the space complexity or storage requirements.
Quote
There is no need to invent sophisticated logical constructions with purposely embedded flaws. This flawed conversation can lasts forever. I don't like when someone tries to manipulate me that way.
I am not "inventing" anything, or attempting to manipulate. I have stated a fact about the complexity constraints of the blockchain algorithm, and challenged you to establish that your proposal falls within these constraints. I'll just add this to the ever-growing list of challenges that you refuse to rise to.
Quote
Just forget about that hash table, 24 hours would be pretty enough for human to solve the level. Just check last 1440 blocks.
This is a simpler and much more sound proposal. I would (of course) still much prefer that the network not be paying for work that doesn't secure anything, but if that is the best we can do then we'll live with it.
Can you outline the details for discussion?
Actually there is (at least on average), which is a hash table (see the corresponding Wikipedia entry, for instance). That's what ElvenArcher has been saying above.
HI DOMOB! How've you been? How's life in HUC?
Of course I understand that a hashtable allows for search of sorted set in O(1) time on average, as I elaborated in my last post...
The problem is that it is O(1) on average but grows to O(n) in the worst case. In practice, it will land somewhere in between, depending upon the distribution of the hashes stored. (Which is up to the miners' selection of hashes.) "Somewhere in between" is more than the maximum O(1) time that can be implicitly assumed as safe to add to block validity check! If block validity check is anything more than linear in the number of transactions in the block then there is, of course, a potential problem.
In order to be able to say that such an added complexity is safe for the network we would need to be able to quantify a priori that the slowdown potentially introduced over time by the hashes added every block does not significantly impact the block validity check in any meaningful term, even if miners are selecting a degenerate distribution of hashes on average.
So far, I have seen no such measure of the performance impact.
I will not just make a change that could kill the network within a few years on blind faith that it shouldn't be "any problem." We need to know that it will have a non-feasibly low probability of being any problem.
If it can be shown that the natural growth of this table and the amount of degeneracy of the set sorting that can be introduced on average by malicious hash selections is highly unlikely to introduce any significant added time to block validity check, at least for many decades, I would be much more comfortable with the proposal.
Considering that the miner picks their seeds there is nothing to prevent degeneracy, so what we have here is primed for a potential DoS attack, as well, where a bot miner picks clustered level hashes to solve in order to drive this search time up toward O(N).
So you want to use hash table without calculating hashes at all? Of course every node will have different random salt. You can attack only if you know it (And you will be able to attack only this particular node, it can detect it easily and change the salt, but if someone have access to other's moto folder wouldn't it be more sane to steal the wallet instead of this almost useless salt).
Quote
Your check would need to somehow be O(1) and it just simply can't be...
You can tell controversial things about something that nobobody can really prove. But it is mindless to do such thing in this particular case when everybody can go to wikipedia and see that O(1). If you was able to write your bot and make patches for MOTO you obviously know how to program and I'm pretty sure that you are aware of all basic algorithms.
But first you tell us that you don't see any solution at all except checking every block. Then you tell us that there are in fact some algorithms that can be used but they will require Log(n) time.
If you are uncomfortable with that hash table or if you think that it is unnecessary waste of HDD you can simply tell us that. There is no need to invent sophisticated logical constructions with purposely embedded flaws. This flawed conversation can lasts forever. I don't like when someone tries to manipulate me that way.
Just forget about that hash table, 24 hours would be pretty enough for human to solve the level. Just check last 1440 blocks.
There is no actual O(1) option, here. This is the problem... no matter what you do, checking for the duplicate level will grow in time, slowing the block validity check bit by bit every block, until the network falls over. Block validity checking *really* does need to be strictly linear in the number of transactions, and *not* at *all* more than this. There's no escaping that. Your check would need to somehow be O(1) and it just simply can't be...
If you have some magical way to search a set in less than O(log) worst case I'm sure the world would like to hear about it... This would be a groundbreaking accomplishment!
If you have some magical way to search a set in less than O(log) worst case I'm sure the world would like to hear about it... This would be a groundbreaking accomplishment!
Actually there is (at least on average), which is a hash table (see the corresponding Wikipedia entry, for instance). That's what ElvenArcher has been saying above.
I wrote all this and no one notices??
I still don't follow what you're getting at with this. Can you write out an overview of the proposed logic, defined in a more abstract form? (Formulas instead of numbers?)
Ok, the human's reward is decided like this:
A Human's Payout = coin reward * ( number of blocks to average / number of human solutions in the last number of blocks to average)
So, if 20 human solutions were included in the last 10 blocks (average of 2 solutions per block) then the reward of the next block would look like this: (if coin_reward = 10 and the number of blocks to average is 10)
10 * (10 / 20)
But the bot that solves the real block should receive 10% of each human player's reward otherwise there is no incentive to include the human solutions.
Quote
I'm still holding out hope for some solution that doesn't require any reduction in security, as well...
Well, you could argue that the security of this solution to the problem isn't reduced because no humans are playing right now anyway. Where did you get that Log? You don't want to rebuild it completely and just want to make some kind of a tree? Or are you talking about collisions? Anyway you log is naturally limited by hash size so I don't see any problem.
?!?
Let's consider some options:
First the naive approach, simply keeping a list of hashes for every level seen. Of course searching this list is O(N) in the number of levels seen. Of course a super-linear growth by block depth is right out as unacceptable.
So let's imagine storing instead in a bintree. (It could be splay, radix, whatever...) Now we can search in O(log(N)). The value for N grows (by up to 10) with each block, the number of level hashes stored. The limit is not on the number of bits in the hash, but on the total number of values of hashes, and this is quite large. This is sub-linear, but still growing.
Finally, we could use a hash table, as you point out. This allows for searching in O(1) in the average case, yes, but still grows as O(N) in the worst case. We cannot assume average case because there is nothing that actually asserts uniformity of the data. We can say that it will be sub-linear, but also more than constant. Whether this would end up better or worse than the log tree in practice is hard to say, but we do know that it could be just as bad as the naive approach. Considering that the miner picks their seeds there is nothing to prevent degeneracy, so what we have here is primed for a potential DoS attack, as well, where a bot miner picks clustered level hashes to solve in order to drive this search time up toward O(N).
There is no actual O(1) option, here. This is the problem... no matter what you do, checking for the duplicate level will grow in time, slowing the block validity check bit by bit every block, until the network falls over. Block validity checking *really* does need to be strictly linear in the number of transactions, and *not* at *all* more than this. There's no escaping that. Your check would need to somehow be O(1) and it just simply can't be...
If you have some magical way to search a set in less than O(log) worst case I'm sure the world would like to hear about it... This would be a groundbreaking accomplishment!
How do you figure? It can never be O(1), at best the time complexity will grow O(log) by depth.
Where did you get that Log? You don't want to rebuild it completely and just want to make some kind of a tree? Or are you talking about collisions? Anyway you log is naturally limited by hash size so I don't see any problem.
I wrote all this and no one notices??
I still don't follow what you're getting at with this. Can you write out an overview of the proposed logic, defined in a more abstract form? (Formulas instead of numbers?)
Quote
Edit: Can you also answer this please?
Quote
I don't know much about qmole. Does it have SDL support? If so, it might possibly work, but is probably nontrivial.
Quote
Can human blocks be based off bot blocks, but only from the last 10 minutes, so they have 10 minutes to complete their level or a new level is generated?
I've been mulling over something similar, but don't have an answer just yet. One thing that I think would be safe to say is that things are much simpler all around if we do not actually allow an indefinite time for solutions.... We can put a very long limit, but I'm increasingly thinking that any sustainable solution must put *some* limit!
I'm still holding out hope for some solution that doesn't require any reduction in security, as well...
Just rebuild it every few years and it will always give you O(1). There is no problem at all.
How do you figure? It can never be O(1), at best the time complexity will grow O(log) by depth. This is still strictly more than just linear in transaction count! As such, there will always be "some point" where the block validity check time grows to be too much. Maybe we can push this out to a significantly long curve, hundreds/thousands of years or so, but I'm quite skeptical that this could be made to work reasonably for even a decade.
I think until we could put some hard numbers behind increase in block size and block validation time we cannot just assume that it would be "no problem at all..."
The concern is not about the size of the hashtable itself, but the ever increasing time required to enumerate it for each block.
Just rebuild it every few years and it will always give you O(1). There is no problem at all.
And your radix will have constant search time too (beware of 10 ms seek time if you want to use tree on HDD).
So time of verification will always be limited.
How can we assert that a "free" level is not duplicated without checking all prior blocks? The complexity of checking a block should grow linearly with the number of transactions in the block, and nothing else. If the time to check a block grows linearly by block depth then this creates a gradual slowdown of the network over time, which is not acceptable. The only operation that should be linear in block depth is resync!
What is the problem? Simple hash table is not enough for this? If you affraid that it will not fit in RAM you can contruct it in some file.
A hash table (probably we'd actually use a radix tree, but such details are neither here nor there) would do it, the problem is the growth of this hashtable over time. The concern is not about the size of the hashtable itself, but the ever increasing time required to enumerate it for each block.
Verifying a block (assuming the same number of transactions) should take the same amount of time regardless of it is block number 10, 1000, or 10000000. The complexity of block verification is supposed to be linear in the number of transactions in the block. It should not take any longer to verify a block with 5 transactions in 10 years from now than it takes to verify a block with 5 transactions today.
Because this table would grow with each block the time to validate a block today would be significantly less than the time to validate the same block in 5 years from now. This is a problem, these times should be the same. Having complexity of block validation being more than linear in the number of transactions implies that eventually the network would reach a point where clients would not be able to validate blocks as quickly as they are produced. At such a point the network would cease to function.
I suppose that we could resolve this by perpetually increasing the time between blocks, but this is undesirable for (hopefully) self-evident reasons.
Quote
Quote
Let's start with something simple, verifying your domain over the bot. This could be done in a number of ways... signing a message or sending coins, including some predefined token message into the blockchain, etc. Your call.
LOL So increased or switched-off production will not convince you?
It would, if done correctly. However, if done correctly it can only convince *me* and not the community at large. (The prearranged switch off time would have to be privately arranged between us, and undisclosed.) I'd prefer that you do this in a way that can demonstrate to everyone, not just to me... but I'll take what I can get. If this is the route that you'd like to take, I can arrange a switch-off time with you in PM.
EDIT: more typos
How can we assert that a "free" level is not duplicated without checking all prior blocks? The complexity of checking a block should grow linearly with the number of transactions in the block, and nothing else. If the time to check a block grows linearly by block depth then this creates a gradual slowdown of the network over time, which is not acceptable. The only operation that should be linear in block depth is resync!
What is the problem? Simple hash table is not enough for this? If you affraid that it will not fit in RAM you can contruct it in some file.
Quote
Let's start with something simple, verifying your domain over the bot. This could be done in a number of ways... signing a message or sending coins, including some predefined token message into the blockchain, etc. Your call.
LOL So increased or switched-off production will not convince you?
I didn't think too much about all of this but I don't see any serious flaw that we cannot overcome somehow (at first sight).
This is certainly an improved refinement, but I still see a lot of problems.
How can we assert that a "free" level is not duplicated without checking all prior blocks? The complexity of checking a block should grow linearly with the number of transactions in the block, and nothing else. If the time to check a block grows linearly by block depth then this creates a gradual slowdown of the network over time, which is not acceptable. The only operation that should be linear in block depth is resync!
You misunderstand my intent. I am far less interested in the details of your bot as in quantifying the necessary resource contribution to overcome it.
Ok, I don't want to give you my current bot (and if I would how could you be sure that I gave you really the best one I have?). I can help you to measure anything you want by varying my production. Tell me what you want me to do.
Let's start with something simple, verifying your domain over the bot. This could be done in a number of ways... signing a message or sending coins, including some predefined token message into the blockchain, etc. Your call.
Quote
But anyway what's the point? I possibly can run it on 1 or 2 or 20 PCs. Or maybe I don't need to pay for electricity or have access to a huge supercomputer for free. How can you be sure that someone doesn't have 100X better bot right now and just waiting for convenient moment to start it.
We have to assume that all actors are rational. If someone had a 100x bot it would be irrational for them not to be running it already, so it is safe to assume that there is no such bot.
How many nodes you run it on or what your electricity costs are not relevant. All that needs to be determined is the actual efficiency of the bot, itself, which needs to be overcome. We can assume that however many nodes you have or however cheap your electricity is that there will be someone else with comparable resource to apply. All we really seek to know is how much ("1:1") resource does need to be applied!
Quote
So I can help you to measure what you want but you will never be sure that this measurements is correct.
Yes, the only way to fully quantify the efficiency of the bot would be a direct comparison of algorithms. As you obviously have no interest in sharing such details, the best we can hope for is an approximation. This would still be better than the nothing that we have now!
Quote
The only measurement that can be relatively trusted is if there would be 100 more miners and they would grab 90% of moto and I would not be able to do anything for weeks. It that case you could possibly assume something about my bot power.
Yes, but this is just a restatement of the "we can't get there from here" catch-22.
Quote
Quote
but the average alt network has less than 10!
So one of them can easily rent 10X more hash power and get 51% at least for a short period of time?
HEH, you must not follow the alts much. Such shenanigans are not uncommon.
Quote
I can explain. I spent a lot of time making this bot, then spent time and electricity to mine moto, I also have greate amount of moto right now. What is the reason for me to do anything bad to moto now? Of course if there would be a chance to get 1000000$ by performing something like that I would understand your concern.
On the other hand we would have 4 guys that didn't invest any resources into making bot, they didn't do anything except clicking the button to download it. They have nothing to loose. Any of them can just ask 3 friends or just use some additional PCs and make doublespend just for fun.
If there was 100 miners, one of them would have to find 100-200 PCs to run the bot. This would be much more problematic for him of course.
On the other hand we would have 4 guys that didn't invest any resources into making bot, they didn't do anything except clicking the button to download it. They have nothing to loose. Any of them can just ask 3 friends or just use some additional PCs and make doublespend just for fun.
If there was 100 miners, one of them would have to find 100-200 PCs to run the bot. This would be much more problematic for him of course.
I've heard the "I'm heavily invested, so I won't attack" argument many times before. Usually it was from people who were about to destroy a market, in one way or another...
It is a nice story, but it offers no actual assurances.
Quote
Quote
The problem is that no-one would rationally do this unless they had some way to know that their resource contribution does have some chance at all to "help moto become profitable."
It's just some kind of black-and-white thinking.
In reasoning there is no other kind of thinking.
Quote
Just answer this simple question:
Do you really believe that all guys who accidentially discovered this coin and decided to try to mine moto (I don't talk about you), so do you believe that they then made full research about how many miners there are, how many moto each miner get (they would have to put huge efforts to get this information from the blockchain), how exactly moto works and so on.
Do you really believe that all guys who accidentially discovered this coin and decided to try to mine moto (I don't talk about you), so do you believe that they then made full research about how many miners there are, how many moto each miner get (they would have to put huge efforts to get this information from the blockchain), how exactly moto works and so on.
Huge efforts? It is trivial to see how many nodes are submitting blocks, and what the hashrate distribution is. Any miner who knows the first thing about mining will pay attention to these statistics.
Quote
Do you believe that they really do all of this, and exactly the result of this research is the TRUE reason why they refuse to mine.
I can understand your concerns about distribution and so on, but I don't think that this is the reason that we have too few miners.
I can understand your concerns about distribution and so on, but I don't think that this is the reason that we have too few miners.
My concerns are about security of the chain, not about distribution. (Well, I have separate concerns about distribution, specifically the lack of an end to subsidy, but this is an unrelated open question...)
Quote
Maybe now, after you wrote about it on this forum it became a reason, but why they didn't mine before?
It's not like my recent posts about the state of affairs are "news" to anyone. Just read back over the thread, everyone has been well aware of the 51% attack for quite some time.
Quote
And I can tell you what I think the reason is:
The lack of good website where they can read information about moto, lack of the block explorer, lack of mining calculator, instructions and direct link to the bot. And, of course, low price and only one exchange.
The lack of good website where they can read information about moto, lack of the block explorer, lack of mining calculator, instructions and direct link to the bot. And, of course, low price and only one exchange.
Again, all of these concerns are secondary to the security of the network. Your last point, low price on only one exchange, is a problem directly predicated on the security problem. It cannot change until the security problem is resolved.
Quote
Also, I think that everybody who tries to use moto, try to mine it by hand first, and those everlasting restarts prevent them from having fun. If they could mine without restarts, maybe then they would try to mine with bot, or just tell their friends about this cool game and they would start to mine too (manually first, and then with bot).
"Maybe," but again we have no reason to infer this.
Quote
So, let's not overthink too much.
Yes, the last thing that we would want to do is to think too hard... if we did that we might realize something true. Can't have that....
Quote
I can try to help you make those "measurements" somehow but don't forget about other ways to cure moto. I'm talking about good website with docs and instructions etc. And of course about eliminating level restarts.
Again I must point out that even if your assumption is correct and we do find a stable way to eliminate level restarts, and this does draw in more people, this is a *BAD* thing, not a good thing, so long as your 51% attack persists. We cannot bring popularity before security, all that would accomplish is to create more potential victims for your potential attack. The network must be made secure before it can be made popular or else likely all we are doing is leading sheep to their slaughter.
Again, I must say: I'll not sell snake oil. I will not promote a coin that is insecure. I'll not tell people that they should put their money at risk by choice.
Nothing else matters before the security of the chain.
If the network becomes secure again, I'll gladly do these sort of promotions, but not before. (I'm also highly suspect of anyone who would.)
EDIT: fixed typos
Ok, I will just refine this scheme slightly:
If there are any free solutions, miner can include them and get small fixed fee from each level along with his half of total reward for solving the block. The second half of the block reward will always be divided among all free solutions in last 20 blocks (If there is no free solutions in previous 20 blocks, miner could be required to add at least one in his new block).
In some cases (if previous blocks contain several free levels maked by this bot) he can decide to not include anything. But in general, previous 20 block will not contain any of his free levels, so he will just loose fees.
Now about why bots will not mine free levels (they actually will of course).
There are multiple cases, if we allow to use outdated real solutions as free solutions we will get some complicated system. I think it will work, but it's somewhat hard to analyze.
If we completely separate real and free levels, then bots will simply distribute their hash power between real and free levels to maximize the reward.
The equilibrium will be achieved (maybe I'm wrong) when bots real levels hash power will be equal to the sum of bots free levels hash power and humans free levels hash power (if we assume that humans can't mine real blocks and that target time will be adjusted to maintain one free level per block).
If accidentially human hash power will become greater than total bot hash power, there will be no reason for bots to mine free levels at all (but I will be surprised if this happens).
Of course bot can precompute tons of free levels and hold them but what's the point? He would get more reward if he just use that power to compute real levels. Moreover, target time can change and his levels can become useless. And they also can not be used to perform an attack.
I didn't think too much about all of this but I don't see any serious flaw that we cannot overcome somehow (at first sight).
Of course, it's just a draft and needs to be checked and corrected but I still think that we must give humans unlimited time somehow.
Ok, I don't want to give you my current bot (and if I would how could you be sure that I gave you really the best one I have?). I can help you to measure anything you want by varying my production. Tell me what you want me to do.
But anyway what's the point? I possibly can run it on 1 or 2 or 20 PCs. Or maybe I don't need to pay for electricity or have access to a huge supercomputer for free. How can you be sure that someone doesn't have 100X better bot right now and just waiting for convenient moment to start it.
So I can help you to measure what you want but you will never be sure that this measurements is correct.
The only measurement that can be relatively trusted is if there would be 100 more miners and they would grab 90% of moto and I would not be able to do anything for weeks. It that case you could possibly assume something about my bot power.
So one of them can easily rent 10X more hash power and get 51% at least for a short period of time?
I can explain. I spent a lot of time making this bot, then spent time and electricity to mine moto, I also have greate amount of moto right now. What is the reason for me to do anything bad to moto now? Of course if there would be a chance to get 1000000$ by performing something like that I would understand your concern.
On the other hand we would have 4 guys that didn't invest any resources into making bot, they didn't do anything except clicking the button to download it. They have nothing to loose. Any of them can just ask 3 friends or just use some additional PCs and make doublespend just for fun.
If there was 100 miners, one of them would have to find 100-200 PCs to run the bot. This would be much more problematic for him of course.
It's just some kind of black-and-white thinking.
Just answer this simple question:
Do you really believe that all guys who accidentially discovered this coin and decided to try to mine moto (I don't talk about you), so do you believe that they then made full research about how many miners there are, how many moto each miner get (they would have to put huge efforts to get this information from the blockchain), how exactly moto works and so on.
Do you believe that they really do all of this, and exactly the result of this research is the TRUE reason why they refuse to mine.
I can understand your concerns about distribution and so on, but I don't think that this is the reason that we have too few miners.
Maybe now, after you wrote about it on this forum it became a reason, but why they didn't mine before?
And I can tell you what I think the reason is:
The lack of good website where they can read information about moto, lack of the block explorer, lack of mining calculator, instructions and direct link to the bot. And, of course, low price and only one exchange.
Also, I think that everybody who tries to use moto, try to mine it by hand first, and those everlasting restarts prevent them from having fun. If they could mine without restarts, maybe then they would try to mine with bot, or just tell their friends about this cool game and they would start to mine too (manually first, and then with bot).
So, let's not overthink too much.
I can try to help you make those "measurements" somehow but don't forget about other ways to cure moto. I'm talking about good website with docs and instructions etc. And of course about eliminating level restarts.
If there are any free solutions, miner can include them and get small fixed fee from each level along with his half of total reward for solving the block. The second half of the block reward will always be divided among all free solutions in last 20 blocks (If there is no free solutions in previous 20 blocks, miner could be required to add at least one in his new block).
In some cases (if previous blocks contain several free levels maked by this bot) he can decide to not include anything. But in general, previous 20 block will not contain any of his free levels, so he will just loose fees.
Now about why bots will not mine free levels (they actually will of course).
There are multiple cases, if we allow to use outdated real solutions as free solutions we will get some complicated system. I think it will work, but it's somewhat hard to analyze.
If we completely separate real and free levels, then bots will simply distribute their hash power between real and free levels to maximize the reward.
The equilibrium will be achieved (maybe I'm wrong) when bots real levels hash power will be equal to the sum of bots free levels hash power and humans free levels hash power (if we assume that humans can't mine real blocks and that target time will be adjusted to maintain one free level per block).
If accidentially human hash power will become greater than total bot hash power, there will be no reason for bots to mine free levels at all (but I will be surprised if this happens).
Of course bot can precompute tons of free levels and hold them but what's the point? He would get more reward if he just use that power to compute real levels. Moreover, target time can change and his levels can become useless. And they also can not be used to perform an attack.
I didn't think too much about all of this but I don't see any serious flaw that we cannot overcome somehow (at first sight).
Of course, it's just a draft and needs to be checked and corrected but I still think that we must give humans unlimited time somehow.
You misunderstand my intent. I am far less interested in the details of your bot as in quantifying the necessary resource contribution to overcome it.
Ok, I don't want to give you my current bot (and if I would how could you be sure that I gave you really the best one I have?). I can help you to measure anything you want by varying my production. Tell me what you want me to do.
But anyway what's the point? I possibly can run it on 1 or 2 or 20 PCs. Or maybe I don't need to pay for electricity or have access to a huge supercomputer for free. How can you be sure that someone doesn't have 100X better bot right now and just waiting for convenient moment to start it.
So I can help you to measure what you want but you will never be sure that this measurements is correct.
The only measurement that can be relatively trusted is if there would be 100 more miners and they would grab 90% of moto and I would not be able to do anything for weeks. It that case you could possibly assume something about my bot power.
Quote
but the average alt network has less than 10!
So one of them can easily rent 10X more hash power and get 51% at least for a short period of time?
Quote
As I said in PM, this argument is like asking us to "just trust you exclusively, 100%" instead of trusting say 4 guys each with 25% or 100 guys each with 1%.... because those other guys are of course going to be untrustworthy.
I don't know about anyone else, but I'd trust the 4 guys each with 25% before the 1 guy with 100% any day. I don't care who the 5 people in question are, but it holds *especially* true when the 1 guy is saying "no really, just trust me..."
This makes no sense at all. This claim makes me wonder if you even understand what a 51% attack really is. The whole premise of the blockchain is that it works as long as we don't trust *ANY* one person alone.
I don't know about anyone else, but I'd trust the 4 guys each with 25% before the 1 guy with 100% any day. I don't care who the 5 people in question are, but it holds *especially* true when the 1 guy is saying "no really, just trust me..."
This makes no sense at all. This claim makes me wonder if you even understand what a 51% attack really is. The whole premise of the blockchain is that it works as long as we don't trust *ANY* one person alone.
I can explain. I spent a lot of time making this bot, then spent time and electricity to mine moto, I also have greate amount of moto right now. What is the reason for me to do anything bad to moto now? Of course if there would be a chance to get 1000000$ by performing something like that I would understand your concern.
On the other hand we would have 4 guys that didn't invest any resources into making bot, they didn't do anything except clicking the button to download it. They have nothing to loose. Any of them can just ask 3 friends or just use some additional PCs and make doublespend just for fun.
If there was 100 miners, one of them would have to find 100-200 PCs to run the bot. This would be much more problematic for him of course.
Quote
The problem is that no-one would rationally do this unless they had some way to know that their resource contribution does have some chance at all to "help moto become profitable."
It's just some kind of black-and-white thinking.
Just answer this simple question:
Do you really believe that all guys who accidentially discovered this coin and decided to try to mine moto (I don't talk about you), so do you believe that they then made full research about how many miners there are, how many moto each miner get (they would have to put huge efforts to get this information from the blockchain), how exactly moto works and so on.
Do you believe that they really do all of this, and exactly the result of this research is the TRUE reason why they refuse to mine.
I can understand your concerns about distribution and so on, but I don't think that this is the reason that we have too few miners.
Maybe now, after you wrote about it on this forum it became a reason, but why they didn't mine before?
And I can tell you what I think the reason is:
The lack of good website where they can read information about moto, lack of the block explorer, lack of mining calculator, instructions and direct link to the bot. And, of course, low price and only one exchange.
Also, I think that everybody who tries to use moto, try to mine it by hand first, and those everlasting restarts prevent them from having fun. If they could mine without restarts, maybe then they would try to mine with bot, or just tell their friends about this cool game and they would start to mine too (manually first, and then with bot).
So, let's not overthink too much.
I can try to help you make those "measurements" somehow but don't forget about other ways to cure moto. I'm talking about good website with docs and instructions etc. And of course about eliminating level restarts.
Put on a botscanner and make the reward for bots 20 times less 
I don't follow what you're getting at here... In any case, it doesn't explain why the miners wouldn't simply *only* include their own transactions, and ignore anyone else's.
The bot miner would need to get a larger reward than if they simply provided a solution themselves, otherwise there is no incentive to take someone else's solutions... In other words, the reward for the "human" solution would need to be a net negative in order for the bot to see incentive to include it in a block instead of their own solution.
The bot miner would need to get a larger reward than if they simply provided a solution themselves, otherwise there is no incentive to take someone else's solutions... In other words, the reward for the "human" solution would need to be a net negative in order for the bot to see incentive to include it in a block instead of their own solution.
What I'm saying is, if the bot were to only allow their own solution into the block they would be losing motocoins. This is because the reward for humans miners is based off the average human solves in the last 10 blocks (regardless of how many humans play in the current round) not just the current block (and the bot gets 10% of each human's reward). So if 10 humans solve a block, and the bot will get 10% of their rewards, then if the bot chooses not to allow human solves then they won't get the human's 10% reward. This gives them an incentive to include the human's reward.
If they only accept their own solution, and an average of 10 humans mined the last 10 blocks, then they will only get:
10 coins (from the bot's block) + 10 coins / 10 (average human players of the last 10 blocks) * 1 (number of human solutions in block)
But if they accepted, say 10 humans rewards, then their payout would look like this:
10 coins + 10 /10 *10 / 10 (10% of the human's reward)
So in total the bot would get 11 coins by accepting human solutions.
If they also accepted their own solution with the human solutions they would get 12 coins.
This means on average the bots will get 1 extra Motocoin if they accept all human solutions.
I don't know if I explained that right but I don't really have much time to check.
Human solutions should be n=10 to stop "premining" from the bot or someone else because then it could stop them from suddenly releasing 100 solutions in one block to get lots of coins but penalise real human miners.
Edit: Can you also answer this please?
Quote
http://www.qmole.uk
Would it be possible to compile Motocoin for iOS on the Qmole app?
Would it be possible to compile Motocoin for iOS on the Qmole app?
Quote
PROGRAMMING LANGUES
Common Lisp (ECL)
C, C++ (gcc, g++, clang, clang++)
Java (JamVM)
Clojure
Lua
Scheme (Gambit)
OCaml
Python
Perl
A+ APL
Common Lisp (ECL)
C, C++ (gcc, g++, clang, clang++)
Java (JamVM)
Clojure
Lua
Scheme (Gambit)
OCaml
Python
Perl
A+ APL
Edit 2: Wow, syncing is taking forever, 3+ hours and its only synced 100,000 blocks. Will we ever get on of those blockchain torrents (i've forgotten the name) where you put it in your %appdata%/Motocoin folder and the wallet imports the blocks? Maybe its bottlenecked by my CPU... Its an i5-4670K @ 3.40 GHz
Jump to: