The School of Computer Science at the University of Guelph has partnered with an award-winning startup to revolutionize connectivity across Northern Canada.
The Maple Ridge-based tech company Left has teamed up with the University of Guelph to launch a $2.1 million project with Mitacs to spread Mitacs’ patented mobile mesh network to a wide range of remote communities in Canada.
This is the largest partnership the School of Computer Science has ever undertaken, incorporating “120 graduate student internships over five years, from universities across Canada.” Left and Mitacs are providing the majority of the funding for this project, while the cooperation of universities across Canada will lay the groundwork for an ambitious connectivity project.
Mitacs’ platform, RightMesh, operates as a traditional mesh network for internet connectivity. As University of Guelph Professor Jason Ernst put it, mesh networking “allows people to connect with each other using the Bluetooth, Wi-Fi or Wi-Fi Direct capabilities built into smartphones, even if those phones are currently offline.”
Essentially, devices which are physically able to connect to the internet are able to act as nodes in an ad hoc network, so that individual devices can connect to these nodes, and these nodes can in turn connect to the internet. As long as the Wi-Fi or Bluetooth-enabled devices are connected to a device that is itself connected to the internet, these devices can tap into the internet off of this connection.
Such an ambitious project was made possible through the combined efforts of these tech companies and the participating universities of Canada. As the press report stated, places like “the Inuit community of Rigolet, Nunatsiavut, where climate change has negatively affected food security, health and wellness, and personal safety” will reap some of the largest benefits.
Rigolet was a testing ground for this project in 2017, and Ernst claimed that it showed great promise in “providing life-saving data without dependence on traditional internet.” Even as traditional infrastructure has been wholly unable to provide this community with reliable access to many comforts of life, hooking into RightMesh has enabled free and decentralized internet access without additional costs. Now, this new partnership will improve access in Rigolet and bring access to many other communities in Northern Canada as well.
Dan Ruimy, a member of the Canadian Parliament, believes it is a good sign that Vancouver-based companies are partnering with companies like Left from elsewhere in Western Canada to bring about such wide innovation. “For many years, Vancouver has been the lone driving force of tech innovation in the area,” said MP Ruimy, adding that this is “a project that helps bridge Canada’s digital divide.” With projects like this, tech innovation and tech access can spread across the nation in multiple ways.
This article originally appeared on Bitcoin Magazine.
BitMEX just launched a website to make it easier to keep tabs on hard and soft forks on the Bitcoin blockchain.
The website will monitor many different aspects of the networks and their associated blockchains, with the ultimate goal of keeping track of these variables during forks to be “potentially useful in helping to detect unintentional consensus bugs.”
The article says that BitMEX is launching this new website in anticipation of an upcoming hard fork for Bitcoin Cash, which is expected to take place on November 15, 2018.
BitMEX Research took to Twitter to announce its new tool. In the comment section, the company continued to take shots at Craig Wright, whose infamous claiming of Satoshi Nakamoto’s identity has made him a pariah in the industry, for his part in the November 15 fork.
“[Craig Wright’s] (AKA “Fake Satoshi”) node, Bitcoin SV, is expected to fork off from the network onto a new chain,” the thread reads.
The Twitter thread went on to explicitly state that the focus of Fork Monitor will be to examine Bitcoin’s network, insinuating that the website’s highest priority isn’t necessarily looking to keep precise notes on Bitcoin Cash and its own forks.
Still, the planned date of the BCH hard fork has given BitMEX ample time to build a functional monitoring website that will eventually gather more hard data. At its current stage, Fork Monitor is something of a pilot project, albeit one that “will hopefully provide useful information to some stakeholders” in the future.
This article originally appeared on Bitcoin Magazine.
The Liquid Network is up and running.
More than a year after its conceptual introduction at the Blockchain Association of Canada’s Government Forum in Ottawa, Blockstream’s bitcoin scaling solution made its public debut on October 10, 2018, after going live among its partners on September 27.
Described by its creators as “an inter-exchange settlement network,” Liquid is Blockstream’s complement to Lightning. However, whereas Lightning is designed for micropayments, Blockstream’s COO Samson Mow told Bitcoin Magazine, “Liquid is designed to facilitate fast and reliable high value transfers.”
“Liquid allows parties to send funds to any destination, without the need to establish channels ahead of time. Funds in Lightning are ‘hot’ (private keys are online), whereas you can store Liquid Bitcoin in both hot or cold wallets. Liquid also has the ability to have Lightning added as a second layer as well, so we view these two technologies as complementary and both important for the ecosystem.”
Unlike its counterpart in Lightning, which is a secondary layer, Liquid was built as a Bitcoin sidechain. Though not exclusive to Bitcoin, you can think of a sidechain as an extension of the Bitcoin blockchain. It allows users to swap coins from the main blockchain to its sidechain in a 1-to-1 parity, usually to tap into a feature that the main network doesn’t provide.
For Liquid, that feature is fast transactions with a special emphasis on trading mass sums between exchanges, financiers and market makers. As such, Mow says that exchanges and members of the Liquid network will be the main providers of liquidity, since they will be the ones keeping a balance of L-BTC which, in turn, they would allow their users to swap for.
This design is a bit of a spin on the original ideation of a sidechain. The concept was initially pitched as an avenue for trustless swaps, but Liquid’s iteration, which requires intermediaries to execute these swaps, may be called a federated sidechain.
“The members of Liquid secure the network by running functionary servers that run the Liquid blockchain as well as maintaining the two-way peg to the Bitcoin blockchain,” he said. He drew the comparison that “Liquid functionaries are like miners” who “generate new blocks to add to the Liquid blockchain.”
To leverage sidechain’s features, users have to exchange mainnet BTC for Liquid Network’s L-BTC using peg addresses.
“When someone wants to move BTC to the Liquid sidechain,” Mow explained, “they send it to a unique peg-in address. When someone is ready to move their money back to the Bitcoin blockchain, they can make a peg-out transaction that will tell the [Liquid members] to send Bitcoin to the desired address.”
Upon launch, the project has 23 partners lined up to serve as Liquid members, namely Altonomy, Atlantic Financial, Bitbank, Bitfinex, Bitmax, BitMEX, Bitso, BTCBOX, BTSE, Bull Exchange, DGroup, Coinone, Crypto Garage, GOPAX (operated by Streami), Korbit, L2B Global, OKCoin, The Rock Trading, SIX Digital Exchange, Unocoin, Xapo, XBTO and Zaif.
Moving forward, Liquid hopes to expand its membership and build out its services. These services could include Issued Assets (IA), Mow explained, what amount to “native tokens within the Liquid blockchain.” These IA could be security tokens, tokenized commodities/real-world assets or even Ethereum.
More than IA, Mow stated that Liquid has “a lot of things coming down the pipe” following its launch. These include a Liquid Testnet that is anchored to Blockstream Signet (Blockstream’s testnet for Bitcoin), GreenAddress integration, a Liquid mobile wallet for mobile platforms, a user interface for Issued Assets, a Liquid Block Explorer and hardware wallet support. He expects these features to be fully functioning by 2018, with more coming in 2019.
In the short term, Blockstream will focus on building out these features to ease Liquid’s introduction to and use in the wider cryptocurrency community. In the long term, Mow said the the company hopes to see Bitcoin at the epicenter of a nexus of sidechains that allow for a seamless, interconnected exchange of the industry’s many assets.
“The end game is a platform for the trustless exchange of many assets, with Bitcoin at the center,” said Mow. “We knew that having a high speed inter-exchange settlement network with privacy features would be something the market would respond well towards, but we’ve seen an incredible interest from parties interested to issue tokens and assets on Liquid as well. They’ve just been waiting for a secure and reliable solution to do so.”
This article originally appeared on Bitcoin Magazine.
Today marks the official release of Bitcoin Core 0.17.0, the 17th generation of Bitcoin’s original software client launched by Satoshi Nakamoto almost 10 years ago and still the dominant Bitcoin implementation on the network today. Overseen by Bitcoin Core lead maintainer Wladimir van der Laan, this latest major release was developed by some 135 contributors over a span of about seven months.
The result of well over 700 merged pull requests, Bitcoin Core 0.17.0 includes a range of performance improvements and bug fixes, as well as other changes.
Here’s an overview of some of these changes.
Coins in a wallet are effectively stored as separate chunks (“transaction outputs”). There is typically one chunk for each received payment; therefore, most chunks represent different amounts. When a payment is made from a wallet, different chunks are added together to make up an amount that’s large enough to make the payment, plus the fee. The different chunks often don’t add up to the exact amount needed, however, in which case a “change address” is added to the transaction, sending any leftover funds back to the same wallet.
Up until now, the Bitcoin Core wallet added different chunks together. Only then would it calculate and add the fee required to pay for the transaction. But in some cases, adding the fee to the transaction meant that the added chunks no longer made up a large enough amount, in which case an additional chunk had to be included.
Bitcoin Core 0.17.0 introduces the “Branch and Bound” algorithm designed by BitGo engineer Mark Erhardt. This offers two concrete improvements. First, the fee for each chunk is calculated before it is selected to be part of a transaction in order to avoid new chunks having to be added later. Second, the algorithm tries to match different chunks so they add up to the exact amount needed, avoiding the need for “change addresses” (where the leftover “change” gets sent) where possible. (Big wallets with lots of chunks, like those operated by exchanges or other high-traffic entities, are less likely to need change addresses than other wallets.)
Additionally, the coin selection algorithm in Bitcoin Core 0.17.0 includes an optional privacy improvement.
While it is against best practices, it’s possible to receive multiple payments to the same Bitcoin address. (This happens a lot with donation addresses, for example.) Reusing addresses is bad for privacy in itself as it’s obvious that all the coins on that address and all payments made from that address are from the same user. But it’s even worse when the different chunks tied to the same address are used in different transactions, linking them to chunks that weren’t initially associated with that address.
To fix this last problem, Bitcoin Core 0.17.0 gives users the option to prioritize adding chunks tied to the same address together in a transaction and to leave any other chunks out of the transaction where possible.
Since Bitcoin Core 0.15.0, it’s been possible to create several wallets that operate independently of each other. These wallets all have their own separate Bitcoin addresses, private keys and, therefore, funds. Users can utilize the different wallets for different purposes; for example, one wallet can be used for personal day-to-day purchases, another for business-related transactions, and a third just for trading. This can make accounting easier and more convenient, and users can more easily benefit from increased privacy as the different wallets cannot be linked to each other by blockchain analysis.
However, up until now, new wallets could only be created when starting up the node, and it was not available for Bitcoin Core wallet (GUI) users. Both of these limitations are now resolved. Bitcoin Core 0.17.0 lets users create new wallets whenever they’d like, and it offers this feature in the GUI.
As an added benefit, Bitcoin Core 0.17.0 introduces a feature called “Scantxoutset.” This lets users quickly verify whether their new wallet already includes coins (for example, because the private keys are imported from another wallet) by checking the unspent transaction output (UTXO) set, instead of rescanning the entire transaction history.
Whereas Bitcoin Core versions older than 0.13.0 still required users to back up all their private keys, all Bitcoin Core versions since have offered Hierarchical Deterministic (HD) wallets instead. HD wallet users only need to store one seed phrase (a list of words) as a backup.
However, Bitcoin Core users who upgraded their system to Bitcoin Core 0.13.0 and newer were unable to create new HD wallets. An incompatibility between non-HD wallets and HD wallets meant that these users were still stuck backing up all their private keys.
Bitcoin Core 0.17.0 now lets these users upgrade to the HD format as well. In addition, Bitcoin Core wallet users who already had HD wallets can now opt to generate or import a new HD seed.
Bitcoin wallets typically store private keys, which allow users to spend their coins. But Bitcoin Core has also supported “Watch Only” addresses for some time now. The private keys to these addresses are not stored in the wallet, but coins attached to these addresses are still visible in the wallet. This lets users easily accept payments and keep track of their funds while, for example, storing their private keys offline.
Bitcoin Core 0.17.0 takes this concept one step further and allows users to create specific Watch Only wallets in which every address is a Watch Only address. As a concrete example, this will make it easier to use Bitcoin Core to keep track of funds in a hardware wallet or on a paper wallet in the form of an HD seed.
While many transactions are straightforward — one user pays another — Bitcoin allows for more complex types of transactions as well. These include, for example, multisignature (multisig) transactions where several users need to sign off on sending funds, as well as privacy-enhancing CoinJoin transactions where different users merge their independent transactions into one big transaction.
To better facilitate these types of transactions, Bitcoin Core 0.17.0 introduces the BIP 174 Partially Signed Bitcoin Transaction (PSBT) framework, designed by Andrew Chow. This framework lets Bitcoin Core users sign a transaction partially, but also adds metadata to such a partially signed transaction. This metadata can be used by someone else to complete the transaction.
PSBT will be particularly useful if the standard is adopted by other wallets. As one potential use case, it could, for example, let a user protect his funds by locking them into a multisig account in which a transaction would require a signature created from the Bitcoin Core wallet, as well as a signature from a hardware wallet. Or it could let Bitcoin Core users partake in CoinJoin schemes with (other) privacy-preserving wallet users.
For now, the partially-signed-transaction feature is only for users who operate Bitcoin Core from the command line or through connected applications.
Storing all (on-chain) Bitcoin transactions that ever happened, the Bitcoin blockchain is currently well over 180 gigabytes and growing every day. New Bitcoin Core users must download and validate all this data.
Thanks to a trick called “blockchain pruning,” however, these users do not necessarily need to store all this data. In pruning mode, nodes will automatically forget about older transaction data and keep only what’s necessary to operate securely. Until now, pruning mode could be enabled only through command line.
For the first time, Bitcoin Core 0.17.0 offers a convenient GUI toggle to enable pruning from the wallet, making it more accessible for casual, non-technical Bitcoin users who wish to run a full node for optimal security.
For more details on what’s new in this latest version of Bitcoin Core, see the Bitcoin Core 0.17.0 release notes or watch Chaincode Labs engineer and Bitcoin Core contributor John Newberry’s presentation at the London Bitcoin Devs Meetup.
This article originally appeared on Bitcoin Magazine.
For well over a year, versions of Bitcoin Core — Bitcoin’s leading software implementation — contained a severe software bug. The bug was fixed with Bitcoin Core 0.16.3 (and 0.17.0rc4), released this week, and the status of the Bitcoin network now appears to be safe, with no harm done. The Bitcoin Core project has since released a full disclosure report, revealing that the bug was even worse than previously thought.
These are the good, the bad and the ugly details about one of Bitcoin Core’s nastiest bugs to date. (But not in that order.)
The bad, of course, is the bug itself, now documented as CVE-2018-17144 in the Common Vulnerabilities and Exposures databank.
The bug was introduced as part of a block relay-related performance improvement deployed in Bitcoin Core 0.14.0, officially released in March of 2017. In short, the bug would have nodes fail to reject a block containing a transaction that spends the same coins (“inputs”) multiple times. Indeed, it would allow for an (irregular) form of double-spending: arguably the very thing Bitcoin was designed to prevent.
It posed a serious problem, which could have manifested in several ways.
First, Bitcoin Core versions 0.14.0 through 0.14.2 (and, in some cases, newer versions), would have accepted the block but, at the same time, recognized that something was wrong. However, they wouldn’t be able to tell what was wrong, exactly. As a result, the node would stop operating altogether and shut down. If an invalid block caused by this bug had made its way to such nodes, they would have, in effect, crashed. That’s bad.
But it gets much worse.
Bitcoin Core versions 0.15.0 through 0.16.2 included another performance improvement, making it such that, in some cases, these nodes would no longer have realized something was wrong. Specifically, if the double-spent coin had not been moved in the same block already (which is often the case), these nodes would have accepted the transaction and block as normal. In a hypothetical, worst-case scenario, a malicious miner could have inflated Bitcoin’s money supply by copying his own coins, and anyone relying on Bitcoin Core versions 0.15.0 through 0.16.2 would have accepted these coins as valid.
Technically, the bug could also have caused a blockchain fork between affected nodes (Bitcoin Core 0.15.0 through 0.16.2 and codebase forks of it) and unaffected nodes (most notably Bitcoin Core 0.13.2 and older, as well as some alternative Bitcoin implementations). This is unlikely, however, since the latter category probably doesn’t have sufficient hash power behind it to generate even a single block within a couple of days — let alone several blocks. These nodes would have instead stalled, waiting for a valid block.
Still, the bug in question could have allowed for one of the worst attacks on Bitcoin in years. It’s sobering for many that this bug made it into a release of Bitcoin’s leading software implementation, as well as several codebase forks of it, and remained unnoticed for about 18 months.
Now, the good news.
The first and main piece of good news is that the bug has never been exploited in any way.
The second piece of good news is that it was not very likely the bug would ever have been exploited in the first place. This is because the attack could only have been exploited by a miner intentionally creating an “attack” block — not by a miner doing so by accident and also not by a regular user.
This means that a miner would have had to knowingly risk forfeiting a regular block reward worth some $80,000. An attack like this would have been noticed fairly quickly — everything happens on a public blockchain, while crash reports would probably have flooded chat rooms and forums. At that point, the Bitcoin user base would certainly agree that the added inflation was, in fact, caused by a bug — and should not be accepted as a new protocol rule.
Therefore, like with the bug that caused the value overflow incident in 2010 or the bug that split the Bitcoin network in 2013, a majority of miners (by hash power) would have either upgraded or downgraded their software quickly, rejecting the “attack block” to mine on the “honest chain” instead. As soon as this honest chain overtook the “attack chain,” even vulnerable nodes would have switched to the honest chain and disregarded the attack chain, leaving the attacking miner without any block reward.
Further, coins on the attack chain would presumably have dropped in value rather quickly: Markets are unlikely to value a coin that can be copied “out of thin air” by a malicious miner. As such, this miner would have immediately undermined the value of the same coins being copied, defeating the point of the attack. (Granted, the miner could also make money by shorting the markets, but this still comes with significant risks.)
The third piece of good news is that the bug was responsibly disclosed by an unknown person on Monday to several developers working on Bitcoin Core (as well as Bitcoin Cash implementations Bitcoin ABC and Bitcoin Unlimited). It was originally presented as a denial of service (DoS) bug which, as mentioned, is accurate for Bitcoin Core versions 0.14.0 through 0.14.2. But on further examination, Bitcoin Core contributor and Chaincode Labs employee Matt Corallo found that the same bug was also an inflation vulnerability.
The bug was quickly patched and released on Tuesday in a new Bitcoin Core minor release: Bitcoin Core 0.16.3. The bug is also patched in the fourth and latest release candidate for Bitcoin Core’s upcoming major release, 0.17.0. Meanwhile, the select group of Bitcoin Core contributors that were aware of the bug started reaching out to key players in the Bitcoin ecosystem, most notably miners and large businesses, asking them to upgrade to Bitcoin Core 0.16.3. Regular users were also urged to upgrade.
The fourth piece of good news is that a majority of miners on the network has probably upgraded to get rid of the bug by now. This means that even if an attacker were to try and exploit it, he wouldn’t get very far. The honest miners would overtake the attack chain sooner rather than later, at which point even non-upgraded nodes would accept the honest chain as the only valid chain. To err on the side of safety, users are currently recommended to wait for extra confirmations before accepting a payment, however.
(In technical terms, the effects on the Bitcoin protocol are as follows: Bitcoin Core 0.15.0 introduced an “accidental hard fork” that was never triggered or acted on by miners and, therefore, never led to a blockchain fork. This “hard fork” has practically been undone by an intentional, miner-enforced soft fork over the past couple of days, possibly also enforced by the Bitcoin economy at this point in time.)
The severity of a bug like this can be tricky to deal with on an open, decentralized, continuously operating network, supported by open-source software. As exemplified when Bitcoin Unlimited patched a bug in early 2017, the very act of fixing a vulnerability in the code might reveal it to potential adversaries, opening a window of attack until the fix is widely deployed on nodes in the field.
To avoid such attacks, those Bitcoin Core contributors aware of the problem decided not to make the severity of the bug public right away. Initially omitting some information from miners, companies and the greater public, they opted to disclose the DoS vulnerability — but not the inflation vulnerability. They hoped that the DoS vulnerability (and some strong recommendations) would be enough reason for users to upgrade, without tipping off a potential attacker. A full disclosure would follow later.
However, not everyone shared this approach. As the bug came under the spotlight, more people started to figure out on their own that the bug was more severe than just a DoS vulnerability. It’s rumoured that some started to leak the full extent of the vulnerability, arguably putting the Bitcoin network at greater risk of attack. When the vulnerability was reported on Hacker News (though later retracted), there was little reason to keep it under the covers much longer.
Fortunately, by then, it seemed to the Bitcoin Core contributors in the know that most miners had upgraded, meaning that the Bitcoin network was safe. While sooner than originally planned, the Bitcoin Core project opted to publish the full disclosure by Thursday evening.
A number of altcoins based on Bitcoin’s codebase are possibly still vulnerable to the attack, however, and the fact that the weakness is now publicly known probably does not help. While the leading implementations of the biggest Bitcoin codebase-based cryptocurrencies — most notably Bitcoin Cash’s Bitcoin ABC — deployed fixes and are also safe by now, smaller coins may still be at risk.
Update Saturday, September 22nd: Pseudonymous Bitcoin Unlimited developer “awemany” has come forward as the person who found the bug.
This article originally appeared on Bitcoin Magazine.
Ever since its inception Bitcoin has never really been private. Although Satoshi Nakamoto’s white paper suggests privacy was a design goal of the protocol, government agencies, analytics companies and other interested parties — let’s call them “spies” — have ways to analyze the public blockchain and peer-to-peer network, to cluster Bitcoin addresses and tie them to IP addresses or other identifying information.
A lack of privacy is a problem. Bitcoin users might not necessarily want the world to know where they spend their money, what they earn or how much they own, while businesses may not want to leak transaction details to competitors — to name a few examples. Additionally, a lack of privacy could lead to a loss of fungibility: the property by which each monetary unit is worth the same as any other, which is an essential requirement for money. If, for example, it can be established that certain coins were at some point used for politically sensitive purposes, some might be less willing to accept these “tainted” coins as payment, harming fungibility for all of Bitcoin.
Fortunately, spying on Bitcoin users is becoming increasingly difficult. Recent months in particular saw the introduction of a number of promising, privacy-enhancing technologies, and several more solutions should be released throughout the rest of the year or the next.
Here’s an overview of some of the most promising projects.
Almost two years in the making, TumbleBit was long among the most highly anticipated privacy solutions to be rolled out on Bitcoin.
TumbleBit is a coin-mixing protocol that uses a (centralized) tumbler to create off-chain payment channels between participants in a mixing session. Through these channels, all participants send coins and receive an equal amount of different coins in return. This process breaks the trail of ownership for all: neither spies nor any of the participants can re-establish who paid who. Further, and importantly, TumbleBit utilizes clever cryptographic tricks to ensure that even the tumbler can’t establish a link between the users.
TumbleBit does require two on-chain transactions per participant (one to open a channel, one to close it). While a trustless solution, this does make it one with somewhat higher fees than the alternatives.
TumbleBit was first proposed in 2016 by an academic research team from Boston University, George Mason University and North Carolina State University, headed by Ethan Heilman and presented at Scaling Bitcoin Milan in the fall of that year. The ball really got rolling when NBitcoin developer Nicolas Dorier implemented an early version of the technology, which was later improved by privacy-focused developer Ádám Ficsór and others, to ultimately be implemented in Stratis’ Breeze wallet.
This Breeze wallet was officially released about a month ago, meaning that TumbleBit is currently available for anyone to use — though usage (and, therefore, the privacy-providing anonymity set) is reportedly still low.
ETA: Available now
CoinJoin is an old idea by Bitcoin standards, first proposed by Bitcoin Core contributor Gregory Maxwell in 2013. In essence, the trick is to combine several transactions into one bigger transaction, obfuscating which bitcoins are moving from which sending addresses (“inputs”) to which receiving addresses (“outputs”), exactly.
As a simple example, let’s say Alice, Bob and Carol all want to mix their coins with each other. Using CoinJoin, they can create a transaction that sends money back to themselves, using new addresses not tied to their identity. As long as Alice, Bob and Carol use equal amounts of coins, spies can’t tell which of the new addresses belongs to whom. (If they use different amounts of coins it’s obvious which coins moved where.)
CoinJoin transactions have been a reality for years, but for a long time one problem remained: Someone — like Alice, Bob or Carol — needs to construct the transaction. This person must learn exactly which old addresses are sending bitcoin to which new addresses; otherwise, it would be impossible to construct the transaction. If this person is a spy — which is often impossible to know — the effort becomes pointless: The spy could re-establish the trail of coin ownership.
This problem can also be solved, using a trick mentioned by Gregory Maxwell in the same 2013 proposal, dubbed “Chaumian CoinJoin” (after David Chaum’s blind signature scheme).
In short, Alice, Bob and Carol will now connect to a central Chaumian CoinJoin server, perhaps operated by a wallet provider. First, they all give their sending addresses, as well as blinded (cryptographically scrambled) receiving addresses, which are cryptographically signed by the server. Then, Alice, Bob and Carol disconnect in order to reconnect via a hidden connection (like Tor) and provide their unblinded addresses. Utilizing the magic of Chaumian blind signatures, the server can verify that the unblinded addresses match with the blinded addresses. This allows it to verify that the addresses really belong to Alice, Bob and Carol — not to an attacker — without learning which of the addresses belong to whom.
The Chaumian CoinJoin proposal fell by the wayside for about four years after it was first proposed. Then, about a year ago, Ádám Ficsór — while working on Breeze’s TumbleBit implementation — rediscovered the proposal and decided to implement it.
Embedded in the ZeroLink framework Ficsór has since designed, Chaumian CoinJoin is now implemented in Ficsór’s new privacy-focused Wasabi Wallet, which was recently released in beta. Even more recently, privacy-focused Samourai Wallet announced it will soon release a mobile ZeroLink implementation, called Whirlpool. Yet another, newer wallet by the name of Bob Wallet is also developing a ZeroLink implementation.
ETA: Available now (beta)
While CoinJoin — including Chaumian CoinJoin — was always possible, and first proposed years ago, it’s never caught on in a big way so far. For a long time, no popular wallet offered the feature, which may be because CoinJoin transactions add complexity, with little upside for those who don’t care about privacy as much.
Named after its inventor Claus-Peter Schnorr, Schnorr signatures are considered by many cryptographers to be the best type of cryptographic signatures in the field. Perhaps the biggest concrete advantage for Bitcoin is that multiple signatures can be aggregated into a single signature. This means that one signature can prove ownership of multiple sending addresses (inputs). Therefore, only one signature is ever needed per regular transaction, no matter how many sending addresses (inputs) are included.
CoinJoin transactions, of course, always include multiple sending addresses as well, at least one for each participant and possibly more. Schnorr signatures could, therefore, add a new benefit to using CoinJoin: They enable all participants, not only to combine their transactions into one, but also to combine their signatures in that transaction into one. This would make the CoinJoin transaction smaller in size than the individual transactions combined would have been which, in turn, means that miners should charge a smaller processing fee.
With Schnorr, there would be a cost benefit to using the most private option, which might just provide the right incentive for wallets to implement it and make it the go-to option for everyone.
In addition, Schnorr signatures’ mathematical properties will benefit a brand new class of more complex, smart contract-like solutions with names like “scriptless scripts,” “Taproot” and “Graftroot.” Interestingly, these solutions would appear like regular Bitcoin transactions on the Bitcoin blockchain. This could for example enable futures markets, decentralized exchanges or insurance contracts without spies being able to identify anything but regular-seeming transactions.
ETA: Optimistically, 2019
Another CoinJoin-related privacy measure was introduced by Samourai Wallet in May 2018 as a replacement for a similar but inferior solution. Called STONEWALL, the trick doesn’t actually utilize CoinJoin — but makes it seem that it does.
STONEWALL transactions are, in effect, regular transactions: They send bitcoin from one user to another. However, STONEWALL transactions do something odd: They include an unnecessary number of sending addresses (inputs) and change addresses (outputs). This makes the transaction look a lot like a CoinJoin transaction — a transaction where two people are combining their transactions into one — even though, in reality, it isn’t. (More details here.)
The idea behind STONEWALL is to break (indeed, stonewall) the assumptions that spies presumably make when analyzing the Bitcoin blockchain. If these spies can’t tell for sure whether transactions are really CoinJoin transactions or not, any conclusions based on this transaction data is worthless.
Samourai Wallet will soon also deploy 2-wallet STONEWALL, which are real CoinJoin transactions, shared between two users that trust one another with their privacy.
ETA: Available now; 2-wallet STONEWALL to follow in the next month or two
A very different method to deanonymize Bitcoin users is through analysis of the peer-to-peer network. More specifically, spying nodes could monitor the Bitcoin network to try and find out where transactions originate: The first node to transmit a transaction is probably the one that created it.
Dandelion is a solution proposed by a team of academic researchers from Carnegie Mellon University, the University of Illinois and MIT. It was recently presented at the Building on Bitcoin conference in Lisbon by Carnegie Mellon University professor Giulia Fanti.
The solution counters network analysis by changing how transactions are spread over the peer-to-peer network. Instead of immediately broadcasting and forwarding a new transaction to as many peers as possible, the Dandelion protocol initially sends a new transaction to only one peer node. This node randomly decides whether it also forwards it to only one peer — or not. If forwarded to only one peer, the next node will randomly decide what to do as well. (And so forth.) If not forwarded to only one peer, the node transitions to broadcasting the transaction to as many peers as possible, and all receiving peer nodes follow suit. This should make it significantly harder for spies to pinpoint where a transaction originated.
A version of Dandelion has already been implemented by the research team, and the general proposal has received a positive response within Bitcoin’s development community. As such, it seems likely to be included in an upcoming Bitcoin Core release (though the very next release, 0.17.0, will come too soon).
Another older proposal to limit network analysis is BIP 151, authored by Bitcoin Core maintainer and Shift developer Jonas Schnelli. BIP 151 is a somewhat straightforward solution: It would let Bitcoin nodes encrypt traffic (hence, transaction and block data) between them.
It should be noted, however, that in bare form BIP 151 is no panacea for privacy. For one thing, the Bitcoin blockchain is public anyway, and, more importantly, nodes could connect to and share data with the very same spies they’d prefer to hide from. Still, BIP 151 could be a stepping stone to counter several types of attacks, including attacks on privacy (such as man-in-the-middle attacks).
And even in bare form, the solution is arguably better than nothing. Specifically, particular use cases and scenarios would benefit from peer-to-peer encryption; for example, ISPs or open wifi networks would no longer be able to monitor Bitcoin traffic.
While BIP 151 dropped off the radar a little bit for a year or two after it was first proposed, Schnelli recently picked up the project again and re-drafted an “official” BIP to be discussed and potentially included in Bitcoin Core.
To use Bitcoin without needing to download and verify the entire blockchain, many people use light clients, like mobile wallets. Unfortunately, almost all of these light clients have weak, if any privacy protection. They typically share their addresses with either a central server or a random node on the network, both of which can be spies or be spied on.
Many of the light clients that (effectively) share their addresses with a random node on the network use a trick called Simplified Payment Verification (SPV). These SPV clients typically use “Bloom filters” to request the transactions potentially relevant for them — if there are any. While such a filter will return false positives, which means the SPV client will request more transactions than strictly needed, these are few compared to downloading all transactions.
Unfortunately, SPV wallets do effectively reveal all their addresses to the nodes they request this data from as well. To tackle this problem, Lightning Labs developers Olaoluwa Osuntokun and Alex Akselrod, along with Coinbase developer Jim Posen, proposed a new solution called “compact client-side block filtering.”
Compact client-side block filtering was originally designed for Lightning Labs’ Lightning-focused Neutrino wallet but can be used by regular Bitcoin wallets as well: the Wasabi Wallet already implemented the solution in its beta release.
Compact, client-side block filtering essentially inverts the trick that current SPV wallets use. Instead of SPV wallets requesting transactions relevant to them by creating and sending out a Bloom filter, full nodes create a similar filter. SPV wallets then use this filter to establish that relevant transactions did not happen. If the filter does produce a match, Neutrino fetches the relevant block to see if the match really concerns the exact transaction, instead of a false positive.
Since SPV wallets using compact, client-side block filtering no longer request anything specific from any node, to instead receive a one-size-fits-all filter, they also reveal nothing about their transaction history.
ETA: Available now (beta)
Liquid is the first commercial sidechain developed by blockchain development company Blockstream. Its main purpose is to establish transaction channels between exchanges and other high-volume Bitcoin companies (like brokerages), allowing them to send bitcoin and other assets between them much faster than the Bitcoin blockchain would allow. In the future, regular users (most obviously traders) should be able to access the sidechain too, with special Liquid wallets.
One feature implemented on Liquid is Confidential Transactions (CT). CT is a trick that blinds (hides) the sending and receiving amount(s) in transactions. This is possible because clever cryptography allows math to be performed on the blinded amounts. All Liquid users can verify that the receiving amount(s) did not exceed the sending amount(s). In other words, they can check that no bitcoin was created out of thin air — even if they don’t know exactly how much money changed hands.
In the context of Liquid, this means (among others things) that exchanges can move funds between them without anyone being able to tell how much was moved. The process offers privacy, and competitors will, for example, be unable to tell how much money is held in the exchanges. Meanwhile, traders can no longer use such information to trade on, which is effectively a form of front running possible today due to the public nature of Bitcoin’s blockchain.
As Liquid becomes available to regular traders later on, these users could, most obviously, utilize the protocol to keep their balances hidden from spies, even after withdrawing funds from an exchange to temporarily hold it on the sidechain or move it to a different exchange. In addition, CoinJoin types of solutions could be developed for Liquid wallets, for a particularly powerful combination of privacy technologies. (As several transactions are merged into one and amounts are hidden, establishing links between the addresses becomes virtually impossible.)
Even further out, CT may also be implemented on the main Bitcoin protocol. There are some ideas for how to accomplish this through a backward-compatible soft fork already, but, while technological innovation is advancing, such upgrades would still come with significant detriment for scalability and are probably still far from becoming a reality.
ETA: Available for exchanges and other high-volume Bitcoin companies any day now; regular traders later and mainnet users maybe one day.
Author’s note: This article specifically focuses on new and upcoming privacy technologies; older solutions also include stealth addresses, using a Bitcoin full node as a wallet, Coin Control, JoinMarket and other existing CoinJoin solutions, Ricochet, PayNyms, the Lightning Network’s Spinx, Monero-swapping, centralized mixers (at your own risk) and more.
This cover story was inspired by Ádám Ficsór’s recent tweetstorm on the same topic. Bitcoin Magazine does not endorse any of the products or services mentioned in this article. Always do your own research before sending or storing bitcoin anywhere.
This article originally appeared on Bitcoin Magazine.
In order to make payments on the lightning network — Bitcoin’s second layer solution for instant and cheap transactions — users must first fund lightning channels. This process, however, creates a slight disconnect between lightning users and on-chain users. Lightning users can pay lightning users, and on-chain users can pay on-chain users, but they can’t pay one another directly.
To solve this, “Submarine Swaps” allow users to make trustless transactions between lightning addresses and on-chain addresses in either direction. The technology could be a game changer for both Bitcoin lightning and mainnet users, as it would remove the transaction barriers between them.
“[I] think this makes it a lot more attractive to [run] a lightning-only service,” Submarine Swap’s developer Alex Bosworth told Bitcoin Magazine, as on-chain users wouldn’t beexcluded. “You don’t have to […] worry about including the on-chain people,” he said. “You can outsource that to somebody else, and you don’t have to trust them.”
Using the same cryptographic tricks as those used in the lightning network, Submarine Swaps use a trustless middleman to link a Lightning channel transaction with an on-chain one. This middleman, likely a program called a swap provider, is tasked with settling both the on-chain and off-chain transactions with both users, bridging the gap between Bitcoin’s network and the lightning network.
If one lightning network user wants to send funds to an on-chain user, for example, the middleman will transfer these funds to its own lightning wallet, if (and only if) he sends a transaction with comparable funds on the Bitcoin blockchain to the desired on-chain address. The process works the same in the inverse if an on-chain address wants to send funds to a lightning address.
“There’s lots of different ways it can be used,” Bosworth said. “So let’s say an exchange wants to send to a lightning invoice but it doesn’t have lightning funds, or it doesn’t have a lightning wallet; in that case, it could ask somebody who does have that to assist them, and then they could do so in a way where its locked to their on-chain unit.”
He continued to explain that the feature could ultimately be integrated into wallets, enabling an on-chain client “that doesn’t even know about lightning” to transact with its users.
Bosworth also pointed out that the swap providers could be the one and the same person. “It’s flexible in that respect. So you can have it be either a [third party] or it could even be yourself.”
When asked if the swapping mechanism would want for liquidity, Bosworth said that he believes transaction rewards will incentivize enough users to front their bitcoin for transactions. “[Users] are incentivized by the swap rate to provide liquidity, I think that will attract more liquidity. This is a low risk operation, so I can either have my coins just sit there doing nothing or I can have them available for swaps and generate some revenue,” he stated.
The Submarine Swaps concept was originally conceptualized by Lightning Labs CTO Olaoluwa Osuntokun — though Bosworth came up with the same idea independently. The technology can be applied in various use cases, as Bosworth envisions.
The technology is still in its infancy, as Bosworth explained, and it’s also contingent on the development of existing lightning network applications.
“I’ve started doing tests on mainnet, and you can try testing it out on Submarine Swaps so you can see a swap in action, but there’s lots of stuff to work out and the LND still needs work; they’re working on a major new release, so things are moving along but I wouldn’t say it’s like super safe because not everything is 100 percent yet.”
This article originally appeared on Bitcoin Magazine.
A new way to trade bitcoin and digital currencies is now in the books. SparkSwap is the first crypto exchange to be built on the Lightning Network. It allows users to trade both bitcoin and altcoins in seconds without depositing assets with a third party.
In a blog post, SparkSwap founder Trey Griffith said, “You can trade between different blockchains (currently Bitcoin and Litecoin, with others coming soon), with trades settling in about a second — a transaction time comparable to some of the leading centralized cryptocurrency exchanges.
“In an industry that, at times, seems to value hype and white papers over delivered, working software, we’ve opted for the latter. Our software is in a pre-alpha state, but we’ve successfully used it to execute BTC/LTC trades on the Bitcoin and Litecoin testnets.”
SparkSwap is made up of two primary components. The first is called the Broker and is the software run by users. It interprets user actions and converts them into network actions. It also executes payment channel network swaps and manages user wallets and private keys.
The second component is known as the Relayer, which is software run by staff members. It connects brokers who wish to execute monetary swaps; provides orderbook updates; and mitigates fraud and market manipulation. The Relayer also assists users with agreeing on swap prices and executes trades over payment channel networks like the Lightning Network, which eliminates the need for third parties.
Griffith explains, “With SparkSwap, you no longer need to choose between fast settlement, liquid trading pairs, and maintaining control of your assets. Your assets are no longer exposed to theft or loss by exchanges, either from bad actors or local governments.”
Crypto enthusiasts once believed that the Lightning Network was limited strictly to bitcoin, though this isn’t necessarily the case. For the longest time, bitcoin and altcoin exchanges occurred through processes known as atomic swaps where, if one individual wanted to trade altcoins for bitcoin while another sought to trade bitcoin for altcoins, they could trade by submitting two transactions: one to the bitcoin blockchain and the other to the respective altcoin blockchain.
The bitcoin from the second individual is sent to the first, who can then claim it, granted he reveals a secret number as part of the on-chain claim-transaction. This secret number, in turn, lets the second individual claim the altcoin on its respective blockchain. This prevents fraud from either end, while ensuring each party receives their respective funds.
Even though the process worked, it was also a hassle. The Lightning Network improves on atomic swaps by connecting not two blockchains but two payment channels, which can allow multiple parties to trade back and forth without trusting one another.
The Lightning Network can also be used to send transactions across different blockchain platforms, thereby permitting currencies to change owners off-chain. The result is a trustless environment in which currencies can move about without recording the transactions on specific blockchains.
Speaking with Bitcoin Magazine last year, Litecoin creator Charlie Lee stated, “Previous atomic swaps that I have done were on-chain and had the on-chain limitations of slow [transactions] and high transaction fees. Off-chain atomic swaps are significantly better. They are instant, [have] low fees and better protect one’s privacy.”
Griffith claims that SparkSwap works by utilizing the same trustless processes over the Lightning Network. He also says that while there is still more work to be done, the system is ready for public use, as staff members are eager to witness the community’s reaction and improve upon the technology from there.
“We’d like to be helpful if we can,” he states.
This article originally appeared on Bitcoin Magazine.
The Breeze Wallet with the Breeze Privacy Protocol public mainnet has been released and is now open to the public. The wallet showcases Stratis technology — a platform built for visual basic apps and blockchain solutions — and places heavy emphasis on both privacy and security for businesses seeking to implement business-to-business (B2B) transactions on the Stratis and Bitcoin blockchain networks.
The Breeze Wallet was first scheduled for release in mid-2017. Designed as a bitcoin wallet for desktops, the application would come with TumbleBit — a promising privacy advancement built on top of Bitcoin — and give customers the opportunity to mix their coins without the need to trust one another or the receiving wallets.
Speaking with Bitcoin Magazine last year, Stratis Founder and CEO Chris Trew explained, “We are integrating TumbleBit because it’s a trustless and secure solution that works with Bitcoin without any forks.”
Based in the U.K., Stratis is a startup that offers end-to-end solutions for development, testing and deployment of blockchain applications. Aside from maintaining its own blockchain, Stratis also boasts a native token, the Stratis token, and builds tools for existing blockchains like Ethereum and Bitcoin.
Developers claim the wallet boasts a user-friendly interface, along with what they dub the Masternode Client Discovery protocol, in which the Bitcoin or Stratis blockchain is used to discover, validate and connect to a Stratis Masternode. The process is decentralized and occurs through a trustless environment that is less vulnerable to network disruption.
Users employing the wallet can “obfuscate” transactions, meaning they can render them obscure or unintelligible. This primarily works for ventures or individuals seeking to conduct on-chain business while preventing that business from being viewed by the public. If a company receives regular payments from customers or makes payments to a supplier, this would be deemed commercially sensitive information and would thus be shielded.
Companies can also utilize the wallet to connect to a Stratis Masternode, thereby giving their transactions added protection across both the Bitcoin and Stratis networks. This is primarily done through TumbleBit, which provides anonymity by allowing several people to utilize the same payment channels. The channels are then protected with cryptographic puzzles that prevent any non-users from gaining access to the information they present.
The Breeze Wallet is compatible with Windows 64-bit and 32-bit, along with Mac OS X and Ubuntu. Respective wallet download links are available here.
At press time, Stratis had not responded to Bitcoin Magazine’s request for comment.
This article originally appeared on Bitcoin Magazine.
What’s the best that can happen? That’s the focus of Fetch.ai in the realm of artificial intelligence (AI).
Episode 025 of the What Bitcoin Did podcast featured a wide-ranging conversation between host Peter McCormack and Fetch co-founder/CTO Toby Simpson about both best-case and worst-case outcomes for AI. But it wasn’t all speculation: developments with Fetch in the here and now provided plenty of insight into the ever-increasing interconnection between AI and decentralization.
Fetch, based in Cambridge, U.K., describes itself as “a decentralized digital world in which useful economic activity can take place,” one with an adaptive, self-organizing smart ledger at its core. While not available for a public test just yet, it claims to have a functioning internal system that has brought its plans to life. Within that system, Simpson fondly refers to the virtual “world” that is being incubated. In it, digital entities called Autonomous Economic Agents (AEAs) represent Internet of Things (IoT) machines and work independently of human control, all while connecting to the traditional world through Fetch’s Open Economic Framework (OEF), which provides sensory input to the AEAs.
The concept of an unpermissioned ledger is central to Fetch’s smooth functioning and scalability, and Simpson was quick to point out that their own ledger is designed to pick up where traditional blockchain architecture leaves off, pursuant to their goal of eventually enabling billions of transactions per second.
“We’re all drawing from the ideas of decentralized ledger technologies, and we’re all trying to create and build a system where you can establish that global truth when you never quite know which individual parties you can trust,” he noted. “But we had to do it differently. We had to paralyze [the] blockchain, effectively, so we could get a much larger number of transactions through the system, and we combine that with a bunch of other things in order to increase those volumes even further.”
As Simpson explained, it was this high-volume goal that led Fetch to develop what it sees as a key tenet of its capabilities, which it calls “useful proof of work” (uPoW), a system that consolidates general-purpose computing problems into proof-of-work packages. The end result of its workings will, in theory, lead to a vastly more efficient distributed computing platform that can support a more stable ledger capable of achieving the massive scale Fetch envisions (this is outlined in greater detail in the Fetch.ai white paper).
“You’ve got the Bitcoin network, and the Ethereum network, and you look at the huge amount of computing power that that has,” Simpson said. “You’re talking supercomputers over supercomputers over supercomputers. Wouldn’t it be cool to be able to do something useful with that, for the benefit of their network and the users of the network? For us, this was originally about a sort of giant Tetris game, really, where you’re trying to figure out which transactions don’t collide with each other and don’t share resources, because you execute those in parallel.”
If Fetch is able to execute its plan, Simpson hopes it won’t just be a triumph for the firm he co-founded, but also a redemption of sorts for the negative environmental impact that blockchain technology has borne.
“There’s a lot of people talking about it’s a huge waste of energy — it could possibly go down as the biggest waste of energy of all time,” Simpson said. “You think, ‘Well, if we’re doing something useful with it, then it’s not anymore!’ Then we’ve got the globe’s largest supercomputer, and we’re doing stuff with it.”
Nonprofit organization PoWx has launched this week with the goal of boosting the idea behind proof of work (PoW) through more innovative algorithms. The company is seeking to decentralize Bitcoin mining and make it more accessible to consumers through a new technology that executives have dubbed “optical PoW” — a new type of hardware that utilizes a more advanced and energy-efficient form of laser technology as the cornerstone of mining.
Bitcoin and cryptocurrency mining is usually off limits to those who cannot afford the expensive mining computers and equipment. In addition, miners are usually stuck dealing with high energy bills and excessive consumption of electricity. It is estimated that approximately 0.15 percent of the world’s energy is used to mine cryptocurrency.
This is where optical PoW comes into play. PoWx founder Michael Dubrovsky says the technology can alter Bitcoin’s current algorithm to make mining more decentralized and that the software’s advancements could make the mining arena “healthy enough and scalable enough.”
The idea for optical PoW arose last year. Dubrovsky says concern was growing that the mining space would eventually become more centralized. Dubrovsky and the PoWx team specifically point their fingers at Bitmain, the Chinese mining giant largely responsible for building and supplying most of the necessary equipment to power Bitcoin mining.
Speaking with Bitcoin Magazine, Bitcoin Core and Bitcoin Knots developer Luke Dashjr said he’s all for optical PoW and believes the mining scene as it stands could damage the future of cryptocurrency.
“Bitmain has compromised Bitcoin’s security, so changing to a new proof-of-work algorithm is necessary to secure the network again,” he commented. “One problem that enables mining centralization is that electricity costs are lower for large corporations than they are for ordinary users. Optical PoW claims it can eliminate this problem, and since it is an entirely new kind of technology, it also eliminates almost all of Bitmain’s advantages in trying to monopolize a new algorithm.”
If the new algorithm passes, mining chips could become less expensive, thereby potentially increasing the level of decentralization. In addition, optical PoW would make mining more efficient, which would allow miners to extract more coins in less time, giving them the opportunity to compensate for respective energy usage.
Unfortunately, PoWx still has several obstacles to overcome, the biggest one being a lack of funding. At press time, the company is garnering very little monetary assistance.
Furthermore, switching Bitcoin’s current proof-of-work algorithm won’t be easy. Every user will be required to update their own software, and in the end, it will be up to the public to either accept or reject the idea. Granted several users dismiss it or decide it’s not in their best interest, Bitcoin may “split” again as it did several times before, which has resulted in the creation of Bitcoin Cash, Bitcoin Gold and other so-called “forkcoins.”
Dashjr believes this could cause several hurdles. “Any PoW change requires consensus from the entire community, and thus far, it doesn’t seem probable that we will achieve that, in large part due to FUD [Fear, Uncertainty and Doubt] spread by miners who make it sound more dramatic than the simple change it really is,” he claims. “The community will need to overcome these unwarranted fears before Bitcoin can successfully migrate to a new algorithm.”
However, the company’s long-term goals remain ambitious. Dubrovsky estimates the release date of optical PoW to be early 2019. PoWx is also seeking to build a second company — Arrakis Photonics — that will put the hardware into practice.
All Cypherpunks value privacy; it’s basically the founding principle of the collective of cryptographers, academics, developers and activists grouped around the 1990s mailing list by the same name. But few put it in practice like Wei Dai does. Once described as an “intensely private computer engineer” by the New York Times, not many personal details are known about the man who, two decades ago, dreamed up an electronic cash system intriguingly similar to Bitcoin.
This lack of personal details is made up for by Wei Dai’s work and proliferation of ideas. A talented cryptographer, Dai created and still maintains Crypto++: a C++ library for cryptographic algorithms. Dai is also, to this day, active on rationality forums like LessWrong, where he philosophizes on such topics as artificial intelligence, ethics, epistemology and more. His insights earned him the praise of well-known AI researcher Eliezer Yudkowsky and repeated invitations to speak at his Machine Intelligence Research Institute (MIRI; previously known as the Singularity Institute).
Dai’s interest in philosophy and politics is nothing new. Back in the 1990s, as a young bachelor student in computer science at Washington University, his curiosity led him to the writings of Timothy May, one of the “founding fathers” of the Cypherpunk movement. Dai was inspired by the crypto-anarchy May advocated; the brand-new ideology prevalent amongst Cypherpunks based on the conviction that cryptography and software could provide and safeguard political and economic freedom better than any system of government would.
“I am fascinated by Tim May’s crypto-anarchy,” Dai wrote in 1998. “Unlike the communities traditionally associated with the word ‘anarchy’, in a crypto-anarchy the government is not temporarily destroyed but permanently forbidden and permanently unnecessary. It’s a community where the threat of violence is impotent because violence is impossible, and violence is impossible because its participants cannot be linked to their true names or physical locations.”
By the mid-1990s, Dai engaged in discussions on various topics on the Cypherpunks mailing list such as digital reputation systems, game theory, privacy and anonymity in digital cash systems. Perhaps more importantly, Dai made a number of proposals to further the Cypherpunk cause, including trusted timestamping, an encrypted TCP tunneler, a secure file sharing system and more. It garnered him a reputation as a prolific contributor to the Cypherpunk community — though, even back then, no one knew much about him personally. (Not even whether Dai was male or female, Timothy May recently said.)
But Dai would become best known for an idea he casually announced in November 1998, just after graduating from university. “Efficient cooperation requires a medium of exchange (money) and a way to enforce contracts,” Dai explained. “The protocol proposed in this article allows untraceable pseudonymous entities to cooperate with each other more efficiently, by providing them with a medium of exchange and a method of enforcing contracts. […] I hope this is a step toward making crypto-anarchy a practical as well as theoretical possibility.”
He called his proposal “b-money”.
Typical digital money systems use a central ledger to keep track of account balances. Whether it’s a central bank, a commercial bank, VISA or any other payment provider, a centrally-controlled database somewhere tracks who owns what.
The problem with this solution, from Dai’s and the crypto-anarchist perspective, is that it ultimately lets governments control the flow of money through regulation, while participants in the system are usually required to identify themselves. “My motivation for b-money was to enable online economies that are purely voluntary … ones that couldn’t be taxed or regulated through the threat of force,” he later explained.
So, Dai came up with an alternative solution. Or really, two alternative solutions.
In the first solution, instead of a central entity controlling the ledger, all participants maintain separate copies of the same ledger. Any time a new transaction is made, everyone updates their records. These ledgers, furthermore, would consist of public keys, with amounts attached to them — no real names. This decentralized approach would prevent any single entity from blocking transactions, while offering a level of privacy to all users.
As a quick example, let’s say Alice and Bob are b-money users. They both have a public key: Alice has public key “A” and Bob has public key “B”, for which they both control their unique private keys. And, as recorded in the ledgers maintained by all users, both their public keys hold b-money units; let’s say three units each.
If Bob wants to receive two b-money units from Alice (because he’s selling her a product), he sends her his public key: B. Assuming Alice wants to buy the product, she then creates a transaction in the form of a message: “2 b-money from A to B.” Next, she signs this message, with her private key corresponding to A. The message and the cryptographic signature is then sent to all b-money users.
The signed message proves to all b-money users that the rightful owner of A wants to send two b-money units to B. Everyone, therefore, updates their ledgers, now attributing a total of one b-money unit to A and a total of five b-money units to B — without learning that Alice or Bob control either.
If this solution sounds familiar, it should: It’s roughly how, 10 years later, Satoshi Nakamoto designed Bitcoin.
Dai considered his first b-money solution impractical, however, “because it makes heavy use of a synchronous and unjammable anonymous broadcast channel,” he explained in his proposal.
Put differently, the first b-money proposal didn’t solve the double-spending problem. Alice could send two b-money units to both Bob’s B and to Carol’s C at the same time, transmitting these transactions to different parts of the network. Both Bob and Carol would give Alice a product in return … only to later find out that half of the network won’t acknowledge their new balances.
That’s why Dai came up with a second b-money solution, all in the same proposal.
In this version, not everyone maintains a version of the ledger. Instead, the system would consist of two types of users: regular users and “servers.” Only the servers, linked through a Usenet-style broadcast network, would maintain the b-money ledgers. To verify that a transaction went through like it should, regular users — like Bob and Carol — would have to verify it with a random subset of these servers. (In case of a conflict, Bob and Carol would presumably reject the transaction from Alice and not sell her anything.)
While not detailed in the proposal, anyone would probably have been able to become a server, but “each server is required to deposit a certain amount of money in a special account to be used as potential fines or rewards for proof of misconduct,” Dai proposed. The servers should also periodically publish and cryptographically commit to ownership databases.
“Each participant should verify that his own account balances are correct and that the sum of the account balances is not greater than the total amount of money created,” Dai envisioned. “This prevents the servers, even in total collusion, from permanently and costlessly expanding the money supply.”
If this sounds somewhat familiar as well, that’s no wonder either: Dai’s second b-money proposal loosely resembles what would today be called a proof-of-stake system.
To boot, Dai added an early version of a smart contract solution to his proposal(s). These types of smart contracts most closely resemble a mixture of a proof-of-stake system and an arbitration system, where both parties to a contract and an arbitrator must all deposit funds in a special account. Curiously for modern standards, however, these contracts did not have a dispute resolution system encoded: Instead it was possible that, in case of disputes, different users (or servers) would adjust their own ledgers differently, in effect leaving the state of ledgers on the network out of consensus. (Presumably, the potential penalties would make the cost of cheating too high to risk it.)
Yet, where b-money would have perhaps differed most sharply from Bitcoin was Dai’s proposed monetary policy.
Bitcoin’s monetary policy is of course very straightforward. To bring coins in circulation, it initially issued 50 new bitcoins per block, a number which has since dropped to 12.5. This number will continue to decrease over time until, some hundred years from now, the total amount of bitcoin issued caps out at slightly below 21 million. Whether or not such a monetary policy is ideal has been a subject of debate, but one thing is clear: So far it has not produced a stable coin value.
In contrast, a stable coin value was explicitly part of Dai’s vision. To achieve this, the value of b-money was to be coupled to the value of a (theoretical) basket of goods. For example, 100 b-money units would be worth one basket of goods. This should give b-money a stable value, at least in relation to this basket of goods: the same 100 b-money units would buy the same basket of goods in the past, in the present and in the future.
To issue new coins, users were to determine what a basket of goods would cost relative to a solution to a computational problem: a “proof of work.” If, for example, a basket of goods should cost $80 at specific point in time, it would have to be matched by a proof of work that would on average cost $80 to produce. If, 10 years later, the same basket of goods were to cost $120, the same 100 units would have to be matched with a proof of work that’d cost $120 to produce.
Using this indicator, the first person to produce a valid proof of work would be credited 100 new b-money by all users or the servers. Therefore, no one would be particularly incentivized to produce proofs of work unless they intended to use b-money, limiting inflation to the growth of the “b-money economy.”
Alternatively, in an appendix to his proposal, Dai suggested that money creation could be realized through an auction. Either all users (first protocol) or the servers (second protocol) would first have to determine an optimal increase of the monetary base. Then, if this ideal increase were to be established at 500 b-money units, for example, an auction would determine who should create these 500 units: whoever was willing and able to provide the most proof of work for it.
B-money was never implemented. It couldn’t have been: “b-money wasn’t a complete practical design yet,” Dai acknowledged in a LessWrong forum thread a couple of years ago. What’s more, Dai did not expect b-money to take off in a big way, even if it was implemented.
“I think b-money will at most be a niche currency/contract enforcement mechanism, serving those who don’t want to or can’t use government sponsored ones,” he explained in an email following his announcement on the Cypherpunks mailing list.
Indeed, several of b-money’s problems remained unsolved or at least under-specified. Perhaps, most importantly, its consensus model was not very robust, as best shown by Dai’s proposed smart contract solution. It has since also been found that proof-of-stake systems introduce new challenges that Dai may not have foreseen; for example, it’s not clear how “misconduct” can be objectively established. And that doesn’t even get into the more nuanced problems of the proposal, such as a lack of privacy due to traceability of funds or potential coin issuance (“mining”) centralization. Indeed, some of these problems are still not solved for Bitcoin today.
Dai — who after proposing b-money went on to work for TerraSciences and Microsoft, and may have retired early on since then — would not stick around to solve these problems.
“I didn’t continue to work on the design because I had actually grown somewhat disillusioned with crypto-anarchy by the time I finished writing up b-money,” Dai later explained on LessWrong. He reiterated, “I didn’t foresee that a system like it, once implemented, could attract so much attention and use beyond a small group of hardcore Cypherpunks.”
Yet, Dai’s proposal was not forgotten: b-money ended up as the first reference in the Bitcoin white paper. Still, as similar as b-money and Bitcoin’s designs may be, it’s possible that Satoshi Nakamoto was not inspired by Dai’s idea at all. Dai himself believes that Bitcoin’s inventor came up with the idea independently.
Shortly before publishing the Bitcoin white paper, Hashcash inventor Dr. Adam Back directed Satoshi Nakamoto to Dai’s work, making Dai one of few people Bitcoin’s inventor personally reached out to before publishing his white paper. But Dai did not respond to Satoshi’s email. In retrospect, he wished he had. Unsurprisingly, Dai questions Bitcoin’s coin generation model.
“I would consider Bitcoin to have failed with regard to its monetary policy (because the policy causes high price volatility which imposes a heavy cost on its users, who have to either take undesirable risks or engage in costly hedging in order to use the currency),” he wrote on LessWrong. “[O]ne possible impact of Bitcoin might be that due to its deficient monetary policy and associated price volatility it can’t grow to very large scales, and by taking over the cryptocurrency niche, it has precluded a future where a cryptocurrency does grow to very large scales.”
He added, “This may have been partially my fault because when Satoshi wrote to me asking for comments on his draft paper, I never got back to him. Otherwise perhaps I could have dissuaded him (or them) from the ‘fixed supply of money’ idea.”
This is the third installment in Bitcoin Magazine’s The Genesis Files series. The first two articles covered Dr. David Chaum’s eCash and Dr. Adam Back’s Hashcash. For more from Wei Dai, visit weidai.com.
The shift has already started; finance is moving onto the blockchain, leveraging the decentralization and disintermediation benefits of the technology’s architecture.
Assets of all kinds are being moved to the blockchain, creating a more efficient and economical system for the transfer of value, and management of fractional ownership. This migration isn’t just disrupting the existing financial system, it’s democratizing access to growth capital across the world.
Today, security for much of the blockchain community relies on an outdated hash algorithm standard (SHA-2), one not best suited to the needs of the demanding financial markets. Existing chains will eventually need to upgrade to what our team has determined to be the best-in-class cryptographic hash function, SHA-3, but new blockchains should implement it now.
These are the very early days of putting securities on the blockchain. As leaders in crypto-securities and blockchain technologies for the capital markets, we must be thoughtful about how we facilitate this transfer of assets; we must ensure that we operate in such a way that lays the groundwork for long-term security and sets a standard for industry best practices. Implementing the best-in-class cryptographic hash function, Secure Hash Algorithm-3 (SHA-3), serves this mission.
Blockchain technology is disrupting the data management industry. Peer-to-peer networks have promoted the use of cryptography, creating a growing demand in data security and transparency solutions.
A cryptographic hash function is an algorithm that employs mathematics to create a unique digital fingerprint of alphanumeric characters of a fixed size, given an input document of unknown size. This makes the task of comparing the authenticity of a document with an original very simple: Instead of having to read both documents in detail, we can simply compare the much smaller digital fingerprint produced by the hash function.
In peer-to-peer networks, hash functions help secure transaction data by generating a unique digital fingerprint for each transaction. Transaction hashes are organized into a Merkle tree (a.k.a. a hash tree) to help validate the authenticity and relationship of each transaction stored on the blockchain.
The SHA-3 hash function is also used at the block level to generate a proof-of-work challenge that becomes the target for miners seeking to create the next block on the blockchain. This challenge is an important part of how the network maintains its integrity and reaches a decentralized consensus. Cryptocurrency is awarded to the miner that successfully calculates a SHA-3 hash that matches the requirements specified in the proof-of-work challenge.
While blockchain technology is the clear way forward for industry early adopters, within traditional finance there remain concerns about corporate and enterprise application. Serving these needs, and thus bringing the blockchain solution to the mainstream, will depend on how blockchains are architected to protect client data from network interference or manipulation. As a significant component of the architecture, the right hash function can determine enterprise-level operability.
As a hash standard providing certified security over users’ private keys as well as high speed, hardware-based encryption, SHA-3 best suits the needs of tomorrow’s capital markets. SHA-3 has the right characteristics to instill confidence in a peer-to-peer network that does not rely on centralized intermediaries for authority or governance.
Unlike the hash function of Bitcoin and other blockchains based on SHA 256, SHA-3 was developed by community collaboration via the National Institute of Standards and Technology (NIST), forcing different perspectives and issues to be addressed. This meant that the hash function had to endure public scrutiny and exhaustive testing in order to be considered the hashing standard, which it hs now become. In 2015, NIST released SHA-3 as its standard for “securing the integrity of electronic information.”
A subset of Keccak, SHA-3 cryptography is built on sponge construction, a particular method of “absorbing” data in and then “squeezing” it out. Unlike other cryptographic hash functions, sponge construction allows for the input and output of any amount of data, extending the output function and making for greater flexibility of use.
One outdated concern weighed against SHA-3 is a slower hashing speed than its predecessors. This is fair, but only with regards to software. When it comes to hardware, SHA-3 easily outpaces SHA-1 and SHA-2, and hashing is increasingly occurring within hardware components. The third in a series, SHA-3 is remarkably different from its first and second iterations which share some of the same math and cryptographic structure (MD5).
We have the opportunity to take what we’ve learned from today’s most prominent blockchains and create an iteration of the technology that leverages what works and meets our business needs for capital markets.
Building a new, dedicated cryptosecurity blockchain allows for customization and transparency that can better serve the needs of the future. Following the Federal Information Processing Standard (FIPS), SHA-3 is best suited to industry use with a hashrate “an order of magnitude higher than SHA-2,” as pointed out by the Keccak team.
After our own recent survey of hash algorithm candidates, including Equihash, Cuckoo Cycle and Ethash, we concluded that SHA-3 genuinely best serves the needs of capital markets. The survey looked at method of operation, work independency, ASIC optimization or resistance, difficulty control, algorithms, security and speed. Of the candidates, SHA-3 proved to be best-in-class, providing certified security and establishing trust in a network supporting global securities issuance, trading, and clearing and settlement.
Still nascent in its expansion, the blockchain industry as a whole is showing signs of maturity.
Continued volatility in the valuation of cryptocurrencies has proven to be too much for people looking for quick crypto profits. Token price does not faze those who “hodl” with a vision to build better tools and networks for a better future. And while volatility has helped to reduce some of the hysteria around cryptocurrency, there is a growing community looking for greater sophistication from industry participants. “Buidl,” a direct homage to “hodl,” is a movement focusing on development over cryptocurrencies. “Buidl” encourages teams to examine how blockchain technology can best support needed societal change versus quick, frivolous application. Thoughtful infrastructure is the way forward.
When it comes to capital markets, it should not be a race to move assets onto the blockchain, but a strategic process that makes it easy for new market participants to access growth capital and for existing participants to leverage the full benefits of distributed ledger technology. Employing the best-in-class cryptographic hash function serves this mission and empowers trust in a trustless system.
This is an opinion piece by Kiarash Narimani, Ph.D., Development Director at Equibit Group. View expressed are his own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
It’s time to move past the inefficiency of antiquated organizational structures, and blockchains are the key. So say the creators of DAOstack, a solution that’s designed to intuitively move people into systems of decentralized governance and away from the traditional top-down hierarchies that predominate the planet today.
DAOstack CEO Matan Field was the featured guest on Episode #237 of Epicenter, joining hosts Brian Fabian Crain and Sébastien Couture for a deep dive into his personal journey with, and considerable ambitions for, the company he co-founded. It’s the second act in the world of Decentralized Autonomous Organization (DAO) design for this theoretical physicist, who originally set out to combine the blockchain and decentralization with the short-lived company Backfeed.
Realizing in the midst of Backfeed that both a technological partner and a revised focus were necessary, the company stopped operations. Field hit reset, and the result was DAOstack, a platform for decentralized governance which allows collectives to self-organize, gathering with relative ease and efficiency over their shared goals and values.
In conversation with Crain and Couture, Field described how the primary appeal of DAOstack crystallizes around its concept as a “WordPress for DAOs.”
Evolved from open-source origins, WordPress provides website creators with a set of backend tools that make it relatively simple to design, launch and grow an extremely wide array of websites, from simple blogging to full-blown media portals and e-commerce operations.
Thousands of plugins and themes are available to further customize a WordPress site and make it suit an individual organization’s unique needs.
“When I say that you establish and operate a DAO easily, like you would a blog in WordPress,” Field says in the interview, “the meaning is that you have a framework of rules for coordination of people. If I want to establish a new DAO with its own rules, its own governance protocol, I don’t have to code that from scratch.”
The idea that this WordPress workflow can be applied to enabling DAOs is compelling, to say the least. It makes the massive challenge of taking on ancient systems of hierarchical management seem achievable, even user-friendly. That’s key if Fields’ vision of enabling decentralized infrastructures — for everything from governments to hedge funds, insurance companies, coding collectives and climate change warriors — is going to see significant adoption.
Need a use case of a deployment where the user-friendly DAOstack can make a positive impact? Field provides one with the Ethereum project itself which, in his estimation, has abundant financial and human capital (in the form of thousands of developers).
“So what is the limiting factor in producing solutions? Why haven’t we solved the scalability problem?” he posits. “The actual answer is the decision-making capacity to wisely deploy capital into human capital and produce solutions. That’s exactly the role for Alchemy: decentralizing the decision-making function, so that people can get into the system, and they can make any proposal to use funds. People can vote on a proposal and produce decisions in large numbers, effectively.”
The rollout of DAOstack took another step with the public sale in May of GEN, which is the native crypto token of DAOstack’s ecosystem. Meanwhile, there is a Q3 2018 release scheduled for the GENESIS DAO, which will be open to public participation as it marks the first DAO created using this stack.
How will it fare? Doubtless, Field and his colleagues will patiently be on pins and needles as they watch it unfold, informed as they were by their Backfeed experience which showed them that infrastructures require time to evolve.
No matter how it pans out, however, his experiment bears out a truth noted by Crain at the podcast’s conclusion: “Finding new ways of collaborating, organizing and building structures and organizational systems is one of the most exciting aspects of blockchain.”
[ANNOUNCE] hash cash postage implementation
The date is March 28, 1997, when the 2,000-or-so subscribers of the Cypherpunks mailing list receive an email with the above header in their inbox. The sender is a 26-year-old British postdoc at the University of Exeter, a young cryptographer and prolific contributor to the mailing list named Dr. Adam Back. The email includes a description and early implementation of what he describes as a “partial hash collision based postage scheme” — a sort of stamp equivalent for emails, based on a nifty cryptographic trick.
“The idea of using partial hashes is that they can be made arbitrarily expensive to compute,” wrote Back, explaining the advantage of his system, “and yet can be verified instantly.”
This proposal by the cryptographer who would go on to become the current Blockstream CEO did not immediately garner much attention on the email list; just one reader responded, with a technical inquiry about the hashing algorithm of choice. Yet, the technology underlying Hashcash — proof of work — would shape research into digital money for more than a decade to come.
Back’s Hashcash was actually not the first solution of its kind.
By the early 1990s, the promise of the internet, and the advantages of an electronic mailing system in particular, had become obvious to techies paying attention. Still, internet pioneers of the day came to realize that email, as this electronic mailing system was called, presented its own challenges.
“In particular, the easy and low cost of sending electronic mail, and in particular the simplicity of sending the same message to many parties, all but invite abuse,” IBM researchers Dr. Cynthia Dwork and Dr. Moni Naor explained in their 1992 white paper bearing the name “Pricing via Processing or Combatting Junk Mail.”
Indeed, as email rose in popularity, so did spam.
A solution was needed, early internet users agreed — and a solution is what Dwork and Naor’s paper offered.
The duo proposed a system where senders would have to attach some data to any email they send. This data would be the solution to a math problem, unique to the email in question. Specifically, Dwork and Naor proposed three candidate puzzles that could be used for the purpose, all based on public-key cryptography and signature schemes.
Adding a solution to an email wouldn’t be too difficult, ideally requiring only a couple of seconds of processing power from a regular computer, while its validity could easily be checked by the recipient. But, and this is the trick, even a trivial amount of processing power per email adds up for advertisers, scammers and hackers trying to send thousands or even millions of messages at once. Spamming, so was the theory, could be made expensive and, therefore, unprofitable.
“The main idea is to require a user to compute a moderately hard, but not intractable, function in order to gain access to the resource, thus preventing frivolous use,” Dwork and Naor explained.
While Dwork and Naor did not propose the term, the type of solution they introduced would become known as a “proof of work” system. Users would have to literally show that their computer performed work, to prove that they spent real-world resources.
A nifty solution, but perhaps too far ahead of its time. The proposal never made it very far beyond a relatively small circle of computer scientists.
Around the same time that Dwork and Naor published their white paper, a group of privacy activists with a libertarian bent came to recognize the enormous potential of the internet as well. The ideologically driven crowd started to organize through a mailing list centred around privacy-enhancing technologies. Like Dwork and Naor, these “Cypherpunks” — as they would come to be called — utilized the relatively new science of cryptography to work toward their goals.
Over the years, Adam Back — who earned his Ph.D. in 1996 — established himself as one of the more active participants on this list, at times contributing dozens of emails in a single month. Like most Cypherpunks, the cryptographer was passionate about topics including privacy, free speech and libertarianism, and engaged in technical discussions pertaining to anonymous remailers, encrypted file systems, electronic cash as introduced by Dr. David Chaum, and more.
But for a while, Back was perhaps best known for printing and selling “munition” shirts: T-shirts with an encryption protocol printed on them, intended to help point out the absurd decision by the U.S. government to regulate Phil Zimmermann’s PGP (Pretty Good Privacy) encryption program as “munitions” within the definition of the U.S. export regulations. Wearing Back’s shirt while crossing the border to exit the United States technically made you a “munitions exporter.”
Like many, Back was not aware of Dwork and Naor’s proof-of-work proposal. But by the mid-1990s, he was thinking of similar ideas to counter spam, sometimes “out loud” on the Cypherpunks mailing list.
“A side benefit of using PGP, is that PGP encryption should add some overhead to the spammer — he can probably encrypt less messages per second than he can spam down a T3 link,” Back commented, for example, in the context of adding more privacy to remailers; an idea somewhat similar to Dwork and Naor’s.
The Cypherpunks mailing list grew significantly in about half a decade. What started out as an online discussion platform for a group of people that initially gathered at one of their startups in the Bay Area became a small internet phenomenon with thousands of subscribers — and often more emails on a single day than anyone could reasonably keep track of.
It was around this time — 1997, close to the list’s peak popularity — that Back submitted his Hashcash proposal.
Hashcah is similar to Dwork and Naor’s anti-spam proposal and has the same purpose, though Back proposed some additional use cases like countering anonymous remailer abuse. But as the name suggests, Hashcash was not based on cryptographic puzzles like Dwork and Naor’s; it was based on hashing.
Hashing is a cryptographic trick that takes any data — whether it’s a single letter or an entire book — and turns it into a seemingly random number of predetermined length.
For example, a SHA-256 hash of the sentence This is a sentence produces this hexadecimal number:
Which can be “translated” to the regular decimal number:
Or to binary:
Meanwhile, a SHA-256 hash of the sentence This, is a sentence produces this hexadecimal number:
As you can see, merely inserting one comma into the sentence completely changes the hash. And, importantly, what the hash of either sentence would be was completely unpredictable; even after the first sentence was hashed, there was no way to calculate the second hash from it. The only way to find out was to actually hash both sentences.
Hashcash applies this mathematical trick in a clever way.
With Hashcash, the metadata of an email (the “from” address, the “to” address, the time, etc.) is formalized as a protocol. Additionally, the sender of an email must add a random number to this metadata: a “nonce.” All this metadata, including the nonce, is then hashed, so the resulting hash looks a bit like one of the random numbers above.
Here’s the trick: not every hash is considered “valid.” Instead, the binary version of the hash must start with a predetermined number of zeroes. For example: 20 zeroes. The sender can generate a hash that starts with 20 zeroes by including a nonce that randomly adds up correctly … but the sender can’t know in advance what that nonce will look like.
To generate a valid hash, therefore, the sender has only one option: trial and error (“brute force”). He must keep trying different nonces until he finds a valid combination; otherwise, his email will be rejected by the intended recipient’s email client. Like Dwork and Naor’s solution, this requires computational resources: it’s a proof-of-work system.
“[I]f it hasn’t got a 20 bit hash […] you have a program which bounces it with a notice explaining the required postage, and where to obtain software from,” Back explained on the Cypherpunks mailing list. “This would put spammers out of business overnight, as 1,000,000 x 20 = 100 MIP years which is going to be more compute than they’ve got.”
Notably, Back’s proof-of-work system is more random than Dwork and Naor’s. The duo’s solution required solving a puzzle, meaning that a faster computer would solve it faster than a slow computer every time. But statistically, Hashcash would still allow for the slower computer to find a correct solution faster some of the time.
(By analogy, if one person runs faster than another person, the former will win a sprint between them every time. But if one person buys more lottery tickets than another person, the latter will statistically still win some of the time — just not as often.)
Like Dwork and Naor’s proposal, Hashcash — which Back would elaborate on in a white paper in 2002 — never took off in a very big way. It was implemented in Apache’s open-source SpamAssassin platform, and Microsoft gave the proof-of-work idea a spin in the incompatible “email postmark” format. And Back, as well as other academics, came up with various alternative applications for the solution over the years, but most of these never gained much traction. For most potential applications, the lack of any network effect was probably too big to overcome.
Nevertheless, Dwork and Naor as well as Back (independently) did introduce something new. Where one of the most powerful features of digital products is the ease with which they can be copied, proof of work was essentially the first concept akin to virtual scarcity that didn’t rely on a central party: it tied digital data to the real-world, limited resource of computing power.
And scarcity, of course, is a prerequisite for money. Indeed, Back in particular explicitly placed Hashcash in the category of money throughout his Cypherpunks mailing list contributions and white paper, mirroring it to the only digital cash the world had seen at that point in time: DigiCash’s Ecash by Chaum.
“Hashcash may provide a stop gap measure until digicash becomes more widely used,” Back argued on the mailing list. “Hashcash is free, all you’ve got to do is burn some cycles on your PC. It is in keeping with net culture of free discourse, where the financially challenged can duke it out with millionaires, retired government officials, etc on equal terms. [And] Hashcash may provide us with a fall back method for controling [sic] spam if digicash goes sour (gets outlawed or required to escrow user identities).”
Despite the name, however, Hashcash couldn’t properly function as a full-fledged cash in itself (nor could Dwork and Naor’s proposal). Perhaps most importantly, any “received” proof of work is useless to the recipient. Unlike money, it could not be re-spent elsewhere. On top of that, as computers increased in speed every year, they could produce more and more proofs over time at lower cost: Hashcash would have been subject to (hyper)inflation.
What proof of work did offer, more than anything else, was a new basis for research in the digital-money realm. Several of the most notable digital-money proposals that followed were building on Hashcash, typically by allowing the proofs of work to be reused. (With Hal Finney’s Reusable Proof of Work — RPOW — as the most obvious example.)
Ultimately, of course, proof of work became a cornerstone for Bitcoin, with Hashcash as one of the few citations in the Bitcoin white paper.
Yet, in Bitcoin, Hashcash (or, rather, a version of it) is utilized very differently than many would have guessed beforehand. Unlike Hashcash and other Hashcash-based proposals, the scarcity it provides is not itself used as money at all. Instead, Hashcash enables a race. Whichever miner is the first to produce a valid proof of work — a hash of a Bitcoin block — gets to decide which transactions go through. At least in theory, anyone can compete equally: much like a lottery, even small miners would statistically be the first to produce a valid proof of work every so often.
Further, once a new block is mined, confirming a set of transactions, these transactions are unlikely to be reversed. An attacker would have to prove at least as much work as required to find the block in the first place, and under normal circumstances exponentially more, for any additional block. The real-world resources that must be spent in order to cheat outweigh the potential profit that can be made by cheating, which should give recipients of Bitcoin transactions confidence that these transactions are final.
This is how, in Bitcoin, Hashcash killed two birds with one stone. It solved the double-spending problem in a decentralized way, while providing a trick to get new coins into circulation with no centralized issuer.
Hashcash did not realize the first electronic cash system — Ecash takes that crown, and proof-of-work could not really function as money. But a decentralized electronic cash system might well have been impossible without Back’s proof of work.
Two researchers from Victoria University of Wellington in New Zealand have proposed a new quantum blockchain technology that, by exploiting quantum entanglement across time, could greatly increase the security of future blockchain systems operating on quantum networks.
Senior author Matt Visser is a renowned mathematician and cosmologist who has authored books with titles like “Artificial Black Holes” and “Lorentzian Wormholes.” The lead author, Del Rajan, is a Ph.D. student in Visser’s group.
“Previous blockchains that worked with quantum operations were presented, but the blockchain itself was never quantum,” said Rajan, as reported by IEEE Spectrum. “We are presenting the first fully quantum blockchain.”
“It’s expected that 10 percent of global GDP could be stored on blockchain technology by 2027,” added Rajan. Therefore, it’s critically important to find ways to increase the security of blockchain networks. Visser and Rajan are persuaded that their quantum blockchain concept could permit watertight tamper-proofing of all records and transactions.
The two scientists propose using “[quantum] entanglement in time between photons that do not simultaneously coexist.”
Quantum entanglement, the “spooky action at a distance” that baffled Einstein, indicates correlations between remote quantum particles that share a common origin or have interacted in the past. Entangled non-local correlation seems instantaneous, or at least it propagates much faster than other physical interactions. In particular, entanglement between particles too remote to exchange signals limited by the speed of light has been repeatedly confirmed in research labs.
It turns out that probing the state of one particle in an entangled pair affects the state of the other particle in subtle ways. While, according to current scientific consensus, entangled correlations can’t be used to send faster-than-light signals, important practical applications of entanglement include quantum computing and quantum cryptography.
For cryptography, entanglement is a double-edged sword. On the one hand, future quantum computers based on entangled qubits — physical quantum bits that can be in a quantum superposition of classical zero and one states — promise to break today’s strongest cryptography. Quantum information technology is actively pursued by entities with large budgets, like governments, including the U.S. and China, and tech giants, including IBM, Intel and Microsoft.
A report recently issued by the National Institute of Standards and Technology (NIST) notes that practical quantum computers, which could be developed in the near future, would be capable of greatly weakening (and, in some cases, rendering useless) existing cryptographic algorithms.
This could result in the need to change, or update, the cryptographic technology used in today’s blockchain systems. The report provides a table, taken from NIST’s 2016 “Report on Post-Quantum Cryptography,” describing the impact of quantum computing on common cryptographic algorithms. In summary, RSA, Elliptic Curve Cryptography (ECDSA and ECDH) and Finite Field Cryptography (DSA) should be considered as no longer secure. AES, SHA-2 and SHA-3 should use larger key and output sizes.
On the other hand, while entanglement enables powerful quantum computers that might soon break today’s best cryptography, it also enables quantum cryptography with unbreakable security, guaranteed by fundamental quantum physics itself. Quantum key distribution exploits entangled correlations to detect attempts by eavesdroppers to intercept cryptographic keys.
If entanglement sounds weird, entanglement in time sounds even weirder. It turns out that nonlocal entangled correlations extend not only across space but also across time.
“[Measuring] the last photon affects the physical description of the first photon in the past, before it has even been measured,” noted the physicists who first demonstrated the concept in the lab. “Thus, the ‘spooky action’ is steering the system’s past.”
Visser and Rajan’s basic idea is to encode data on a quantum particle, explains MIT Technology Review. “This becomes the first quantum block. When more data is available, this is combined with the data from the first particle in a quantum operation that entangles it with a second particle. The former is then discarded, and the record of the first block of transactions is combined with the second block. The data from a third block can be added in the same way, creating a chain.”
Visser and Rajan note: “[In] our quantum blockchain, we can interpret our encoding procedure as linking the current records in a block, not to a record of the past, but [to] the actual record in the past, which does not exist anymore. The attacker cannot even attempt to access the previous photons since they no longer exist.” Therefore, entanglement in time provides a far greater security benefit than entanglement in space.
“Records about past transactions are encoded onto a quantum state that is spread across time,” summarizes Rajan.
“This work can be viewed as a quantum time machine,” adds Visser.
This may sound like science fiction, but it’s backed by solid science and existing technology implementations. “[All] the subsystems of this design have already been shown to be experimentally realized,” note the researchers. Practical applications to creating highly secure transaction networks are likely to attract the interest of governments and corporations.
The quantum blockchain couldn’t be implemented on top of today’s commercial communication networks, which are not designed to handle quantum information. However, Visser and Rajan emphasize that significant progress is currently being made toward the creation of a global quantum network.
“We have reached the point where the question is no longer whether we are going to have a global quantum network, but rather when and how it will be implemented,” claims a recent review published in Nature Photonics.
Among the powerful state actors, China is developing quantum key distribution satellites and a fiber link stretching over 2,000 km from Beijing to Shanghai. In the private sector, South Korean telecom giant SK Telecom is investing $65 million to develop quantum technologies for the telecom and Internet of Things (IoT) markets in partnership with Swiss quantum information company ID Quantique.
In view of the surging interest in quantum information technologies and the theoretical work of Visser and Rajan, it seems plausible that highly secure quantum blockchains could be implemented on future quantum networks.
“You can pay for access to a database, buy software or a newsletter by email, play a computer game over the net, receive $5 owed you by a friend, or just order a pizza. The possibilities are truly unlimited.”
This quote is not from a 2011 Bitcoin introduction video. In fact, the quote is not about Bitcoin at all. It is not even from this millennium. The quote is from cryptographer Dr. David Chaum, speaking at the first ever CERN conference in Geneva in 1994. What he’s talking about is eCash.
If the cypherpunk movement has a godfather, the bearded, ponytailed Chaum is it. To say that the cryptographer — now 62 or 63 years old (he won’t reveal his exact age) — was ahead of the curve is an understatement. Before most people had heard of the internet, before most homes had personal computers, before Edward Snowden, Jacob Appelbaum or Pavel Durov were even born, Chaum concerned himself with the future of online privacy.
“You have to let your readers know how important this is,” Chaum once told a Wired journalist. “Cyberspace doesn’t have all the physical constraints. […] There are no walls … it’s a different, scary, weird place, and with identification it’s a panopticon nightmare. Right? Everything you do could be known to anyone else, could be recorded forever. It’s antithetical to the basic principle underlying the mechanisms of democracy.”
Chaum, who started his career as a computer science professor at Berkeley University, was not just a digital privacy advocate. He designed the tools to realize it. First published in 1981, Chaum’s paper “Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms” laid the groundwork for research into encrypted communication over the internet, which would eventually lead to privacy-preserving technologies like Tor.
But privacy of regular communication was not at the top of Chaum’s priority list. He arguably had an even bigger idea. The Berkeley professor wanted to design a privacy-preserving digital money.
“The choice between keeping information in the hands of individuals or of organizations is being made each time any government or business decides to automate another set of transactions,” Chaum would explain in the Scientific American in 1992. “The shape of society in the next century may depend on which approach predominates.”
Ten years prior, by 1982, Chaum had already solved the puzzle, which he had published in his second major paper: “Blind signatures for untraceable payments.” At a point in time when today’s Bitcoin veterans like Dr. Pieter Wuille, Erik Voorhees or Peter Todd had yet to take their first breath, the cryptographer had designed a solution to realize an anonymous payment system for the internet.
At the heart of Chaum’s digital money system lies his innovation of “blind signatures.”
To understand blind signatures, it’s important to first remember how public key cryptography works and, in particular, what (regular) cryptographic signatures are.
Public key cryptography uses key pairs. Such a pair consists of a public key, which is a seemingly random string of numbers that is mathematically derived from the other, truly random string of numbers: the private key. With the private key, it’s trivial to generate the public key. But with only the public key, it’s practically impossible to generate the private key: it’s a one way street.
Public key cryptography can be used to establish private communication between two people — in academic circles usually referred to as “Alice” and “Bob” — who only share their public keys with one another. Their private keys remain private.
But private communication is not all Alice and Bob can do. Alice can also cryptographically “sign” any piece of data (and so can Bob). To do so, Alice must mathematically combine her private key with this data. The result will be another seemingly random string of numbers known as the “signature.” Once again, it’s impossible to recreate Alice’s private key from the signature (with or without the piece of data). It’s all still a one-way street.
The interesting thing about this signature is that Bob (or anyone else) can check it against Alice’s public key. This tells Bob that it was indeed Alice that created the signature with her private key (and the added piece of data). This can, in turn, mean whatever Alice and Bob want. For example, it can mean that Alice agrees with the content of the data (just like a handwritten signature).
A blind signature then takes all this one step further. This time, Bob first generates a random number, called a “nonce,” and mathematically combines this with the piece of data. This “scrambles” the piece of data to make it seem like yet another random string of numbers. Bob can then give the scrambled data to Alice for her to sign. Alice cannot tell what the original data looks like, so she is “blind signing” it. The result is a “blind signature.”
Now, the interesting thing about this blind signature is that it’s not just linked to Alice’s keys (like any signature would be) and the scrambled data. The same blind signature is also linked to the original, unscrambled data. Using only Alice’s public key, anyone can check that Alice signed a scrambled version of the original data — including, of course, Alice herself, if she does get to see the original data later on.
This blind signature scheme is the trick that Chaum used to create a digital money system.
To realize this, Alice from the above example would actually be a bank: Alice Bank. This is a regular bank, like banks exist today, where customers have bank accounts with (in this example) U.S. dollar deposits.
Let’s say Alice Bank has four customers: Bob, Carol, Dan and Erin. And let’s say that Bob wants to buy something from Carol.
First, Bob requests a “withdrawal” from Alice Bank. (Ideally, he had already made this withdrawal earlier — but never mind that for now.) To make this withdrawal, Bob actually creates “digital banknotes” himself, in the form of unique numbers: “serial numbers.” On top of that, he scrambles these banknotes, as shown above. These scrambled banknotes are sent to Alice Bank.
Having received the scrambled banknotes from Bob, Alice Bank then blind signs each scrambled banknote and sends them back to Bob. For each signed, scrambled banknote that she sends back, Alice Bank subtracts one dollar from Bob’s bank account.
Now, because Alice Bank blind signed the scrambled banknotes, her signature is also linked to the original, unscrambled banknotes. So, Bob can now use the original, unscrambled banknotes to pay Carol by simply sending them to her.
As Carol receives the banknotes, she should forward them to Alice Bank. Alice Bank then checks that she indeed blind signed each of the banknotes, which her blind signatures allow her to do: they are linked to her own keys. Alice Bank also checks that the same banknotes (serial numbers) haven’t already been deposited by someone else in order to ensure that they haven’t been double-spent.
As the banknotes check out, Alice Bank adds the equivalent number of dollars to Carol’s bank balance, and lets Carol know. Upon this confirmation, Carol knows she’s been paid valid banknotes by Bob and can safely send him whatever he was buying from her.
The basic idea behind eCash. Source: faculty.bus.olemiss.edu/
Of key importance, Alice Bank will see the unscrambled banknotes for the first time only when Carol deposits them! As such, Alice Bank has no way of knowing that the banknotes were Bob’s. They could just as well have come from Dan or Erin.
As such, Chaum’s solution offers privacy in payments. This was not new in itself, of course: private payments were the norm in those days. But it was new in digital form. Hence, Chaum’s analogy: cash. Electronic cash. eCash.
By 1990, a little under 10 years after finishing his first papers (younger cryptocurrency developers like Matt Corallo, Vitalik Buterin and Olaoluwa Osuntokun still hadn’t been born), David Chaum founded DigiCash. The company was based in Amsterdam, where Chaum had been living for a couple of years, and specialized in — indeed — digital money and payment systems. These included a government project to replace toll booths (which was eventually cancelled) and smart cards (akin to what we call hardware wallets today). But DigiCash’s flagship project was its digital cash system, eCash. (The system was called eCash, while the money in the system was dubbed “CyberBucks,” comparable to using capital-letter Bitcoin for the protocol and lower case bitcoin for the currency.)
The technical team in the early days of DigiCash. (Chaum not pictured.) Source: chaum.com/ecash
At a time that Netscape and Yahoo! were leading the tech industry to new heights, and where some thought micropayments, not advertisements, would be the revenue model for the web, DigiCash was considered a rising star by tech entrepreneurs of the day. Of course, Chaum and his team had much faith in their technology as well.
“As payments on the network mature, you’re going to be paying for all kinds of small things, more payments than one makes today,” Chaum told the New York Times in 1994, of course, emphasizing the importance of privacy in such a world. “Every article you read, every question you have, you’re going to have to pay for it.”
Interest was significant. By late 1995, eCash was licensed to its first bank: the Mark Twain Bank in St. Louis. Moreover, by early 1996, one of the biggest banks in the entire world got on board: Deutsche Bank. Credit Suisse, a second major player joined later, and several other banks across different countries — including the Australian Advance Bank, Norway’s Norske Bank and Bank Austria — would follow suit.
Yet, what’s perhaps more interesting than the deals DigiCash struck are the deals it did not. Two of the three major Dutch banks — ING and ABN Amro — are said to have made DigiCash partnership deals worth tens of millions of dollars. Similarly, Visa reportedly offered a $40 million investment, while Netscape had interest as well: eCash could have been included in the most popular web browser of that era.
Still, the biggest offer of all probably came from none other than Microsoft. Bill Gates wanted to integrate eCash into Windows 95 and is said to have offered DigiCash some $100 million to do so. Chaum, so the story goes, asked for two dollars for each version of Windows 95 sold. The deal was off.
While a rising star in the minds of technologists of the day, DigiCash seemed to have trouble making a financial deal that would help it to realize its full potential.
By 1996, DigiCash employees had seen one failed deal too many and wanted a change in policy. This change came in the form of a new CEO: Visa veteran Michael Nash. The startup also got a fund injection, while MIT Media Lab founder Nicholas Negroponte was made chairman of the board. (Through its Digital Currency Initiative, the MIT Media Lab employs several Bitcoin Core contributors today.) The DigiCash headquarters were moved from Amsterdam to Silicon Valley. Chaum remained part of DigiCash, but now as CTO.
It wouldn’t make much difference. After several years of trials, eCash wasn’t catching on with the general public. The banks that got on board were experimenting but did not really push the technology; by 1998, Mark Twain Bank had only enrolled 300 merchants and 5,000 users. While a final deal with Citibank came close — it could have given the project a good push — this bank ended up walking out for unrelated reasons.
“It was hard to get enough merchants to accept it, so that you could get enough consumers to use it, or vice versa,” Chaum told Forbes in 1999, after DigiCash had finally filed for bankruptcy. “As the Web grew, the average level of sophistication of users dropped. It was hard to explain the importance of privacy to them.”
DigiCash failed, and eCash failed with it. But even though the technology did not succeed as a business, Chaum’s work would inspire a group of cryptographers, hackers and activists, connected through a mailing list. It was this group — which included DigiCash contributors like Nick Szabo and Zooko Wilcox-O’Hearn — that would come to be known as the cypherpunks.
Perhaps a bit more radical than Chaum himself ever was, the cypherpunks kept the dream of an electronic cash alive, proposing alternative digital currency systems throughout the 1990s and early 2000s. In 2008, about 10 years after DigiCash’s demise, Satoshi Nakamoto sent his proposal for an electronic cash to the de-facto successor of the then-defunct cypherpunk mailing list: Bitcoin.
Bitcoin and eCash have little in common from a design perspective. Crucially, eCash was centralized around DigiCash and could not really be its own currency. Even if every single person in the world would only use eCash for all their transactions, banks would still be necessary to offer account balances and confirm transactions. This also means that eCash — while providing privacy — was not as censorship resistant. Where Bitcoin was able to keep WikiLeaks funded even through a banking blockade, for example, eCash could not have done the same thing; banks could still have blocked WikiLeaks’ accounts.
Still, Chaum’s work on digital currency, dating back to the early 1980s, remains relevant. While Bitcoin itself does not employ blind signatures, scaling and privacy layers on top of the Bitcoin protocol could. Bitcointalk forum and r/bitcoin subreddit moderator Theymos, for example, has been a champion of an eCash-like scaling sidechain for Bitcoin for some time. Adam Fiscor, a leader in the domain of Bitcoin transaction privacy today, is realizing coin-mixing services utilizing blind signatures, as once proposed by Bitcoin Core contributor Greg Maxwell. And yet-to-be-announced Lightning Network technology could utilize blind signatures to improve security.
And Chaum himself? He returned to Berkeley, where he is responsible for a long list of publications, many in the field of digital elections and reputation systems. Perhaps, some 20 years from now, an entirely new generation of developers, entrepreneurs and activists will look back at these as the groundwork for a technology that is about to change the world.
This article is partly based on two articles published in the 1990s: “E-Money (That’s What I Want)” by Steven Levy for Wired, and “Hoe DigiCash alles verknalde” (Translated: “How DigiCash Blew Everything”) by an unknown author for Next! Magazine. There is also a wealth of information on chaum.com/ecash.
One hard fork later, there are four new Monero projects.
Privacy-centric cryptocurrency Monero hard forked to version 12 of its protocol yesterday. But not everyone is on board. Following the example once set by Ethereum Classic, some users are continuing on the pre-hard fork Monero blockchain… though in this case not as a single project. Now there is Monero Classic (XMC), Monero 0 (XMZ), Monero Original (XMO) and a second project by the name Monero Classic (XMC) (which in this article we will refer to as Monero-Classic); these are all continuing on version 11 of the Monero protocol. Of course, this means they are all still compatible on a single network, using the same coin — just with different names.
Here’s the story of the pre-hard fork Monero blockchain and the four different projects keeping it alive.
As an ongoing protocol upgrade process, Monero has made a habit of hard forking once every six months. The latest hard fork introduced several new features, including an increased ring-size for more private but also bigger (thus more resource-intensive) transactions, multi-signature transactions, initial Ledger Nano S hardware wallet support, and more.
The latest hard fork also introduced a tweak to Monero’s CryptoNight proof-of-work hashing algorithm. This backwards-incompatible change makes all existing ASIC (application-specific integrated circuit) mining hardware useless. Such specialized hardware is a bigger concern on the CryptoNight hashing algorithm than most other hashing algorithms, as it could let ASIC miners launch denial-of-service (DoS) attacks on non-ASIC miners and non-mining nodes on the network.
The risks presented by ASIC-mining hardware appeared to be reason why at least most of Monero’s development and user community agreed on the change. However, not all parties were equally happy with the hard fork, presumably. Most notably, major hardware manufacturer Bitmain, as well as smaller manufacturers Halong Mining and PinIdea, recently all announced that they had developed ASIC machines for the CryptoNight hashing algorithm (and such hardware was probably used to mine on the Monero blockchain in secret). All this hardware would be rendered mostly worthless after Monero’s hard fork.
Now, over the past couple of days and weeks, four projects have announced that they will continue to use the pre-hard fork Monero protocol. Since all four are using the same protocol, they are (at least as far as we can tell) really all the same network and coin, albeit with different names and logos.
These are the four new projects continuing the pre-hard fork Monero blockchain.
This first, Monero Classic, is initiated by a group that self-identifies as Monero enthusiasts from Singapore — including developers and “a few” miners — who felt it was “time to take action.” Speaking to Bitcoin Magazine, representative Bento Tan explained that he believes that the development of ASICs is a healthy, market-driven process.
“The ability to have choices promotes competition and that drives growth. We have to look at things at that level. Unilateral control is a suffocating death because you take away the need to improve and innovate.”
Tan added that he considers this healthy market dynamic to be confirmed by the fact there are three different manufacturers to have created ASICs — not just one.
Further, hard-forking to make mining hardware obsolete is a considered a bigger risk than the risk of mining centralization. A statement on the Monero Classic website reads:
“The main message of Monero Classic is that we believe that the developers changing the proof of work creates more centralization and harms decentralization.” And: “The M[o]nero developers are saying that they can and will change the consensus rules whenever it suits them and the community seems to be conditioned into following the wishes of the developers.”
Monero Classic has no connections with any of the other new Monero projects, Tan said, and has no plans to cooperate with them.
On the project website, the person behind Monero-Classic identifies himself as “PZ, an early Bitcoin evangelist and blockchain eco builder”. (You can read more about PZ here.)
Not unlike (the other) Monero Classic, PZ explains on this website that “the emergence of specialized mining machine[s] for a cryptocurrency is [a] normal market economy phenomenon.” Additionally, PZ argues that “if there are professional mining machines, the events like ‘Monero was attacked by more than 500,000 botnets’ could be avoided,” referring to botnets that have been used to mine Monero.
Since the project seems to have originated from China, is actively promoted by Bitmain’s mining pool AntPool, and of course because Bitmain has much to gain from a continuation of Monero with the CryptoNight hash algorithm, some suspect that this ASIC hardware manufacturer has a hand in this project, too. However, when asked by Bitcoin Magazine, a Bitmain representative suggested this was not the case.
Bitcoin Magazine was unable to get in contact with PZ or anyone else from the Monero-Classic project by time of publication.
Speaking with Bitcoin Magazine, a pseudonymous spokesperson for Monero 0 identified the group as one of “concerned users” and “proof-of-work maximalists,” some of whom operate hobby operations for mining.
On the project website, Monero 0 writes:
“We’ve decided that the Monero Project’s strategy to continuously hard fork is no longer a stable or a sane strategy. We believe that Satoshi’s Proof of Work is the only mechanism for decentralized consensus. The so-called ‘network upgrades’ that are centrally mandated by the Monero Project are a Trojan Horse designed to compromise the effectiveness of Proof of Work in the Monero network. Monero 0 is not a fork; it is the original Monero.”
The Monero 0 spokesperson further said that Monero is “an NVDA project”, that “‘proof of fork’ is not a consensus method,” and that “Bitmain is trying to destroy Monero” — but did not have time to explain more.
Not much is known about Monero Original or the people behind it.
The project has a GitHub, and it sent press releases to several outlets. This press release did not contain much information, but it did include a statement from the “lead developer of Monero Original team”:
“Monero has always been about freedom of choice, about diversity and about the strong community behind it. We are providing the Monero fans [with] a possibility to support the iconic coin and stay on the original chain. Monero Original team stands for diversity, which is a logical marker of evolution. We are excited to see our favourite coin mature, and we are even more excited to help [in] keeping this diversity.”
At least one cryptocurrency exchange — HitBTC — indicated it would make XMO balances available to all XMR holders at the time of the hard fork. This does not necessarily mean that HitBTC will also offer XMO trading, but it does make it more likely they will.
Bitcoin Magazine reached out to the Monero Original project but did not receive any response by the time of publication.
So far, it appears that both the new Monero blockchain and the pre-hard fork blockchain are being mined. Most hash power is still on the pre-hard fork blockchain, and both are supported by less hash power than they were before the hard fork. This means that blocks are being found more slowly, in particular on the new Monero blockchain, but this situation should stabilize within days.
Assuming that at least one of the four new projects succeeds in keeping the pre-hard fork Monero blockchain running (and assuming the new Monero blockchain keeps running too), this could lead to some complications.
For one, the Monero hard fork did not implement replay protection. This could mean that users who spend XMR on the new Monero blockchain could unintentionally spend the equivalent coins on the pre-hard fork blockchain, and vice versa.
Thanks to other changes on the new Monero protocol, this risk appears limited for users of the pre-hard fork blockchain, however. The default transactions they make will be considered invalid on the new Monero protocol. But users of the new Monero blockchain do not have that same luck. If they want to keep their pre-hard fork coins, they should move these before they move their XMR, and do so with the default ring-size of five (or six).
Over time, replay attacks should become less likely, even for users that didn’t move their coins. This is because on Monero, mixing coins is a requirement, and the odds that users will mix their coins with coins that are only valid on one chain will increase. Doing so will make the whole transaction invalid on one of both chains.
A bigger problem is that moving coins on both blockchains independently reveals which coins are controlled by the same user. This is at odds with Monero’s central value proposition of privacy and fungibility. Therefore, anyone who uses Monero for privacy reasons is best advised to completely choose one chain and ignore the other. (It’s presumably best to ignore the chain that carries the least value.)
Even users that do not use both chains may suffer from somewhat decreased privacy. If they mix their coins with users who revealed which coins they own, it can reduce the anonymity set of the users that did not. This added risk is probably compensated for on the new Monero protocol by the increased ring-size for transactions, however.
Whether the pre-hard fork version of Monero (in the form of the four different projects) will gain and retain any market value of course remains to be seen.
Monero lead developer Riccardo Spagni did not respond to a request for comment by the time of publication.
Update April 7th: It appears there is a fifth project on the pre-hard fork Monero blockchain: MoneroC. Additionally, trading of XMO has by now commenced on HitBTC. At the time of writing this update, one XMO trades for 0.00175 BTC, which is about $12, or 0.07 XMR, but the price is very volatile. Some minor details were updated in the rest of the article as well.
Thanks to Monero community contributor Justin Ehrenhofer for clarifying some of the technical details.
The Lightning Network’s first mobile app for Bitcoin’s mainnet is now available through Google Play. Known as the Eclair Wallet, the app was released on April 4, 2018, via French technology startup ACINQ, and is being offered specifically to Android users.
Devices employing software version 5.0 or higher can send Lightning payments, which require significantly lower fees than the standard Bitcoin network. Transactions also happen much faster compared to on-chain confirmations.
Describing the new product on GitHub, ACINQ wrote:
“The Eclair Wallet is a next-generation, Lightning-ready Bitcoin wallet. It can be used as a regular Bitcoin wallet, and can also connect to the Lightning Network for cheap and instant payments. This software is based upon eclair [another Lightning implementation], and follows the Lightning Network standard.”
The product’s release marks the latest in a long list of items that have come by way of the Lightning Network over the past several weeks. In March, for example, the protocol’s “first Lightning mainnet release,” known as Ind 0.4-beta, went live to widespread acclaim. Several other new tools have since entered the market by way of private developers, and an upcoming beta known as c-lightning is expected to be available relatively soon.
The Lightning Network on Bitcoin is made possible in part due to Segregated Witness, the protocol upgrade that activated on Bitcoin last summer. The app’s popularity has also inspired users to request an iOS edition of the product.
The wallet does, however, come with certain limitations. According to a description written by ACINQ, “Lightning channels are outbound only: you can pay with LN but you cannot receive or forward payments with this wallet.” It further states that if users wish to enjoy the full LN experience, they are advised to run a full Eclair node.
The Lightning Network is described as a “peer-to-peer system” working as a “second-layer payment protocol” leveraging the security of Bitcoin’s blockchain to process (micro)payments. The Network’s scalability should allow it to process millions to billions of transactions per second across the network.
Founded in 2014, ACINQ is based in Paris, and seeks to build “products and services for the Bitcoin ecosystem.”
With the advent of the long-anticipated Lightning Network (LN), crypto enthusiasts have more to look forward to than faster, cheaper transactions. Just as smart contracts brought DApps to Ethereum’s network, the Lightning Network is primed to bring a host of Lightning apps to Bitcoin. These applications, fittingly dubbed LApps, will leverage the Lightning Network to usher in a new generation of payment applications to the blockchain industry.
Lightning Labs rolled-out their beta for the first implementation of the Lightning Network on March 15, 2018. In practice, the Lightning Network allows Bitcoin users to send transactions on an off-chain network through payment channels. Since these channels aren’t connected to the blockchain, users can send near-instant transactions, however small they may be, without incurring exorbitant fees.
Before the Lightning Network went live, Lightning Labs launched their Lightning Desktop Wallet so users could get a feel for the network while it was in testnet. Now that the LN is in full beta, Lightning Lab’s wallet has been joined by Zap, a user-friendly wallet by Jack Mallers that’s meant to make the Lightning Network more accessible to the general public.
In the few weeks since its release, developers have introduced LApps for the network that look outside the limits of mere wallet and payment channel functionality. Now, there are dozens of Lightning applications for any of four distinct implementation (lnd, eclair, c-lightning and lit) across four programming languages (Go, C, Scala and Java), as developers continue to build on the technology.
One such developer, Nadav Ivgi, has been particularly busy. He’s the man behind the seven new applications showcased during Blockstream’s “Week of LApps.” The blockchain development company presented the projects as an extension of Lightning Charge, a payment processing solution for c-lightning, Blockstream’s implementation of the protocol in the C programming language.
Among these creations, Ivgi gives us nanotip, a tipbot that gives content creators and users an LN alternative to traditional bitcoin tipbots. Complementing the WooCommerce Lightning Gateway, one of Blockstream’s first LApps, Lightning Publisher is an additional WordPress plug-in that gives publishers an ad-free revenue alternative. With it, they can charge their readers a subscription to access content, payable through LN payment channels. Similarly, FileBazaar lets content creators monetize their data and files — be they pictures, videos or other documents — with an online marketplace that offers pay-per-view access to such content.
Lightning Charge’s LApp suite also comes with its own point-of-sale solution for merchants, nanopos. As one might imagine, point-of-sale applications have proliferated for the Lightning Network, as developers grind out code to find a solution to the market’s needs. Among these, we have another WooCommerce plug-in built on the Lightning Network Daemon (lnd), and Strike, a Stripe-esque API for merchants built with Eclair, the Scala programming language’s implementation of the LN. Eclair is also working on Lightning Conductor, an application that would allow users to convert their payment channel balances to bitcoin and back without closing the channels themselves.
Payment solution LApps abound but that hasn’t kept developers from building innovative, more nuanced applications for the Lightning Network. Take, for instance, Bitrefill, an application that allows you to top-off a prepaid mobile phone card with payment channels, or CoinMall, a Lightning-powered online marketplace for digital products. There’s even a Slack tipbot and one called CoinTippy for Reddit, Twitter, Telegram and other platforms. And then there’s 1ML, a search engine built to track nodes, applications and other aspects of the LN ecosystem.
There are more unconventional and curious manifestations still. Bitquest, a crypto-centric Minecraft server, is getting its own Lightning payments option, while Lightning Gem and Thunderdice have begun tapping into off-chain, Satoshi-funded gambling. Y’alls, a Yours-like blogging platform, is using Lightning payments for pay-per-view articles. Hungry? Lightning has that covered, as well, with Block and Jerry’s and Starblocks, crypto-couriers dishing out ice cream and coffee in exchange for LN micropayments (sadly, these services are not yet fully available).
This is just a sampling of an expanding list of LApps, and, if anything, the diversity of the applications currently in existence shows that the limits of what the Lightning Network can offer are confined to the imagination of the developers building on it. Bear in mind that, while these applications can run on either Bitcoin’s mainnet or testnet, their developers generally recommend that users stick to testnet payments until the Lightning Network’s kinks are ironed out. But with more than 1,000 nodes already supporting Lightning’s mainnet, it likely won’t be long until these, and other applications, can make the leap toward full functionality on Lightning Network’s growing architecture.
As of a couple of weeks ago, the first Lightning implementation — lnd — is officially in beta. The second implementation — eclair — followed last week, while the third — c-lightning — is expected to do so soon. As such, the Lightning Network, the long-awaited Bitcoin overlay network for cheap and instant transactions, is by many of its developers considered safe enough to use on Bitcoin’s mainnet: a major milestone for the technology that has been years in the making.
This is the story so far.
The earliest origins of the Lightning Network can be traced back as far as Bitcoin itself.
The first piece of the Lightning puzzle is a concept called “payment channels.” Payment channels are essentially bitcoin balances between two Bitcoin users, and only two users: the rest of the world does not need to know or care about their mutual balances. Importantly, these balances can be updated without requiring any on-chain Bitcoin transactions; where the balance of one user increases, the balance of the other decreases by the same amount. In effect, this allows both participants to transact between each other, without burdening the entire network with their transaction data.
Once the users are done transacting, they can settle their payment channel by transmitting only one transaction to the network: that transaction pays out to each what they should receive based on their channel balances. To these users’ benefit, this should also mean that the channel updates (“off-chain transactions”) are cheaper because they don’t require mining fees, and are faster because they don’t require blockchain confirmations.
This general idea is arguably as old as the very first Bitcoin software released by Satoshi Nakamoto in 2009. Bitcoin 0.1 included a raw draft of code that would let users update a transaction before it was confirmed:
A rough draft of payment channel code included in Bitcoin 0.1. Source: GitHub
While this code was a rough draft, Satoshi Nakamoto went into more detail about how payment channels could work in private communication with then-bitcoinj developer Mike Hearn.
Satoshi Nakamoto’s explanation of how payment channels could work, described by Mike Hearn. Source: Bitcoin-dev mailing list
Although the general concept of payment channels has existed for as long as Bitcoin itself, Satoshi Nakamoto’s design was not entirely secure. Most importantly, a user in a payment channel could collude with miners in order to claim more bitcoin than the channel balance should let him.
A solution to this problem was proposed for the first time in the summer of 2011, after Satoshi Nakamoto had left the Bitcoin project. Bitcointalk forum user “hashcoin” outlined a two-tier payment channel that required users to exchange several partially signed multisignature transactions and transactions with timelocks that depended on one another to be valid. If one participant should disappear, the other could claim all the funds in the payment channel after some time had passed. A downside of this design, however, was that hashcoin’s channels could only work in one direction. Alice could pay Bob an arbitrary number of times, but Bob could not pay Alice through the same channel.
An idea similar to hashcoin’s resurfaced in early 2013, and this time it escaped the theoretical realm. In April of that year, a payment channel concept was described by Jeremy Spilman on the Bitcoin-development mailing list. He had even coded up a proof of concept. This design was, in turn, tweaked by Mike Hearn, after which future Bitcoin Core contributor, Blockstream co-founder and Chaincode Labs developer Matt Corallo turned the concept into working code for bitcoinj by mid-2013.
Another year later, in 2014, Alex Akselrod (now an engineer at Lightning Labs) was the first to propose a bi-directional payment channel. Alice could pay Bob an arbitrary number of times, while, using decreasing timelocks, Bob could pay Alice within the same channel — albeit a limited number of times. As opposed to one-directional payment channels, however, this solution was never actually implemented in code.
Around the same time that the first payment channels were proposed, others — including for example Bitcoin Core developers Peter Todd and Gavin Andresen — were thinking about off-chain payment networks. If Alice could pay Bob through an off-chain transaction, and Bob could pay Carol through an off-chain transaction, then Alice should be able to pay Carol through Bob without requiring any on-chain transactions.
An early illustration of Plooy’s payment layer design, which would evolve into Lightning Network precursor Amiko Pay. Source: Corné Plooy
With suggestions added by Bitcoin Core developer and future Blockstream CTO Gregory Maxwell, and Ripple inventor Ryan Fugger (among others), this idea evolved throughout the years into a merger of Bitcoin and the original Ripple technology, resulting in the system Plooy called “Amiko Pay.” Earlier drafts of Amiko Pay did not utilize payment channels and therefore injected trust in the system, however: should one user refuse to settle a balance with another user, the latter would have no recourse.
An early payment network proposal that utilized payment channels was proposed by mathematician and future Bitcoin emBassy TLV co-founder Meni Rosenfeld in the summer of 2012. On the Bitcointalk forum, Rosenfeld described a system in which Bob (from the above example) is replaced by a payment processor, with both Alice and Carol as its customers. The payment processor could, in turn, also have channels with other payment processors, with more customers, turning the payment channel network into a hub-and-spoke system.
While such a system did introduce a little bit of trust in the payment processors — they could refuse to forward a payment and keep the money instead — this risk was considered small: the trick would only work for one payment before a customer would notice and stop using the channel. Additionally, bigger payments could be cut into smaller increments so that if one payment processor proved to be unreliable, only a small portion of the payment would be lost.
This solution resurfaced a couple of times throughout the years. Bitcoin Core contributor Peter Todd, for example, published the concept to the Bitcoin-development mailing list in 2014. Payment processor BitPay, meanwhile, published a white paper on similar inter-channel payments (“Impulse”) in early 2015. And a solution like this would actually be implemented by the Swedish startup Strawpay, called Stroem (or Ström), at around the same time — but none of these iterations ever took off in a meaningful way.
The logo of the now-defunct Strawpay micropayment startup. Source: The Internet Archive
A relatively early attempt at establishing a trustless payment channel network was made by Alex Akselrod. First described in a wiki draft in 2013, to be implemented as a proof of concept throughout 2014, Akselrod’s solution went a long way toward solving the problem on a theoretical level. The main problem was that it would still be rather clunky in practice. If a payment were to fail anywhere along the route of a transaction, for example, a user would have no recourse but to wait until the funds were freed through the payment channel timelocks, which could potentially take months.
Meanwhile, by 2015, Plooy’s Amiko Pay had evolved to the point where it could potentially work trustlessly, too. However, his design would have required relatively far-reaching changes to the Bitcoin protocol, to the point where rolling back certain types of transactions would be necessary. While technically possible, it was not obvious whether such changes to the Bitcoin protocol would be adopted.
Later that same year, researchers from the technical university in Zurich (ETH Zurich), Dr. Christian Decker (now at Blockstream) and Roger Wattenhofer, proposed yet another overlay network design in their white paper “A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels.” Their solution relied strongly on timelocks as a sort of “countdown ticker” for payment channel validity, which was combined with a cryptographic trick called an “invalidation tree” for expired channel balances.
Akselrod’s solution, the later drafts of Amiko Pay, and Duplex Micropayment Channels (DMCs) were all similar to the Lightning Network in some ways, and could have worked in their own right by making different trade-offs. If the Lightning Network had not been invented, any of these solutions might have become (the basis of) Bitcoin’s go-to scaling layer instead.
But of course, the Lightning Network was invented.
After years of payment channel and network design evolution, all the pieces of the puzzle finally fell together in early 2015.
Thaddeus “Tadge” Dryja — the CTO of smart contract trading platform Mirror — and Joseph Poon wrote a white paper titled “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments,” first published in February of that year.
It proved to be a game-changer.
The Lightning Network white paper, as this publication came to be referred to, proposed several solutions to realize a payment channel network completely trustlessly: no participants could cheat without risking all the money they put up in their channel, while middlemen forwarding transactions would be unable to steal even a tiny bit of it. Additionally, the solution required relatively few changes to the Bitcoin protocol and promised to be more flexible and user-friendly than the alternatives proposed so far.
The key innovation described in the white paper are “Poon-Dryja channels”. Like earlier payment channel designs, Poon-Dryja channels depend on the exchange of partially signed and non-broadcasted transactions. But compared to previous payment channels, these new channels take an additional step involving the exchange of secret numbers, which allow payment channels to be updated in either “direction.” Alice can pay Bob an arbitrary number of times, and Bob can pay Alice within the same channel an equally arbitrary number of times.
Additionally, the Lightning Network leverages Hashed Timelock Contracts (HTLCs). This concept is usually attributed to Tier Nolan and was originally designed for cross-blockchain transactions; for example, to exchange bitcoin and litecoin trustlessly. In the Lightning Network, this solution is instead used to link payments across payment channels.
Poon and Dryja first presented their idea publicly at the San Francisco Bitcoin Devs Seminar in February 2015:
In the months thereafter, during the spring and summer of 2015, Bitcoin’s scaling issue and the block-size-limit dispute turned into a public feud. In the midst of this crisis atmosphere, a series of two conferences was organized for late 2015: Scaling Bitcoin Montreal in September and Scaling Bitcoin Hong Kong in December. In Montreal, Poon and Dryja presented their proposal once again, then both Poon and Dryja gave a second, more in-depth presentation in Hong Kong as well.
Right after this second edition of the conference in Hong Kong, Gregory Maxwell proposed a scaling road map on the Bitcoin-development mailing list. This road map prominently included the Lightning Network. It gained support from the majority of Bitcoin’s technical community and became the de facto road map for the Bitcoin Core project.
If anticipation for the Lightning Network wasn’t big enough already, it certainly was now.
The Lightning Network white paper is a long and complex document, covering highly technical concepts; in 2015, few people had the time and skill to read through and understand it. But general understanding increased significantly when long-time Linux kernel developer Rusty Russell learned about the white paper. In a series of blog posts published in early 2015, Russell “translated” the proposal for a more general (but still quite technical) audience.
Then, in May of 2015, Russell was hired by blockchain development company Blockstream to develop an actual implementation of Lightning in the C programming language: c-lightning. This major step toward implementation proved pivotal. A concept that had only been proposed a couple of months prior was now in the process of being realized by a world-class developer. Russell was later joined by Christian Decker at Blockstream, while other developers — including Corné Plooy — would, over the next couple of years, contribute to the open-source project as well.
Soon after Russell started working on c-lightning, Blockstream was no longer the only company to realize a Lightning implementation. By the summer of 2015, ACINQ, a smaller Bitcoin technology company that had originally planned to develop smart-card-based hardware wallets, decided to try their hand at the promising technology as well. The Paris-based startup would later announce that it had developed its own implementation of the Lightning protocol in the Scala programming language, named eclair.
From ACINQ’s eclair announcement. Source: medium.com
Another couple of months down the road, a third implementation was in the works. By January 2016, both of the Lightning Network white paper authors, Poon and Dryja, together with Elizabeth Stark and Olaoluwa “Laolu” Osuntokun, founded a whole new company to develop Lightning: Lightning Labs. Lightning Labs would spearhead development on lnd, an implementation of Lightning in Google’s Go programming language (also known as “golang”).
About one year after founding the company, in early 2017, Dryja left Lightning Labs to instead join MIT Media Lab’s Digital Currency Initiative, the same organization that employs Bitcoin Core lead developer Wladimir van der Laan and several other Bitcoin Core contributors. At MIT, Dryja continued to work on the Lightning implementation he bootstrapped at Lightning Labs, which he renamed lit; both lnd and lit exist today. Lit differentiates itself from lnd and other implementations by being a wallet and a node wrapped into one; today, it also supports multiple coins simultaneously through a configuration option.
Additionally, blockchain company Bitfury, best known for its mining pool and mining hardware, forked the lnd implementation to yet another version of the software. Unique to this fork is that it made trade-offs in the design so as not to require a malleability fix on the Bitcoin network — more on that later. Bitfury also made contributions in the realm of transaction routing, most notably in the form of a protocol called “Flare.” (Development of the Bitfury fork of lnd appears to have stalled for now, however.)
Further, in 2016, major wallet provider Blockchain announced that it developed a simplified version of the Lightning Network called thunder. This implementation made relatively big trade-offs compared to typical Lightning implementations, most notably because it required trust in counterparties on the network. By making this trade-off, it was able to launch an alpha release of its implementation as early as spring of 2016, long before any other development team. (While thunder might also be made compatible with the Lightning Network in the future, development of this implementation appears to have stalled for now, as well.)
In the days right after Scaling Bitcoin Milan, the third edition of the conference organized in late 2016, contributors to most Lightning implementations gathered for what came to be referred to as the first Lightning Summit. Here, they discussed how to make all of the different implementations interoperable, resulting in a Lightning Network protocol specification dubbed “BOLT” (an acronym for Basis of Lightning Technology). Where the Lightning Network white paper was a theoretical proposal, BOLT became the basis of the actual Lightning Network as we know it today.
When the Lightning Network white paper was first published, the idea described was actually not compatible with the Bitcoin protocol — at least not securely. To enable the Lightning Network as described, Bitcoin required several protocol changes.
The first of these were new timelocks that would make payment channels resistant to Bitcoin’s malleability bug. This problem was already in the process of being solved even before the publication of the Lightning Network white paper, however, and was conclusively solved in 2015, when a new type of timelock designed and proposed by Peter Todd was implemented in the Bitcoin protocol: CheckLockTimeVerify (CLTV).
Later, Bitcoin Core developers realized that the Lightning Network would function even better with relative timelocks. These allow users to lock bitcoins up for a specific point of time after another transaction has been confirmed. In the context of Lightning, users can keep their payment channels open indefinitely, whereas CLTV timelocks require them to close their channels periodically. A soft fork upgrade to realize relative timelocks, called CheckSequenceVerify (CSV), was activated on the Bitcoin network by the summer of 2016.
But the biggest protocol change that the Lightning Network required (at least assuming a decent user experience), was a malleability fix for any Bitcoin transaction.
At the time of the publication of the Lightning Network white paper, malleability was considered a big challenge. While a soft fork draft to fix it was in progress at the time, developers weren’t sure this could work and thought it might require a hard fork instead. Then, by late 2015, Bitcoin Core contributors realized that Segregated Witness (SegWit), a malleability fix that was part of Blockstream’s Elements Project, could be deployed on Bitcoin as a backward-compatible soft fork.
After a long struggle, the Segregated Witness soft fork finally activated in the summer of 2017, paving the way for the Lightning Network on Bitcoin as well.
(For more on the history of Segregated Witness, also see “The Long Road to SegWit: How Bitcoin’s Biggest Protocol Upgrade Became Reality.”)
Even while Segregated Witness had yet to be deployed on the Bitcoin protocol (and it was not completely certain that it ever would), development of the Lightning Network was well under way.
This started on testnet, the Bitcoin copy specifically designed for testing purposes. Or more accurately, in this case, the Lightning Network started on a dedicated version of testnet, dubbed “SegNet 4” (it was the fourth SegWit-specific testnet), launched in May of 2016.
Less than six months after the deployment of SegNet 4, in October 2016, the Blockstream development team had advanced its c-lightning prototype to the point where it was usable. In what was referred to as “Lightning First Strike,” Decker had “bought” a cat picture from Russell using testnet bitcoins over an early iteration of the Lightning Network.
The cat picture Christian Decker “bought” from Rusty Russell. Source: Blockstream.com
By January 2017, the first Lightning implementation — lnd — was released in alpha. With that, the Lightning Network itself had “officially” entered into its “alpha stage”: developers from around the world were, for the first time, invited to experiment with the technology, while Lightning Labs would continue to help test and improve the code.
This alpha phase, in turn, led to a growing number of developers building applications on top of lnd and other Lightning implementations. These “Lapps,” as Lightning implementations have come to be called, ranged from desktop and mobile wallets, to micropayment blogging platforms, to gambling sites, to explorers, and much more — though, in most cases, still designed for Bitcoin’s testnet.
During the summer of 2017, Segregated Witness finally activated, and the groundwork for the Lightning Network on Bitcoin was completed. From then, it took Blockstream about three months to announce its first transaction on Bitcoin’s mainnet. A little later, in November, Lightning Labs made its first Lightning transaction across blockchains: from Bitcoin to Litecoin. And in December, development teams from Blockstream, Lightning Labs and ACINQ announced that they had performed successful interoperability tests.
Moreover, by the end of the year, others started to actually use the Lightning Network on Bitcoin’s mainnet with real money — in some cases even against recommendations of its developers. A growing number of Lightning channels were opened, and by December developer Alex Bosworth had paid his phone bill through a Lightning channel he had set up with payment processor Bitrefill: one of the first real-money purchases over the Lightning Network ever.
Another month later, Blockstream — while the c-lightning implementation was still in beta — opened a webshop where real products could be bought with real bitcoins, albeit with a clear warning of the risks involved. And in February 2018, in an almost poetic closure of Lightning’s alpha stage, Bitcoin’s legendary Lazlo Hanyecz of “Bitcoin pizza” fame announced that he’d bought pizzas (of course!) through the Lightning Network.
Lazlo Hanyecz enjoying his pizzas. Source: http://eclipse.heliacal.net/~solar/bitcoin/lightning-pizza/
After years of development, and even more years of conceptualization, perhaps the biggest milestone of all was reached several weeks ago.
Midway through March 2018, Lightning Labs’ lnd was the first Lightning implementation to be released in beta. Announced simultaneously with a $2.5 million seed investment round, which included big-name investors like Twitter CEO Jack Dorsey, Lightning Labs deemed the Lightning implementation it had been spearheading ready for use on Bitcoin’s mainnet — though primarily for technical users.
This announcement was followed by a tweet from ACINQ on March 28, announcing that eclair had also been released in beta and was thus deemed ready for mainnet use, as well. The startup added that their Android Lightning wallet would be released the following week. (At the time of publication of this article, that is this week.)
Blockstream’s c-lightning implementation has not yet been released in beta, though its development team indicated to Bitcoin Magazine this may follow shortly, too. Adding to a still-growing list, the blockchain development company did, however, introduce seven brand-new Lapps in the last week of March, highlighting the company’s progress on the Lightning front.
While people were already using Lightning software even in alpha, the beta phase has only further stimulated this growth. At the time of publication of this article, well over 1,000 Lightning nodes have opened up almost 5,000 payment channels, holding over 10 bitcoin (some $70,000 at the time of writing) in aggregate. Hundreds of new nodes are coming online every day, and even a Litecoin-specific Lightning Network is taking shape, which could, in the future, be made interoperable with Bitcoin’s.
A graph of the Lightning Network at time of publication. Source: lnmainnet.gaben.win
Yet, even with all this progress, it’s still early days for the Lightning Network. Most users of the network today are still very technical (often developers), and use cases are mostly experimental. While the beta software release(s) are major milestones, development and improvement of the network is an ongoing process, and much still needs to be done, while open questions on routing, privacy and other risks remain. Most likely, only further adoption will answer them.
Author’s note: While doing research for this article, I came to realize that the full (pre)history of the Lightning Network is even more extensive than I already knew it was. Outlining it into a single piece required cutting corners and leaving out details, which does not do justice to all the people, projects and concepts that help(ed) realize this technology. This article an attempt at outlining the story so far, but it is best understood as a rough summary — not an exhaustive historic or technical account. Thanks to everyone who provided information and other input.
On a day when the cryptocurrency community was on high alert for gags, whimsical announcements and other tomfoolery, the creator of Ethereum, known for pulling his own pranks in the past, stepped forth with a most serious proposal: setting a cap on Ethereum’s monetary supply — which has long had no cap at all — at 120 million.
On April 1, 2018, a day known as April Fools’ Day, Vitalik Buterin published Ethereum Improvement Proposal (EIP) 960 to limit the supply of ether (ETH) to 120,204,432 — twice the amount issued in the project’s presale in 2014. To those paying close attention, the proposal was listed under “meta,” a hint that this was a meta joke, meant to leave people scratching their heads and wondering if he was being serious or not.
For those still wondering whether or not https://t.co/z44anVrOuT was an April Fool’s joke, the answer is: it was an April Fool’s meta-joke. *The point* was seeing people argue about whether or not the proposal is “real”.
— Vitalik “Not giving away ETH” Buterin (@VitalikButerin) April 2, 2018
If the community wants fixed supply and people believe that EIP 960 is a good way to achieve that, then it should adopt the proposal. If the community does not, then it should not. This is true regardless of whether or not the original intent was in jest.
— Vitalik “Not giving away ETH” Buterin (@VitalikButerin) April 2, 2018
All meta joking aside, the proposal recommends implementing the cap as part of a hard fork when the platform switches from its proof-of-work consensus algorithm to Casper, a proof-of stake algorithm still in development, as early as the end of this year.
“In order to ensure the economic sustainability of the platform under the widest possible variety of circumstances, and in light of the fact that issuing new coins to proof of work miners is no longer an effective way of promoting an egalitarian coin distribution or any other significant policy goal, I propose that we agree on a hard cap for the total quantity of ETH,” the proposal states.
This is the first time Buterin has suggested setting a limit on Ethereum’s supply of ether.
Some argue that a supply limit is important to a cryptocurrency because it creates scarcity, making a “coin” more valuable, sort of like gold. Yet, a hard cap can also mean there is no way to replenish the supply when coins fall out of circulation due to people dying, losing them or even holding on to them.
Unlike Bitcoin, which has a supply limit of 21 million coins programmed into it, Ethereum has never had a monetary cap, which means over time the number of ether in the system could go up indefinitely.
As it stands, 60 million ether were initially created during the Ethereum presale to raise money for building the network. Following the network’s launch in 2015, five new ether have been created for every new block, every 15 seconds. That brings the current supply of ether to around 98.5 million and counting. If EIP 960 goes through, the new cap would likely require reducing the issuance of new coins or finding a way to balance the supply.
For instance, in an earlier blog post, Buterin talks about introducing “sinks” or fees into the system that would lead to ether actually being destroyed, as a way to create more scarcity.
Buterin’s proposal to change Ethereum’s monetary policy is timely because it sets the stage for Casper, which will introduce changes to how ether are distributed and used.
Buterin’s arguments for a supply cap are based on the idea that in a proof-of-stake system, the coin holders themselves are the ones who get the block rewards, not the miners. Also, because proof of stake consumes far less energy than proof of work, block rewards can be lower. Finally, he thinks the money supply can be better controlled through a system of fees and rewards paid by those using the platform.
It is important to keep in mind that EIP 960 is only a proposal and not certain to be adopted.
On March 20, 2018, it was revealed that a bug hidden in Coinbase’s Ethereum smart contract setup could have given users access to unlimited amounts of ether. At press time, it does not appear as though the vulnerability was ever exploited or even noticed by users.
The issue was first discovered last December by VI Company, a Dutch firm that specializes in fintech. The company was planning to give its employees ether bonuses in celebration of the upcoming holiday season when researchers noticed the issue with their “ETH receiving code” while garnering funds from a contract. They saw that by using a smart contract, a series of digital wallets could be “tricked” into recording ether transfers and purchases that had never actually happened.
The team issued the following statement in a vulnerability report later published on the firm’s HackerOne account in January 2018:
“By using a smart contract to distribute [ETH] over a set of wallets, you can manipulate the account balance of your Coinbase account. If [one] wallet transaction in the smart contract fails, all transactions before that will be reversed, but on Coinbase, these transactions will not be reversed, meaning a person could add as much Ethereum to their balance as they want.”
The report specified the following steps for taking advantage of the exchange’s weakness:
Had users noticed the glitch, they could have been able to turn themselves into crypto-billionaires overnight.
The problem was resolved after the team changed the contract handling logic. VI Company claimed there were only “accidental” losses for Coinbase and stated there were no attempts to exploit the vulnerability. Coinbase executives later thanked VI Company’s counterparts by sending them a $10,000 bounty for their work.
Though instances like these are rare, they can occur from time to time. In February 2018, popular Japanese exchange Zaif aroused heavy controversy after a bug was exposed that allowed users to purchase bitcoin through its system at no charge. Representatives of the company claimed the error occurred within its “price calculation system” and that seven transactions had occurred where customers bought bitcoin for zero yen. Six of these transactions were later reversed.
Zaif’s parent company, Tech Bureau Corp, had faced several checks the previous month after regulators claimed it was vulnerable to cyberattacks. The exchange later apologized to users, saying the problem would not affect individual customer amounts. Zaif is one of a small handful of cryptocurrency trading platforms currently registered with the Japanese government.
Any programmer who has ever sat down to build a DApp at one point has had to think about the limits of current public blockchains, the most important and obvious one being their limited throughput, i.e., the number of transactions processed per second. In order to run a DApp that can handle real-world throughput requirements, blockchains must become scalable.
One answer to blockchain scaling is sharding. Sharding promises to increase the throughput by changing the way blocks get validated by the network. The key feature of sharding that makes it unique among all (on-chain) scaling solutions is horizontal scaling, i.e., the throughput increases as the mining network expands. This particular characteristic of sharding may make it the ideal fuel to spur rapid adoption of blockchain technology.
This article will briefly discuss the scaling issues with existing blockchain platforms — briefly only, because most readers must already be familiar with it. It will then discuss how sharding and its different forms can be a promising solution to the scaling problem. It will also touch upon some of the theoretical and practical challenges to implementing sharding and how some of these challenges can be overcome.
One of the biggest problems that public blockchain platforms face today is scalability. All popular platforms are struggling to handle a larger number of transactions per second. In fact, today the public Ethereum and Bitcoin networks can handle 7-10 transactions per second on average. These figures are far inferior to those of centralized payment processors like Visa, which processes roughly 8,000 transactions per second on average.
Slow transaction processing creates a major problem because they choke up the networks, making it difficult to use the blockchain for applications such as real-time payments. The longer a payment takes to be processed, the more inconvenient it becomes for the end user; this is one of the main reasons why payment methods like PayPal and credit cards like Visa are still much more attractive. As more complex DApps start to rely on the same network, the problems caused by slower transaction speed will only compound.
From a more technical standpoint, all blockchain consensus protocols have a challenging limitation: Every fully participating node in the network must validate every transaction and must seek agreement from other nodes on it, and this is the component of blockchain technology that creates distributed ledgers and makes it secure.
In most chains like Bitcoin and Ethereum, nodes are run by the public. While the decentralized consensus mechanism provides some vital advantages such as fault tolerance, security, political neutrality and authenticity, this method to verify chains comes at the cost of scalability. It will take more and more processing power to verify these public blockchains as they get larger, and this may create bottlenecks in these networks and slow down the creation of new applications.
Sharding is a scaling technique that was inspired by a traditional concept of database sharding, whereby a database is partitioned into several pieces and placed on different servers. In the context of a public blockchain, the transaction load on the network would be divided into different shards comprising different nodes on the network. As a consequence, each node would process only a fraction of incoming transactions, and it would do so in parallel with other nodes on the network. Breaking the network into shards would result in more transactions being processed and verified simultaneously. As a result, it becomes possible to process more and more transactions as the network grows. This property is also referred to as horizontal scaling.
We could imagine that existing blockchains operate like a busy highway with one toll station operating on only one toll booth. The result would be a traffic jam as people wait in long lines to pass the toll station. Implementing a sharding-based blockchain is like adding 15 or 20 toll booths to the highway. It would dramatically improve the rate at which traffic can progress through the stations. Sharding would make a tremendous amount of difference and dramatically improve transaction speed.
The implementation of sharding-based blockchains could have various benefits for public blockchains. First, thousands of transactions or even more could be processed every single second, changing the way people feel about the efficiency of cryptocurrencies as payment methods. Improving transaction throughput will bring more and more users and applications to decentralized systems, and this will, in turn, advocate further adoption of blockchains, making mining more profitable and attract more nodes to public networks, creating a virtuous cycle.
Furthermore, sharding could help bring down transaction fees since less processing will be needed to validate a single transaction; nodes can charge smaller fees and still be profitable to run. Coupling low fees with high transaction processing capability, public chains will become increasingly attractive to real-world use cases. The more these positive trends continue, the more mainstream adoption we’ll see of cryptocurrencies and blockchain applications in general.
This is the basic concept, but there are more granular ways to implement sharding strategies like network and transaction sharding, and state sharding. With network and transaction sharding, the network of blockchain nodes is split into different shards, with each shard formed to process and reach consensus on a different subset of transactions. This way, unconnected subsets of transactions can be processed in parallel, significantly boosting the transaction throughput by orders of magnitude.
On the other hand, on today’s mainstream public blockchains, the burden of storing transactions, smart contracts and various states is borne by all public nodes, which could make it prohibitively expensive in terms of required storage space to maintain ongoing operations on the blockchain.
One potential approach, called state sharding, has been proposed to resolve this issue. The crux is to divide the entire storage into pieces and let different shards store different parts; thus every node is only responsible for hosting its own shard’s data instead of the complete blockchain state.
While all the different forms of sharding may be very intuitive, unspooling the technical details can reveal the complexity of the approaches and the underlying challenges. Some of these challenges are easy to overcome, while others not quite so. Generally speaking, network and transaction sharding are easier to accomplish while state sharding is much more complicated. Below, for the different sharding mechanisms, we categorically discuss some of these challenges and how feasible are they to be overcome.
The first and foremost challenge in sharding is the creation of shards. A mechanism will need to be developed to determine which nodes reside in which shard in a secure way in order to avoid possible attacks from someone who gains a lot of control over a particular shard.
The best approach to beat an adversary (at least in most of the cases) is through randomness. By leveraging randomness, it should become possible for the network to randomly sample nodes to form a shard. Random sampling prevents malicious nodes from overpopulating a single shard.
But, where should the randomness come from? The most readily available source of public randomness is in blocks, for instance, the Merkle tree root of transactions. The randomness available in blocks is publicly verifiable and (close to) uniform random bits can be extracted from it through randomness extractors.
However, simply having a randomized mechanism to assign nodes to a shard is not sufficient. One must also ensure that the network agrees on the members in a shard. This can be achieved through a consensus protocol like proof of work, for example.
Transaction sharding isn’t as simple as it may sound. Consider introducing transaction sharding in a Bitcoin-like system (without smart contracts), where the state of the system is defined using UTXOs. Let us suppose that the network is already composed of shards and a user sends out a transaction. The transaction has two inputs and one output. Now, how should this transaction be assigned to a shard?
The most intuitive approach would be to decide on the shard based on the last few bits of the transaction hash. For instance, if the last bit of the hash is 0, then the transaction is assigned to the first shard, else it is assigned to the second shard (assuming we have only two shards). This allows the transaction to be validated within a single shard. However, if the user is malicious, he may create another transaction with the same two inputs but a different output — yes, a double spend. The second transaction will have a different hash and, hence, the two transactions may end up in different shards. Each shard will then separately validate the received transaction while being oblivious of the double-spend transaction being validated in the other shard.
In order to prevent the double spend, the shards will have to communicate with each other while the validation is in progress. In fact, since the double-spend transaction may land in any shard, a given shard receiving a transaction will have to communicate with every other shard. The communication overhead may, in fact, defeat the entire purpose of transaction sharding.
On the other hand, the problem is much simpler to solve when we have an account-based system (without smart contracts). Each transaction then will have a sender’s address and can then be assigned to a shard based on the sender’s address. This ensures that two double-spend transactions will get validated in the same shard and hence can be easily detected without any cross-shard communication.
With the promises of state sharding come a new set of challenges. As a matter of fact, state sharding is the most challenging of all sharding proposals so far.
Continuing with our account-based model (let us not bring in smart contracts for the moment), in a state-sharded blockchain, a specific shard will only maintain a portion of the state. For instance, if we have two shards and only two user accounts, say for Alice and Bob, respectively, then each shard will keep the balance of one single user.
Imagine that Alice creates a transaction to pay Bob. The transaction will be handled by the first shard. Once the transaction is validated, the information about Bob’s new balance must be shared with his shard. If two popular accounts are handled by different shards, then this may entail frequent cross-shard communication and state exchange. Ensuring that cross-shard communication will not outweigh the performance gains from state sharding is still an open research problem.
One possible way to reduce the cross-shard communication overhead is to restrict users from making cross-shard transactions. With our example, this would mean that Alice would not be allowed to transact directly with Bob. If ever Alice has to transact with Bob, she will have to hold an account in that shard. While this does eliminate any cross-shard communication, it may limit the usability of the platform somewhat.
The second challenge with state sharding is data availability. Consider a scenario where, for some reason, a given shard is attacked and goes offline. Since the state of the system is not replicated across all shards, the network can no longer validate transactions that have dependency on the offline shard. As a result, the blockchain may become largely unusable. A solution to this problem is to maintain archival or backup nodes that can help the network troubleshoot and recover from data unavailability. However, those nodes will then have to store the entire state of the system and hence may introduce centralization risks.
Another point to consider in any sharding mechanism (certainly not specific to state sharding) is to ensure that shards are not static for resilience against attacks and failures; the network must accept new nodes and assign them in a random manner to different shards. In other words, the network must get reshuffled once in a while.
However, reshuffling in the case of state sharding is tricky. Since each shard only maintains a portion of the state, reshuffling the network in one go may render the entire system unavailable until some synchronization is completed. To prevent outage, the network must be reshuffled gradually to ensure that every shard has enough old nodes before a node is evicted.
Similarly, once a new node joins a shard, one has to ensure that the node is given ample time to sync with the state of the shard; otherwise the incoming node will reject outright every single transaction.
In conclusion, sharding is definitely an exciting and promising direction for blockchains to pursue in order to solve scalability problems without compromising decentralization and transparency. However, there is no doubt that sharding, particularly state sharding, is notoriously difficult to do right both at the design level and at the implementation level.
Sharding should be handled with care. Also, more research needs to be done to establish the viability of state sharding as it may not be the silver bullet to storage problems. Researchers and developers are actively seeking alternate solutions at this moment. And perhaps, the answer is just right around the corner.
This is a guest post by Dr. Yaoqi Jia, head of technology at Zilliqa. Views expressed are his own and do not necessarily reflect those of BTC Media or Bitcoin Magazine.
Last week, on March 15, 2018, Lightning Labs unveiled their beta for the Lightning Network in a flash of media attention and enthusiasm. The Lightning Network has been heralded as a solution to Bitcoin’s scalability issues, and the developments were greeted by the community with tremendous optimism.
A little less than a week later, the Stellar network team has announced that they will be integrating the Lightning Network. That makes Stellar among the first projects to formally announce integration of the Lightning Network since the beta release last week.
“We’re super excited about Lighting,” Stellar founder Jed McCaleb told Bitcoin Magazine in an interview. “It’s a great idea and a necessary one if any of these protocols are going to achieve their vision.”
To McCaleb, Stellar isn’t an exception, and he believes that the Lightning Network will be integral to the growth of the platform going forward:
“We have a lot of partnerships that have been announced and that will be announced soon that will start pushing the threshold for what Stellar can do. In order to keep the network efficient and stable, we need something like Lightning.”
The blog post echoes these sentiments, as it claims that the Lightning Network will help Stellar move forward into a more scalable future. McCaleb has actually toyed with the idea of implementing the Lightning Network since the technology’s theoretical infancy. In a 2015 blog post, he wrote somewhat of a treatise on the subject, outlining how the network operates and stating that a “Lightning-like system” is already feasible on Stellar.
With today’s announcement, McCaleb and the rest of the team are dropping the “like” and keeping the “Lightning,” going for a full-scale implementation on Stellar’s platform. They’ve released a tentative timeline regarding this implementation that included a BUMP_SEQUENCE testnet on April 1, 2018; beta implementation for state channels on August 1, 2018; a livenet on Stellar for these state channels and a Lightning Network Beta on October 1, 2018; and fully functional livenet for the Lightning Network on December 1, 2018.
The addition of the BUMP_SEQUENCE operation and state channels are hallmarks of Stellar’s individual implementation of the technology and reflect McCaleb’s original plans for Stellar’s use of it. Like payment channels on Bitcoin’s Lightning Network, state channels will be the off-chain avenue through which users can conduct payments, but they’ll be open to additional network features, as well, “such as … creating, deleting or changing permissions on accounts.”
These channels will make use of source accounts and sequence numbers to keep tabs on payments before the finalizing transaction is sent to the network. As the name suggests, a source account represents a user’s account on a state channel, and the sequence number tracks the number and sequence of payments made within that channel.
According to the blog post, “The new operation enables transactions to arbitrarily increase the sequence number of a target account.”
The team will release further developments to detail how state channels can be used for “multi-hop payments” between users without established channels and cross-chain atomic swaps. In addition, it invites peer review and feedback from the community and researchers as the current schematics are not final.
For now, though, McCaleb and the rest of the team are focused on getting the ball rolling so Stellar users — and the rest of the crypto ecosystem — can start reaping Lightning’s benefits:
“There’s three main benefits,” he said to Bitcoin Magazine. “There’s the scalability benefit, obviously — Stellar can scale pretty well right now but Lightning takes that much, much further; there’s privacy benefits, as Lightning allows transactions to be kept off the public ledger; and then there’s also interoperability,” he said in reference to the prospect of Atomic Swaps.
“It should make a much more flexible, interoperable ecosystem which is good for everyone.”
Today, March 15, Lightning Labs announced lnd 0.4-beta, the first beta release of the Lightning software implementation spearheaded by the development company. This makes lnd the first ever Lightning implementation to be marked as beta, meaning that the development team deems it to be feature complete and safe enough for use on Bitcoin’s mainnet — though the software could still contain bugs. In conjunction, Lightning Labs has also announced a $2.5 million seed investment round, which will fund further development of lnd.
“We’re calling this lnd release a beta as it has all the necessary safety, fault-tolerance and security features that we’ve deemed necessary to feel comfortable with early users to start experimenting with small amounts of real bitcoin and litecoin,” Lightning Labs CTO Olaoluwa Osuntokun told Bitcoin Magazine.
As an open and permissionless project, the Lightning Network was already being rolled out by users eager to test the highly anticipated scaling layer — even before any Lightning implementation was released in beta. Lightning Labs, in particular, favored a more cautious approach, as the development team was still working on “breaking changes,” Osuntokun explained. He noted that users who have opened payment channels with previous lnd releases will now have to close these channels before upgrading to the latest version.
Other new features implemented in the lnd beta include a new private key seed format specifically designed for Lightning; improved fault-tolerance in case something goes wrong; and smarter pathfinding for routing payments, as well as bug fixes and other improvements.
In conjunction with the software release, Lightning Labs announced a seed-funding round of $2.5 million to fund continued development of lnd. Investors include big names in the Bitcoin, blockchain and broader tech industry, such as Litecoin creator Charlie Lee; BitGo CTO Ben Davenport; Square and Twitter CEO Jack Dorsey; former PayPal COO and Yammer founder David Sacks; Tesla and SpaceX angel investor Bill Lee; head of Square Capital and Square’s People Lead Jacqueline Reses; Eventbrite co-founder Kevin Hartz; Robinhood co-founder Vlad Tenev; and The Hive, Digital Currency Group and others.
Lightning Labs CEO Elizabeth Stark hopes that, with the release of the lnd beta and the seed-funding round, development of Lightning Network technology will move to its next phase.
“Lightning is not just about scalability, it’s also an app development platform. I think a lot of people don’t get that yet,” she told Bitcoin Magazine.
Building on lnd, developers can write apps that connect to the Lightning Network. Lightning Lab’s Lightning App Directory already features several dozen such apps, not limited to apps developed by Lightning Labs itself. Examples include Lightning wallets for desktop and mobile, a blogging platform with micropayments, a gambling site and more. Although most of these apps are only available on Bitcoin’s testnet so far, this is likely to change with the release of lnd 0.4-beta.
Moving forward, Lightning Labs plans to implement a range of new features in lnd, including “watchtowers” to outsource security (channel monitoring) to third parties, atomic multipath payments to increase payment channel liquidity, routing tools for Lightning node operators and more. And while lnd is already compatible with both Bitcoin and Litecoin, the two networks are not yet interoperable; a fix for this is also planned for a future release.
It should be noted that although the lnd 0.4-beta release marks a milestone in the development of the Lightning Network, it is still in beta — so it is still somewhat risky to use.
“This is still an early beta version aimed at developers and advanced users,” Stark said. “As with any early software there will still be bugs. Users shouldn’t be putting more money on Lightning right now than they are willing to lose.”
For full details of the release, see the lnd 0.4-beta release notes.
Owning cryptocurrency comes with its own set of challenges. One of the biggest of those challenges is managing the private keys that enable you to spend funds. Lose your private keys, and your money is gone.
In a business environment, a common way to manage funds owned by multiple people is via what’s called a multisignature (multisig) address, a type of smart contract requiring two or more parties to sign off on a transaction to move the funds.
This can be problematic, however. Let’s say you have a three-of-three multisig that requires you and two business partners to sign off on a transaction. If one person dies, disappears or becomes incapacitated, those assets become frozen — a risk some might feel uncomfortable with when dealing with tens of thousands of dollars or more.
One way to ameliorate that risk might be to opt for a two-of-three multisig, where only two instead of all three individuals need to sign off on a transaction. But that’s not a complete solution either. Two players could conspire against the other one and run off with the money.
What now? If your funds are on the Ethereum blockchain, you could write a smart contract that would allow you to free the funds if one person in your trio disappeared.
However, Bitcoin with its limited scripting language makes things more difficult. “This seems like an unsolvable problem if you think about the traditional tools,” said Ari Juels, a professor at Cornell Tech and co-director of the Cornell Initiative for Cryptocurrencies and Contracts (IC3).
In a paper titled “Paralysis Proofs: How to Prevent Your Bitcoin from Vanishing,” researchers Fan Zhang, Phil Daian, Iddo Bentov and Ari Juels from the IC3 outline how to deal with what happens when a party is unable, or unwilling, to sign off on a multisig transaction in Bitcoin. The solution involves a combination of blockchain technology and trusted hardware — Intel SGX, in this case.
Trusted hardware allows you to run code inside a protected enclave. Even a computer’s own operating system is unable to access data inside an enclave, so if your computer were to be hacked, the code in the enclave would remain secure.
IC3’s solution proposes replacing a trusted third party, such as a lawyer or a bank, who would put money in an escrow, with a trusted hardware solution that retains control of a master key to the funds.
If one of the three people in the contract dies, the other two initiate a “paralysis proof.” That proof is based on a challenge sent to the missing third person. If the missing person responds to the challenge, the money stays put. If the missing person does not respond, the trusted hardware releases the funds to the remaining two players.
Trusted hardware is only part of the solution, however. If the third person were to try and respond to the challenge request with an indication she is still alive, conceivably, the other players could intercept that message. To ensure that does not happen, the second half of IC3’s solution involves sending the message via the blockchain, which provides a tamper-proof and censorship-resistant medium.
“By combining these two [methods], we can achieve the exact properties we’re after,” Juels explained to Bitcoin Magazine. “We can enable trusted hardware to determine whether or not somebody is alive, and there is no way to prevent a relevant message from getting transmitted if it is coming through the blockchain.”
Put simply, this is how to achieve a paralysis proof as outlined by the IC3 researchers:
This not the only use case for a paralysis-proof system. Juels thinks the solution would work well in any situation that called for a controlled access to private keys that could not otherwise be maintained on a blockchain. “It is actually a very general scheme you could use for lots of other purposes,” he said.
For instance, a paralysis-proof system could be used as a dead man’s switch for control over the release (or decryption) of leaked information or a journalist’s raw materials. It could also be used in numerous ways to control daily spending limits from a common pool of money or as a conditioned expenditure based on an outside event (as reported by an oracle), like a student getting good grades or a salesperson meeting a sales quota.
“Basically, you can a rich set of conditions around the expenditure of money using the fact that a trusted hardware kind of acts like a trusted third party,” said Juels.
Following the release of the first Bitcoin Lightning Network white paper, published in February 2015, developers have been working on Lightning Network implementations to enhance the throughput and usability of the Bitcoin network. For an overview, see this three-part series on “Understanding the Lightning Network.”
In December 2017, lightning developers ACINQ, Blockstream and Lightning Labs, announced the 1.0 release of the Lightning protocol and the world’s first Lightning test payments on the Bitcoin mainnet across all three implementations. The standardization and deployment of the Lightning Network’s second-level, off-chain payment layer is expected to result in instant bitcoin transactions, improved scalability and lower fees, enabling fast and cheap micropayments.
Blockstream’s implementation of the Lightning spec, c-lightning, is a low-level technology designed to implement the Lightning spec without added complexity. At the same time, Blockstream realizes that developer tools are needed to unlock the power of Lightning for advanced applications, such as those that integrate with credit card companies and with existing online payment systems.
“Web developers will be able to work with c-lightning through their normal programming techniques, and they’ll also get expanded functionality such as currency conversion, invoice metadata, streaming payment updates and webhooks,” reads the Blockstream announcement. “Together, these additions make it easy for developers to use c-lightning to create their own, independent web-payment infrastructures.”
“Lightning Charge makes integration with the Lightning Network much simpler, since it bridges the needs of application developers and the underlying infrastructure, to provide a simple and extensible way to accept Lightning payments,” Blockstream developer Christian Decker said in conversation with Bitcoin Magazine.
“Since the introduction of Lightning Charge, less than 48 hours ago, we have seen a dramatic interest in the Lightning Network, both on the user as well as the developer side,” Decker added. “We have gotten a lot of feedback, and the mainnet network has doubled in the number of participants.”
The desired effect of the Lightning Charge launch was to reach a wider audience, get early feedback from future users and to showcase what will be possible in a not-so-distant future, and I think we have achieved that goal.
Israeli entrepreneur Nadav Ivgi, founder of Bitrated, worked with Blockstream developers to create Lightning Charge. “Together with him we built this new code, or this immediate piece of software that provides this nicer to use interface,” said Decker.
“So far the development for Lightning has been mostly on the network side of things. It’s been very much this close-knit group of people that are building it and are trying to build the infrastructure. Infrastructure is nice to have. But if nobody can actually use it then it’s not worth much, right?”
To test Lightning Charge, Blockstream is launching the Blockstream Store, a working e-commerce site that allows users to make small purchases of stickers and t-shirts. “By offering an early demonstration of this cutting-edge technology, we hope to bring Lightning to life with real-world functionality, providing a way for you to test Lightning and become a part of the micropayment revolution,” states the Blockstream announcement.
The Blockstream Store, built on WordPress and WooCommerce, connects with Lightning Charge and c-lightning through a WooCommerce Lightning Gateway, which Blockstream also released as part of the Elements Project.
The only way to purchase the items in the Blockstream store is with a Lightning payment. A disclaimer warns that, although the products sold in the store are real, this store is for testing and demonstration purposes only.
“Lightning is still very new and contains known and unknown bugs,” reads the disclaimer, adding that users may lose funds.
“We believe this is an important step towards a full rollout of the network as a whole, however we’d like to remind users that the Lightning Network is still experimental and that testnet is to be preferred for testing before making the jump to mainnet,” Decker told Bitcoin Magazine.
On December 14, 2017, BitPay announced a first step toward enforcing the payment protocol: All orders of the BitPay Card will require payments from Payment Protocol-compatible wallets, such as BitPay’s own wallet and a few others. This announcement came after an initial notice in November 2017, when BitPay first announced that BitPay invoices would soon require payments from wallets compatible with the Bitcoin Payment Protocol.
BitPay’s move has since been met with resistance by some wallet developers that don’t support the Bitcoin Payment Protocol; some are suggesting that BitPay is abusing its leading position in the payment processing space and putting user security at risk.
“We absolutely do not support BitPay in aggressively using their dominant position of market share to bully wallet providers into supporting their business plans or bully users into a system that degrades their privacy and the fungibility of bitcoin as a whole,” stated bitcoin wallet Samourai in its blog post of January 2, 2018.
The Bitcoin Payment Protocol (BIP70), proposed by Gavin Andresen and Mike Hearn in 2013, describes a protocol for communication between a merchant and their customer, “enabling both a better customer experience and better security against man-in-the-middle attacks on the payment process.” A detailed explanation of the details of the payment protocol, written by Mike Hearn in Q/A format, is available on the Bitcoin forum.
According to BitPay, the Payment Protocol will reduce user error in bitcoin payments, such as payments sent to a wrong address or with a transaction fee that is too low for fast processing by the Bitcoin network.
“We answer thousands of customer support requests every month, and we see first-hand how these problems affect BitPay merchants and their customers,” notes BitPay, adding that if two wallets both “speak” Payment Protocol, the correct receiving bitcoin address and the correct sending amount are locked in automatically by creating an SSL-secured connection to the true owner of the receiving bitcoin address. Instead of cryptic Bitcoin addresses, the protocol uses human readable identifiers, which are then mapped to Bitcoin addresses.
“Our next step will be requiring Payment Protocol payments for all BitPay Card loads,” stated BitPay. “From there, we will move to require Payment Protocol for all BitPay invoices … We continue to work with other wallet providers in the Bitcoin ecosystem to advance adoption of the Bitcoin Payment Protocol. We’re encouraged by the response we have received. Widespread adoption of Payment Protocol will immediately improve the bitcoin payment experience.”
According to a list provided on the BitPay website, Copay, Mycelium and Electrum wallets, along with Bitcoin Core, support Payment Protocol payments. “These true bitcoin wallets all already ‘speak’ Payment Protocol,” stated BitPay. “If you are using a non-Payment Protocol wallet or service to pay BitPay invoices, you will need to move your spending bitcoin to a wallet or service which can support Payment Protocol. We strongly recommend that you use a true bitcoin wallet for spending to avoid delayed transactions, but you will be able to use any service compatible with Payment Protocol.”
This list, however, is out-of-date. Bitcoin Magazine reached out to several other wallets to verify their status.
“Our currently released app Airbitz does support BIP70 and has since 2015,” Paul Puey, Co-Founder and CEO of AirBitz (recently rebranded as Edge), told Bitcoin Magazine. “Edge Wallet (currently in beta) will support BIP70 in a future production version.” BitPay currently lists Airbitz as not supporting BIP70.
Bread also has supported BIP70 since 2015, contrary to information supplied on BitPay’s list.
One of the most outspoken opponents of this policy shift has been Samourai Wallet.
“We have to be very clear here,” Samourai stated bluntly in its recent blog post. “Samourai Wallet will not support BIP70 in our products, therefore, our wallet users will NOT be able to send bitcoin to QR codes generated by BitPay invoices, as they do not provide a valid Bitcoin address.”
According to Samourai, BIP70 “remains largely unadopted by the majority of wallet and service providers” due to many security and privacy concerns, including the required support of legacy public-key infrastructure features with known vulnerabilities, such as OpenSSL and Heartbleed.
Indeed, the recent revelations about Meltdown and Spectre have created additional security concerns among some critics.
“Meltdown/Spectre greatly increase the risk of keys being stolen from memory,” James Hilliard, developer and MyRig engineer, told Bitcoin Magazine, “since they are side-channel attacks that allow processes to spy on the memory other processes (wallet private keys generally have to go into memory at some point in order to sign the transaction).”
“We do share some of the concerns but do not feel as strongly as Samourai Wallet,” said Puey. “In the case of the acquisition of a payment QR code from a website, one is already trusting SSL public key infrastructure to know that a public address is from the owner. Adding BIP70 to that makes it no worse. However, if one is doing a peer-to-peer transaction between two wallets that are physically next to each other, there is no need to rely on an https server query to obtain a public address, and that process absolutely introduces more risk than necessary.”
Many bitcoin wallets, including Coinbase and Jaxx, don’t support BIP70 at the moment. Others, like Airbitz and its upcoming Edge, support BIP70 but less enthusiastically than BitPay.
Addison Cameron-Huff is President of Decentral, the company that develops the Jaxx wallet. Referring to BitPay’s statement that BIP70 does for Bitcoin what secured web-browsing (HTTPS) did for the internet, he told Bitcoin Magazine, “I think BitPay is overstating the case for BIP70. It’s also a bit misleading to refer to BIPs as ‘standards,’” adding that the “BIP” acronym stands for “Bitcoin Improvement Proposal,” not “Bitcoin Improvement Standard.”
“Not showing addresses is a big change in how people use Bitcoin, and, as of January 2018, I think it’s premature to force this change ecosystem-wide, but BitPay is only insisting upon this for people who want to use BitPay,” continued Cameron-Huff. “We’ll see over the coming months how this change affects their user base and whether alternative payment processing firms win marketshare (or don’t). Ultimately, the cryptocurrency world is one in which the best products and proposals tend to win out in the market, and only time will tell whether this was a good decision for BitPay and more importantly: a good decision for the Bitcoin community.”
“We have had multiple conversations with BitPay and have expressed our concerns with the BIP70 protocol including unnecessary complications that do not truly solve the problems presented,” said Puey. “We feel that extensions to the BIP21 spec could have been implemented that would have achieved the same goals that BitPay desired without the added complications, centralization or SSL security implications.”
“While we intend to continue supporting BIP70 we do NOT recommend that providers use it or require it to receive payment and instead pursue extensions to BIP21 instead,” concluded Puey. “We have experienced a multitude of issues with BitPay’s support of BIP70 including their own servers being unable to provide payment information through the provided payment URL causing wallets to fallback to BIP21-style payments if capable.”
Bread wallet CMO Aaron Lasher told Bitcoin Magazine that while Bread already supports BIP70, the company has plans to “make it work with BitPay in an upcoming release.” He emphasized that it will be important to maintain the wallet’s core functionality and ensure that its high level of privacy remains.
“Bread is a consumer-focused wallet, so we support anything at face value that improves or simplifies the user experience, provided we are able to maintain sufficient privacy and financial control on behalf of our users.”
Similarly, Cameron-Huff explained that while Jaxx doesn’t currently support BIP70, if BIP70 becomes an actual widely adopted standard, then Jaxx will enable it for users.
“We will be keeping an eye on this change with BitPay and other large blockchain ecosystem organizations,” concluded Cameron-Huff. “We are always looking to improve Jaxx but also have to balance this with not forcing changes upon our users or implementing hasty changes that might cause a negative experience for our 600,000 users.”
A representative from the hardware wallet Ledger told Bitcoin Magazine, “We do not plan yet to support BIP70 directly in our wallet as it’d only make sense if we could offer an end-to-end support to the hardware wallet which is not doable yet, considering the complexity of this protocol.”
Ledger added that it might support it through a translating gateway later in the future while keeping users aware of the extra risks. Like Airbitz/Edge, the company expressed a preference for BIP21.
“Security wise, we also believe that BIP70 is not in a great state today (not supporting ECDSA certificates, duplicating standard PKI issues where users have to authenticate possible rogue certificates, possibly forcing public authentication cookies on users through specific outputs) and would appreciate if all payment providers could keep offering regular BIP21 URLs for interoperability.”
In many ways, 2017 was Bitcoin’s best year yet. Most obviously, increased adoption made the pioneering cryptocurrency’s exchange rate skyrocket from under $1000 to well over 10 times that value.
But from a tech perspective, things seem to be just getting started: 2018 promises to be the year that a number of highly anticipated projects are either launched or adopted.
Here’s a brief overview of some of the most promising upcoming technological developments to keep an eye on in the new year.
Segregated Witness (SegWit) was one of Bitcoin’s biggest — if not the biggest — protocol upgrade to date. Activated in August 2017, it fixed the long-standing malleability bug, in turn better enabling second-layer protocols. Additionally, SegWit replaced Bitcoin’s block size limit with a block weight limit, allowing for increased transactions throughout the network, thereby lowering fees per transaction.
However, adoption of the upgrade has been off to a relatively slow start. While some wallets and services are utilizing the added block space offered by SegWit, many others are not yet doing so. This means that, while Bitcoin is technically capable of supporting between two and four megabytes worth of transactions per ten minutes, it barely exceeds 1.1 megabytes.
This is set to change in 2018.
For one, the Bitcoin Core wallet interface will allow users to accept and send SegWit transactions. Bitcoin Core 0.16, scheduled for May 2018 (though this may be moved forward), will most likely realize this through a new address format known as “bech32,” which also has some technical advantages that limit risks and mistakes (for example, those caused by typos).
“To spend coins from the P2SH format currently used for SegWit, users need to reveal a redeem script in the transaction,” Bitcoin Core and Blockstream developer Dr. Pieter Wuille, who also co-designed the bech32 address format, told Bitcoin Magazine.
“With native SegWit outputs this is no longer necessary, which means transactions take up less data. Recipients of SegWit transactions will be able to spend these coins at a lower cost.”
Perhaps even more importantly, several major Bitcoin services — like Coinbase — plan to upgrade to SegWit in 2018 as well. Since such services account for a large chunk of all transactions on the Bitcoin network, this could significantly decrease network congestion, thereby decreasing average transaction fees and confirmation times, even for those who do not use these services.
While further SegWit adoption should provide immediate relief of fee pressure and confirmation times, truly meaningful long-term scalability will likely be achieved with second-layer solutions built on top of Bitcoin’s blockchain.
One of the most highly anticipated solutions in this regard — especially for lower value transactions — is the lightning network. This overlay network, first proposed by Joseph Poon and Tadge Dryja in 2015, promises to enable near-free transactions and instant confirmations, all while leveraging Bitcoin’s security.
The solution has been under active development for about two years now, with major efforts by ACINQ, Blockstream and Lightning Labs. Progress on the scaling layer has been significant all throughout 2017, with early software releases of different but compatible software implementations, useable wallets interfaces and test transactions happening both on Bitcoin’s testnet and even on Bitcoin’s mainnet on a regular basis now.
“I’d say we have solved the main technical problems and have a relatively good idea on how to improve on the current system,” Christian Decker, lightning developer at Blockstream, told Bitcoin Magazine. “One last hurdle that’s worth mentioning is the network topology: We’d like to steer the network formation to be as decentralized as possible.”
Given the current state of development, adoption of the lightning network should only increase throughout 2018 — not just among developers, but increasingly among end users as well.
“Integration and testing will be the next major step forward,” Lightning Labs CEO Elizabeth Stark agreed, noting: “Some exchanges and wallets are already working on it.”
While it is sometimes misrepresented as such, Bitcoin is not really private right now. All transactions are included in the public blockchain for anyone to see, and transaction data analysis can reveal a lot about who owns what, who transacts with whom and more. While there are solutions available to increase privacy right now — like straightforward bitcoin mixers — these usually have significant drawbacks: They often require trusted parties or have privacy leaks.
TumbleBit was first proposed in 2016 by a group of researchers led by Ethan Heilman. It is essentially a coin-mixing protocol that uses a tumbler to create payment channels from all participants to all participants in a single mixing session. Everyone effectively receives different bitcoins than what they started with, breaking the trail of ownership for all. And importantly, TumbleBit utilizes clever cryptographic tricks to ensure that the tumbler can’t establish a link between users either.
An initial implementation of the TumbleBit protocol was coded by NBitcoin developer Nicolas Dorier in early 2017. His work was picked up by Ádám Ficsór as well as other developers, and blockchain platform Stratis announced it would implement the technology in its upcoming Breeze wallet, which also supports Bitcoin, by March 2018. Recently, in mid- December of 2017, Stratis released TumbleBit integration in this wallet in beta.
The other promising solution, ZeroLink, is an older concept: it was first proposed (not under the same name) by Bitcoin Core contributor and Blockstream CTO Gregory Maxwell, back in 2013. Not unlike TumbleBit, ZeroLink utilizes a central server to connect all users but without being able to link their transactions. As opposed to TumbleBit, however, it creates a single (CoinJoin) transaction between all participants, which makes the solution significantly cheaper.
This idea seemed to have been forgotten for some years until Ficsór (indeed, the same Ficsór that worked on TumbleBit) rediscovered it earlier this year. He switched his efforts from TumbleBit to a new ZeroLink project and has since finished an initial ZeroLink implementation.
Ficsór recently ran some tests with his ZeroLink implementation, and while results showed that his implementation needs improvement, Ficsór considers it likely that it will be properly usable within months.
“I could throw it out in the open right now and let people mix,” he told Bitcoin Magazine. “There is no risk of money loss at any point during the mix, and many mixing rounds were executing correctly. It is just some users would encounter some bugs I am not comfortable with fixing on the fly.”
Sidechains are alternative blockchains but with coins pegged one-to-one to specific bitcoins. This allows users to effectively “move” bitcoins to chains that operate under entirely different rules and means that Bitcoin and all its sidechains only use the “original” 21 million coins embedded in the Bitcoin protocol. A sidechain could then, for example, allow for faster confirmations, or more privacy, or extended smart contract capabilities, or just about anything else that altcoins are used for today.
The concept was first proposed by Blockstream CEO Dr. Adam Back and others back in 2014; it formed the basis around which Blockstream was first founded. Blockstream itself also launched the Liquid sidechain, which allows for instant transactions between — in particular — Bitcoin exchanges. Liquid is currently still in beta but could see its 1.0 release in 2018.
Another highly anticipated sidechain that has been in development for some time is RSK. RSK is set to enable support of Turing-complete smart contracts, hence bringing the flexibility of Ethereum to Bitcoin. RSK is currently in closed beta, with RSK Labs cofounder Sergio Demian Lerner suggesting a public release could follow soon.
Further, Bloq scientist Paul Sztorc recently finished a rough implementation of his drivechain project. Where both Liquid and RSK for now apply a “federated” model, where the sidechain is secured by a group of semi-trusted “gatekeepers,” drivechains would be secured by bitcoin miners.
If drivechains are deployed in 2018, the first iteration of such a sidechain could well be “Bitcoin Extended:” essentially a “big block” version of Bitcoin to allow for more transaction throughput. That said, reception of the proposal on the Bitcoin development mailing list and within Bitcoin’s development community has been mixed so far. Since drivechains do need a soft-fork protocol upgrade, the contention does make the future of drivechains a bit more uncertain.
“Miners could activate drivechains tomorrow, but they often outsource their understanding of ‘what software is good’,” Sztorc told Bitcoin Magazine. “So they’ll either have to decide for themselves that it is good, or it would have to make it into a Bitcoin release.”
Schnorr signatures, named after its inventor Claus-Peter Schnorr, are considered by many cryptographers to be the best type cryptographic signatures in the field. They offer a strong level of correctness, do not suffer from malleability, are relatively fast to verify and enable useful features, thanks to their mathematical properties. Now, with the activation of Segregated Witness, it could be relatively easy to implement Schnorr signatures on the Bitcoin protocol.
Perhaps the biggest advantage of the Schnorr signature algorithm is that multiple signatures can be aggregated into a single signature. In the context of Bitcoin, this means that one signature can prove ownership of multiple Bitcoin addresses (really, “inputs”). Since many transactions send coins from multiple inputs, having to include only one signature per transaction should significantly benefit Bitcoin’s scalability. Analysis based on historical transactions suggest it would save an average of 25 percent per transaction, which would increase Bitcoin’s maximum transaction capacity by about 33 percent.
Further on, Schnorr signatures could enable even more. For example, with Schnorr, it should also be possible to aggregate different signatures from a multi-signature transaction, which require multiple signatures to spend the same input. This could, in turn, make CoinJoin a cheaper alternative to regular transactions for participants, thereby incentivizing a more private-use Bitcoin. Eventually the mathematical properties of Schnorr signatures could even enable more advanced applications, such as smart contracts utilizing “Scriptless Scripts.”
Speaking to Bitcoin Magazine, Wuille confirmed that there will probably be a concrete Bitcoin Improvement Proposal for Schnorr signatures in 2018.
“We might, as a first step, propose an upgrade to support Schnorr signatures without aggregation,” he said. “This would be a bit more straightforward to implement and already offers benefits. Then a proposal to add aggregation would follow later.”
Whether Schnorr signatures will already be adopted and used on Bitcoin’s mainnet is harder to predict. It will require a soft fork protocol upgrade, and much depends on the peer review and testing process.
Chain is best known for the open-source Chain protocol and Chain Core, an enterprise blockchain infrastructure that facilitates financial transactions on scalable, private blockchain networks. An open-source developer edition of Chain Core is available to developers, with a testnet operated by Chain. Ivy was developed at Chain as a smart contract language for Chain Core. With Ivy for Bitcoin, which compiles to Bitcoin Script, Chain wants to make it easier for average programmers to write smart contracts for the public Bitcoin network.
By design, Bitcoin doesn’t include a Turing-complete programming language for smart contracts of arbitrary complexity. But this doesn’t mean that Bitcoin doesn’t support smart contracts. In fact, the simple, low-level, primitive operations included in Bitcoin’s native scripting language (Bitcoin Script) can be exploited to write smart contracts of significant complexity. “Bitcoin Script does provide a set of useful primitives — signature checks, hash computations, and absolute and relative timelocks — and the freedom to combine those primitives,” notes the Chain news release.
However, Bitcoin Script is not being fully used by software developers, which according to Chain is due to “the relative difficulty of reading and writing Bitcoin Script programs, and of creating and using addresses from those programs.” In fact, Bitcoin Script is a very low-level, assembly-like language, which doesn’t offer the readability and ease of use of high-level programming languages. Therefore, most Bitcoin programmers limit themselves to simple applications, without pushing Bitcoin Script to its limits.
The Chain developers want to change that with Ivy, a higher-level language that allows developers to create custom, SegWit-compatible Bitcoin addresses that enforce arbitrary combinations of conditions supported by the Bitcoin protocol, including signature checks, hash commitments and timelocks.
Earlier this year, Chain released Ivy Playground, a tool for designing, drafting and testing smart contracts on a Chain Core blockchain network with Ivy. Now, Chain is making Ivy available to Bitcoin developers and releasing Ivy Playground for Bitcoin, which allows developers to design, create and spend simulated Bitcoin contracts. The playground includes preloaded smart contract templates for Bitcoin and developer documentation.
A disclaimer states that Ivy is relatively untested prototype software and should be used for educational and research purposes only. “Do not attempt to use Ivy to control real Bitcoins,” warns the front-page document.
Besides Chain, other developers are realizing that Bitcoin needs more sophisticated smart contracts and user-friendly programming environments for smart contracts. Recently, blockchain developer Blockstream introduced Simplicity, a new programming language for blockchain-based smart contracts, intended for inclusion in Blockstream’s sidechains and eventually in Bitcoin. Lead developer Russell O’Connor said that “after extensive vetting,” Simplicity support could be considered for inclusion in one of the next releases of Bitcoin.
In the Blockstream announcement, O’Connor noted that Ivy’s programming language development efforts may be suitable for being compiled to Simplicity. But it now appears that Ivy’s progress toward these more sophisticated Bitcoin smart contracts is advancing faster than some might have expected.
Bulletproofs, presented in a paper titled “Bulletproofs: Short Proofs for Confidential Transactions and More,” describe a new zero-knowledge proof system. The proposal uses on-chain scaling for privacy and suggests a new, faster and more compact way to verify privacy-enhancing Confidential Transactions (CTs). Specifically, Bulletproofs can decrease the size of these verifications for these types of transactions drastically. Furthermore, the authors of the paper — Stanford University’s Applied Cryptography Group, overseen by professor Dan Boneh — have already managed to create a practical implementation for Bulletproofs.
This is how it works.
Currently, all transaction information — such as wallet addresses and especially the sent amount of bitcoins — are visible on the Bitcoin blockchain. This affects the privacy of all users. If we wish to pay wages via the Bitcoin network, for example, this means that every salary will be visible on the blockchain network. This, in turn, could mean that someone (like your landlord) could look up how much money you’re making to try and increase your rent accordingly.
Confidential Transactions are much needed to bring any type of blockchain to a higher level of privacy. Confidential Transactions combine and utilize several cryptographic tricks so that only the sender and the receiver of a transaction are aware of the amount transacted. These cryptographic tricks let users obfuscate the amounts they are transacting while still allowing onlookers to perform math on the obfuscated amounts. Basically, anyone can still check that the sum of sent bitcoins is greater than the sum of received bitcoins.
Confidential Transactions are realized with “zero-knowledge proofs.” These proofs are best described as a method for proving to another party that a Confidential Transaction is valid without conveying any information about the Confidential Transaction itself.
However, as stated in the Bulletproofs paper: “Current proposals for CT zero-knowledge proofs have either been prohibitively large or required a trusted setup. Neither is desirable.”
First of all, if we have to prove multiple range proofs, which is the case for multisignature transactions, the complexity and size will scale in a linear fashion. For example, if the size of a single proof is 2 kB, two proofs are 4 kB, three proofs are 6 kB and so on.
Additionally, zero-knowledge proofs typically require a trusted setup: they must be initialized by some trusted authority. However, the security properties of the Bitcoin system don’t apply to that authority because in practice it means that the authority could produce fake “proofs.” These fake proofs could lead to uncontrolled and undetectable inflation.
Bulletproofs could solve these problems.
According to the paper, “In any distributed system where proofs are transmitted over a network or stored for a long time, short proofs reduce overall cost.”
Bulletproofs are claimed to be able to reduce the cryptographic proof significantly: from 8 kB to 734 bytes, though this depends on what the transaction looks like. Moreover, when dealing with multiple proofs, the size increases with just a few percent instead of this linear scaling. And in addition, Bulletproofs do not require a trusted setup.
Andrew Poelstra, contributor to the research paper and mathematician at Blockstream, believes that Bulletproofs are very practical: “We have already implemented a first version in the Bitcoin crypto library libsec256k1, which can verify proofs three and a half times faster than the verifier for the classic rangeproofs. It is a drop-in replacement for classic rangeproofs that does not affect other aspects of the system and is therefore very easy to integrate.”
Until now, Confidential Transactions were just a theoretical concept because they were so heavy to implement. With Bulletproofs, the implementation of Confidential Transactions on Bitcoin suddenly becomes more likely.
Bitcoin is usually not considered the blockchain best suited for self-executing conditional payments, better known as smart contracts. While it does support basic programmability to enable features like time locks and multi-signature (multisig) schemes, competing projects like Ethereum, Ethereum Classic or Qtum are often expected to better support more advanced applications.
However, a new wave of research is increasingly questioning this assumption. For example, Scriptless Scripts, a project spearheaded by Blockstream mathematician Andrew Poelstra, cleverly utilizes the magic of cryptography to move smart contracts off-chain, while leveraging Bitcoin’s security, but without requiring extensive smart-contract support on the Bitcoin protocol itself.
Along similar conceptual lines, Discreet Log Contracts (DLCs) could deploy another class of smart contracts on top of Bitcoin. A project by one of the authors of the original Lightning Network white paper, Tadge Dryja, and recently presented at Scaling Bitcoin Stanford, DLCs could realize blockchain-enforced insurance companies, futures contracts, dollar-pegged coins and much more.
Here’s how that works.
Many types of smart contracts essentially boil down to “bets.”
Let’s say, for example, that someone wants to insure himself against being unable to travel due to a potential pilot strike. That person can then “bet” there will be a strike. If there is no strike, the “bet” is lost as if it were an insurance down payment. If there is a strike, on the other hand, the “bet” is won, like an insurance payout.
As a more interesting example perhaps, people can also bet on the price of BTC relative to the US dollar: a futures market. If someone bets that the BTC price will go down, and the BTC price does go down, he “wins” more BTC; if the BTC price goes up, he “loses” some BTC. Interestingly, this can be structured to ensure that the person entering into these “bets” is practically guaranteed to end up with the same USD value in BTC regardless of what happens. This can, in turn, be used to realize a “stablecoin” with fixed USD value on Bitcoin’s blockchain. (It should be noted that there are extreme examples where this doesn’t hold up, like a scenario where Bitcoin fails completely and BTC drops to zero dollars — but, in most cases, it works.)
However, while these types of smart contracts are interesting, they cannot be executed based on blockchain-based data alone. A blockchain cannot tell whether pilots are striking, nor what the USD/BTC exchange rate is. This requires data input from outside of the blockchain, and this is where “oracles” come in.
Oracles are essentially trusted sources of information; they provide data that cannot itself be “read” by a blockchain. This data can be inserted into a smart contract, which will then execute based on the oracle’s input.
Since the types of smart contracts described above need to rely on such external data sources anyway, it makes sense to leverage the trust in oracles in order to simplify a smart contract. Instead of more complex solutions, oracles can, for example, be “plugged into” a relatively basic multisig scheme.
As a simple example, let’s say that next summer Alice and Bob want to bet a bitcoin on the FIFA World Cup final between Argentina and Brazil. Alice thinks Argentina will win; Bob thinks Brazil will. To make this bet blockchain-enforceable, Alice and Bob both send one bitcoin to a multisig address that requires two of three signatures to spend the coins. One of these three keys is held by Alice, another key is held by Bob and the third key is held by the oracle.
If Argentina wins, Alice and Bob should both sign a transaction from this address that sends both bitcoins to Alice. Since this requires only two signatures, Alice and Bob’s signatures suffice, and the oracle never comes into play. (Needless to say, if Brazil wins it’s the other way around: Alice and Bob sign a transaction sending both coins to Bob.)
A problem arises only when the losing party — Bob — refuses to sign the transaction. It’s in this scenario that the oracle would use its third key to help Alice claim the two bitcoins. Importantly, exactly because this is an option, Bob really has no reason not to sign. (This is even more true if Alice and Bob put up some collateral so Bob gets refunded some of his BTC if he signs.)
Ideally, the oracle’s signature should hardly ever be needed at all; Alice and Bob can complete the bet on their own.
Still, the basic multisig and oracle solution has its weaknesses. For example, the oracle would probably have to be involved with setting up the bet; or at least it should be available to act as a sort of judge whenever needed. This means that the oracle could potentially be corrupted, for example, if Bob offers the oracle a share of the coins if they collude to steal both. And Alice and Bob also have no privacy from the oracle: the oracle will know exactly what they are betting on and how much they are betting. Meanwhile, the rest of the world can tell that Alice and Bob used an oracle for their bet (and, therefore, that it was a bet).
These are the problems that Discreet Log Contracts could solve. They maintain the benefits of the straightforward multisig and oracle solution — but eliminate most of its weaknesses.
As mentioned, Dryja, who is currently working for MIT Media Lab’s Digital Currency Initiative, is one of the authors of the lightning network white paper. His DLC project is based on a similar concept.
A key idea behind the lightning network is that two people can open a payment channel, allowing them to transact with each other. Such a payment channel utilizes Bitcoin’s basic programmability (like time locks and multisig addresses) and combines it with some clever tricks to commit transactions to other transactions, all without broadcasting them to the network unless needed.
Over time, as the people in the channel transact with each other, these payment channels are updated with new balances or “channel states.” Either party can then “drop” the latest channel state on the blockchain at any time and claim their balance whenever they want to. And importantly — this is where Bitcoin’s basic programmability is leveraged — both parties can only safely broadcast the latest channel state. If they try to cheat by broadcasting an earlier channel state, their counterparty can actually claim every single coin in the channel.
DLCs works similarly. But where a lightning network payment channel only lets the parties involved broadcast the most recent channel state, DLCs limit them to broadcasting only the channel state reflecting the correct outcome of a bet.
This is where the oracle comes in — but this time combined with some fancy math tricks.
As opposed to 2-of-3 multisig schemes where oracles act a bit like judges, oracles in DLCs more closely resemble broadcasters. For our World Cup bet, it would make sense that the oracle is a sports-betting service, a football news website, perhaps the FIFA or another entity that broadcasts the winner anyway and that is reasonably trusted not to lie about it.
Let’s say the oracle in this case is a sports-betting service that regularly publishes the score and winner of the World Cup final on their website. To enable a DLC, the same sports-betting service only needs to add a minor additional step.
Basically, this “broadcast oracle” has a public key and a private key. (A private key is really just a randomly generated number, while the public key is a seemingly random number derived from that private key.) This public key is published somewhere, most likely on the betting service’s website for anyone to find. The private key is, of course, kept private: This can be used by the oracle to sign a message. (Such a signature, too, is a seemingly random number but is derived from the private key in combination with the message.)
The possible outcomes of the bet are known as well: either Argentina wins the World Cup final or Brazil wins. The sports-betting service, therefore, announces that it will broadcast one of two very specific messages: “Argentina won” or “Brazil won.”
Now, what’s interesting about public key cryptography is that the sports-betting service’s public key can be used to figure out what a signature of the message — “Argentina won” or “Brazil won” — will mathematically “look like.” (“Look like,” in this case, doesn’t mean that Alice and Bob can produce the signature themselves, but they can calculate certain mathematical properties that it will have.)
Because Alice and Bob can calculate what the potential oracle signatures will “look like,” they can use it in their DLC.
First, before the World Cup final, Alice and Bob pay one bitcoin to a “funding transaction.” From this funding transaction, several potential transactions are constructed — but these are not yet broadcast over the network.
Here’s where the cryptography gets a bit complex.
What the sports-betting service signatures “look like” is cleverly embedded in these several potential transactions, where each potential signature enables a different transaction. (Specifically, and somewhat unconventionally, what the signatures “look like” is used as public keys in key-pairs for the different transactions.)
In other words, knowing what the oracle’s potential signatures will “look like,” Alice and Bob can construct their payment channels such that the two different potential signatures can be used to validate two different channel states: one where Alice gets two bitcoins and one where Bob gets them.
Then, the actual oracle signature, which is published after the World Cup final is played, is used as private key to validate the winning transaction — and only the winning transaction. If the sports-betting service broadcasts a signature for “Argentina won,” Alice can take this signature, use it as a private key (in combination with her own private key) and claim the two bitcoins from the channel. If the oracle signs a message for “Brazil won,” Bob can. Meanwhile, if either tries to claim the bitcoins without the oracle signature, they will fail, and their counterparty can instead claim both coins.
Further, like lightning network payment channels, the outcome of the bet — two bitcoins for Alice if Argentina wins — can now also be broadcast by Alice and Bob as a fairly regular multisig transaction from the funding transaction. And indeed, exactly because Alice can enforce the outcome with the oracle signature anyway, there is little reason for Bob not to cooperate.
As a result, the “bet” is fully blockchain-enforced through the sports-betting service’s signature, while this service doesn’t need to do anything for this specific bet; it doesn’t even need to know it ever took place.
And, notably, while this bet is relatively simple (either Argentina wins or Brazil wins), in reality DLCs could allow for far more complex scenarios. Exactly because only a fairly regular multisig transaction is broadcasted in the end, it doesn’t really matter if a “bet” has two, 200, or 200,000 potential outcomes.
Thanks to Tadge Dryja for information and feedback. For more details on DLCs, also see Dryja’s presentation
at Scaling Bitcoin Stanford.