Otdfbt

Question

I was shocked to see binance CZ comment to literally "roll back" the bitcoin chain by just "calling" in some favors from "friendly" Asian miners .

This ONE person could effectively do it??? I mean are we all in a bubble, in some kind of utopia then, to think that the chain's decentralization makes it "bulletproof" and resistant to collusion by miners?

(1) This is fundamental question: How are our highly regarded and brilliant Devs of bitcoin explaining such situation where only a handful of persons´ interests could essentially be enough to do a majority 51% attack?

(2) And secondly, are there active debates about how to mitigate such situation in the future, what technical aspects implemented in the btc chain (or to be implemented) could be helpful?

This huge mining farms are essentially very disturbing. it is like in proof of stake , where the "richest" has most power. And in the PoW mining case , its similiar just that the "biggest hardware" has most power.

we have to try somehow to eliminate such easily corruptible scenarios, right?

in todays digital world, there are plenty of collusion examples of even more than 1000 different persons involved.

Handful of colluding majority miners would be a piece of cake, right?

Thank you for explaining to me this issue . I hope sincerely that this is taken up by our awesome dev community, or maybe I am just misunderstanding everything.

Since this is in Hot Network Questions, can someone link an article or something for background context on the comment that sparked this? I know about bitcoin and how a blockchain works, but I don't use it or follow news about it. edit: found ethereumworldnews.com/… myself, looks like a decent summary. — May 11 at 3:19

score 32 · Accepted Answer · 2019-05-11 01:50:07Z

Disclaimer: I believe this question may be primarily opinion-based and not very appropriate for this site, but there are a number of technical misunderstandings that can be clarified along with it, so I'll give it a shot.

There are many nuances involved here, and I fear that a large part of them didn't reach as much of an audience as the exchange announcing "we decided not to do it". I believe this was a poor choice of words, as the decision they made wasn't whether or not to roll back the chain; only whether or not to offer a bounty for doing so. I personally believe it would be very unlikely that the alternative would have actually resulted in a deep rollback.

Let's analyze the situation from a number of perspectives.

