There is a lot of misunderstanding about risk, wallet compatibility, and upgrade pacing, even among many core devs. Let’s focus on some basic aspects of software engineering and risk analysis.
Let’s review some basic engineering attributes of bitcoin.
A Bitcoin transaction is a signed message, an atomic entity. The signature is the proof of message authenticity. Creating a signature — signing a transaction — requires access to private keys.
A Bitcoin block is a container for signed messages.
BBSI, a base block size increase — a change to the container size.
BBSI: Changing the size of the container does not impact signed message integrity or authenticity. Per-message signing code is not changed.
SegWit: Changing the per-message signature does impact signed message integrity and authenticity. Code that touches private keys, money movement is impacted.
BBSI provides a predictable amount of additional capacity (+1M) at a predictable time — flag day.
SegWit does not provide any amount of predictable added capacity, due to the opt-in nature. Range of possibilities include: Little in short term, lots in long term; little to none, ever; lots in the short term.
BBSI: Changing the size of the container is highly compatible with today’s wallets. Many of the most popular wallets, such as copay (bitcore-lib) or Android (bitcoinj), have zero direct sensitivity to block size.
Again, for the cheap seats: Zero wallet changes to take advantage of guaranteed-added capacity, in the case of many SPV wallets. “Just update the underlying node” simple instructions for many others.
SegWit: Changing the per-message signature implies [opt-in] updates to deployed, in the field wallets, sometimes custom forks. Users and businesses face the choice of using current software that is proven working and de-risked, versus new software that touches private keys & message integrity, and imposes new upgrade risks on core money movement systems.
Thus, in the real world, sites may increase capacity with (a) a node upgrade that does not impact private keys and money directly [in the same process memory space], or (b) node upgrades and wallet upgrades that impact per-message integrity.
Sites face a choice of a simple node upgrade that does not impact per-msg integrity and private keys, versus a change that does. At large enterprises, there is literally a legally mandated de-risk’ing process for deploying a wallet upgrade, versus a node upgrade, due to the different risk profiles that involve private key exposure to software change.
The opt-in nature of SegWit is a good thing. It lets sites evaluate their risk on a per-site basis. Sites that can bear more risk upgrade early. Sites with custom wallet library forks, large enterprises will take longer to go through their de-risked production upgrade process. Organic, not forced adoption.
It is factual and within software engineering and infosec norms to observe that many sites upgrading wallets (not nodes!) rapidly to SegWit implies notable holistic (community wide) risk: more sites exposing large swaths of users to per-message integrity changes and thus private key/money risk over a short period of time. Example: 80% of all new-transaction-generators (wallets) upgrading message signing code over a 1–3 month timeframe would be a system-wide risk to bitcoin, versus a node-level upgrade over a similar timeframe.
It is also factual to observe that given the opt-in nature and different risk profiles, the amount of capacity delivered by SegWit alone may be low — at least at first — as it is paced by opt-in upgrades. CTOs and the community at large must plan for a realistic worst-case of little SegWit adoption, therefore, little delivered added capacity. Pragmatic CTOs plan for all paths: little SegWit adoption, strong SegWit adoption, a range in between.
Let’s illustrate all this with a concrete example.
Case studies are useful because we provide field data, not theory. Case studies move beyond the realm of what a user might theoretically do, to what they have committed time, money and other sources to accomplish.
Our scenario begins with a Chinese bitcoin exchange. Broadly speaking to avoid sensitive disclosures, the architecture is ring-fenced: P2P nodes run in a less-secure DMZ zone. The core exchange treasury management software, including a bitcoin hot wallet, runs in a more secure zone. The wallet is based on a custom fork of the bitcoinj library.
In the case of a block size increase, the exchange must
<<>>Perform risk and legal liability reviews
<<>>Upgrade their P2P nodes prior to hard fork
That’s it. The core exchange systems are untouched. Their custom wallet works just fine with a larger base block size.
To enable Segregated Witness support in their systems, the exchange must
<<>> Perform heightened risk and legal liability reviews, because this changes money-handling and private-key-handling software.
<<>> Upgrade P2P nodes
<<>> Wait for upstream open source bitcoinj library to have SegWit support
<<>> Wait for upstream open source bitcoinj library to have production release
<<>> Integrate bitcoinj SegWit updates into exchange’s custom bitcoinj fork
<<>> Perform a full production release test cycle of core money-handling, private-key-handling systems.
<<>> DevOps pushes changes to live system.
There is simply no comparison in risk profiles. A SegWit update at this Chinese exchange has an obviously higher risk profile by all normal scientific standards:
<<>> Transaction signing code changed, vs not
<<>> Money handling code impacted, vs not
<<>> Private key handling code impacted, vs not
<<>> Core financial systems updated, vs not
<<>> Greater total pieces of software updated, vs fewer
<<>> More lines of changed code to audit, vs less
<<>> Greater legal exposure, vs less (due to private keys/money code changing)
The incentive for this exchange is clear: A node upgrade yields a network with added capacity, versus the added engineering/time/risk costs of a wallet upgrade.
In the ideal world, SegWit would see 6–12 months of live money testing on a side chain or altcoin (litecoin!), before being rolled out. But we take the world as it comes to us; BIP91 is active — moving on!
Conclusion
That is why — in my personal opinion — segwit2x is the best path for the community: It adds a good long term foundation for bitcoin — SegWit — but is pragmatic about the range of speeds of an opt-in roll-out that includes message integrity changes.
Changing message container size has a much lower risk profile and delivers provable added capacity to sites in a way that does not require them to upgrade core financial systems.
Base block size increase delivers what users need today, and SegWit secures the foundation for tomorrow.
Note : Information Writer Jeff Garzik
