Palladium and Botanix Labs have announced the launch of a new stablecoin, PUSD, on Bitcoin’s first EVM-equivalent Layer 2 network, according to a press release sent to Bitcoin Magazine.

The PUSD stablecoin, developed by Palladium Labs, boasts a unique feature of being over-collateralized by 110%, a strategic measure aimed at enhancing its resilience against potential risks inherent in DeFi infrastructure. Importantly, the stablecoin’s algorithmic monetary policy attempts to remain immune to governance changes or manipulation by administrator keys, aiming to ensure its integrity and reliability.

“To realize the true value of decentralized finance, crypto needs to break free from infrastructure that is susceptible to exploits and manipulation,” stated Palladium Labs CEO Akash Gaurav. “At Palladium, we designed this stablecoin for resilience and reliability. By leveraging the unique capabilities of the Botanix EVM, we can radically increase the security and reliability of stablecoin access for millions of people using Bitcoin.”

Operating on the Botanix EVM, which has been in development since early 2023, Palladium leverages the capabilities of this platform to enhance the security and accessibility of stablecoin transactions for Bitcoin users. The Botanix EVM’s underlying sidechain protocol, known as the Spiderchain, plays a pivotal role in safeguarding funds transferred from the Bitcoin base layer to the EVM network.

“The importance of native stablecoins to the technological renaissance happening on Bitcoin cannot be overstated,” said Willem Schroe, inventor of the Spiderchain and co-founder of Botanix Labs. “We are thrilled to support the Palladium team in launching their over-collateralized stablecoin on our EVM network.”

With the launch of PUSD on Bitcoin’s first EVM Layer 2 network, Palladium and Botanix Labs aim to meet the growing demand for secure and efficient DeFi solutions, seeking to pave the way for a new era of financial innovation on the Bitcoin blockchain.

Source link

A common chant from many in this space these days in response to any discussion of changes to the Bitcoin protocol is “Don’t mess with Layer 1! You can just build it on Layer 2!” This seems like a very logical thing to do, right? Why risk the security and stability of L1 when you can just build on top of it? The problem is this fundamentally fails to understand the relationship between Layer 1 and Layer 2.

An L2 protocol is an extension of the L1. Everything that an L2 is designed to do must ultimately reduce down to what the L1 is capable of. The blanket statement of “just do it on L2!” obfuscates numerous implicit realities of what can or can’t be done on an L2 given the current state of the base layer. For instance, imagine trying to build the Lightning Network without the existence of multisignature scripts. You couldn’t. It wouldn’t be possible to share control between more than one person, and the whole concept of a payment channel wouldn’t be possible.

The Evolution of Payment Channels

The entire reason that payment channels can exist in the first place is because of the fact that L1 of Bitcoin supports the ability for multiple people to share control of a UTXO with a multisig script. What is possible on a L2 is inherently constrained by what is possible on L1; yes, of course it is possible to do things on L2 that aren’t possible on L1, but the ultimately limiting factor of what you can do off-chain is what is possible on-chain. Faster payment confirmation in a payment channel is only possible because on-chain custody can be shared between multiple people.

Even that isn’t enough for a safe payment channel though. The original payment channel had a pre-signed transaction using an nLocktime timelock that gives the funder their money back after so many blocks, and only supported payment channels in one direction. Transaction malleability made these original payment channels unsafe to use. If the funding transaction was malleated by someone before confirming, then the refund transaction would become invalidated and the funder would have no way to claim their money back. The other party in the channel could effectively hold their money hostage.

CHECKLOCKTIMEVERIFY, the absolute timelock opcode, was the solution. CLTV allows you to make a coin unspendable until a certain blockheight or time in the future. This, in combination with the ability to make scripts that can be spent in multiple ways, allowed the multisig UTXO to have a script path where the funder could spend all of the funds themselves after a timelock. This guaranteed the funder would be able to claim the money back in a worst case scenario even if the funding transaction was malleated. The channel could still only facilitate one-way payments though.

