First, I'd just like to say that I feel this was your most reasonable post to date.
Oh, I missed that fix. Issue with gitian build were obvious to you because you made that changes but not to me.
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.
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.
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.
// Motocoin-FIXME: ok?
CBigNum GetBlockWork() const
{
return (CBigNum(1)<<250) / (nBits+1);
}
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.
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.
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.)
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.
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.
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.
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?
No. I don't know what in the code made you think that way. We really wanted to make human-only mineable coin.
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.
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.
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 (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!
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.
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.
Isn't five being several?
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.
I gave you access on github to the repo and website. I can even send you private key for sending alert to peers.
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.
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.
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.)
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).
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.
everyone speaking up certainly seems to think that you should at this point.
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)
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),
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.
their opnion is based on emotions and not on understanding and analysis of your proposals and technical disussion that surrounds them.
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.
