Bitcoin Forum

Basicly its a fairly hyptothetical question.

But lets, just for a moment assume bitcoin had something like a "kill-switch".
A method that, by design, would revert all transactions that have ever been done.

What would be the consequences?

As this is open source, any kill switch would be publicly visible.  It's not there.  Now then, within a closed source implementation, such as any proprietary "coin" invented by J.P. Morgan for example, a kill switch could easily be hidden.

Game over!

I said "by design", not "by code". That might sound like a splitting hairs, but its actually really a very different thing.

May i quote you on that?
(Outside this forum?)

orphaned block, not a shit was given.

And if the block was several blocks longer than the "valid" block chain?
<edit>I mean, if the "attacking" blockchain was longer?<edit>

The bitcoin "design" is quite simple and straightforward, it is highly doubtful a purposeful flaw exists that remains unknown.

That's not to say that the design may not ultimately fail, for example mining incentives could evolve in a manner that damages bitcoin, but an intentional kill switch is just plain unlikely.

Sure! I say game over because (unless it was averted before the switch was flipped by means of hard fork where the "kill-switch" was omitted), the trust would be gone. Game Over!

I am not considering an "intentional" kill switch (unless that had been the Satoshi´s intention).
Merely a design flaw that could have the same consequence.

Well said. A hard fork can be a remedy for everything after all ;)

everyone ignores attacking blockchain.

if this happens i'm buying....

Why would a client ignore a longer block chain? Basicly the valid block chain would be the "attacking" block chain, wouldnt it?

Was the blockchain rolled back a few years ago to fix some problem? If there were any big problems in the future the dev's would probably roll back the blockchain and do a hard fork to fix it. A design flaw would create loss of confidence and a price drop, but I doubt it would kill bitcoin unless it was unfixable.

everyone ignores attacking blockchain, by upgrading their client.

you should have been there

poeple were still making TX as the chine was forking and every single TX got through onto the right chain

I was impressed.

When you upgrade the client to one that has a fix for such a switch, that would be a hard fork, no? The same as when they implemented the checkpoints and it was a mandatory upgrade which is probably the one you are referring to in your next post ;)

And assuming i (or $whoever) had a/several blockchains dozens of blocks longer than the "valid" blockchain? What then?

its no use, the blockchain necessarily is what the majority want it to be.

Yes, the longer chain is technically recognized as the "correct" chain by the network, but this has been rolled back with a fork before, and as Adam said, an upgrade to the client would be necessary by the majority (>50%) of the network.

This is the same thing as 51% attacks

add to that, that the majority overrule hashing power.

if marjory says "block that mega miner with 30% mining power because we don't like him"

hes blocked.

of course its very hard to get >51% to all agree on something. but in this most ridiculous sanrio it would fly.

Hmm, so we have this ledger with every Bitcoin transaction going back to the beginning. Every 10 minutes a new block is added to show the latest transactions.

Then some "kill switch" does what exactly? Wipes out the ledger? On everyone's computer? Even those that are turned off? Even those not connected to the Internet?

It would be harder to do than wipe out all bank accounts of all banks, all stocks, bonds, etc in the whole world.

No, it is not.
In the real world the the block chain does not have a constant exponential factor. Any deviation results in a suboptimal difficulty for the real chain compared to a "perfect" chain with a constant exponential factor.
Thus an attacker would save time or difficulty by choosing a constant exponential factor for difficulty increasements.

No, the only safety are the so called checkpoints. Those are hardcoded into the clients. In other words all transactions since the last hardcoded checkoint would be save.
But otherwise, yes, it doesnt matter if the PCs are turned on or off.

Would we have to forget some of those transactions? Like how some of the initial transactions done by Satoshi are so famous?

Memory wipe as well?

It would be difficult, yes! But not impossible.
It wouldn't matter about the disconnected clients. Once they sync to the network, if for instance something was added to that final block to make the client no longer start or recognize the chainstate, then every client would be broken.


The 51% comment was more gear toward the majority of the network would have to agree on one chain. Not that this hypothetical "bug" would be synonymous to a 51% attack