In order to facilitate two-way payments, a proper solution to transaction malleability was necessary. This was a huge motivator for Segregated Witness. A timelock is all that was necessary for a one way channel because the money only increased in one direction. The only risk to the sender was that the other party would never claim what they have already been sent on-chain, leaving the rest of the sender’s money trapped. The timelock refund both gave the receiver the incentive to claim funds on-chain before the timelock, when they would lose all the funds they had already been sent, and the sender a worst-case recourse in case something happened to permanently knock the receiver offline. Script does not support enforcing certain amounts to certain future scripts, so a pre-signed transaction is the only viable initial refund mechanism if payments are to flow in both directions. This reopened the risk of funds being held hostage.

With the upgrade to Segwit, this problem was solved. In place of the timelock refund incentivizing honest behavior, the penalty key was introduced. Because the funds in a two-way channel can flow back and forth in each direction there will inevitably be a case where both sides had more money in a prior state of the channel than the current one. By establishing a branch in each channel state’s pre-signed transaction using a penalty key, users can exchange these after signing the new state and know if the other party tries to use an old transaction they can claim 100% of the funds in the channel. Timelocks are used to guarantee the normal spending path where users take their respective balances isn’t valid for a time to give channel parties the chance to use the penalty key if necessary. There’s a problem with this though, using CLTV means that at some point in the future the channel has to close or else the timelock will expire and you no longer have that safety period to penalize the dishonest party.

Bi-directional payment channels also needed CHECKSEQUENCEVERIFY, or relative timelocks, in order to solve this issue. Unlike CLTV, which specifies a specific time or blockheight in the future, CSV specifies a relative length of time or number of blocks from the time or block that the UTXO using CSV in the script is confirmed in the blockchain. This allowed the safety period to function for penalty key use without requiring channels having to close on-chain at a pre-decided time.

Even this does not give us the Lightning Network though. There is still no way to actually route a payment across multiple payment channels. They can conduct payments in both directions, but only between the two people involved in the channel. In order to route payments across multiple channels you need, you guessed it, other functionality from the L1. Hash Time Locked Contracts are how this is accomplished, and they require both CLTV as well as hashlocks. Hashlocks require providing the preimage to a hash in order to spend the coins. It’s like a signature, except you actually just reveal the “private key” instead of signing with it. This allows the receiver in a Lightning payment to provide a hashlock, and every intermediate channel between sender and receiver create a script that allows spending immediately with the hash preimage, or refunding the money backwards after a timelock. If the receiver reveals the hashlock, everyone can claim the money for forwarding the payment, if not, then the money can be claimed backwards and reversed without finalizing it.

So the Lightning Network as it exists today depends entirely on five functionalities being possible on the base layer of Bitcoin. Multisignature scripts, absolute timelocks, relative timelocks, Segregated Witness, and hashlocks. Without any one of these features existing on L1, Lightning as we know it today would not be a possible L2 we could construct. Its existence as an L2 is entirely dependent on L1’s capability to do certain things. So if one were to, in a world with a Bitcoin that did not support hashlocks, timelocks in script, and no malleability fix, simply go “Just build a bidirectional multi-hop payment channel system on Layer 2! We shouldn’t be messing around with Layer 1” it would be a completely incoherent statement.

The Catch

That said, strictly technically speaking, it still would have been possible to build that bidirectional multi-hop payment channel system in that world without those three features on L1. At a massive cost in terms of introducing trust in other people to not steal your money when they are capable of doing so. A federated sidechain. Everyone could have just set up a federated chain like Liquid or Rootstock and added those features to the sidechain, building the Lightning Network there instead of on the mainchain. The problem with that is, it’s not the same thing. On a technical level the network would function exactly the same, but no one using it would actually have the same degree of control over their coins.

When they closed out a Lightning channel it would settle on a sidechain backed by a federation, i.e. it would just be an accounting entry on top of someone else’s multisig wallet where you have no ability to control those coins on L1. You just have to trust the distributed group operating the federation to not rug everyone. Even drivechains (which ironically itself requires new L1 functionality to be done) is just another form of federation at the end of the day, with some extra restrictions added to the withdrawal process. The federation is just miners instead of people holding private keys.

