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

Source link

The new Launchpad will provide those looking to inscribe directly onto Bitcoin an easy way to build their collection.

Magic Eden, an NFT platform, has announced the opening of a Launchpad to inscribe collections using the Ordinals protocol on Bitcoin. 

This comes shortly after the platform’s launch of an Ordinals marketplace, which has helped Magic Eden become the “top marketplace for trading Bitcoin inscriptions,” according to the press release.

The press release describes the company’s goal of offering a safe and secure platform for creators to launch their collections, with the first collection launch scheduled for April 7, 2023. According to the release, the platform has already served over 500 creators and raised over $150 million on their behalf.

Zhuoxun Yin, COO, and co-founder of Magic Eden commented on the announcement, “We’re excited to expand our creator capabilities to Bitcoin and offer easy ways for creators to get started and launch… With Ordinals, content can be preserved forever, and we’re proud to be helping creators and the Ordinals community grow together.”

Magic Eden’s move to provide creators with a Launchpad for Bitcoin inscriptions comes at a time when Bitcoin inscriptions have seen a significant uptick in popularity throughout Q1 2023, as the press release describes.

The Ordinals protocol allows users to insert arbitrary data onto specific UTXOs, effectively enabling immutable NFTs built directly into the Bitcoin blockchain. Since the launch of the protocol, its impacts have been debated. That being said, almost 1,000,000 pieces of data have been inscribed onto the blockchain already as of the time of writing, and there are no signs of that stopping. 

Source link

Source link

Source link

On Monday, the non-fungible token (NFT) marketplace Magic Eden announced the launch of Bitcoin Ordinal inscription support. Magic Eden said it has partnered with the wallets Hiro and Xverse to “bring a familiar wallet transaction experience to the marketplace.”

Magic Eden’s Decision to Launch on Bitcoin Without Royalty Support and Compete With Emerging Markets

Magic Eden announced in a recent blog post that it has added Bitcoin Ordinal inscription support to the NFT marketplace. Last year, the Solana-based NFT market expanded to Polygon and Ethereum. With the addition of Bitcoin, Magic Eden now supports a total of four blockchains. The team is also “re-planning a more concerted entry into Ethereum,” according to the blog post.

The Bitcoin-centric section of the marketplace currently features several Bitcoin Ordinal inscription collections, including “Bitcoin Boos,” “Bitcoin JPGs,” “BTC Machines,” “Ordinal Tortoises,” “Unordinals,” “Satoshi Punks, and “Megapunks.”

At the time of writing, there were close to 600,000 Ordinal inscriptions on the Bitcoin blockchain, with a total of 567,622 minted. According to statistics from Dune Analytics, the number of Ordinal inscriptions surpassed the 500,000 milestone on March 17, 2023.

Magic Eden says the recent move to support Ordinal inscriptions is in line with Bitcoin culture. “By building on Bitcoin, we contribute to the culture of trust, security, and decentralization that is synonymous with the blockchain,” the NFT marketplace explained.

The blog post goes on to say:

This move aligns with our mission to promote the benefits of collectibles and blockchain technology while remaining true to the principles that underpin the technology.

Magic Eden’s Bitcoin-centric market will compete with other Ordinal inscription markets that have emerged since inscriptions started gaining traction, such as Gamma.io, Ordx.io, and Generative.xyz. The marketplace, however, has been an active NFT market for some time, as Magic Eden has recorded $2.08 billion in all-time sales. To smooth the Ordinal inscription support process, the NFT marketplace Magic Eden partnered with the wallets Hiro and Xverse.

According to dappradar.com statistics, Magic Eden ranks as the fifth-largest NFT marketplace in terms of all-time sales. As far as Bitcoin-based Ordinal inscription sales are concerned, Magic Eden said it spent a long time thinking about handling royalties and “decided to launch on Bitcoin without royalty support for now.” Magic Eden has also created a new Twitter handle for the Bitcoin-centric version of the NFT marketplace, which is called @meonbtc.

What do you think the future holds for Bitcoin-based NFT marketplaces? Share your thoughts in the comments section below.

Jamie Redman

Jamie Redman is the News Lead at Bitcoin.com News and a financial tech journalist living in Florida. Redman has been an active member of the cryptocurrency community since 2011. He has a passion for Bitcoin, open-source code, and decentralized applications. Since September 2015, Redman has written more than 6,000 articles for Bitcoin.com News about the disruptive protocols emerging today.