Without checkpoints a competing blockchain starting of the genesis block with a simple 7% difficulty growth per switch would be at the same length as the current blockchain. And just be running at ~ 300GH/s.
Obviously its a lot harder thanks to checkpoints.
But this means the trust in the algorythm has been breached and instead the trust of "core developers" is required to include checkpoints.
This shouldnt be necesarry. The difficulty algorhythm is imho flawed. The simple average of the last 2016 blocks is just plain stupid.

you know what i mean?
i'm wondering if you guys agree with this or not?

Whatever you seem to mean is not true. The hardcoded checkpoints decided by devs overrule overything.

It would help if you learned how Bitcoin works.   "Longest chain" doesn't mean highest block height it means the chain consisting of valid blocks with the highest total cummulative difficulty.   Your chain with 7% difficulty growth every 2016 blocks would never be the longest chain.  There are no shortcuts to the longest chain.    The current longest chain is ~2^70 hashes worth of work.  The only way to make one longer would be to do more work.


The checkpoints are not necessary to prevent an attack.  An attacker however could waste a lot of time and resources of new bootstrapping nodes by feeding them giant worthless low difficulty chains. Any well connected node can identify the correct longest chain but time/resources spent validating a chain to find out it is inferior is still wasted time/resources. Checkpoints reduce the amount of resources an attacker could could cause a new node to waste.

The newest checkpoint is more than 7 months old.  That alone should help your realize it isn't a security mechanism.  I mean does anyone think limiting an attacker to "only" rolling back 7 months of the blockchain would be an effective defense?  Everyone is going to say "good thing for that checkpoint it limited us to only 7 months of double spends, had it been 8 months that might have shaken my confidence"?

Well, I always assumed "Speculation" meant speculating about price.  But I guess there are other kinds of speculation I had not co sidered. Well played!

Someone would fix it and relaunch it starting from the last "old" block. This would happen within hours after the incident.

This has actually happend once, where 184,000,000 bitcoins were created due to a floating integer bug.

say everyone wants to kick off a huge malicious miner off the network, ( it makes no sense for a miner to act maliciously but lets say it happening ), someone with like 30% hashing power start attacking, everyone wants to kick him off, the core is patched to block this miner, everyone upgrades because they wish it, and there you go, majority overruled hashing power.

point is hashing is just a way of achieving consensus in an automated way, and can be side swiped given "manual" consensus.

The majority of the hashing power must agree to this change.  So it's not that the "majority overruled hashing power".  It's just that the majority of the hashing power overruled the minority, as in any other double-spend attempt.

There is literally no way this would work. You could block IPs submitting blocks, or find another workaround.
BUT if this guy is really malicious, than he is watching everything very carefully and will be proactively changing his IP and setting to something different.

Also, there are "Red Alert" scenarios, that would fix malicious attacks in the shortterm, even 51% attacks, but there is nothing longterm!

The easiest way to do this is by destroying every copy of the Blockchain in existance and inducing amnesia in every Bitcoin user.

Anything less than that will be rolled back. You can have a kill switch that works "temporarily" and may cause mass panic and losses for Bitcoin users, but whatever you do can be undone.

exactly.

all i'm trying to say is that, its our network, and we choose how it works in every detail, just because someone has alot of hashing power doesn't give him any real, long term, power over the system, the will of the majority supersede all. hashing power will ALWAYS service US, the moment it doesn't we ignore it

Bitcoin could as a last resort become a pure POS coin for a while too.

Sure there is. If we are being 51% attacked by a miner using SHA256 ASICS we could switch to another hashing algorithm. If we are being 51% attacked by some multi-purpose hardware that can efficiently run many hashing algorithms, then we can replace the POW system with something else.

While these kind of changes will be hard to swallow and you may have a hard time convincing people to make these kind of changes, they are always an option.

I meant longterm in the sence that we don't change from SHA256. The majority of hashpower will always win there longterm. But that is not an issue but foremost a feature.

You are absolutely right, in the end a switch to delegated proof of stake or something similar is a good alternative, though I hope it never get chosen out of a NEED due to an attack!

it doesn't need to

hashing power will ALWAYS service US, the moment it doesn't we ignore it

Well hypothetically of there was a killswitch and it was triggered, it would kill bitcoin (hence the name killswitch). Most technically savvy people who read the code would have noticed this however.