This is the implicit reality, whether they understand it or not, underlying the reaction “just build it on L2!” whenever someone is discussing improvements to L1. There is the scope of what is already possible to build on L2, which is rather limited and restricted by its own scaling limitations, and then there is the scope of what is not already possible. Everything falling into the latter category is impossible to build without interjecting some trusted entity or group of entities that ultimately is in control of users’ funds for them.

What’s the Point?

“Layer 2” is not a magic incantation. You can’t just wave a magic wand and chant the words, and anything and everything becomes magically possible. There are strict inescapable limitations of what an L2 can accomplish, and those limitations are what the L1 can accomplish. This is just an inherent fact of engineering reality when looking at a system like Bitcoin. You can’t escape it in any way except by degrading the trust assumptions more and more the more flexible of an L2 you build beyond the capabilities of L1.

So when discussions around these issues occur, such as what improvements can be made to L1, two things are of utmost importance. First, those improvements to L1 are almost entirely centered around enabling the construction of more flexible and scalable L2s. Secondly, L2s cannot magically enable everything. L2s have their own limitations based on those of the L1, and to have a discussion regarding changes to L1 without acknowledging the only way around those limitations is to introduce trusted entities is not an honest conversation.

It’s time to start acknowledging reality if we are going to discuss what to do with Bitcoin going forward, otherwise nothing is happening but denial of reality and gaslighting. And that is not productive. 

Source link

Bitcoin script, it seems, has been sorely underestimated.

Following the release of the Ordinals protocol and BitVM white paper in 2023, conceptions are shifting about what is possible on the Bitcoin base layer, and it’s clear Bitcoin is now absorbing demand from other blockchains in the wider cryptocurrency ecosystem.

Of course, developers have harbored aspirations to add additional features to Bitcoin since the earliest days of the protocol’s 15-year history. From early sidechains like Liquid and Rootstock to the L2s of tomorrow, Bitcoin Magazine has always covered legitimate scaling initiatives.

However, there are a new wave of imitators seeking to take advantage of these developments in order to market arbitrary crypto tokens. Amidst this Bitcoin L2 gold rush, Bitcoin Magazine’s Editorial Board believes it is necessary to clarify its position on L2 coverage.

To be eligible for coverage, a Bitcoin L2 must:

• Use bitcoin as its native asset: The L2 must be foundationally designed to use bitcoin as its primary token or unit of account, and the mechanism for paying fees for the system. If it has a token, it must be backed by bitcoin.

• Use Bitcoin as a settlement mechanism to enforce transactions: Users of the L2 must be capable of exiting the system through a mechanism that returns unilateral control of their funds on Layer 1.
• Demonstrate a functional dependence on Bitcoin: If Bitcoin were to experience a total failure, and the system in question were to remain operational, then it is our position that that system is not a Layer 2 of Bitcoin.

Protocols built on Bitcoin that do not fit into the category of Layer 2, but that still may be eligible for coverage include:

• Meta Protocols: Systems like Counterparty (XCP) or Ordinals, protocols outside of the bounds of the Bitcoin protocol, and exist and function on Bitcoin Layer 1, but do not have their own separate blockchains. Bitcoin Magazine has historically covered news and events related to such protocols, and will continue to do so.

• ‘Parasite’ Layers: These systems depend on Bitcoin to exist, and cannot function independently without Bitcoin, but do not fulfill the other criteria required to be considered a Layer 2. Bitcoin Magazine does not cover these protocols at this time.

This policy clarification does not apply to our stablecoin or tokens coverage decisions.

Further, it pertains only to BitcoinMagazine.com and its Print publication, and does not represent policies enforced by The Bitcoin Conference, Rare BTC or UTXO Management, the institutional fund owned and operated by BTC Inc, and which may have exposure to Bitcoin-based L2s. 

Source link

