Bitcoin Builders Exist Because Of Users

Bitcoin Magazine

Bitcoin Builders Exist Because Of Users

Builder: Nicholas Gregory

Language(s): C++, Rust

Contribute(s/ed) To: Ocean Sidechain, Mainstay, Mercury Wallet, Mercury Layer

Work(s/ed) At: CommerceBlock (formerly)

Prior to Bitcoin, Nicholas was a software developer working in the financial system for banking firms developing trading and derivatives platforms. After the 2008 financial crisis he began to consider alternatives to the legacy financial system in the fallout. 

Like many from that time, he completely ignored the original Slashdot article featuring the Bitcoin whitepaper due to the apparent focus on Windows as an application platform (Nicholas was a UNIX/Linux developer). Thankfully someone he knew introduced him to Bitcoin later on. 

The thing that captured his interest about Bitcoin rather than other alternatives at the time was its specific architecture as a distributed computer network. 

“The fact that it was like an alternative way. It was all based around [a] kind of […] network. And what I mean by that, building financial systems, people always wanted a system that was 24-7.

And how do you deal with someone interacting [with] it in different geographical parts of the world without it being centralized?

And I’d seen various ways of people solving that problem, but it never had been done, you know, in a kind of […] scalable solution. And using […] cryptography and proof of work to solve that issue was just weird, to be honest. It was totally weird for me.”

All of the other systems he had designed, and some that he built, were systems distributed across multiple parts of the world. Unlike Bitcoin however, these systems were permissioned and restricted who could update the relevant database(s) despite that fact that copies of them were redundantly distributed globally. 

“The fact that in Bitcoin you had everyone kind of doing this proof of work game, which is what it is. And whoever wins does the [database] write. That mess[ed] with my head. That was […] very unique.”

Beginning To Build

Nicholas’s path to building in the space was an organic one. At the time he was living in New York City, and being a developer he of course found the original Bitdevs founded in NYC. Back then meetups were incredibly small, sometimes even less than a dozen people, so the environment was much more conducive to in-depth conversations than some larger meetups these days. 

He first began building a “hobbyist” Over The Counter (OTC) trading software stack for some people (back then a very significant volume of bitcoin was traded OTC for cash or other fiat mediums). From here Nicholas and Omar Shibli, whom he met at Bitdevs, worked together on Pay To Contract (BIP 175). 

BIP 175 specifies a scheme where a customer purchasing a good participates in generating the address the merchant provides. This is done by the two first agreeing on a contract describing what is being paid for, afterwards the merchant sends a master public key to the consumer, who uses the hash of that description of the item or service to generate an individual address using the hash and master public key. 

This allows the customer to prove what the merchant agreed to sell them, and that the payment for the good or service has been made. Simply publishing the master public key and contract allows any third party to generate the address that was paid, and verify that the appropriate amount of funds were sent there. 

Ocean and Mainstay

Nicholas and Omar went on to found CommerceBlock, a Bitcoin infrastructure company. Commerceblock took a similar approach to business as Blockstream, building technological platforms to facilitate the use of Bitcoin and blockchains in general in commerce and finance. Shortly afterwards Nicholas met Tom Trevethan who came on board. 

“I met Tom via, yeah, a mutual friend, happy to say who it is. There’s a guy called, who, new people probably don’t know who he is, but OGs do, John Matonis.  John Matonis was a good friend of mine, [I’d] known him for a while. He introduced me to Tom, who was, you know, kind of more on the cryptography side. And it kind of went from there.”

The first major project they worked on was Ocean, a fork of the Elements sidechain platform developed by Blockstream that the Liquid sidechain was based on. The companies CoinShares and Blockchain in partnership with others launched an Ocean based sidechain in 2019 to issue DGLD, a gold backed digital token. 

“So we, you know, we were working on forks of Elements, doing bespoke sidechains. […] Tom had some ideas around cryptography. And I think one of our first ideas was about how to bolt on these forks of Elements onto […] the Bitcoin main chain. […] We thought the cleanest way to do that was […] using some sort of, I can’t remember, but it was something [based on] single-use sealed sets, which was an invention by Peter Todd. And I think we implemented that fairly well with Mainstay.”

The main distinction between Ocean and Liquid as a sidechain platform is Ocean’s use of a protocol designed at Commerceblock called Mainstay. Mainstay is a timestamping protocol that, unlike Opentimestamps, strictly orders the merkle tree it builds instead of randomly adding items in whatever order they are submitted in. This allows each sidechain to timestamp its current blockheight into the Bitcoin blockchain everytime mainchain miners find a block. 

