Bitcoin off chain MPC Layer 2 protocol. First live state chain implementation.
Global
- Tweets 795
- Following 737
- Followers 3,484
- Likes 1,895
Mercury Layer retweeted
also not shy about about takings others work and providing no credit. @mercurylayer
...
1
16
893
Mercury Layer retweeted
Nice to hear @mercurylayer still getting some love...
Privacy on Bitcoin is a constant battle, but what if statechains were part of the answer?
In this clip from Chat_176, Talip and I explore how statechains can enable private Bitcoin activity without exposing your moves on L1. We get into amount-hiding sidechains, dark pools, and why designs that auto-return funds to you if a custodian disappears are so powerful. This one’s a technical nerd-snipe into the future of private Bitcoin markets and smarter custody.
2
16
1,614
more swap routes on the way
after demonstrating a privacy preserving swap between @mercurylayer and our custom fork of @payy_link, we've now added a new route to bitcoin dark pools
in the demo below @stutxo, shows a privacy-preserving swap between the blinded statechain and @Blockstream's @Liquid_BTC
no bitcoin transaction is broadcasted on chain in the swap. the stablecoin asset and amount is not visible to public observers on liquid
protocol can be improved with adaptor signatures
team is working on an additional route as we prepare for the release of our SDK
stu 🥪🥞
3
5
33
2,226
we built a bitcoin dark pools prototype 🪄
tl;dr - we built a privacy-preserving, bitcoin exchange using @mercurylayer, nostr, and a zk-execution network. the bitcoin transfer is completed offchain via a blind co-signer. the stablecoin network only reveals hashes of inputs and outputs, no amounts or user addresses. orders are matched peer-to-peer using nostr identities. exchange is atomic & privacy-preserving. deets:
this protocol is built on the following:
- statechains, a way to transfer ownership for bitcoin utxos offchain by reassigning spending keys
- private stablecoin network with flexible zk-circuits/contracts that lock funds to a specific sha256 hash
- a blind co-signer that facilitates ownership transfer for bitcoin utxos offchain per a specific order
the exchange builds upon mercury layers’ latch protocol. the seller locks their offchain "utxo" into an order that they create. the order specifies that an offchain transfer to the buyer’s offchain address should occur after buyer & seller commit to it. an order with a hash is created.
the order hash is then used to lock stablecoins on the zk network. meaning, the buyer must lock their funds into an escrow contract where the funds are only claimable by revealing the preimage for the order’s sha256 hash (or they refund the buyer after a timelock).
after these stables (or any other shitcoin, tbh) are locked on the zk side, the buyer submits the tx hash to the seller. after verifying that stables are locked in escrow, the seller calls the co-signer to unlock the transfer to the buyer. after verifying that the seller has committed this, the buyer also calls the co-signer to unlock the transfer. the co-signer reassigns the statechain multisig spending key to the buyer and tweaks their keyshare. the co-signer then deletes their key with the seller.
after the statechain transfer, the co-signer then reveals the preimage for the order to the seller. the seller uses that to claim the stables on the zk network out of the escrow contract. swap completed. buyer trusts signer deleted their keyshare up until the point the exit the statechain back to bitcoin.
we’ve taken this swap protocol and developed an RFQ protocol using nostr identities. in the exchange application, users create a nostr identity and submit buy and sell orders. only their npub, and the amount of their respective order, is revealed. no bitcoin addresses or other pii is exposed. when a user finds an suitable offer in the orderbook, they submit an encrypted firm quote with exact amounts and prices. only the counterparty in the trade can decrypt this message.
from an onchain perspective, there is no onchain bitcoin transaction. on the stablecoin side, zk magic only see hashes of inputs and outputs publicly available. you can’t even discern which token was involved in the trade.
the co-signer is blind and dumb. validation is done peer-to-peer between countparties. co-signer only signs when its told to.
this is a demo and opinionated design. in our view, it’s extremely privacy-preserving and makes nice tradeoffs wrt user self-custody.
we’ll building more optimized versions that make different tradeoffs, but wanted to share this example. all code will be open-sourced in the future.
🪄
23
48
232
23,965
i think one thing i got right when researching bitcoin l2s was a strict classification for bitcoin native l2s versus sidesystems
because with truly bitcoin native L2s (ark, lightning), a centrally coordinated asset freeze is not possible at the protocol level. i'd argue also argue that a blind statechain (i.e. @mercurylayer) cannot do this style of censorship, either.
sidesystems (meaning any blockchain with a bridge to a host chain) on the other hand, are currently all capable of doing this and would have to if required.
building a trust-minimized rollup is incredibly hard. in this example, arbitrum's security council is nearly as distributed as it can get. but it can still take this type of action.
in bitcoin, added programmability via l2s/sidesystems will come with this tradeoff (among others). trust-minimization means that you have parent chain trust assumptions and a cryptographically secured mechanism to enter and leve the protocol. if the system includes a mechanism where any human operator(s) can freeze any user funds, then it it is not trust minimized.
all bitcoin sidesystems have human operators and can enforce this style of censorship.
worth considering when engaging with these systems.
The Arbitrum Security Council has taken emergency action to freeze the 30,766 ETH being held in the address on Arbitrum One that is connected to the KelpDAO exploit. The Security Council acted with input from law enforcement as to the exploiter’s identity, and, at all times, weighed its commitment to the security and integrity of the Arbitrum community without impacting any Arbitrum users or applications.
After significant technical diligence and deliberation, the Security Council identified and executed a technical approach to move funds to safety without affecting any other chain state or Arbitrum users.
As of April 20 11:26pm ET the funds have been successfully transferred to an intermediary frozen wallet. They are no longer accessible to the address that originally held the funds, and can only be moved by further action by Arbitrum governance, which will be coordinated with relevant parties.
1
7
31
2,851
Mercury Layer retweeted
Spark could not even do the blinded stuff that @MercuryLayer had working 2 years ago!
2
2
11
858
Mercury Layer retweeted
And in some ways less. No blinded signer which is the key innovation of @mercurylayer
1
3
10
694
Mercury Layer retweeted
The code for Mercury Layer is sitting right here. It needs a new champion. Lightspark is basically the same protocol. Cc: @TTrevethan @mercurylayer @gregory_nico
github.com/commerceblock/mer…
2
2
8
2,354
RT @januszg_: Some thoughts on statechains
I used to say "Lightning is the only L2". I changed my mind and think protocols like @buildonsp…
1
314
Mercury Layer retweeted
Statechains are only interested when they are blinded. @mercurylayer implemented this two years ago, all open source…
Found out today that @lightspark's statechain model does NOT use a blinded server. It's not a privacy tool. That's sad. I recommend preferring Mercury's over Lightspark's if privacy is important to you.
2
8
1,016
Mercury Layer retweeted
and as im asked quite often, an incomplete list of what im excited for:
-@citrea_xyz rollup w/ bitvm bridge
-@Strata_BTC rollup w/ bitvm bridge
-@BotanixLabs launching + research on spiderchain
-@babylonlabs_io and bitcoin staking in general
-@arch_prime sidechain where VM interacts with L1 transactions
-@nomicbtc being used on cosmos chains
-@build_on_bob's roadmap and collab with @fiamma_labs on bitvm bridge
-@tBTC_project and @MezoNetwork potential integration
-@rootstock_io's upgrades with faster blocktimes and bridge
-tracking @Stacks sBTC adoption versus other derivative assets
-statechain protocols (@buildonspark & @mercurylayer)
-implementations of ark (@secondhq & @ArkLabsHQ), also past payments use cases
-shielded csv, payments protocol
-initial winner in LST tokens and seeing where they're primarily deployed // used
-sidechains like @fractal_bitcoin being used as a testing ground for CAT, etc.
-Lightning Network to continue as an L2 for sovereign & technical users and being integrated with various protocols
-whatever @TaprootWizards are doing
-whatever @char_btc is doing
-@StarkWareLtd and @l2iterative's research
-soft fork discussions
-some other projects in stealth
Bitcoin Layers’ year in review 🔬
I wrote a review on @bitcoinlayers' yearly progress for @blockspace. 2024 was supposed to be the year of the bitcoin renaissance, but the year was largely driven by speculation and custodians propping up TVL. All (mostly) secured by ambiguous federations.
We’ve reviewed 18 in-production systems that claim to be a “bitcoin L2” and are tracking another 25-30~ that are on testnet. Some claim there are 75-100 L2s, but it seems a large percentage of announced projects are abandoned. For example, there are still references of ZKSats, which turned out to be a rug pull and stole user deposits: nitter.net/januszg_/status/182806…
More sidechain-style projects will be coming to market in 2025 with “rollups” capturing a large amount of mind share. While the proposed @citrea_xyz and @Strata_BTC designs are more trust-minimized than current sidechain models, there is a misconception on around how they're actually going to work in practice: nitter.net/januszg_/status/185967…
Still, not everything is another full-on, alternative blockchain.
Statechain protocols like @mecurylayer and @buildonspark are coming to market. And the race to onboard the Ark is accelerating with the support of @secondhq and @ArkLabsHQ. Albeit with tradeoffs in trust assumptions.
It’d be unfair to not mention @lava_xyz which have the majority of mindshare for applications that leverage DLCs. Their protocol allows users to borrow stablecoins against their BTC and has seen an uptick in interest, and adopton, this year.
On the research side, BitVM(2) continued to nerd snipe us all. An alliance of 5 teams was formed to accelerate its development.
A lot of research was released this year, including the updated Shielded CSV (aka zkCoins) paper. It’s a new protocol that could bring offchain, shielded payments for BTC. nitter.net/BitcoinLayers/status/1…
Most in-production projects have proven to be some flavor of a sidechain with a federated two-way peg with bitcoin. This means they are an alternative blockchain with a bridge that is managed by permissioned parties.
This design is very similar to leveraging wrapped BTC on major L1s such as Ethereum or Binance Smart Chain. And, new wrappers are being developed with TVL and activity being driven by “points programs” where users leverage chains, apps, and new tokens in hope for an upcoming airdrop.
When we talk about this renaissance, we need to understand that the majority of proposed designs are limited by what’s possible on bitcoin today.
Nearly every project, from bitcoin staking to rollups, would be improved if new opcodes are introduced. People may say there’s no demand, but Babylon, for example, is now the third largest protocol measured by TVL (57,000~ BTC) and it's not even live. Only deposits are.
To track developer sentiment around the next soft fork, there is now have a wiki where developers provide feedback, and their rationale, for supporting various proposals.
CTV, CSFS, and CAT seem to have the most support.
The tl;dr is that there is a lot of new interest, investment, and people building in this sector. But, we have to be cautious when advocating for this new category. It's tradeoffs all the way down.
We're hopeful that 2025 provides users new solutions and current projects accelerate progress on their technical roadmaps.
We’ll be here to document it.
13
8
81
9,956
Mercury Layer retweeted
This guy has not heard of @mercurylayer or OpenDimes…
Recently, I have seen several instances where people receive crypto by receiving a private key or a hardware wallet.
This is a bad idea.
The giver still has access to those crypto. You should move the crypto to an address you own. Or better, just ask the giver to send it to an address you own.
Having two people access the same key (or seed) is a bad idea. When those crypto move (or by a hacker), it's almost impossible to prove who moved it (or got hacked).
1
9
1,097
Mercury Layer retweeted
Bitcoin wasn’t hijacked; it was understood early that blockchains don’t scale easily, much like databases. How do Google/Amazon scale? With multiple DBs and caches. Bitcoin hasn’t cracked that yet—truth is, demand isn’t overwhelming.
This debate reminds me of my time at Merrill Lynch: a manager (with no coding experience) demanded I make risk calculations multithreaded. I told him it was dumb. He moved me off the team and spent millions on a multithreaded project—when it went live, it ran slower.
The point? Tools like multithreading—or increasing block size—are context-specific. They’re not magic fixes, and applying them blindly can backfire. Lessons from both Bitcoin and corporate life.
7
10
85
10,388
Mercury Layer retweeted
Originally i wanted to contribute to bitcoin because I was genuinely board in my 9 - 5 job and bitcoin looked like something that could change the world...
sadly i don't think i have anything to say to people who are suspicious of the motivations of opensource developers, trying to deliver value to users around the globe often without any compensation in sight, but will cheer for the involvement of creatures like Fink and Saylor.
2
6
1,007
Mercury Layer retweeted
This is outrageous—a government official attacking Bitcoin without evidence of it being used in this way. Pure fear-mongering. Yet another dark day under one of the most clueless governments we’ve seen...
David Lammy
34
11
122
17,639
Mercury Layer retweeted
There’s been some confusion about what @mercurylayer is (and isn’t). The original concept explored a mechanism to send private keys via adaptor signatures. However, this wasn’t feasible at the time due to the lack of Schnorr signatures, plus the complexity of passing an adaptor signature between owners. The key innovation of @mercurylayer is the key update mechanism, allowing a private key to be updated while keeping the public key the same, enabling off-chain transfers. Later, we advanced this to make the process blinded.@TTrevethan #bitcoin #layer2
2
7
38
5,244
Mercury Layer retweeted
Surprised to see you tagging Andreas in this conversation while breaching the actual ethos of open source software (esp in Bitcoin) and not crediting a single second the work of @mercurylayer @TTrevethan and @gregory_nico that’s been years in the making (since early 2020). :)
5
12
31
6,600