Following my view that the price, fee, and flexibility advantages offered by L2 metaprotocol solutions over on-chain Ordinals will ultimately prove decisive, I’ve focused my energies on advancing such solutions. Over the last few months, I’ve been deeply involved in both TA and RGB projects. In early September, I established a group in which the developers of L2 metaprotocol wallets, exchanges, and projects – as well as any other interested parties – can collaborate. I traded the first tokens on the new “Tiramisu” and “NostrAssets” TA exchanges and named the now-abandoned “Spank” TapAss (get it?) exchange. Most recently, I founded what will be the first 10,000 piece profile picture (PFP) art collection on RGB, Single-Use-Seal (named for the cryptographic primitive invented by Peter Todd in 2016 which forms the basis of RGB).

Given that creating the artwork for Seals, marketing the project and interacting with its (exceptional) community constitutes the most significant investment of my time into L2 metaprotocol projects, it follows that I believe RGB has greater potential than TA. However, unlike RGB which is currently undergoing a code audit by Blockstream before the gates are thrown wide to user investment, TA is available as a functional alternative to Ordinals right now. From personal experience, I can testify that TA tokens and NFTs are working and trading extremely well, with Lightning support as standard… So why, in the current high- fee environment, is the Ordinals war still raging, as shown by the recent battle over OCEAN mining pool filtering Ordinals transactions?

Image Inscriptions – Here to Stay?

As an artist (or, more accurately, amateur cartoonist), I well understand that limitations often spur creativity. A blank page can be intimidating in its endless possibility, whereas restrictions suggest structure and sometimes present a starting point. The size limitations of Inscriptions have obviously not stopped an explosion of creativity, from charming low-res and pixel art to improved technical efficiencies, like recursive inscriptions. However, the tight restrictions on file size imposed by the on-chain format does exclude certain possibilities.

For example, Single-Use-Seals explores the human artist’s role in a culture increasingly fabricated by AI. To achieve “Proof-of-Art” verification across the PFP collection and to filter AI-generated entries from our various community contests, Seals relies on high-res photographs of handmade art. At a resolution of 3072 by 3072 pixels, it’s possible to conduct a CSI-style enhancement of a Seal, sufficient to confirm the irregular pen strokes, imperfections of the paper, and shifting photographic tones as human made:

For a 10,000 piece collection, achieving this level of fidelity is cost-prohibitive within Inscriptions – if not technically impossible, given that each Seal image is roughly double the maximum size of a Bitcoin block. The same limitations apply even more so to high-quality audio and video content. Nevertheless, the high cost of scarce blocksize is as much a feature as a bug. Placement within the world’s first, costliest, and most secure blockchain confers an undeniable prestige. Those with suitably-small art or deep pockets will therefore continue to raise the perceived value of their work through direct association with Bitcoin. This will inevitably lead to a situation where data-heavy art (or that produced by the archetypal starving artist) finds its natural place on Layer 2 metaprotocols. Thus I still foresee a fee-determined bifurcation of Bitcoin-based art between layers.

BRC-20s – Time to Go!

Whereas image Inscriptions have their place, in my view BRC-20s (and related on-chain tokens) are now obsolete. There are some significant and fundamental drawbacks to these tokens:

1. BRC-20s are minted on a first-come-first-served-no-refunds (FCFS/FU) basis. If your transaction arrives after all supply has been claimed then your funds are wasted and you get nothing. This leads to the bursts of intense fee competition which are so disruptive to the Bitcoin network – and cause much Ordinals backlash.
2. BRC-20s rely on centralized indexers, run primarily by exchanges, to keep the ledger of who-owns-what straight. The potential for desynchronization and fraud is high.
3. BRC-20 transfers and actions require on-chain Bitcoin transactions. This is expensive and relatively slow compared to tokens on competing chains.
4. BRC-20 tokens are limited in their application. To my knowledge, the basic functions expected of tokens on other chains, such as any kind of decentralized financial applications, have yet to materialize. Certainly nothing like a BRC-20 stablecoin of any repute exists at this time – Stably is not something I’d recommend even to a central banker.
5. BRC-20s are limited to 4 character tickers – and all the juiciest 4-letter words have long since been taken.