Citation required (preferably a link to the source file).

In other words you are saying that if two chains started with the same hashrate and one chain mined at this rate constantly (2016 blocks per 14 days, or 4032 per 28 days) while an other one alternates between this hashrate and double the hashrate (thus creating the first 2016 blocks in 7 days and then 28 days thereafter, or 35 days per 4032 blocks) the later chain would be valid even if this is shorter since it has a higher "cumulative difficulty"?

So you are saying that an attacker with sufficient hashrate (e.g. a company or gov with access to a huge batch of next-gen asics) could just fork of an old block and create a new valid shorter chain as long as cumulative has rate is higher???

Yes.

Here's a thought experiment for you.  Imagine that the day Satoshi launched Bitcoin someone forked the blockchain, right from the Genesis block.  He's been mining, on a tiny computer, since that day.  On his chain, the difficulty never went much above 1, because he's the only miner - but his chain still produces one block every ten minutes.   He's been doing this since day 1, and his blockchain is about the same length as the real one.  It varies from time to time - sometimes his chain is a couple of blocks longer, sometimes a couple of blocks shorter.

Today, his chain is a couple of blocks longer than the public chain.  Today, he broadcasts all his blocks to the world.

In a naive world, his 313631 blocks would be considered longer than the official chain of 313629 blocks, and every client on the planet would immediately have a block reorganisation, and accept his chain as valid.

But Satoshi wasn't naive.  In the real world, his chain is worthless, because a block mined at difficulty 18 billion is considered to be 18 billion times more work than a block mined at difficulty 1.

Of course, there are all sorts of other reasons why the attack wouldn't work - you can never have a block reoganisation that goes back past the last checkpoint, and anyway, the average block interval on the public chain is significantly less than 10 minutes due to rising hash rate (so in reality the public chain would be longer in terms of block height anyway).  But I hope this example helps you see why Satoshi designed it this way.

roy

I really would prefer a link to the source. Found those for checkpoints, but a quick google didnt find anything corresponding to a "cumulative difficulty".

I already played that thought experiment. Given the average increase of ~7% per difficulty switch this hypothetical chain would have a difficulty of 1.07^155 or roughly 36k.


As i said i still want to see that in code.
Because what you are saying is very naive. I dont believe Satoshi was that naive.
Given the exponentially decrease in network security (due to block reward halvings) relative to the worth of the network the attack would just get cheaper relative to potential disruption. As soon as undoing a transaction (even if its more than 6 blocks old) is a lot cheaper than actually loosing the money you spent, hey whats to stop someone. Well, except for the central bitcoin authority adding more checkpoints.

It's a thought experiment, so by definition it's naive.  The purpose wasn't to demonstrate a real attack scenario - it was to try and help motivate why this is a better way to define the longest chain.

Do you mean "why you would think this would be a better way" or that "its actually being done this way"?

The attacking blockchain will be considered as invalid by other people, and will be ignored. It's length is irrelevant

By the way, this topic has nothing to do with this speculation section.

It is actually being done this way.  Why do you think otherwise?

Not a link to the code, I know, but the developer documentation says "Assuming a fork only contains valid blocks, normal peers always follow the longest fork (the most difficult chain to recreate) and throw away (orphan) blocks belonging to shorter forks." https://bitcoin.org/en/developer-guide#block-height-and-forking

Let me turn this around.  Everyone is telling you it is done this way - why are you somehow convinced it isn't?

The code you are looking for is comparison between blockchain difficulties. The parameter is nChainWork which is a sum of work of all found blocks on the chain. This parameter decides which chain lives (main.cpp line 80 for example)

Simply because your link says the opposite of what you said.

Ok, finally a decent answer, gonna check it.

In this most ridiculous Sanrio it would fly:

https://i.imgur.com/jg2Lpid.png

Risk is always central to speculation, so I disagree.  It's silly, but it's not irrelevant.

Now my Eva Air grab, that was irrelevant.

keep dreaming go back to sleep

No, the developer documentation says "the most difficult chain to recreate", but I really don't know why we're arguing about this.

Well, to be precise it says
and
Even assuming that "the most difficult to recreate" implies total hashrate and not length thats fairly ambigous.
But anyway, piramida had it right. The comparator on line 80 (starting at line 76) is used by FindMostWorkChain, which in turn is called by ActivateBestChain. And there is no arguing with the code there.