If we only consider miner's actions, is it theoretically possible for them to roll back the chain? Yes. If you're wondering if there is a small number of mining company CEOs in the world, which, if all together convinced, with complete disregard for their own financial interests, the health of the network, or legal repercussions, could decide to roll back the chain to a point before the theft, the answer is yes. This is the reason why people care about mining decentralization, and permissionlessness of entering the mining market. However, unless it's not just a majority of the hash rate that is on board with this, but actually close to all the network's hashrate (a substantially harder problem, as there are many small miners in addition to the few big ones), this would likely have take days or even weeks (if it's close to 50%), a time during which many things can happen - including a public outcry and a UASF-style fork to prevent the rollback from being accepted by the ecosystem. If considered over an even bigger timescale, events like this may even incentivize people and businesses to become miners, in order to reduce the influence of large pools.

Assuming miners maximize short-short term profit, would it be financially interesting to rollback? No. Even if we assume that everyone in the network is acting selfishly to try to maximize their own (short-term) profit, and ignores the protocol rules and the possible repercussions from doing so, it is not. By the time the information about the theft became known, the transaction was already confirmed several hours before. During those hours, miners had created dozens of blocks, which together earned several hundred BTC in subsidy and fees. The exchange would need to offer at least that amount to the affected miners, to compensate them for the income they'd lose from rolling back those blocks, before it would even be worth discussing. Let's call this the rollback cost R. As the stolen amount was in the thousands (let's call this S), that seems like a reasonable option. However, nothing prevents the thief from using (part of) the stolen funds to do the same. Every BTC offered by the exchange above R can be countered by an equivalent amount offered by the thief. And then it becomes clear that the thief has the upper hand: the exchange can at most gain S-R by a rollback, but the thief stands to gain S by not having a rollback. A theoretical possibility is a bidding war between the exchange and the thief, where both increase the amount paid to make miners act in their favor. The end game of this is that the exchange offers S-R, the thief offers slightly more and keeps R, and miners are paid S-R by the thief, and no rollback happens.

What would happen in the real world? Theoretical models are interesting to study, but in reality many more practical considerations exist. I believe those too are generally in favor of no rollback:

Coordination between distrusting miners (especially close 100% hashrate) is hard, and would take time. The more time it takes, the less advantageous a rollback becomes (see the above point), and the more damage would be done to the ecosystem (see the next point).

An hours-long (in the very best case) or a weeks-long (in the worst case) rollback would monumentally hurt the ecosystem, and likely undermine the public's confidence in the system to the extent that it would severely reduce the profitability of many parties involved (including miners and the exchange itself!).

Even ignoring all the above, miners may not be willing to take a bribe to rollback because of legal reasons if they're publicly known (which they mostly currently are). They may equally not want to take stolen money as a bribe, so this cuts in both directions. This point becomes weaker if the mining ecosystem is more decentralized, but that would also make coordination harder.

As I pointed out above, in the extreme scenario where such a rollback is actually happening, the public has time to react. If a sufficiently large group of economically relevant parties in the network refuse to accept the rollback, miners have no choice but to go along with that. This is a last-resort option, and likely damaging to the ecosystem on its own, but it is an option.

So to summarize: in theory there are absolutely ways in which a rollback could happen, and it's good to be aware of those. In reality, the security of the system relies on economic incentives already which are nontrivial to analyze. It however seems very unlikely that in the case of a theft a deep rollback is a reasonable outcome.

You might want to elaborate on your short term profit formula to consider that R depends not just on the existing blocks but on the share of honest hashrate. E.g. In the simplified theoretical model R is infinite after confirmation with >50% hashrate honest. At just under 50% honest it's finite but much larger than the number of blocks that need to be replaced. Only at 0% honest does R equal just the cost of blocks that need to be replaced. Coordination challenges alone assure that some hashrate would behave honestly. — May 11 at 1:14
@pieter-wuille thanks great! but one question remains please: How do people intend to make the btc infrastructure MORE decentralized? And i dont agree with your opinion that "coordination" is "hard" to achieve. i think its easily achieved IF they have (for whatever reason) ONE and the same goal... — May 12 at 19:24

score 9 · Accepted Answer · 2019-05-11 01:16:57Z

(adding some color) Some discussion I saw suggested that people promoting this believed they only needed to achieve >50% hashpower, which caused them to overestimate the feasibility. Reorging with only slightly over 50% would take weeks-- even months, creating massive disruption if successful, and virtually guaranteeing an effective public initiative to block it. In such an event once the rollback began, users would advise each other to use the 'invalidateblock' debugging command to make their nodes ignore it. [I also had multiple users ask me to review patches ahead of the fork that would have blocked it, I told them I thought they were over-reacting and that this was a nothing burger. :)-- but a patch would only be needed before a fork existed, and clearly people were ready to start responding to this only on the basis of twitter chatter]

chytrikchytrik 8,1652629 · Accepted Answer · 2019-05-11 03:42:48Z

I want to add a little bit to the coordination problem that @PiererWuille mentioned.

Not only does the probabilistic success of a rollback depend on the ability of miners and affected parties to coordinate, it also requires that individual miners must trust one another to participate in the rollback.

Consider this: If I had a significant portion of the hashpower, and I wanted my competitors to waste their resources mining a chain that will not end up being accepted, then why wouldn’t I just pretend that I was going to mine a rollback chain, but then actually keep working on the already-established chain? If the parties invested in a rollback were counting on my hashpower to succeed in their plan, then by not participating in the rollback I would guarantee its failure, and increase my profits at the same time (since less hashpower would be working on the already-accepted chain).

So coordination is tough beyond just actually contacting and coordinating with the other parties involved. The safest bet continues to be mining at the tip of the most-work chain.

I don't follow, how would you pretend to be working on the rollback chain? Are you imagining they trust your word? Or are you imagine some way of forging proof of work? — May 11 at 6:24
@DavidSchwartz hmm I suppose the colluding miners could share partial work with each other as proof, but I think the issue still remains in a weaker form. Over short time periods (and you want to act quickly, if attempting a rollback) it is hard to make someone prove they are mining with as much hashpower as they say they are. What if they just have bad luck? Or what if they don’t actually commit their hashpower? Or they commit less than they agreed to? Over longer periods, it becomes more obvious if someone is faking it. — May 11 at 12:03
It's really not hard at all. Literally, this is a completely solved problem. It's only difficult for very small amounts of hash power, which doesn't matter. With large amounts of hash power, you can get very, very highly accurate measurements of amount of hash power and what is being hashed in just a few seconds with absolutely no difficulty whatsoever. — May 11 at 21:38
@DavidSchwartz I think the problem still remains, consider the standoff that would occur: "who is going to be the first one to switch hashpower to the rollback chain?" Even you lie about your intention to mine it, your competitors won't realize that until some amount of time has passed, and by then they will have wasted resources mining, and setting up their backend to make the switch. I agree it is a small consideration though. — May 12 at 0:03
@Elliot Lots of ways. For example, they could publish a transaction splitting the 3000 BTC into a number of outputs and then dribble out the keys to each of those outputs to the miners as needed. — May 13 at 7:35

score 2 · Accepted Answer · 2019-05-20 08:04:03Z

There a are a few things to take into account when we consider the probabilities of a reorg attack (destroying net value) to be successful:

If the reorg is shallower than 100 blocks (COINBASE_MATURITY), the attacker can minimize the amount of direct victims. But if we are talking about a deeper one, not only the payments he wants to revert may have been spent, mixed with additional inputs and all those coins owned by other innocent people, this would also apply to coinbases earned by honest miners. The longer it takes to perform the reorg, the higher the amount of victims and their value at stake.

The attack may take a long time. The fraction of miners participating (via direct control or bribes) and the amount of blocks to revert will determine how long.

For example, to revert 6 blocks (1 hour worth of confirmations) before coinbases start maturing, the attacker will need to get immediate control over 51.5% of the hashing power. If he falls short of that percentage or requires more time to convince some of the miners, it will take him over 33 hours and reverting more than 100 blocks in total, so rewards from the first blocks may have been mixed and spent already, tainting UTXOs worth much more.

enter image description here

If the attack uses existing mining capacity, during the time it takes to reorg the chain, the capacity on the longest chain would be reduced to less than half (slower block production). You can expect this to have an impact on fees and miner rewards, as the offer for transaction confirmations is not able to satisfy demand users will have to fight for the reduced space available. Higher rewards on the honest chain will put additional pressure on miners carrying the attack. It's difficult to predict how high they can go in the middle of all that FUD, with many people rushing to move coins to trade.

A significant reorg does not only affect direct victims, every bitcoin holder would be affected due to a diminished confidence in the system, a reduction in Bitcoin utility and a drop in the price of the coins as a consequence.

PoW is a trust-minimized market signal enabling us to scale social consensus. But, if somebody builds a heavier chain with a lower value, breaking PoW trust-minimization, users can choose not to follow it and make a UASF, invalidating the reorg:

$ bitcoin-cli invalidateblock "blockhash"

Coins in each chain are only as valuable as their chances to become part of the winning one. Miners coordination to carry the attack, higher fees in the longer/honest chain and UASF risk during the reorg are all factors against reorg-coins having as much value as those in the honest chain. This makes even more challenging to use them to bribe miners.

How can we make reorgs even more difficult? @LukeDashjr provided the first two of these ideas, that would help us achieve stronger immutability:

If users set individual checkpoints in their nodes, this would discourage reorg attempts and split the chain if one happens, leaving it for market to discover the value of each chain when PoW consensus assumptions break down.

Use pool swapping rule introduced by BFGMiner to prevent miners from wasting work on stale blocks. If one pool implements a reorg policy (even if it is trying to earn bribes), miners will refuse to ditch previously validated blocks and switch to a pool working on the newest block.

@TheBlueMatt's BetterHash mining protocol would have a similar effect, making practically impossible for mining pools to enforce an ordering of transactions, hence removing their ability to censor some of them.

The more independent miners, the more difficult it will be for anybody to coordinate them and try to 51% attack the network with existing mining capacity. Currently over 40% and growing.

enter image description here

But not every reorg is an attack destroying net value. We have examples when the blockchain was reorged, discarding some PoW as worthless, because it was economically rational to do so and avoid a greater damage:

On 15 Aug 2010, output-value-overflow bug created 184.5 billion BTC. Around 5 hours after the incident (30 blocks), a fix was released: client 0.3.10. It is believed that 51 blocks were reorged in total (>70% of the hashing power mined the alternative chain during ~12 hours). 2250 BTC in rewards were lost.

On 11 Mar 2013, migration from Berkeley DB to LevelDB caused a 6 hours chainsplit at block 225430. The 0.8.0 chain reached a maximum lead of 13 blocks over 0.7.2 at block 225451, but it was abandoned and reorged at block 225454. 600 BTC in rewards were lost.

score 0 · Accepted Answer · 2019-05-11 15:35:23Z

--Re-reading the question, and realize I didn't answer the question :(. Instead, I have written below what Binance should have done!

Reorg sounded like as if BTC code would be permanently changed for future. I'm presenting below a suggestion in which Miners would still decide to work an alternate chain, not because of code change, but for a crumb of incentives available on that "possible" alternate chain.

Exchange whose coins were stolen will need to change its intent from recovering the BTCs for themselves to letting BTCs go to miners as 7,000 BTCs benefits the Bitcoin Ecosystem, then Exchange can take the following actions.

Step 1:
Exchange creates a number of serial transactions “double-spending” all the stolen 7000 Bitcoins. Using Binance example, Binance creates say 280 transactions of 25 BTCs each. They are serial in nature.

Txn1: From stolen address to address1 6975 BTCs, Fee 25 BTC

Txn2: From address1 to address2 6950 BTC, fee 25 BTC

....

Txn280: From address279 to address address280 0 BTC, fee 25 BTC

Step2:
Miners can potentially earn 25 BTCs each for next 280 Blocks if they decide to go back and re-mine from the block before the theft! If some pools start doing it, then others will start joining as they will start realizing that it is in their economic interest to join this!

In this scheme, Exchange has given up on the 7000 BTCs but instead of thief, BTCs will be given to the Bitcoin Ecosystem. It should be done in few hours of the theft, so as to make it look feasible to miners.

Can Exchange get greedy and not give the all lost BTCs to miner? While it is possible, but remember that thief may play a similar game by giving away larger part of BTCs to the miners! Actually, thief may still play games by giving higher (say, 50BTC) fee each on quite a few transactions to keep miners working on the chain with his transaction of his stolen BTCs! So, ability of Exchange to confidently tell miners that they will get all 7000 BTCs will be required.

While this may disrupt the Bitcoin chain for some time, but if this gets done one or two times, incentives for large scale theft will reduce.

Hi Satoshi, if your answer should not be an answer you should be able to delete by a link below your answer. — May 11 at 15:42
Even if the exchange gives all 7k bitcoin to the miners, the thief will still be able to outbid them, due to the cost of enacting a roll-back. See Pieter's answer for an explanation. — May 12 at 0:41
Understand and agree on being potentially outbid! My write-up was more in the direction that if victims of all large theft do this, they force thieves to give away lot of stolen Bitcoins to miners and essentially reduce the incentive for the thieves to do large scale thefts! — May 12 at 16:25

Tamas BlummerTamas Blummer 18723 · Accepted Answer · 2019-05-11 08:58:10Z

Reverting a few blocks of advance is an event that is in the realm of the regular workings of the network, it would also be too fast to trigger and deploy the social resilience (aforementioned potential UASF) of the community. The exchange could create transaction(s) that forges an ad-hoc majority coalition of miner, who if only replace the hacker transaction, but otherwise do not alter previously created blocks' payload were unlikely target of any lawsuits. Miner who would accept a counter bribe of the hacker however would be certainly sued. Whether such an incentivized re-org is feasible depends mostly on the preparedness of the exchange and the miner of acting on an offer within a very short time frame. This was clearly not the case with Binance recently. An incentivized re-org can be done and could happen as sophistication of actors using the network improves, arguing strongly as if something technically feasible can not possibly happen creates a false sense of finality and security by only a single confirmation.

You can't just replace ONLY the hacking transaction. What if the hackers spent the bitcoins to buy goods and services from different vendors? What is those vendors spent those bitcoins to their suppliers? If you alter the original transaction, none of the other transactions remain valid. So you are basically sacrificing the people who play by the rules in favor of those that put their bitcoins in centralized systems? — May 11 at 9:06
Your what-if scenario just highlights that relying on too few confirmations can become expensive. Re-orgs that drop transactions happen regularly with depth 1 and could happen with more blocks in case of a temporary network split. It is arrogant to assume one would know and correctly evaluate all considerations miner make if offered an incentive to participate in re-org. — May 11 at 10:20
Binance did not know they were hacked until several hours later. When they considered they could roll back the chain it was almost multiple hours which means ~100 blocks were already mined on top of the block that contained the 'hacking' transaction. By the time they garner support of the miners, another 100 blocks might have been mined. So you are saying, people should wait for 200 block verification? — May 11 at 10:24
Also note that in my answer I specifically only talk about deep reorgs; the situation is indeed very different if the needed reorg is only a few blocks deep. — May 11 at 16:06
Tamas is probably with respect to relatively short intervals, however, the reason people shouldn't trust those is because the network will naturally and unavoidably have them esp during internet instability events. In terms of rollbacks the short time that gets in the way of coordinating the defense also hurts coordinating the defense. I have generally recommended parties accepting high value no-recourse payments should be waiting tens of confirmations at a minimum, higher if no active monitoring and response is possible. — May 12 at 2:31

score 32 · Accepted Answer · 2019-05-11 01:50:07Z

Disclaimer: I believe this question may be primarily opinion-based and not very appropriate for this site, but there are a number of technical misunderstandings that can be clarified along with it, so I'll give it a shot.

There are many nuances involved here, and I fear that a large part of them didn't reach as much of an audience as the exchange announcing "we decided not to do it". I believe this was a poor choice of words, as the decision they made wasn't whether or not to roll back the chain; only whether or not to offer a bounty for doing so. I personally believe it would be very unlikely that the alternative would have actually resulted in a deep rollback.

Let's analyze the situation from a number of perspectives.

If we only consider miner's actions, is it theoretically possible for them to roll back the chain? Yes. If you're wondering if there is a small number of mining company CEOs in the world, which, if all together convinced, with complete disregard for their own financial interests, the health of the network, or legal repercussions, could decide to roll back the chain to a point before the theft, the answer is yes. This is the reason why people care about mining decentralization, and permissionlessness of entering the mining market. However, unless it's not just a majority of the hash rate that is on board with this, but actually close to all the network's hashrate (a substantially harder problem, as there are many small miners in addition to the few big ones), this would likely have take days or even weeks (if it's close to 50%), a time during which many things can happen - including a public outcry and a UASF-style fork to prevent the rollback from being accepted by the ecosystem. If considered over an even bigger timescale, events like this may even incentivize people and businesses to become miners, in order to reduce the influence of large pools.

Assuming miners maximize short-short term profit, would it be financially interesting to rollback? No. Even if we assume that everyone in the network is acting selfishly to try to maximize their own (short-term) profit, and ignores the protocol rules and the possible repercussions from doing so, it is not. By the time the information about the theft became known, the transaction was already confirmed several hours before. During those hours, miners had created dozens of blocks, which together earned several hundred BTC in subsidy and fees. The exchange would need to offer at least that amount to the affected miners, to compensate them for the income they'd lose from rolling back those blocks, before it would even be worth discussing. Let's call this the rollback cost R. As the stolen amount was in the thousands (let's call this S), that seems like a reasonable option. However, nothing prevents the thief from using (part of) the stolen funds to do the same. Every BTC offered by the exchange above R can be countered by an equivalent amount offered by the thief. And then it becomes clear that the thief has the upper hand: the exchange can at most gain S-R by a rollback, but the thief stands to gain S by not having a rollback. A theoretical possibility is a bidding war between the exchange and the thief, where both increase the amount paid to make miners act in their favor. The end game of this is that the exchange offers S-R, the thief offers slightly more and keeps R, and miners are paid S-R by the thief, and no rollback happens.

What would happen in the real world? Theoretical models are interesting to study, but in reality many more practical considerations exist. I believe those too are generally in favor of no rollback:

Coordination between distrusting miners (especially close 100% hashrate) is hard, and would take time. The more time it takes, the less advantageous a rollback becomes (see the above point), and the more damage would be done to the ecosystem (see the next point).

An hours-long (in the very best case) or a weeks-long (in the worst case) rollback would monumentally hurt the ecosystem, and likely undermine the public's confidence in the system to the extent that it would severely reduce the profitability of many parties involved (including miners and the exchange itself!).

Even ignoring all the above, miners may not be willing to take a bribe to rollback because of legal reasons if they're publicly known (which they mostly currently are). They may equally not want to take stolen money as a bribe, so this cuts in both directions. This point becomes weaker if the mining ecosystem is more decentralized, but that would also make coordination harder.

As I pointed out above, in the extreme scenario where such a rollback is actually happening, the public has time to react. If a sufficiently large group of economically relevant parties in the network refuse to accept the rollback, miners have no choice but to go along with that. This is a last-resort option, and likely damaging to the ecosystem on its own, but it is an option.

So to summarize: in theory there are absolutely ways in which a rollback could happen, and it's good to be aware of those. In reality, the security of the system relies on economic incentives already which are nontrivial to analyze. It however seems very unlikely that in the case of a theft a deep rollback is a reasonable outcome.

You might want to elaborate on your short term profit formula to consider that R depends not just on the existing blocks but on the share of honest hashrate. E.g. In the simplified theoretical model R is infinite after confirmation with >50% hashrate honest. At just under 50% honest it's finite but much larger than the number of blocks that need to be replaced. Only at 0% honest does R equal just the cost of blocks that need to be replaced. Coordination challenges alone assure that some hashrate would behave honestly. — May 11 at 1:14
@pieter-wuille thanks great! but one question remains please: How do people intend to make the btc infrastructure MORE decentralized? And i dont agree with your opinion that "coordination" is "hard" to achieve. i think its easily achieved IF they have (for whatever reason) ONE and the same goal... — May 12 at 19:24

score 9 · Accepted Answer · 2019-05-11 01:16:57Z

(adding some color) Some discussion I saw suggested that people promoting this believed they only needed to achieve >50% hashpower, which caused them to overestimate the feasibility. Reorging with only slightly over 50% would take weeks-- even months, creating massive disruption if successful, and virtually guaranteeing an effective public initiative to block it. In such an event once the rollback began, users would advise each other to use the 'invalidateblock' debugging command to make their nodes ignore it. [I also had multiple users ask me to review patches ahead of the fork that would have blocked it, I told them I thought they were over-reacting and that this was a nothing burger. :)-- but a patch would only be needed before a fork existed, and clearly people were ready to start responding to this only on the basis of twitter chatter]

chytrikchytrik 8,1652629 · Accepted Answer · 2019-05-11 03:42:48Z

I want to add a little bit to the coordination problem that @PiererWuille mentioned.

Not only does the probabilistic success of a rollback depend on the ability of miners and affected parties to coordinate, it also requires that individual miners must trust one another to participate in the rollback.

Consider this: If I had a significant portion of the hashpower, and I wanted my competitors to waste their resources mining a chain that will not end up being accepted, then why wouldn’t I just pretend that I was going to mine a rollback chain, but then actually keep working on the already-established chain? If the parties invested in a rollback were counting on my hashpower to succeed in their plan, then by not participating in the rollback I would guarantee its failure, and increase my profits at the same time (since less hashpower would be working on the already-accepted chain).

So coordination is tough beyond just actually contacting and coordinating with the other parties involved. The safest bet continues to be mining at the tip of the most-work chain.

I don't follow, how would you pretend to be working on the rollback chain? Are you imagining they trust your word? Or are you imagine some way of forging proof of work? — May 11 at 6:24
@DavidSchwartz hmm I suppose the colluding miners could share partial work with each other as proof, but I think the issue still remains in a weaker form. Over short time periods (and you want to act quickly, if attempting a rollback) it is hard to make someone prove they are mining with as much hashpower as they say they are. What if they just have bad luck? Or what if they don’t actually commit their hashpower? Or they commit less than they agreed to? Over longer periods, it becomes more obvious if someone is faking it. — May 11 at 12:03
It's really not hard at all. Literally, this is a completely solved problem. It's only difficult for very small amounts of hash power, which doesn't matter. With large amounts of hash power, you can get very, very highly accurate measurements of amount of hash power and what is being hashed in just a few seconds with absolutely no difficulty whatsoever. — May 11 at 21:38
@DavidSchwartz I think the problem still remains, consider the standoff that would occur: "who is going to be the first one to switch hashpower to the rollback chain?" Even you lie about your intention to mine it, your competitors won't realize that until some amount of time has passed, and by then they will have wasted resources mining, and setting up their backend to make the switch. I agree it is a small consideration though. — May 12 at 0:03
@Elliot Lots of ways. For example, they could publish a transaction splitting the 3000 BTC into a number of outputs and then dribble out the keys to each of those outputs to the miners as needed. — May 13 at 7:35

score 2 · Accepted Answer · 2019-05-20 08:04:03Z

There a are a few things to take into account when we consider the probabilities of a reorg attack (destroying net value) to be successful:

If the reorg is shallower than 100 blocks (COINBASE_MATURITY), the attacker can minimize the amount of direct victims. But if we are talking about a deeper one, not only the payments he wants to revert may have been spent, mixed with additional inputs and all those coins owned by other innocent people, this would also apply to coinbases earned by honest miners. The longer it takes to perform the reorg, the higher the amount of victims and their value at stake.

The attack may take a long time. The fraction of miners participating (via direct control or bribes) and the amount of blocks to revert will determine how long.

For example, to revert 6 blocks (1 hour worth of confirmations) before coinbases start maturing, the attacker will need to get immediate control over 51.5% of the hashing power. If he falls short of that percentage or requires more time to convince some of the miners, it will take him over 33 hours and reverting more than 100 blocks in total, so rewards from the first blocks may have been mixed and spent already, tainting UTXOs worth much more.

enter image description here

If the attack uses existing mining capacity, during the time it takes to reorg the chain, the capacity on the longest chain would be reduced to less than half (slower block production). You can expect this to have an impact on fees and miner rewards, as the offer for transaction confirmations is not able to satisfy demand users will have to fight for the reduced space available. Higher rewards on the honest chain will put additional pressure on miners carrying the attack. It's difficult to predict how high they can go in the middle of all that FUD, with many people rushing to move coins to trade.

A significant reorg does not only affect direct victims, every bitcoin holder would be affected due to a diminished confidence in the system, a reduction in Bitcoin utility and a drop in the price of the coins as a consequence.

PoW is a trust-minimized market signal enabling us to scale social consensus. But, if somebody builds a heavier chain with a lower value, breaking PoW trust-minimization, users can choose not to follow it and make a UASF, invalidating the reorg:

$ bitcoin-cli invalidateblock "blockhash"

Coins in each chain are only as valuable as their chances to become part of the winning one. Miners coordination to carry the attack, higher fees in the longer/honest chain and UASF risk during the reorg are all factors against reorg-coins having as much value as those in the honest chain. This makes even more challenging to use them to bribe miners.

How can we make reorgs even more difficult? @LukeDashjr provided the first two of these ideas, that would help us achieve stronger immutability:

If users set individual checkpoints in their nodes, this would discourage reorg attempts and split the chain if one happens, leaving it for market to discover the value of each chain when PoW consensus assumptions break down.

Use pool swapping rule introduced by BFGMiner to prevent miners from wasting work on stale blocks. If one pool implements a reorg policy (even if it is trying to earn bribes), miners will refuse to ditch previously validated blocks and switch to a pool working on the newest block.

@TheBlueMatt's BetterHash mining protocol would have a similar effect, making practically impossible for mining pools to enforce an ordering of transactions, hence removing their ability to censor some of them.

The more independent miners, the more difficult it will be for anybody to coordinate them and try to 51% attack the network with existing mining capacity. Currently over 40% and growing.

enter image description here

But not every reorg is an attack destroying net value. We have examples when the blockchain was reorged, discarding some PoW as worthless, because it was economically rational to do so and avoid a greater damage:

On 15 Aug 2010, output-value-overflow bug created 184.5 billion BTC. Around 5 hours after the incident (30 blocks), a fix was released: client 0.3.10. It is believed that 51 blocks were reorged in total (>70% of the hashing power mined the alternative chain during ~12 hours). 2250 BTC in rewards were lost.

On 11 Mar 2013, migration from Berkeley DB to LevelDB caused a 6 hours chainsplit at block 225430. The 0.8.0 chain reached a maximum lead of 13 blocks over 0.7.2 at block 225451, but it was abandoned and reorged at block 225454. 600 BTC in rewards were lost.

score 0 · Accepted Answer · 2019-05-11 15:35:23Z

--Re-reading the question, and realize I didn't answer the question :(. Instead, I have written below what Binance should have done!

Reorg sounded like as if BTC code would be permanently changed for future. I'm presenting below a suggestion in which Miners would still decide to work an alternate chain, not because of code change, but for a crumb of incentives available on that "possible" alternate chain.

Exchange whose coins were stolen will need to change its intent from recovering the BTCs for themselves to letting BTCs go to miners as 7,000 BTCs benefits the Bitcoin Ecosystem, then Exchange can take the following actions.

Step 1:
Exchange creates a number of serial transactions “double-spending” all the stolen 7000 Bitcoins. Using Binance example, Binance creates say 280 transactions of 25 BTCs each. They are serial in nature.

Txn1: From stolen address to address1 6975 BTCs, Fee 25 BTC

Txn2: From address1 to address2 6950 BTC, fee 25 BTC

....

Txn280: From address279 to address address280 0 BTC, fee 25 BTC

Step2:
Miners can potentially earn 25 BTCs each for next 280 Blocks if they decide to go back and re-mine from the block before the theft! If some pools start doing it, then others will start joining as they will start realizing that it is in their economic interest to join this!

In this scheme, Exchange has given up on the 7000 BTCs but instead of thief, BTCs will be given to the Bitcoin Ecosystem. It should be done in few hours of the theft, so as to make it look feasible to miners.

Can Exchange get greedy and not give the all lost BTCs to miner? While it is possible, but remember that thief may play a similar game by giving away larger part of BTCs to the miners! Actually, thief may still play games by giving higher (say, 50BTC) fee each on quite a few transactions to keep miners working on the chain with his transaction of his stolen BTCs! So, ability of Exchange to confidently tell miners that they will get all 7000 BTCs will be required.

While this may disrupt the Bitcoin chain for some time, but if this gets done one or two times, incentives for large scale theft will reduce.

Hi Satoshi, if your answer should not be an answer you should be able to delete by a link below your answer. — May 11 at 15:42
Even if the exchange gives all 7k bitcoin to the miners, the thief will still be able to outbid them, due to the cost of enacting a roll-back. See Pieter's answer for an explanation. — May 12 at 0:41
Understand and agree on being potentially outbid! My write-up was more in the direction that if victims of all large theft do this, they force thieves to give away lot of stolen Bitcoins to miners and essentially reduce the incentive for the thieves to do large scale thefts! — May 12 at 16:25

Tamas BlummerTamas Blummer 18723 · Accepted Answer · 2019-05-11 08:58:10Z

Reverting a few blocks of advance is an event that is in the realm of the regular workings of the network, it would also be too fast to trigger and deploy the social resilience (aforementioned potential UASF) of the community. The exchange could create transaction(s) that forges an ad-hoc majority coalition of miner, who if only replace the hacker transaction, but otherwise do not alter previously created blocks' payload were unlikely target of any lawsuits. Miner who would accept a counter bribe of the hacker however would be certainly sued. Whether such an incentivized re-org is feasible depends mostly on the preparedness of the exchange and the miner of acting on an offer within a very short time frame. This was clearly not the case with Binance recently. An incentivized re-org can be done and could happen as sophistication of actors using the network improves, arguing strongly as if something technically feasible can not possibly happen creates a false sense of finality and security by only a single confirmation.

You can't just replace ONLY the hacking transaction. What if the hackers spent the bitcoins to buy goods and services from different vendors? What is those vendors spent those bitcoins to their suppliers? If you alter the original transaction, none of the other transactions remain valid. So you are basically sacrificing the people who play by the rules in favor of those that put their bitcoins in centralized systems? — May 11 at 9:06
Your what-if scenario just highlights that relying on too few confirmations can become expensive. Re-orgs that drop transactions happen regularly with depth 1 and could happen with more blocks in case of a temporary network split. It is arrogant to assume one would know and correctly evaluate all considerations miner make if offered an incentive to participate in re-org. — May 11 at 10:20
Binance did not know they were hacked until several hours later. When they considered they could roll back the chain it was almost multiple hours which means ~100 blocks were already mined on top of the block that contained the 'hacking' transaction. By the time they garner support of the miners, another 100 blocks might have been mined. So you are saying, people should wait for 200 block verification? — May 11 at 10:24
Also note that in my answer I specifically only talk about deep reorgs; the situation is indeed very different if the needed reorg is only a few blocks deep. — May 11 at 16:06
Tamas is probably with respect to relatively short intervals, however, the reason people shouldn't trust those is because the network will naturally and unavoidably have them esp during internet instability events. In terms of rollbacks the short time that gets in the way of coordinating the defense also hurts coordinating the defense. I have generally recommended parties accepting high value no-recourse payments should be waiting tens of confirmations at a minimum, higher if no active monitoring and response is possible. — May 12 at 2:31

搜尋此網誌

Otdfbt

51% attack - apparently very easy? refering to CZ's “rollback btc chain” - How to make sure such corruptible scenario can never happen so easily?What would happen if a mining pool admins having majority of hash power turns evil?

6 Answers
6

Your Answer

Post as a guest

6 Answers
6

6 Answers
6

Post as a guest

Popular posts from this blog

Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

51% attack - apparently very easy? refering to CZ's “rollback btc chain” - How to make sure such corruptible scenario can never happen so easily?What would happen if a mining pool admins having majority of hash power turns evil?

6 Answers 6

Your Answer

Sign up or log in

Post as a guest

Post as a guest

6 Answers 6

6 Answers 6

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Popular posts from this blog

Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O﻿ / ﻿43.24775, -8.60070

6 Answers
6

6 Answers
6

6 Answers
6

Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070