Further to point 1… New BRC-20s deployments are under constant threat by “The Sophon,” a rather aggressive bit of now-public code, developed by Rijndael to stifle new on-chain tokens. Named for the single-proton supercomputers deployed by aliens to block scientific progress on Earth (at least in Cixin Liu’s excellent sci-fi trilogy, “Remembrance of Earth’s Past”), Bitcoin Sophons scan the mempool for any new BRC-20 activity. Upon detection, Sophons pay for a high-fee transaction intended to front-run the original BRC-20 deployment transaction and set its total supply to 1. This effectively occupies the BRC-20’s intended ticker and invalidates any mint transactions from users, incidentally wasting any of their en-route transactions.

Suffice to say, I’m one of many Bitcoiners who believes that BRC-20s, in a word, suck. However, rather than trying to neutralize them via expensive Sophon transactions or censor them at the miner level, my preferred solution is to publicize the superior alternatives. To that end:

AdamCoin (AC) is the first token deployed on the Tiramisu TA wallet and exchange. AC enjoys a bullish and active market and, like all tokens on Tiramisu, can be traded by both Liquidity Pool and Order Book. Many other tokens and NFTs are available for trading on Tiramisu and the process of creating new ones is cheap and reliable (sans menacing multi-dimensional micro-computers). As an added bonus in these trying high fee times, Tiramisu deposits and withdrawals can be made via Lightning.

TRICK and TREAT are twin TA tokens trading on the open-source NostrAssets platform. With a Telegram channel of 13,000+ members, trading is brisk indeed and has the added bonus of integration with the Nostr protocol (despite Fiatjaf’s heated objections). Currently NostrAsset’s only real drawback is that it doesn’t allow the minting of new tokens or NFTs.

PePe-RGB is an RGB-based project in the final stages of launch preparations. PePe has already attracted a massive Twitter following of 28,500+ people and enthusiasm runs high for the PePe’s initial stage; the release of the world’s first popular RGB-20 token. There’s a lot more in PePe’s plan however, already there’s a fully-3D animated avatar, the grandson of the ubiquitous memetic frog, cast as the protagonist in a narrative set to play out across a cyberpunk city. It’s even rumored that a certain Seal may guest star… and even release his own token with utility for a verified-human-art market in future!

So, with such fine L2 tokens available, the question is why anyone still bothers with BRC-20s? As even the most scorchingly laser-eyed Bitcoin Maxi must admit, shitcoins ON Bitcoin are a damn site better than shitcoins IN Bitcoin!

Stealthy Stablecoins in the Colourful Dark

Speaking of tokens, it’s understandable that many Bitcoiners have little interest in them. However, stablecoins are – like it or not – major players in our space. The third largest coin by market cap, Tether, is particularly noteworthy for regularly having the highest daily trading volumes across the market. It seems that fiat and BRC-20 enjoy a similarly persistent demand, despite the existence of vastly superior alternatives… And while a cryptocurrency bound to fiat may be far from the cypherpunk ideal, that doesn’t mean it can’t be improved. For example, a digital Dollar invisible to chainanalysts and regulators alike (24:30) offers some interesting new possibilities in a world of increasing monetary sanctions and surveillance. Perhaps with such possibilities in mind, Tether’s CEO and Bifinex’s CTO, Paolo Ardoino, has named RGB as the rightful successor to the stablecoin’s original platform, and the best opportunity for issuing stablecoins on BTC.

Indeed, while nothing prevents the issuance of stablecoins on TA, RGB has some technical advantages which make it an ideal platform. Firstly, TA has the constraint of its universe model, in which each asset issuer creates their own unique and separate universe in which their assets operate. While it’s possible to bridge universes, this requires permission from the original issuer. For assets intended to trade freely across the web – and stablecoins are surely most useful when easily transferable between various exchanges, wallets, etc. – this structure presents some obvious difficulties and centralization issues. RGB has no such constraints. Any two parties using the RGB system can freely exchange any amount of assets. Additionally, due to RGB’s client-side validation model, only those parties would be aware that any such exchange occurred… Might we be looking at “gaining a new territory of freedom for several years,” about 15 years after Satoshi’s original statement?

