Topic: Re: Taking Down Bitcoin (Read 2461 times)

this article is about a platform called Perfect Money, not Bitcoin.

-bm

or some of those who owned bitcoins would find another way to to preserve their wealth.

Sorry bout my calculations which were incorrect, but still you get the idea. At 100PH/S you would have to pay 1000 times more, a small sum of 169,000,000$. No-one, I mean NO-ONE would pay fucking 169million$ just to prove a point.

Once again the big players wnt allow this!

Well I think about BTC as an gate to new world we have already entered. If Bitcoin itself becomes corrupt we can always give value to another crypto (with need for different hardware). Also there is not just one Goverment on planet meaning they would compete with each other even when such "BTC destruction plan" would exist.

Try 85646.89 TH/s (~85.6 PH/s). If the current network hashrate was 100 TH/s, Bitcoin would most likely have been killed off with a very cheap 51% attack right now. 51% attacks, 75% attacks and 99% attacks are very expensive to conduct right now and extremely unlikely.

No, it's WAY off. If the current hashrate is 100TH, you need to add 300TH to own 75% of the hashrate

You realize that the current hashrate is like 100TH/S so they would have to add another 75TH to that in order to own 75% of the hashrate. They would need 75 1TH machines which would cost them 169425$ (Antminer S1's). For a government that kind of money is only a shit in the corner of their chest but would they really risk that kind of money for something like this?

My calculations might be a little off (I did some Google search and found that 100TH from there) so the sum might even be bigger!

Lol, the gaping hole in the argument pointed out so eloquently.

Difficulty adjustment works because it happens only once in 2016 blocks. An attacker trying to manipulate timestamp will only produce a very small effect on the difficulty. There are already many discussion saying why it is a bad idea to adjust difficulty for each single block

As mentioned earlier, if we had a reliable decentralised NTP service, we don't even need a blockchain in the first place. Your proposal is like trying to lifting yourself off from the ground with your own hands.

And finally, if someone owning 99% of hashing power decides to attack the network, there are many many ways to do so. Even if you system could be successfully implemented, the attacker could keeping mining empty blocks so no transactions may go through.

This rebuttal is pretty good! I like it

However, remember that you are THE BIG BAD GOVERNMENT. You can do pretty much anything.

(I don't believe a good government would wish to destroy such a wonderful thing as Bitcoin, this is why you are a BAD government)

So:

5. Seize the factory(ies) of the company(ies) making the ASICs ("We suspect you have hashish here, we are closing down this factory until further notice").
6. Keep the factory running (you don't want all the good people working in it to lose their jobs because you know there is no hashish) and deploy the resulting mining hardware as soon as possible while you are searching for the (nonexistent) hashish. Make sure you are building that mining megarig somewhere out of the way so nobody sees you (especially keep reporters away). The other 75% of miners is struggling as they are looking for another factory(ies) to support their growth while you are growing by leaps and bounds.
7. Continue doing 6 until you capture 75% of the total network hashrate or even more.
8. Returrn the seized ("borrowed") factories back to the owners along with a huge pile of Bitcoins ("we apologize for our mistake, we thought you had some hashish hidden here, took us 5+ years to search it all, please accept this pile of BTC and goodbye"). This helps to cover the tracks of your real intents with the seizure. Everyone will think this is the end of the story except you.
9. Continue growing the covertly established mining megarig as outlined in the scenario.

Additionally the seizure (pardon, "borrowing") would very likely send the cryptocurrency exchange rates into sky very quickly as somebody pointed out, making the step 8 here much easier to do. Especially if big press releases would be made at or around the event ("Government seized the factories of the largest SHA256 ASIC ")

And don't forget to also make big press releases when doing the step 8 to support more exchange rate rise 

Well, as I already said in a previous post, this is bound to fail because of the flexibility of the Bitcoin core developers so the end of the attack is going to look like this:

10. Once you got 99% of the hashrate and you put all your order so you won't get hit by the resulting chaos in Bitcoin economy.
11. Pull the plug.
12. Realize that the chaos dissipates in 2 days because the Bitcoin core developers issued a "critical update" killing your bloated hashrate.
13. Fix your megarig to accept the new rules and then push the plug back.
14. After a while try again by going to 11.
15. After several loops between 11 and 14 realize that the Bitcoin core developers will always fix that damn thing in 3 days or less so you're not getting anywhere.
16. Give up.

Or:

15. After several loops between 11 and 14 realize that the Bitcoin core developers implemented proof of stake and other nasty countermeasures in the Bitcoin protocol so you are hopelessly screwed.
16. Give up.

Ok, BIG BAD GOVERNMENT. Case closed. Maybe it is time to build a nice global Bitcoin address ownership register and require people to register their addresses there. You futile effort already produced that huge mining megarig so financing this should not be problem this time. The only problem is that you still want the Bitcoin network destruction and that is NOT going to happen so you won't get what you want ...

That is true if you want to increase the current rate by a factor of 100 in a couple of days or months. But if you look at my scenario and think about it a little, you can see that they don't need to hurry with the attack too much. They can start small and fund next stages of the expansion of their hashing capacity from the profits made by the previous stages. They could start with as little as 25% of the current hashing capacity (or, maybe even 10%). Given the current exchange rates that would give them %45000 per hour of income at the beginning which would all spend on more hashers and electricity. They could even repay the "loan" taken from the taxpayer's money well before they reach into 50% of the hashing capacity. And the more they conquer, the more income they will get from it.

You know, the point of the scenario is that nothing in the network is going to indicate that something bad is going to happen ... until they pull the plug. They could even recoup the price of the hardware (by selling the generated coins that are abundantly flowing out of their 99% of hashing power) they used to pull out the attack before they pull the plug.

I don't believe in "provable decentralized timestamps" and I did not expected to have these. I was thinking about some way how all nodes in the network could agree on "what time is it" with reasonable accuracy. The "reasonable accuracy" would be good enough to make near-real-time difficulty adjustments but it would be not sufficient for transaction ordering so you would still need mining. The near-real-time difficulty adjustment would remove the need for "emergency updates" killing the difficulty if 99% of the hash power would suddenly disappear into thin air.

Well, yes but you don't care about the expenses when you don't have to pay it out of your pocket (remember, it is the *government*. All they have to do is to yell loudly enough into the crowd that cryptocurrencies are only used by cyber criminals to evade punishment for their drug trafficking and child pornography and the crowd won't mind allowing them to use their taxes for taking it down).


Just today I was thinking about it (actually before reading your post) and I realized that it would be pretty stupid government to attempt to do it. Yes, they might kill Bitcoin as it is but the Bitcoin developers would simply sit down, figure out why it happened, designed a fix and deploy an emergency update that would change the protocol starting from block X (exactly as you say here). What an intelligent government would more likely to do would be to establish some service where people could register their Bitcoin addresses/wallets. The government does not need the private keys, it would just need to know "person with this ID owns this(ese) address(es)". Then those who are not interested in shady business practices would simply comply and continue as usual. This would allow them to focus investigation to those who don't want their ownership of an address becoming public.


This type of attack would most likely not work (modify the client to reject empty blocks when there are transactions to be commited), however a workable alternative would be spamming the network with bitdust, including this bitdust into their blocks. They could also include extraorbitant fees in those transactions to keep people from moving bitcoin with fees lower than this. However even this would most likely not work well.

The strategy I presented allows the attacker to keep himself hidden all the time until he decides to pull the plug. That would cause much more disruption of the network than acting "strange" from the very start of the attack.

They could also try to mine the coins and dump them to an unspendable address to reduce the money supply. However I believe now that it is pretty late for this kind of attack. They could only hope that the resulting reduction of the money supply would cause the money to be awkward to use (imagine how you are going to work with currency with its smallest unit valued at $1000 ... But that problem still can be fixed by starting to penalize coin hoarding by draining the coins out of addresses which show inbound but no outbound activity for too long (I saw some discussion on a more advanced version of cryptocurrency where there were proposals to reward maintenance of full nodes. The resulting cryptocurrency is more robust against malicious proofs of work. See proof of stake for more info.

So right now I can conclude that the scenario I proposed would work ... for a few hours or maybe days in the worst case. Then a patch would be issued, everything would return back to normal and the attacker would find itself wasting a lot of effort in vain. Sure, he would have pretty nice income stream now but that was not what he wanted .

Well, if that would be true then the difficulty adjustment would also not work. In order to be able to adjust the difficulty you need to know how long it took to generate the last 2016 blocks. So there *is* some knowledge of time. It is not exact, but it is there and it is sufficiently precise to make adjustments of difficulty that keep the block generation from getting runaway.

My idea is to use these ideas from that code that do the difficulty adjustments to implement the scenario described. Regarding the time source I was thinking about some sort of NTP-like time propagation protocol which the clients would use to track something called "current network time". A NTP service could be used by random nodes to obtain the current time but the real NTP queries should be very infrequent and made only by a few nodes, essentially the network should collectively keep track of time. The nodes shall poke throughout the network, asking random node about the time (and JUST only about the time) and then update their clock accordingly.

In order to gain 99% of the network hash rate, you need to increase the current rate by a factor of 100, and you would need enough mining equipment to generate 10,000,000,000 GH/s. At $2 per GH/s, that would cost you $20 billion.

The U.S. government has the ability to spend that much money, but keep in mind that the cost of such a project would be twice the cost of the Defense Department's largest program. Approval for such a project will never happen unless Bitcoin is perceived by many as a major threat to the U.S.

The proposal is that mining would get easier the more time that passes with no blocks found.  So when a miner submits a reduced difficulty block how do you verify that "enough" time has passed.   Of course if you had provable decentralized timestamps you wouldn't need mining to begin with.  Just check the timestamp of transactions and the first one is valid and the second is invalid.

How does that affect the scenario described?

Your proposal won't work, because there is no centralized timing source.

I think if a government bought up tons of ASICs and took down bitcoin, we would likely fork to bitcoin 2.0 with a new proof of work algo.  Everyone who owned bitcoins would support that to preserve their wealth.