Re: Namecoin is Prime for a 51% attack
Posted: Wed Sep 14, 2011 9:06 pm
Oh, I didn't thought that. Then we would just have to wait until most of the hash prefers to generate namecoins rather than attacking the network. The attack will fail. What a stupid panic I had: nothing can force us to download a client that listens to a chain we all know is a lie.vinced wrote: If an attack starts, we could restart the chain at the last lockin with merged mining.
Does merged mining come earlier with this new release?
No, we can just wait for you to get bored or the rest of bitcoin miners to become a majority supporting namecoin. We offer 50 namecoins per block, what do you offer them to be on your side?BitcoinEXpress wrote:You're burning time on lock in points. You will also need to get the majority of miners to do this quickly with updated clients.
As far as I can tell, namecoin is a fork of bitcoin with a new service embebed into the chain, do you mean a bitcoin and namecoin specific flaw?BitcoinEXpress wrote: If you read ArtForz responses to the original thread I made at Bitcoin talk he talks about a specific flaw to NMC.
If doubleC doesn't, yes I claim it.BitcoinEXpress wrote:"Time Traveling" in the block chain wasn't possible till two days ago and now you are saying it's impossible to invalidate a lock in?
If you can beat a lock in, this is because the lock in is not correctly implemented. But I don't know how you can do it wrong with such a simple if.BitcoinEXpress wrote: Want to know what the previous two exploits have in common with the lock in bypass? They were announced by ArtForz and discounted as a falsehood.
Code: Select all
if(... && thisBlocksIsCompatibleWithTheChainIhaveDownloadedWithThisRelease()) {
Thank you. A clear explanation of the attack. But I don't like relaying much on clock reports by miners.makomk wrote: As far as I know ArtForz doesn't have a lock-in bypass though. The problem he found with merged mining is that, because the Namecoin client has no block chain lockins, an attacker can rewrite history to drive down the difficulty, get to the merged mining point relatively cheaply but with a chain that has less total proof of work, then do "free" merged mining to drive the total difficulty on their fork above that of the original.
If any other blockchain decides to switch to merged mining, the developers need to add a block chain lockin at the same time or preferably earlier and they're likely to run into issues if there's a difficulty retargetting between the lockin and the switch-over point. In retrospect it might actually have been safer to specify the threshold based on block timestamps...
Also good to now that the attack is only feasible against a chain that didn't start with merged mining from the beginning.
+1johntobey253 wrote: So what I read from this is, we'd like a lockin at the merged-mining block. Maybe the next release should simply refuse to accept blocks starting at 19200 (MM start) in the hope that we can quickly agree on a 19199 lock-in and upgrade. Whoever stays at 0.3.24.62 get to see a bunch of noise from the attack, but if we have the majority after MM, that will eventually die off.
But I would like to see some motion on the 2015-out-of-2016 bug, any news there?
Maybe the sooner the better. They can change their minds and attack earlier than 19199. Of course, once it's all tested.
If they choose to attack earlier, a release with a lock in the block before the attack would be needed.