The RGB rabbit hole goes a lot deeper, to the extreme future prospect of Prime, whereby Bitcoin itself rebases from its blockchain to a client-side validation model – all achievable on a voluntary basis without any soft or hardfork required. Such a prospect is well beyond the scope of this article, so let’s confine ourselves to another exciting feature of RGB – complex smart contracts running on Bitcoin. This opens the door to all the opportunities (and risks) of the DeFi space but hopefully, done privately and in a low-cost, scalable manner atop Bitcoin. While some will have their objections, the prospect of rendering Ethereum and other on-chain smart contract platforms obsolete holds undeniable appeal…

Conclusion: Layer 2 is Bullish for Bitcoin

As the next Bitcoin bull market gets underway, Bitcoiners have the opportunity to make Layer 2 metaprotocol solutions part of the narrative. By failing to do so, more attention will flow to familiar, flawed options like BRC-20s, which will exacerbate the fee pressures usual to hot Bitcoin markets. Even for Bitcoiners without any interest in the possibilities and prospects of L2 metaprotocol assets, understanding and promoting them is a good way to support Bitcoin’s next growth phase.

This is a guest post by Steven Hay. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Source link

One example of where this issue crops up is the integration of Lightning into different applications and software tools. Lightning is a very complicated protocol stack to implement, involving numerous sub-protocols dictating how to coordinate and process updates to the state of a Lightning channel. This involves the transaction structure for each channel state and what it is enforcing, the order in which each step of crafting and signing new transactions is conducted to guarantee safety of user funds, and functions to watch the blockchain to react in the appropriate way automatically if invalid states are ever submitted to the blockchain.

This is a lot of complexity for a single application developer to take on themselves directly integrating to their project. The obvious conclusion if that requires too much effort is to depend on already produced software handling the problem of implementing Lightning, and simply build your application to talk to that external software. That leads to the next problem: what if your application’s users don’t use that particular Lightning implementation or wallet?

Even by outsourcing that functionality of an app the development team still hasn’t fully escaped the complexity problem. While they don’t have to fully implement Lightning on their own, a developer taking this route now has to handle incorporating API support for any Lightning wallet the user of their application could potentially be using. This necessitates keeping up with any changes or alterations to multiple Lightning wallets, their API, how the internal features of that wallet works and which ones they support. Not keeping up with any changes in a particular wallet would break their application for users of that wallet.

Some standardized mechanism needs to exist for software on both sides of that gap to simply be able to implement that one thing for all of these different tools to talk to each other. This would allow each application developer, and each Lightning wallet developer, to all simply integrate and maintain one single protocol that would enable their applications to communicate with each other.

Nostr Wallet Connect is a protocol making the attempt at being a truly generalized mechanism for fulfilling this need. When seeking to embed Lightning payments into Nostr, all of these complexity issues arriving from how to do it cropped up.

Lightning And NWC

The team behind Amethyst, a Nostr client, and Alby, the web based Lightning wallet, created NWC in order to solve the problem of Nostr users wishing to integrate Lightning into their Nostr experience without having to use a special purpose wallet. The application/protocol is based on Nostr’s identity architecture where every message (event) sent over Nostr is signed by a cryptographic keypair functioning as your identity on Nostr. This allows an application to simply generate a Nostr keypair, and from that alone have a cryptographic authentication mechanism to use in communicating with an external Bitcoin wallet to fulfill the functionality of the app.

Using the keypair to register the external application with the Lightning wallet, the application can now ping your wallet to initiate a payment. The specification currently supports paying BOLT 11 invoices, making keysend payments (invoiceless payments made to a node’s public key), paying multiple invoices simultaneously, generating an invoice to present to someone else to pay you, and a few other functionalities to allow payment history and wallet balance queries from the external application.

All of this is coordinated over Nostr, allowing for a very redundant means of communication not dependent on a single centralized messaging mechanism or the user needing to depend on complicated software such as Tor or other protocols to facilitate the network connection between an application and wallet software or infrastructure running on their home network. Nostr also supports encrypted direct messages, meaning the communication between the wallet and the application is entirely private, revealing no details about payments being coordinated to the Nostr relays used to communicate.

