“`html
Creator: Nicholas Gregory
Languages: C++, Rust
Contributed To: Ocean Sidechain, Mainstay, Mercury Wallet, Mercury Layer
Worked At: CommerceBlock (previously)
Before engaging with Bitcoin, Nicholas served as a software developer within the financial sector for banking institutions, creating trading and derivatives systems. After the 2008 financial collapse, he began exploring options to the traditional financial system amidst the aftermath.
Similar to many of his contemporaries, he initially overlooked the original Slashdot article that showcased the Bitcoin whitepaper because of its apparent emphasis on Windows as an application platform (Nicholas was primarily a UNIX/Linux developer). Fortunately, a friend later familiarized him with Bitcoin.
What intrigued him about Bitcoin, in contrast to other alternatives available at the time, was its distinct architecture as a decentralized computing network.
“The fact that it presented an alternative approach. It was entirely structured around [a] sort of […] network. And what I imply by that is, when constructing financial systems, individuals always desired a system operational 24-7.
And how do you manage someone engaging with it from various geographical locations worldwide without centralization?
I had observed several methods people adopted to address that challenge, but it had never been achieved, you know, in a kind of […] scalable way. And utilizing […] cryptography and proof of work to tackle that problem was just peculiar, honestly. It was completely unusual for me.”
All the other systems he had conceptualized, and some he developed, were distributed across different global regions. However, unlike Bitcoin, these systems were permissioned and limited access to those who could update the corresponding database(s), even though copies were redundantly disseminated worldwide.
“The fact that in Bitcoin, you have everyone essentially participating in this proof of work game, which is what it is. And whoever prevails executes the [database] write. That perplexed me. That was […] extremely unique.”
Commencing Development
Nicholas’s journey into building within this sector was a natural evolution. While residing in New York City, he, as a developer, naturally discovered the original Bitdevs established in NYC. During that time, meetups were quite small, sometimes comprising even fewer than twelve individuals, thereby creating a more intimate environment for thorough discussions compared to some larger gatherings today.
Initially, he developed a “hobbyist” Over The Counter (OTC) trading software stack for certain individuals (at that time, a substantial volume of Bitcoin was exchanged OTC for cash or other fiat currencies). Subsequently, Nicholas collaborated with Omar Shibli, whom he met at Bitdevs, on Pay To Contract (BIP 175).
BIP 175 outlines a mechanism wherein a customer buying a product participates in creating the address the seller provides. This process involves the two initially agreeing on a contract detailing what is being purchased; thereafter, the merchant sends a master public key to the buyer, who utilizes the hash of that description to produce a unique address using the hash and master public key.
This enables the buyer to validate what the vendor consented to sell them and that the payment for the product or service has been completed. Simply disclosing the master public key and contract permits any third party to generate the address that was compensated, and confirm that the relevant funds were sent there.
Ocean and Mainstay
Nicholas and Omar proceeded to establish CommerceBlock, a Bitcoin infrastructure firm. Commerceblock adopted a business approach akin to Blockstream, constructing technological frameworks to enhance the application of Bitcoin and blockchains broadly within commerce and finance. Shortly afterward, Nicholas encountered Tom Trevethan, who joined the team.
“I got to know Tom through, yes, a mutual acquaintance, glad to mention who it is. There’s an individual named John Matonis, whom the newer crowd probably doesn’t recognize, but the veterans certainly do. John Matonis was a close friend of mine, [I’d] known him for quite some time. He introduced me to Tom, who was more focused on the cryptography side. And it evolved from there.”
The primary significant venture they engaged in was Ocean, a fork of the Elements sidechain platform created by Blockstream upon which the Liquid sidechain was founded. The companies CoinShares and Blockchain, in collaboration with others, launched an Ocean-based sidechain in 2019 to issue DGLD, a gold-backed digital token.
“So we were working on forks of Elements, constructing custom sidechains. […] Tom proposed some concepts surrounding cryptography. I believe one of our initial ideas revolved around how to integrate these forks of Elements onto […] the Bitcoin main chain. […] We concluded that the most straightforward approach was […] using a sort of, I can’t recall exactly, but it was something [based on] single-use sealed sets, which was an invention by Peter Todd. I think we implemented that quite effectively with Mainstay.”
The primary difference between Ocean and Liquid as sidechain frameworks is Ocean’s utilization of a protocol crafted at Commerceblock named Mainstay. Mainstay is a timestamping protocol that, unlike Opentimestamps, rigorously orders the merkle tree it constructs instead of arbitrarily adding elements in any order they are submitted. This permits each sidechain to timestamp its current blockheight into the Bitcoin blockchain every time mainchain miners discover a block.
While this is moot for any Bitcoin pegged to the sidechain, for regulated real-world assets (RWA), it provides a definitive ownership history that the federation operating the sidechain cannot alter. This eliminates ambiguities of ownership during legal conflicts.
When inquired about the eventual closure of the project, Nicholas remarked:
“I can’t say if we were ahead of our time, but we had a handful of clients. Nonetheless, there was, yes, minimal adoption. I mean, Liquid wasn’t thriving. And, you know, being situated in London/Europe, every time we met clients to conduct POCs, we were in competition with other well-funded initiatives.
It pronounced how many years prior they had either secured funding from organizations like IBM or some of the major consultancies and were advocating for Hyperledger. Or it was back in the days when we were competing against EOS and Tezos. Consequently, since we were a company requiring investment to construct prototypes or develop sidechains, it made it exceedingly challenging. And back then, adoption was limited.”
Mercury Wallet and Mercury Layer
Following the closure of Ocean, Nicholas and Tom eventually embarked on a statechain implementation, although the route to this was not linear.
“[T]here were several events transpiring simultaneously that led to it. So the two matters were we were engaged in a [proof of concept], a very small […] POC for a prospective client. However, this coincided with Discreet Log Contracts. And one of the obstacles of Discreet Log Contracts is their substantial capital inefficiency. So we sought a method to novate those contracts. Coincidentally, Ruben Sampson wrote a white paper/Medium post regarding statechains. And […] those two concepts, together, potentially addressed that issue regarding DLCs.”
Ultimately, they did not end up implementing a statechain solution for managing DLCs, but opted for a different course of action.
Well, there was another matter unfolding at the same time, coinswaps. And, yes, it’s important to remember that back then, everyone was concerned that by […] 2024/2025 […] network fees could become quite elevated. And to conduct […] coin swaps, you sort of…
“““html
desire to conduct multiple rounds. So […] state chains appeared ideal because […] you effectively take a UTXO, set it off the chain, and then you can exchange it as often as you wish.”
Mercury Wallet was entirely developed and operational, but unfortunately never achieved user traction. At that time, Samourai Wallet and Wasabi Wallet prevailed in the privacy tool arena, and Mercury Wallet could never successfully capture any market share.
Instead of giving up entirely, they returned to the drawing board to construct a statechain variant utilizing Schnorr with the coordinator server blind signing, indicating it could not discern what it was signing. When inquired about the rationale behind these modifications, he remarked: “That would provide us significantly more versatility to explore other functionalities in Bitcoin with L2s. You know, once you have a blinded solution, we thought, well, this could begin fostering interoperability with Lightning.”
Rather than creating a wallet aimed at users this time, they developed a Software Development Kit (SDK) that could be integrated with other wallets.
“{…] I suppose with Mercury Layer, it was essentially constructing a kind of […] comprehensive Layer 2 that anyone could utilize. So we [built] it as an SDK. We did have a default wallet that individuals could operate. Yet we were optimistic that others would integrate it.”
The Conclusion of CommerceBlock
Ultimately, CommerceBlock closed its operations after many years of exceptional engineering achievements. Nicholas and the rest of the team developed numerous systems and protocols that were excellently designed, but at the end of the day, they seemed to consistently be one step ahead of what was needed. That’s not necessarily advantageous when developing systems for end users.
If your efforts are too advanced compared to users’ demands, then in the end, that isn’t a viable strategy.
“…residing in the UK, which is not faring well from a regulatory standpoint, contributed to this. If I had been in Dubai, perhaps that would have been a different discussion. You know, back when we made that choice…things weren’t ideal in the US. I believe conditions have improved there. But also, I think…Bitcoin is in a stable financial position. I think it’s clearly being utilized as a product. However, I believe the L2s in the field simply lack significant user engagement.”
When asked why he believed Layer 2s weren’t being widely adopted, he responded: “…during my experiences working on CivKit (a decentralized marketplace), one of the recurring questions posed to me was, when Tether, when stablecoins? So when you’re engaged in a project aimed at promoting Bitcoin in the global south, but everyone you encounter in the global south wants stablecoins, you start to question, well, am I constructing the correct tool? Do people even wish to utilize this?”
In the end, the most effective and robust engineering efforts still require adoption and usage; otherwise, what is the significance of it in the first place?
“…there has been a transition over the last four years for it to serve as a store of wealth. And I do believe that’s a risk because I think if individuals were using Bitcoin presently and the mempool was costly, congested, and fees were elevated, there are enough intelligent individuals to develop good L2s. But they’re not being constructed because there’s no demand. And, you know, no one wants to create software, whether open source or commercial, when it’s just a group of hobbyists using it. And I think that’s one of the hurdles facing Bitcoin right now. We have a deficiency of users, and that could pose a challenge later on.”
“I think there’s a considerable number of clever individuals in Bitcoin capable of creating fascinating innovations, but I think the current focus has to be on users.”
Source link
“`