While this is useless for any bitcoin pegged into the sidechain, for regulated real world assets (RWA), this provides a singular history of ownership that even the federation operating the sidechain cannot change. This removes ambiguity of ownership during legal disputes. 

When asked about the eventually shuttering of the project, Nicholas had this to say: 

“I don’t know if we were early, but we had a few clients. But it was, yeah, there wasn’t much adoption. I mean, Liquid wasn’t doing amazing. And, you know, being based in London/Europe, whenever we met clients to do POCs, we were competing against other well-funded projects. 

It shows how many years ago they’d either received money from people like IBM or some of the big consultancies and were promoting Hyperledger.  Or it was the days when we would be competing against EOS and Tezos. So because we were like a company that needed money to build prototypes or build sidechains, it kind of made it very hard. And back then there wasn’t much adoption.”

Mercury Wallet and Mercury Layer

After shutting down Ocean, Nicholas and Tom eventually began working on a statechain implementation, though the path to this was not straightforward. 

“[T]here were a few things happening at the same time that led to it. So the two things were we were involved in a [proof of concept], a very small […]POC for like a potential client. But this rolled around Discreet Log Contracts. And one of the challenges of Discreet Log Contracts, they’re very capital inefficient. So we wanted a way to novate those contracts. And it just so happened that Ruben Sampson, you know, wrote this kind of white paper/Medium post about statechains. And […] those two ideas, that kind of solved potentially that issue around DLCs.”

In the end they did not wind up deploying a statechain solution for managing DLCs, but went in a different direction. 

Well, there was another thing happening at the same time, coinswaps. And, yeah, bear in mind, in those days, everyone worried that by […] 2024/2025 […] network fees could be pretty high. And to do […] coin swaps, you kind of want to do multiple rounds. So […] state chains felt perfect because […] you basically take a UTXO, you put it off the chain, and then you can swap it as much as you want.”

Mercury Wallet was fully built out and functional, but sadly never gained any user adoption. Samourai Wallet and Wasabi Wallet at the time dominated the privacy tool ecosystem, and Mercury Wallet was never able to successfully take a bite out of the market. 

Rather than completely give up, they went back to the drawing board to build a statechain variant using Schnorr with the coordinator server blind signing, meaning it could not see what it was signing. When asked why those changes were made, he had this to say: “That would give us a lot more flexibility to do other things in Bitcoin with L2s. You know, the moment you have a blinded solution, we thought, well, this could start having interoperability with Lightning.”

Rather than building a user facing wallet this time, they built out a Software Development Kit (SDK) that could be integrated with other wallets.

“{…] I guess with Mercury Layer, it was very much building a kind of […] full-fledged Layer 2 that anyone could use. So we [built] it as an SDK. We did have a default wallet that people could run. But we were hoping that other people would integrate it.”

The End of CommerceBlock

In the end, CommerceBlock shuttered its doors after many years of brilliant engineering work. Nicholas and the rest of the team built numerous systems and protocols that were very well engineered, but at the end of the day they seemed to always be one step ahead of the curve. That’s not necessarily a good thing when it comes to building systems for end users. 

If your work is too far ahead of the demand from users, then in the end that isn’t a sustainable strategy. 

“…being in the UK, which is not doing that well from a regulatory point of view, played into it. If I was living in Dubai, maybe that would have been a different conversation. You know, back when we made that decision…things weren’t great in the US. I think things have improved there. But also, I think…Bitcoin is in a good place financially. I think it’s clearly being used as a product. But I think the L2s in the space just don’t have much user adoption.”

When asked why he thought people were not using Layer 2s at scale, he had this to say: “…in my adventures of working on CivKit (a decentralized marketplace), one of the questions that was always posed to me is, when Tether, when stablecoins? So when you’re working on a project that’s trying to promote Bitcoin in the global south, but everyone you meet in the global south wants stablecoins, you start to wonder, well, am I building the right tool? Do people even want to use this?”

At the end of the day, the most useful and sound engineering work still needs to be adopted and used, otherwise what is the value of it in the first place? 

“…there has been a shift in the last four years for it to be a store of wealth. And I do think that’s a risk because I think if people were using Bitcoin right now and the mempool was expensive, was jammed up and fees were high, there’s enough bright people to build good L2s. But they’re not being built because there’s no demand. And, you know, no one wants to build software, whether that’s open source or commercially, when it’s just a bunch of hobbyists using it. And I think that’s one of the challenges of Bitcoin right now. We have a lack of users and maybe down the line that’s a problem.”

“I think there’s a lot of smart people in Bitcoin that can build interesting stuff, but I think the focus now has to be users.”

This post Bitcoin Builders Exist Because Of Users first appeared on Bitcoin Magazine and is written by Shinobi.