On the wallet side of the NWC bridge, security restrictions can be implemented to prevent the external application from having unfettered access to wallet funds in the case the Nostr key used to communicate with the wallet was compromised. Restrictions on the amounts allowed to be spent, as well as the frequency of payments, are configurable on the wallet side of the connection.

NWC is useful for far more than simply integrating Lightning into Nostr applications as well. The entire design philosophy of Nostr itself as a protocol was centered around keeping it simple enough that the entire protocol could be easily implemented correctly by any developer with minimal time and resources. Applications that have nothing to do with Nostr can easily integrate NWC or similar protocols with almost no overhead or complexity to address the underlying issues of how to connect a Bitcoin wallet with their application without having to build it directly into the app.

Beyond Lightning

The potential for a protocol like NWC to provide massive value to wallet and application developers goes far beyond integrating Lightning wallets into special purpose applications. The entire long term direction of interacting with Bitcoin, short of some mind blowing fundamental breakthrough no one has yet realized, is towards interactive protocols between multiple users.

Multiparty coinpools are a perfect example. Most of the specific design proposals like Ark or Timeout trees are built around a central coordinating party or service provider, which can easily facilitate a means of message passing between users wallets, but this hamstrings the design space with a single point of failure. If a hundred users are packed into a coinpool together on top of a single UTXO, the security model is based around each user having a pre-signed pathway to withdraw their coins unilaterally on-chain. This mechanism can be exercised in the event of any failure or disappearance of the coordinator to ensure their funds are not lost, but this is the least efficient way to handle such a worst case scenario.

If users were able to find a mechanism to communicate with each other in the absence of the service provider or coordinator, much more efficient on-chain exits could be achieved by using the larger group multisig to migrate their funds elsewhere with a much more efficient (and therefore cheaper) on-chain footprint. NWC and Nostr are a perfect fit for such a scenario.

Collaborative multisignature wallets between multiple parties could also benefit from such a protocol. In combination with standards like PSBT, a simple Nostr communication mechanism could drastically simplify the complexity of different wallets with multisig support coordinating transaction signing in a smooth and user friendly way.

Discreet Log Contracts (DLC) are another amazing use for such a protocol. The entire DLC scheme relies on both parties being able to access oracle signatures to unilaterally close a contract correctly if both parties will not cooperate to settle it collaboratively. Nostr is the perfect mechanism for oracles to broadcast these signatures, and allow for a simple subscription to their Nostr key in users wallets to automatically track and acquire signatures when broadcast by oracles.

As time goes on and more applications and protocols are built on top of Bitcoin with the requirement of interactivity between users, and between different applications, a general purpose communication mechanism to facilitate that without relying on a single point of failure is going to be sorely needed.

Nostr is the perfect underlying protocol to facilitate that given its incredible simplicity and the redundancy of a large set of relays to utilize. NWC is the perfect example of that being a viable solution. 

Source link

CommerceBlock is releasing Mercury Layer today, an improved version of their variation of a statechain. You can read a longer form explanation of how their Mercury statechains work here. The upgrade to Mercury Layer represents a massive improvement against the initial statechain implementation, however unlike the initial Mercury Wallet release, this is not packaged as a fully consumer ready wallet. It is being released as a library and CLI tool other wallets can integrate. Here’s a quick summary of how they work:

Statechains are essentially analogous to payment channels in many ways, i.e. they are a collaboratively shared UTXO with a pre-signed transaction as a mechanism of last resort for people to enforce their ownership. The major difference between a Lightning channel and a statechain is the parties involved in collaboratively sharing the UTXO, and how ownership of an enforceable claim against it is transferred to other parties.

Unlike a Lightning channel, which is created and shared between two static participants, a statechain is opened with a facilitator/operator, and can be freely transferred in its entirety between any two participants who are willing to trust the operator to be honest, completely off-chain. Someone wishing to load a statechain collaborates with the operator to create a single public key that the creator and operator both hold a share of the corresponding private key, with neither having a complete copy of the key. From here they pre-sign a transaction allowing the creator to claim their coins back after a timelock unilaterally.