The reason for the argumenting is fairly simple. If total cumulative hashing power is the deciding factor an attacking entity merely needs overwhelming hashing power to revert all transactions since any given point after the last checkpoint. In other words if any an event such as a sudden advance in technology, a majority if mining gear being sold after a reward halving etc ..., allows for a sudden shift in hashing distribution it is fairly easy to create a more difficult chain. To roll back time by time by n blocks within a timeframe with m further blocks you only need to beat the current chain (simplyfying here with a constant hashrate, principle stands one way or another though) (n+m)/m times the hash rate of the official network. E.g. a competing chain running at twice the hashing power of the official chain could roll back 1 day of transactions per passing day.

Using the length of the block chain, while being being having other disadvantages, is not susceptile to such a sudden increase in hashing power. To roll back n blocks within the next n blocks you need (again assuming the real chain stays at constant difficulty c) to exponentially grow the hashing power to catch up. Even assuming someone where to double the initial power c with every difficulty adjustment (and thus halving the time needed to create his own blocks) he would need 2^(2*no. of difficulty switches) the hasing power to catch up. In other words 4* the power to reverse 2016 blocks, spending the first week recreating the last 2016 blocks at double rate and spending the next week to create the 2016 new blocks at quadrouple rate. Trying to reverse 4032 blocks would require 16x current hashrate etc ...

There is the 51% attack, but anyone in position to do that would be gaining tons of money with mining.

So it would be more like suicide bomb switch.


If it happens, goodbye to descentralized currencies

Here is a possible scenario: A Sybil https://en.bitcoin.it/wiki/Weaknesses (https://en.bitcoin.it/wiki/Weaknesses) attack by an OS vendor that controls 91.68% of the desktop OS market. http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=8&qpcustomd=0 (http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=8&qpcustomd=0). The operating system vendor uses the DRM built into the OS to patch the Bitcoin clients and turn them into malicious clients controlled by it. If the ratio of Bitcoin nodes running on the attacker's OS to the total number of Bitcoin nodes corresponds to the attacker's OS market share, that attacker would control 91.68% of the nodes.

Edit: A variant of this attack is where the attacker manages to create malware that infects the above mentioned OS. If the infraction rate is high enough it could approach the OS market share. If the DRM in the OS is used to spread the malware the attacker could use anti-circumvention laws as a deterrent against anti-malware software.

Control over a certain % of nodes doesn't give you any special power over the network.   As long as nodes can connect to at least one honest node they can distinguish the longest chain.

While it is nice to argue about actual numbers I'm not sure what you are trying to get at here.
This type of consensus requires a majority so by definition the majority decides (eventually), regardless if they are the "attacker" or the "regular" chain.
As has been pointed out this actually also applies to the protocol software itself (let us consider abstract functionality and not a concrete implementation) and not just for the blockchain.

Unless you make very strong assumptions that are unrealistic and unwanted for the goals set out by bitcoin there is no circumventing the requirement for a majority of "correct" processes.

Of course one can always hypothetically "destroy" the protocol by assuming that the attacker owns a majority (and also maintains it, because probabilistic consensus means they have to infinitely often outnumber other participants or their "agreed upon" version can still change. This is one difference to deterministic consensus where the result does not just converge towards a probability of 1 but actually is 1).


As for the assumption of an ominous "kill switch". Effectively this is a majority attack on the (perceived) protocol functionality.
To me the only reasonable assumption where such a scenario could occur is if the ECDSA implementation of bitcoin was fundamentally flawed, allowing an attacker to spend from arbitrary addresses.
One could still try to migrate to another signing implementation but if there is no confidence in the validity of the current distribution of funds it makes little sense to try and salvage it as you cannot reasonably distinguish between rightfully owned addresses and those with stolen funds.

Good point, but I believe that market of bitcoin nodes is dominated by linux.

On the other hand, MS or other entity could attempt to steal or delete wallets stored on Windows desktops and Windows Phone Clients. If 91% of wallets is suddenly deleted, that could slow down the adoption, or even halt it completely (users would be scared to buy bitcoins again).

No