"Sensible defaults" and unintended consequences of the recent orphaned blocks

Read about Prohashing, mining, and coins in general!
Forum rules
Sign up to be notified of new posts to the Prohashing Blog at http://eepurl.com/gx1e0j
Post Reply
User avatar
Steve Sokolowski
Posts: 3966
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

"Sensible defaults" and unintended consequences of the recent orphaned blocks

Post by Steve Sokolowski » Mon May 20, 2019 12:45 pm

On May 15, there were two consecutive orphaned blocks on the Bitcoin Cash network. Given that Bitcoin Cash has one of the longest target times between blocks of any coin, and that it has one of the highest difficulties of any coin, I repeatedly expressed concern that the probability of the orphans solely being a result of chance was astronomically low. I implored developers to investigate the issue, and it seems that more information has recently come to light. In this post, I'll review the latest theories, show why the pools' response likely had a result far different than what was intended, and will discuss how similar issues can be prevented in the future.

Unfortunately, it is still not certain exactly what occurred in regards to this incident, and given the legal implications involved in the participants revealing the full story, it is likely that it never will be. One compelling theory that has been recently advanced is that someone mined a Bitcoin Cash block that spent money that the network allowed anyone to spend. The money had originally been sent to what would have been SegWit addresses had they been on the Bitcoin network. These addresses would have been spendable by anyone, but a code change in bitcoin cash clients for the last six months rendered them inaccessible until May 15.

According to the theory, two mining pools contacted each other and agreed to orphan the block that had spent this money, so that they could instead send all of the money in these addresses back to the addresses where the last transaction originated. However, all other pools continued to mine with the default client settings, and we happened to find a block before those pools could orphan the one they didn't like, putting them two blocks behind. Eventually, they published three blocks, reorganizing the blockchain and causing most exchanges to "lock their wallets" in response.

There is limited evidence to suggest that this theory is true, so it can't be considered proven. If it is true, the implication is that the Bitcoin ABC developers are not directly responsible for the orphaned block, and in that we would apologize for the tweet that mistakenly blamed them for it. Most of the discussion across the Internet has centered around what can be done to prevent this issue from occurring in the future, and how the mining pools that conducted this action should be viewed.

Some people suggested that an open communications channel, like a Telegram chat or automated E-Mails would have prevented this problem. This sort of solution isn't feasible. The employees of Prohashing who could have responded to this particular issue were at Toastmasters and were out of contact at the time of the incident. A communications channel would not have been useful to prevent us from mining the block because nobody would have read the message or answered the phone for two hours. I doubt you could establish a channel where more than 50% of the interested pools and solo miners are, at any given time, awake and not at events that place them out of contact.

In this particular case, even if we had been provided with instant information, and we were able to understand what the problem was and what needed to be done quickly, there wasn't really anything that we could have done anyway. I hadn't programmed a feature in our mining servers to skip a block like this, and it is such a rare circumstance that I don't plan to do so now. There simply wasn't a way to configure the system to respond to the problem with so little notice. The only potential solutions would have been to shut down temporarily or to continue mining Bitcoin Cash, in the hopes of the block not being orphaned. Even if the block would definitely be orphaned, the opportunity cost of buggy miners disconnecting and not reconnecting until their backup pool had disconnected days later would have been higher than the wasted money.

A larger problem with the communication channel suggestion is that this channel would have been just one of many coins' communications channels. The problem isn't a lack of communication, but a lack of a single communications channel for all coins. Not only that, but every coin developer thinks that their project is the most important, so figuring out what messages are urgent would be very difficult. I said I would be willing to pay thousands of dollars a year for a service that announced emergency things like upcoming forks because of this problem, and implored an entrepreneur to create such a service. It could be as simple as an RSS field with a few fields: coin name, deadline for action, and URL that contains the message. I personally can't believe there is no business providing such a service yet. But while such a service would be useful for addressing future issues, it would not help when action needs to be taken now.

To determine what the correct solution is, it's necessary to understand why what happened happened. I'm not convinced of the way that this spending of the segwit address money is being characterized as a "theft" and an "attack." This money was sent to these addresses following the rules as they were defined. In a similar issue on December 26, 2017, we mined a Verge transaction with a tx fee of $180,000. There were some people who suggested we should have refunded that fee, but we could not, because that fee was legally promised to our customers. Some of them devoted enormous amounts of money to mine it.

The way I see it, two pools decided to conduct a 51% attack against the network without consulting anyone else, and this led to consequences such as major exchanges disabling their wallets. Their goal was apparently to "save" these coins that anyone can spend from the "hacker" who mined the first orphaned block. The reason I consider their action an attack is because it obviously wasn't widely supported by users, as otherwise there would have been no surprise and Coinbase would not have locked its wallet in confusion. It's not as if it was an accident that all these blocks were mined around the same time and this happened due to bad luck. They fell two blocks behind the main chain, and probably even started to worry that their action was going to fail because they were falling so far behind.

The problem with "saving" money is that these pool owners believed that they were better qualified to decide what to do with the money than the person who initially spent it. The pools are alleged to have considered all transactions to these addresses as accidental, without considering that other possible reasons for sending money there, like purposely burning coins. Even if we do agree that 100% of the money was accidentally sent, the pools' suggestion to send money back to where it came from doesn't actually resolve the perceived problem, which is correcting mistakes people made. People who deal with customers in this industry all the time will understand that it is possible as much as much of that money was burned or sent to the wrong people as a result of the pools' action. Many people delete wallets that are empty after sending money. Many of the sources of the transfers were automated systems that won't deal with the response. Many people might have the keys somewhere but have no reason to ever check those wallets again to find out money was sent there.

But most importantly, many of the source addresses are exchange addresses. As we have found out through support ticket, the source and destination addresses for a customer's account at an exchange do not usually match. Most of the participants in these discussions don't understand that a majority of users never install a client and simply hold all their money in exchanges. When people send money back where it came from, a rich CEO ends up with a windfall to spend in a new car. It's not an immoral action by the owner; the exchange simply has no way of knowing to whom the money was to intended to be credited.

This is a textbook example of people intending to do the right thing without a lot of thought and evaluation making the problem worse due to unintended consequences. The majority of the money ended up in the hands of exchange owners. Not only did they not accomplish their objective, but they caused money to be lost from other pools, and they disrupted actual commerce by causing exchanges to lock wallets.

But that doesn't make my idea, which would have been to donate all the money to charity, any better. The charity would likely have refused the donation to eliminate liability on the grounds that they didn't make an effort to locate the owners of the money before they spent it. That's why the pools overriding the blockchain was unethical, why my suggestion of what to do would have been unethical, and why the way you would have dealt with the problem would be unethical too. This is what happens when one person, who doesn't have enough knowledge to foresee these consequences as a collection of people would, takes it upon himself to do something "for the good of everyone." The only solution that would not have unintended consequences is to simply allow the network to function as intended.

There's an idea in software development of "sensible defaults." I believe that software should be configured so that it just runs out of the box, and you only change it if you need to. If this outcome was truly desired by the majority of Bitcoin Cash participants, then surely that majority would have had enough sway to get it included in most clients.

Our system simply followed the rules of the daemon and mined according to them. I argue that the Bitcoin ABC developers, who have a large vote in what happens with Bitcoin Cash, should have modified their daemon to return the transactions that should have been mined and to ignore other blocks. They could have added a config value to ignore this default behavior, which a user would manually need to update if desired. Other software could have followed. The default could have been agreed upon well in advance, when there was time for the consequences to be considered and evaluated.

In conclusion, communications channels would not have reached most people on such short notice. Even if such a channel existed, there are so many channels from other coins, and every project thinks that their is the most important, that the message would likely have gone unnoticed by us and many others. If a message had been received, it might not have been clear exactly what was happening, the highly technical nature of the issue would have required time for everyone to understand, and in any case there would not have been enough time to modify software to take action. Even if action were to be taken on such a message, then the result would likely be something undesirable, such as enriching exchange owners because the pools did not have an understanding of actual customer usage patterns. The solution is sensible defaults decided upon well in advance. Sensible defaults would likely result in a carefully considered outcome being achieved, while still allowing those who disagree with the decision to take different action.
Posts: 5
Joined: Sun Oct 29, 2017 1:04 pm

Re: "Sensible defaults" and unintended consequences of the recent orphaned blocks

Post by Mlangford75 » Tue May 21, 2019 2:42 am

BCH would find more support if they dropped "Bitcoin" from the name.
Post Reply