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?

How can I answer high-school writing prompts without sounding weird and fake?

Why use steam instead of just hot air?

How to make the table in the figure in LaTeX?

Limit of an integral vs Limit of the integrand

Why in a Ethernet LAN, a packet sniffer can obtain all packets sent over the LAN?

Exception propagation: When to catch exceptions?

Why was the Ancient One so hesitant to teach Dr. Strange the art of sorcery?

We are two immediate neighbors who forged our own powers to form concatenated relationship. Who are we?

Noob at soldering, can anyone explain why my circuit won't work?

Guns in space with bullets that return?

Why does a C.D.F need to be right-continuous?

Ubuntu won't let me edit or delete .vimrc file

Remove everything except csv file Bash Script

Is a diamond sword feasible?

Why does the Earth follow an elliptical trajectory rather than a parabolic one?

Is the schwa sound consistent?

Ex-manager wants to stay in touch, I don't want to

How did Thanos not realise this had happened at the end of Endgame?

Increase height of laser cut design file for enclosure

Adding slope values to attribute table (QGIS 3)

Should these notes be played as a chord or one after another?

Was this a power play by Daenerys?

"Right on the tip of my tongue" meaning?

Would an 8% reduction in drag outweigh the weight addition from this custom CFD-tested winglet?



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?













3















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.










share|improve this question




























    3















    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.










    share|improve this question


























      3












      3








      3








      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.










      share|improve this 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.







      security mining-theory attack majority-attack






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 1 hour ago









      Pieter Wuille

      49.5k4102166




      49.5k4102166










      asked 3 hours ago









      johnsmiththelirdjohnsmiththelird

      995




      995




















          2 Answers
          2






          active

          oldest

          votes


















          4














          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 both their own financial interests, the health of the network, or legal repercussions, 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.






          share|improve this answer




















          • 1





            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.

            – G. Maxwell
            26 mins ago



















          1














          (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]






          share|improve this answer

























            Your Answer








            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "308"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            noCode: true, onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f87652%2f51-attack-apparently-very-easy-refering-to-czs-rollback-btc-chain-how-t%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            4














            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 both their own financial interests, the health of the network, or legal repercussions, 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.






            share|improve this answer




















            • 1





              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.

              – G. Maxwell
              26 mins ago
















            4














            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 both their own financial interests, the health of the network, or legal repercussions, 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.






            share|improve this answer




















            • 1





              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.

              – G. Maxwell
              26 mins ago














            4












            4








            4







            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 both their own financial interests, the health of the network, or legal repercussions, 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.






            share|improve this answer















            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 both their own financial interests, the health of the network, or legal repercussions, 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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited 1 hour ago

























            answered 1 hour ago









            Pieter WuillePieter Wuille

            49.5k4102166




            49.5k4102166







            • 1





              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.

              – G. Maxwell
              26 mins ago













            • 1





              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.

              – G. Maxwell
              26 mins ago








            1




            1





            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.

            – G. Maxwell
            26 mins ago






            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.

            – G. Maxwell
            26 mins ago












            1














            (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]






            share|improve this answer





























              1














              (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]






              share|improve this answer



























                1












                1








                1







                (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]






                share|improve this answer















                (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]







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited 24 mins ago

























                answered 29 mins ago









                G. MaxwellG. Maxwell

                5,5412840




                5,5412840



























                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Bitcoin Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f87652%2f51-attack-apparently-very-easy-refering-to-czs-rollback-btc-chain-how-t%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

                    Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

                    199年 目錄 大件事 到箇年出世嗰人 到箇年死嗰人 節慶、風俗習慣 導覽選單