Like does the Bitcoin Core have hard coded things like "block x has hash=123" that were added along the lines when developers were pushing updates?
I haven't checked the recent versions, but in earlier version, yes. I assume they are still there.
Topic: Is this a possible to attack blockchain? (Read 126 times)
I haven't checked the recent versions, but in earlier version, yes. I assume they are still there.
I see, thanks for the answers guys.
Also, what exactly do you mean by
Also, what exactly do you mean by
Quote
The secondary reason is that Bitcoin Core (and any other node or mining software that is 100% compatible with Core) has checkpoint hash values that it compares against the blockchain. Any chain that doesn't match those checkpoints is discarded.
Like does the Bitcoin Core have hard coded things like "block x has hash=123" that were added along the lines when developers were pushing updates? Is such attack possible in theory?
No.
if not, then why?
There are 2 reasons.
The most important reason is that the consensus rule does NOT state to follow the chain with the most blocks. That is just an oversimplification that people use when talking about the blockchain because it works in the general case and it is easy to say and understand. The ACTUAL consensus rule is to follow the chain that has the largest total proof-of-work. Since your blocks will be solved at a lower difficulty level, the total proof-of-work will be less than the "real" chain even though your chain has more blocks.
The secondary reason is that Bitcoin Core (and any other node or mining software that is 100% compatible with Core) has checkpoint hash values that it compares against the blockchain. Any chain that doesn't match those checkpoints is discarded.
if so, what effects would it bring to BTC? and how would we prevent it??
It brings no effects since it isn't possible. We prevent it as described.
I've originally wanted to test this idea in a local setup before bringing it to public, but I don't have enough technical knowledge to implement it.
You've saved yourself a lot of wasted time and effort.
What you're describing is somewhat of a sybill attack:
https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack
But existing nodes will reject your blocks if they don't match the confirmed chain.
Just because you're connecting to a node and you have other blocks indexed won't make that node drop his history and adopt you chain.
From the same page:
https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack
But existing nodes will reject your blocks if they don't match the confirmed chain.
Just because you're connecting to a node and you have other blocks indexed won't make that node drop his history and adopt you chain.
From the same page:
Quote
Generate "valid" blocks with a lower difficulty than normal
Using unmodified Bitcoin code, an attacker could segment himself from the main network and generate a long block chain with a lower difficulty than the real network. These blocks would be totally valid for his network. However, it would be impossible to combine the two networks (and the "false" chain would be destroyed in the process).
Using unmodified Bitcoin code, an attacker could segment himself from the main network and generate a long block chain with a lower difficulty than the real network. These blocks would be totally valid for his network. However, it would be impossible to combine the two networks (and the "false" chain would be destroyed in the process).
Now, it's kind of a common knowledge what the 50%+1 attack is, and how it allows attacker to rewrite transaction history.
My idea is, does it really matter to me (as an attacker) to launch the attack and only rewrite the last block (or few blocks)? why not redo the whole block chain and screw it up for everyone?
Lets say I download the first year or two of BTC blockchain, before the time of GPU mining, so the difficulty would be pretty low and can be easily overwhelmed with couple GPU cards. Then, I use a custom GPU miner that will find a block at exactly 10 minutes, because the difficulty is very low, running in an isolated fully controlled environment, and running a custom miner, it shouldn't be hard to generate a block every other minute.
I know there's difficulty change every 2 weeks worth of blocks, but since the blocks are generated with malicious time stamps of 10 minutes delay and I'm running in a controlled environment, it's very easy to trick the system and hold the difficulty at constant level that allows me to keep mining blocks and rewrite the whole history since 2010 for example.
Now, up to this point the whole thing is being run in an isolated controlled environment 'malicious net', so the 'main net' doesn't know about it, what I do next is to mine up to a couple weeks in the future and stop 1 block after a re-target block, then distribute the 'malicious net' on multiple servers to increase upload speed and hit multiple nodes at same time (still not exposed to 'main net') and wait till the re-target happens.
Once it happens, I open my malicious servers to the 'main net', and because I have a longer chain, clients would start to use it, and because it has low difficulty, it'll find more blocks faster and poison more clients with my 'malicious net'.
I've picked to stop at a re-target block because it usually takes a bit longer for miners to find a block after it, giving me more time to distribute my 'malicious net'
This type of attack wouldn't be carried overnight, it will take couple months of preparation for sure.
Is such attack possible in theory? if not, then why? if so, what effects would it bring to BTC? and how would we prevent it??
I've originally wanted to test this idea in a local setup before bringing it to public, but I don't have enough technical knowledge to implement it.
My idea is, does it really matter to me (as an attacker) to launch the attack and only rewrite the last block (or few blocks)? why not redo the whole block chain and screw it up for everyone?
Lets say I download the first year or two of BTC blockchain, before the time of GPU mining, so the difficulty would be pretty low and can be easily overwhelmed with couple GPU cards. Then, I use a custom GPU miner that will find a block at exactly 10 minutes, because the difficulty is very low, running in an isolated fully controlled environment, and running a custom miner, it shouldn't be hard to generate a block every other minute.
I know there's difficulty change every 2 weeks worth of blocks, but since the blocks are generated with malicious time stamps of 10 minutes delay and I'm running in a controlled environment, it's very easy to trick the system and hold the difficulty at constant level that allows me to keep mining blocks and rewrite the whole history since 2010 for example.
Now, up to this point the whole thing is being run in an isolated controlled environment 'malicious net', so the 'main net' doesn't know about it, what I do next is to mine up to a couple weeks in the future and stop 1 block after a re-target block, then distribute the 'malicious net' on multiple servers to increase upload speed and hit multiple nodes at same time (still not exposed to 'main net') and wait till the re-target happens.
Once it happens, I open my malicious servers to the 'main net', and because I have a longer chain, clients would start to use it, and because it has low difficulty, it'll find more blocks faster and poison more clients with my 'malicious net'.
I've picked to stop at a re-target block because it usually takes a bit longer for miners to find a block after it, giving me more time to distribute my 'malicious net'
This type of attack wouldn't be carried overnight, it will take couple months of preparation for sure.
Is such attack possible in theory? if not, then why? if so, what effects would it bring to BTC? and how would we prevent it??
I've originally wanted to test this idea in a local setup before bringing it to public, but I don't have enough technical knowledge to implement it.
Jump to: