18
Jan
2018
What the fork?! Bitcoin vs. Bitcoin Cash
I throw caution to the wind and wade into the debate, with neutrality that would impress the Swiss.
I throw caution to the wind and wade into the debate, with neutrality that would impress the Swiss.
Overall your descriptions of the arguments on the block size debate were good quite – especially at summarizing the main points without any blatant mischaracterizations. My main criticism of the podcast is the analogy of bank settlements with gold. The lightning network proposal has a subtle difference in trust. In gold settlements, one bank is a creditor and the other debtor, so the banks are effectively giving each other short-term loans. OR account holder(s) at the debtor bank may to wait several days to receive funds. With Bitcoin, the participants of the network (i.e. the full nodes) are the escrow service, so the bank creditor only has to trust that debtor cannot convince a sizable portion (or at least _all_ influential portions) to ignore the network “rules” that stipulate that the funds are “locked” until some future point in time. And even if the debtor bank convinced enough people to do this, the proof would be recorded in the blockchain for everyone to observe for themselves. So its instant settlement, with no trust in a single party (only a larger group of participants which must be trusted for Bitcoin use already).
——–
The criticisms that the lightning network is putting the power in the hands of small bankers is NOT a technical limitation. The funds sent to the payment channel can only be spent in that payment channel until the “lockout” period ends; if the user sends all of their Bitcoin to a single channel the other party can temporarily block that person from spending any money. The mitigation strategy is to open many of these payment channels to a number of different entities simultaneously. Critics of this design state that in practice there will only be a handful of entities for payment channels (i.e. large hubs like banks). In the past I would have dismissed this argument, but the majority of people seem to be reluctant to provide _any_ resources to the Bitcoin network. However, it is an important to stress that this limitation would primarily due to human behavior.
——–
The variable block size by Bitcoin ABC is probably not a good idea, and a reason to use that system cautiously. Monero (a competing crypto-currency) has a variable block size, but there are rules governing it that all participants enforce. If a miner increases a block size above the recent average, the mining reward (i.e. inflation) must be reduced until the size hits a point where the block is no longer valid. Typically miners only increase the block size if the transactions fees offset the mining reward, so it expands during high demand then contracts typically. I am not a proponent of this design; I think the algorithm adds more unnecessary variables to the attack surface of the network, but it is an interesting strategy because performing an attack may be difficult and costly to attempt anyway.
Bitcoin ABC instead allows for the node operator to configure their own block size. This could create unintentional network forks, and the number of forks depends on the number of unique block size limits AND the mining hashpower behavior. Its not clear to me how proponents of this system think this will play out (I haven’t seen a clear discussion of this), but my best guess is that the expectation is that over the long-term the miners will abandon forks based on the majority of hashpower and the majority of node operators (if every merchant rejects 20+mb blocks, there is no point in mining that fork). In the short-term, this creates some headaches for the users because the forks will have different transaction history. So users could lose funds based solely on the setting of their blocksize limit. It is even more problematic for web or lightweight wallets – those users may not even be aware that a fork has occurred and may have difficultly knowing which side they are on. While this is a poor appeal to authority, Satoshi did recommend against alternative implementations of the software because of the weird behavior caused when consensus diverges.
Increasing the blocksize faster than the relative CPU cost comes with some security risks, in addition to the centralization concern. Full-node operators may elect to disable some of the rule enforcement so that their hardware can achieve higher transaction throughput. The first thing to go is likely the signature checks, which are the most CPU intensive part. If a large portion of the network is not fully validating the transactions, it could lead to unintentional network forks and loss of money. This is obviously speculative, because I cannot predict what other node operators will do to balance their costs. Ethereum might be the first network to test such scenarios.
Despite all of this, I should make clear that people suggesting a block size increase right now are not crazy. Its only the people that insist on targeting low fees that drive me crazy – that is almost certainly going to be a bad idea.
Thanks for the feedback. Can you point me to good intro(s) to Lightning Network that explain why it’s trustless?
I will try to give a quick summary before I find a better resource. It might be difficult to find one that is written clearly and correctly. There is a whitepaper and a series of github RFCs, but they might be a little technical. The lightning network isn’t my “specialty” (at least not right now), so hopefully I do not misspeak myself.
Bitcoin is usually described as a ledger with accounts, but is actually referencing lots. Each lot referenced in a transaction input is “spent” entirely and only once. If the user needs to spend a portion of the lot (make change), the wallet will send funds back to themselves in a new lot/output. Each individual lot/output can have restrictions on how it can be spent. Typically the restriction is based on a single public key or multiple public keys (so called multisig).
A simple payment channel can be opened by creating a lot/output that requires two signatures to be spent OR one signature after some timeout period. The sender of the transaction has not signed over any Bitcoin to the recipient, but can no longer spend the Bitcoins without the receiver signing a transaction, unless the designated timeout period has ended. If the sender signs and provides a transaction to the receiver, the receiver has a valid transaction that pays them whenever they post it to the network/miners. The sender can send more money by creating a new transaction with more Bitcoin to the receiver. Only one of these transactions to the sender can be spent on the blockchain since they reference the same lot/output. So the prior transaction is immediately revoked by Bitcoin network rules (unless the receiver wants less money).
There are several obvious “catches”: (1) the network has to enforce that the single signature case by the sender is invalid until X time in the future, (2) it is technically a “race” among the participants to get included in the blockchain before the other (assuming a malicious sender), (3) the receiver has to keep their software running to ensure the closing transaction is posted with enough time to beat a malicious sender, and (4) the amount provided by the sender can only increase and is exhausted once it reaches the value of the locked Bitcoins. (1) Is probably not worth discussing since Bitcoin could be stolen arbitrarily in that scenario, and (2) can only be mitigated by having longer lockout periods so the receiver has more time to post the transaction. The on-chain fee situation could also be problematic here, but that discussion is a little lengthy. (4) can only be partially mitigated by opening a channel in the other direction, because eventually both sides will have sent the entire channel worth of Bitcoin. Ultimately, (4) is mitigated by schemes that are both clever and hard to describe quickly. I think (3) is still an issue; I saw someone claim a solution on Stackoverflow that was a hack and doesn’t appear to be listed in the Lightning Network RFC (at a glance). Issue (3) might be the other origin to the claim of being like centralized banks, because an obvious solution is to have some other person handle the payment channel stuff for security reasons. It’s no different than someone using a lightweight or web wallet though – those users are offloading the real work of a bank to someone else if they are not running the software. Hopefully it is someone they trust.
I should have also responded to the use of the word trustless. Initially I said it was like settlement without having to trust a single entity. Even that was poor. Users of the lightning network still have to trust network rule enforcement, that their software continues to run until the channel is closed (see above), and that their settlement transactions can be “cleared’ in a timely manner (also see above). They are of course different aspects of trust for the blockchain layer itself.
After thinking about it more, I am a bit pessimistic on the lightning network. Users will eventually want to transmit high value transactions through this process due to fees, then will completely flip out when something goes wrong. I am beginning to feel for bankers a bit, they get no love.
“I am beginning to feel for bankers a bit, they get no love.”
True, but they seem to get by on money.
Flippancy aside, a very useful and informative discussion.
I’m not going to grumble about your poor technical descriptions, because I thought they were reasonable. There’s a few important bits I think you missed out though.
Suppose you go to buy a coffee and you put a few bucks on the table and the barista insists that before taking your money the two of you must discuss the entire history of where those dollars were spent, every other transaction they were involved with, going back not just to when they were printed, but right back to the invention of money. Then he hands back a quarter in change but now insists on discussing every transaction that quarter has ever been involved with. You can see there’s a problem. Even if the two of you are augmented with high power portable computers, there’s still going to be a problem because each quarter in circulation has been involved in a metric shedload of transactions..
Now, let’s look at how banking clearance works. You mentioned (very quickly) the idea of banks having physical gold and settling up by moving physical gold between bank, but there’s important details:
* Just as an example, consider there are a total of only 4 banks of equal size, approx 1/4 of transactions will be inside the same bank and, these require no inter-bank clearance at all, so there’s an immediate gain in terms of avoiding unnecessary escalation to the other banks.
* Even for those transactions that do go inter-bank, the banks only settle on the residual at the end of the day and by far the majority of transactions will cancel out. Thus, even if the clunky gold delivery takes several hours, the single physical delivery might represent a million or more individual transactions from during the working day.
Here’s one more thing to think about: a normal cafe that takes cash notes and gives change in quarters might be doing one transaction every 10 to 20 seconds during a busy period. These go straight to the cash register and get noted up but the banks never see the full transaction list… they only see the total when the cafe owner gathers up the takings, pays out any creditors (rent, coffee beans, electricity, etc) and goes and banks what is left over. Thus, there’s another big gain in terms of avoiding escalation of transactions into the banking system at all because of tiny cash transactions.
You put this all together and you can see why our current system absolutely could not cope even slightly as a simple linear chain of transactions. The data volume is too massive. The only way it is possible to cope with at all is by using hierarchical tiers, where each layer can destroy some information before passing some aggregated totals up to the next layer. Unless cryptos can achieve something equivalent to this, they are not ready to become mainstream payment systems. Scaling up from a 1M block to a 100M block is at best a very temporary stop-gap solution.
The next step in crypto evolution has got to be a tree structure, not a linear list of blocks, and this must include a mechanism for either safely destroying information (best result if that’s possible) or at very least hiding information. Otherwise it’s only going to be highly limited in terms of applicability. No one fully understands how to do this while still maintaining the guarantee that the network doesn’t fall apart.
Yup, its not clear what the strategy would be if Bitcoin were to actually replace the dollar with all on-chain transactions. The adoption rate can easily hit a point where the computing power necessary to validate the transactions is enormously expensive. This is basically the argument that hated smaller blockers like Gregory Maxwell and Peter Todd were making in 2013 – raising the limit might be sensible right now, but what the hell is the long-term plan here? If the system is lucky it can stay within a “sweet spot” of validation cost and user adoption. In the short-term it appears that people are happy to go to other blockchains for various reasons.
On the topic of replaying every transaction since the beginning – the system would be recording $0.50 “tweet tips” on a permanent global ledger! CPU, bandwidth, and disk storage is likely to continue to fall but it still seems insane that someone 25 years from now who wants to validate Bitcoin will have to replay all of those transactions. Someone anonymously posted a solution to this specific issue called “mimblewimble”. The design has several properties different from Bitcoin, one of them that older transactions can be removed from the blockchain without removing the inflation scheduling auditing capability. However, I am hesitant to say that mimblewimble is universally better than the current Bitcoin design.
http://steve-patterson.com/ep-72-real-story-behind-bitcoin-cash-ryan-x-charles/
Some history behind the fork, somewhat sympathetic to the large block perspective but good to listen to. Mix of technical discussion, economic background, and people and personalities involved.