To transfer a statechain the current owner collaborates with the receiver and operator to sign a cryptographic proof with their keyshare that they are transferring the coin, and then the receiver and operator generate a new pair of keyshares that add up to the same private key and sign a timelocked transaction for the new owner with a shorter timelock than the original (to ensure they can use theirs sooner than past owners). This process is repeated for every transfer until the timelock cannot be shortened anymore, at which point the statechain must be closed out on-chain.

Owners transfer the entire historical chain of past states with each transfer so that users can verify timelocks have been properly decremented and the operator timestamps them using Mainstay, a variant of Opentimestamps where each piece of data has its own unique “slot” in the merkle tree to guarantee that only a single version of the data is timestamped. This let’s everyone audit the transfer history of a statechain.

In The Land Of The Blind

The big change Mercury Layer is bringing to the original version of statechains is blinding. The operator of the statechain service will no longer be able to learn anything about what is being transferred: i.e. the TXIDs involved, the public keys involved, even the signatures that it collaborates with users to create for the pre-signed transactions necessary to claim back your funds unilaterally.

Introducing a blinded variant of Schnorr MuSig2, Mercury can facilitate the process of backout transaction signing without learning any of the details of what they are signing. This necessitates some design changes in order to account for the fact the operator can no longer see and publish the entirety of a statechain’s transfer history. They are not even capable of validating the transaction they are signing at all.

In the prior iteration, uniqueness of a current statechain owner/transaction set was attested to by the operator through the publishing of the entire transfer history of the statechain with Mainstay. That is not possible here, as in the blinded version the operator learns no details at all about these transactions. This necessitates a new way of the operator attesting to current ownership of the statechain. All of this data is pushed entirely to a client side validation model. The operator simply keeps track of the number of times it has signed something for a single statechain, and tells a user that number when it is requested. The user then receives the transactions of past statechain state’s from the user sending to them, and verifies entirely client side that the number of transactions match what the operator claimed, and then fully verifies the signatures are all valid and the timelocks decremented by the appropriate amount each time. In lieu of publishing the full statechain transactions and transfer order to Mainstay, because it is designed to be unaware of all of that information, it publishes its share of the public key (not the full aggregate public key) for the current user for each statechain user. This allows any user receiving a statechain to verify the transfer history and current state is legitimate against the transaction data sent by the sender.

The operator server keeps track of unique statechains to count past signatures by assigning each statechain a random identifier at creation, stored with its denomination and its private key and public key shares (not the entire aggregate public key). The new coordination scheme for sharding and re-sharding the key is done in a way where the server passes its share of the key to the user, and the data necessary for a resharding is blinded so the server is incapable of ever learning the user’s full public key share, allowing it to create the full aggregate public key and identify the coin on-chain.

The design doesn’t even allow for the operator to know when it has signed a cooperative closure with the current owner rather than a pre-signed transaction for a new off-chain owner; it doesn’t see any details to distinguish the two cases from each other. This is safe however for users who could be attacked by someone trying to “double spend” a statechain off-chain providing a fake transaction that couldn’t be settled. Firstly, that user would see on-chain that the UTXO backing that statechain was spent. Secondly the transaction history, because the operator must sign all state updates, would only have a clear cooperative closure in the chain of past transactions. Both of these things would allow the user to refuse the transaction knowing it was not legitimate.

Statechains also allow Lightning channels to be “put on top” of the statechain by having the statechain pay out to a multisig address between two people, and the two of them negotiating a conventional set of Lightning commitment transactions on top of it. It would need to close the statechain on-chain before closing the Lightning channel so would need to use longer timelock lengths for Lightning payments, but otherwise would function perfectly normally.

Overall with the massive privacy improvements of the new iteration of statechains, and the composability with Lightning, this opens many doors for the economic viability and flexibility of second layer transactional mechanisms on Bitcoin. Especially in light of the recent radical changes in mempool dynamics and the resulting fee pressure.

It offers the same type of liquidity benefits of Ark, i.e. being able to be freely transferable without needing receiving liquidity, but unlike Ark is live and functional today. It is undeniably a different trust model than something like Lightning alone, but for the massive gains in flexibility and scalability, it is definitely a possibility to explore. 

Source link