The original author: game-boss.eth (Twitter: @gameboss_eth)

Editor's note: This article provides a detailed introduction to the first recursive inscription game on the Bitcoin ecosystem Ordinals - Pixel Wars. The author uses the game's white paper to further demonstrate gameplay, token economics, guild introduction, and how early participants should layout. As the game is relatively new and many users are still exploring, everyone should still pay attention to related risks and protect their assets during the experience.

This tweet is a detailed introduction to the BTC Pixel War @btcpixelwar. First of all, I would like to thank the group member who provided the information at 19:35 on November 1st. Due to waking up late, the tweet is only being sent out now. This is a very complex long-term game.

The white paper link of Pixel War https://pixelwar.gitbook.io/btc-pixelwar/ provides detailed information on gameplay economics, as well as NFTs, halving mechanisms, airdrop rewards, and more. This tweet mainly discusses how to play and how to layout.

Gameplay

1. Open the BTC Pixel Wars website, click on the "connect wallet" button in the top right corner to connect your Unisat wallet. If you don't have a Unisat wallet, search and install it from the Chrome extension store, create a wallet and remember your mnemonic phrase, then transfer BTC to your Unisat wallet.

2. Now you can start drawing. The red box in the picture indicates the switch between two drawing modes. One is to use a drawing robot to directly upload the picture and generate pixel art. The other is manual drawing. For organizations promoting their brand, they can use the drawing robot. For individual users, it is recommended to use the manual mode to draw complete pixel art with very few pixel blocks.

3. First, let's introduce how to use the drawing robot. Just follow the instructions in the first image. After selecting, you can see the part circled in red, which shows the size of your canvas and how many pixels it contains. You can scale it yourself to reduce or increase the number of pixels. After completing, select "submit" and you can start drawing the image on the right. The last image shows how much it costs. You can manually draw and use the eraser on the left to fine-tune the image.

Most people don't have a lot of money, so they can upload pictures first and then erase the unnecessary content, leaving only the outline. This way, a picture can be completed with very few pixels (a large picture requires a lot of pixels). If you want to create a beautiful picture, you need the help of the guild, where everyone can contribute.

Introduction to the Guild

The way to enter the guild is circled in the red box in the lower right corner. Friends who want to join the guild can click "Apply" to join the Cryptonaunts guild and come to my Telegram group to develop a drawing plan together. Of course, you can also create your own guild. Since I have already created one, I cannot provide a screenshot for illustration. Simply put, you just need to "Create Guild" and set the name and avatar.

If you are using manual mode, you can first create a pixel image for comparison using https://pixel.sumo.app, and then directly draw it on the canvas after fine-tuning.

Finally, some information to note: the data displayed at the top of the image shows the current block height and how many people have submitted pixels. The progress of available pixels for submission is displayed below, and detailed information can be viewed by hovering the mouse over it.

Token Economics

First is the pixel price: the price of each pixel is 0.00003BTC (around 1U). There are a total of 2.1 million pixels on the canvas, which means that when all pixels are purchased, it is worth 21 million US dollars. You can earn 10$BPIX for each pixel you submit. Early supporters will receive 5% of the total pixels as an airdrop, 5% of the pixels as a marketing reward, and daily rewards for guild rankings, which can be evenly distributed among guild members.

The user rankings also give away some pixels every day, and only these can be obtained for free. The remaining 82.5% of pixels need to be purchased.

Because submitting can get a BTCNFT generated from the current screenshot, everyone can choose to submit a pixel when displaying a more complete image with a well-known IP on the canvas to get an NFT for speculation, which is also a good choice.

Then it is halved, and the number of pixels that can be submitted in a single submission will gradually decrease according to the total number of pixels submitted. This process is divided into 7 stages, and after completing the sixth stage, it will enter the final auction stage, which is equivalent to putting a seal on this painting worth 21 million US dollars.

When the remaining pixel count is less than 3000, the auction begins and players can bid on the remaining pixels. The highest bidder wins (similar to the BRC20 method, but without increasing gas). If no one bids within six blocks, the remaining pixels will be automatically auctioned. This stage is expected to be very intense, as the final winner will be able to overlay their pixel art in the center of the canvas.

The gameplay and economics are pretty much covered here, so let me share my personal opinion. There will definitely be a lot of people playing this game, without a doubt. How to profit from it?

Here I will mention some possible hype concepts, first is the canvas-generated NFT, followed by the $BPIX token deployed on the Lightning Network, and then the advertising effect of the canvas after it gains popularity. I will post some specific analysis in my telegram group, and welcome discussion.

Original Link

Original Title: "Unlocking LightningFi: Taproot Assets Goes Live on NostrAssets Mainnet (with Airdrop Tutorial)"

Original Author: Nostr Assets Protocol

Translated by: Deep Tide TechFlow

Recently, Lightning Labs launched Taproot Assets, which has aroused great interest and excitement among users. The enthusiasm of being one of the pioneers to first encounter or own Taproot Assets was evident in our recent Zealy event, with over 8,000 individual Nostr addresses already registered.

In addition, our integrated partner Alby Wallet witnessed a surge in registration during our event, with over 6,000 registered users, a significant increase from previous weeks.

After months of relentless dedication, innovation, and rigorous testing, we are pleased to announce the long-awaited release of Taproot Assets on the NostrAssets mainnet. This significant development brings various possibilities to the Taproot community and opens a new era for decentralized finance.

In the current version, what can you do with Taproot assets on NostrAssets?

We have developed a comprehensive set of features for Taproot Assets, and we will gradually introduce them to the public. This strategy ensures that all features undergo rigorous testing before introducing any new ones.

Transfer Taproot Assets via the NostrAsset web client or other decentralized social messaging applications on Nostr:

Goodbye Gas fees! You can now transfer your Taproot Assets directly to another Nostr address, quickly and cost-effectively.

Trade Taproot Assets on NostrAssets Marketplace:

Enter the world of trading with ease. You can now use satoshis to trade your Taproot Assets on the NostrAssets market, making it easier for you to participate in asset exchanges within the Nostr community.

You can use a lightning wallet like Alby Wallet to deposit satoshis into your Nostr address.

What is NostrAssets?

NostrAssets is an open-source decentralized protocol designed to seamlessly integrate Taproot Assets and Bitcoin into the Nostr ecosystem. It empowers users with the ability to perform various financial activities using their Nostr public and private keys.

It is supported by the Nostr protocol, which is a permissionless and trustless relay network that ensures communication on the internet is not subject to censorship.

With the support of Lightning Network and the powerful Bitcoin blockchain, NostrAssets provides a secure and efficient environment for financial activities.

Why Choose NostrAssets Protocol?

Financialization of Taproot Assets and Bitcoin:

NostrAssets has opened the door to various financial operations, including sending, receiving, and trading. It also supports a wide range of financial applications, such as decentralized exchanges (DEX), derivatives, fundraising, and more.

Empowering Software Developers:

NostrAssets provides software developers with the tools they need to create innovative products across social platforms, games, and various other fields. This facilitates the emergence of practical use cases and drives widespread adoption.

Enriching the value of Bitcoin and Lightning Network ecosystem:

NostrAssets enriches the value of the Bitcoin and Lightning Network ecosystems, creating a positive feedback loop that benefits all users.

From seamless chatting to trading:

NostrAssets achieves composability and interoperability on natural language through Nostr. It acts as a bridge connecting different decentralized applications on Nostr, enabling them to work seamlessly together. Users can easily perform financial operations using conversational language. For example, you can say "transfer 100 sats to Bob" on decentralized social messaging applications such as Damus and Iris to initiate transactions, making the experience user-friendly and accessible.

NostrAssets protocol's next step?

Importing Taproot Assets from Other Daemon Universes: (This feature will be released in future updates)

NostrAssets will allow you to easily import Taproot Assets from other Daemon Universes, such as Lightning Lab Universe. This means you can access and manage your assets from various sources, all within the Nostr ecosystem.

Receiving/Sending Taproot Assets in and out of Nostr (this feature will be released in future updates):

Receive Taproot Assets to your Nostr address or send them.

There are two exciting new features coming soon: asset issuance and the launch of Fair Mint for Taproot Assets.

TRICK OR TREAT

Original Title: "The True Potential of RGB"

Original Author: Ajian

This article attempts to provide a concise description of an asset issuance protocol on Bitcoin, RGB, which can also be understood as an off-chain smart contract system, and points out its differences from other protocols that aim to achieve similar functions. These differences make RGB protocol far more scalable than them and leave more room for programming. In addition to introducing the completed design of RGB, we will also explore these programming possibilities 1.

What is the RGB protocol?

The idea of issuing assets on Bitcoin has been around for a long time. However, the Bitcoin protocol has its own characteristics: its state is expressed only by Bitcoin UTXOs ("Unspent Transaction Outputs"); a UTXO carries only two pieces of data: its own denomination (Bitcoin value), and a "script public key" (also known as a "locking script"), used to program the spending conditions of this fund, such as providing a signature of a certain public key; the opcodes allowed to program the locking script are provided by the consensus rules of Bitcoin, and they cannot be used to implement arbitrary security rules. Therefore, it is impossible for us to create other assets within UTXOs - Bitcoin scripts cannot program security checks for these assets. This means that all ideas for issuing assets on Bitcoin are essentially a creative use of the Bitcoin block space. This means that we need to design an off-chain smart contract system and require that the steps that change the contract state - for example, contract A changes parameters, and B transfers a certain amount of some asset to C - upload information to the blockchain. By collecting this information, we can obtain the latest state of this smart contract system.

One rough design idea is to upload the information of the steps that change the contract state to the Bitcoin blockchain as is. This can certainly work, but it faces several problems: (1) since complete information is uploaded, it may consume more block space, and when users need to change the contract state (such as transferring funds), they will also need to pay more on-chain fees. Especially when we hope that such off-chain contract systems have better programmability than Bitcoin, the increase in programmability may come at the cost of consuming more block space; (2) almost any information in the block can change the off-chain smart contract, so users must obtain all Bitcoin block data to determine the latest state of the off-chain contract system, which increases its verification cost; (3) depending on the design of the off-chain smart contract system, perhaps only the same level of privacy as Bitcoin can be obtained, or even worse privacy. If more privacy can be provided, it may require more block space. (Note 5: https://www.btcstudy.org/2023/09/12/the-potential-of-RGB-protocol/#note5)

In the past, a protocol with high usage called "Omni" was used. It did not upload the complete information of off-chain contract transactions, only the hash value of the transaction. This approach solved the above problem 1, decoupling the complexity and economic cost of off-chain contract transactions. However, users still need to obtain the full Bitcoin block data to determine the latest status of the Omni protocol. In addition, it does not specifically enhance privacy.

而 RGB uses a new paradigm called "single-use seals". Its usage is simple: RGB requires that every state of every contract must be attached to a Bitcoin UTXO; and once this state needs to be changed, the UTXO must be spent and the transaction spending it must be confirmed on the blockchain. In addition, the Bitcoin transaction spending it must provide the hash value of the content of the state transition to indicate the UTXO to which the changed state is attached. 6.

From the perspective of RGB developers, this design is similar to numbered plastic seals: it is easy to tell if it has been tampered with, and once it has been tampered with, it cannot be used again. However, from another perspective, the UTXO that has been possessed can be regarded as a container or ceramic piggy bank for this state - if you want to take out the money in the piggy bank, you must break the piggy bank and put the money inside into a new one.

This design is in stark contrast to the previous protocol that treated the entire block as a capital letter board. Using UTXO as a container means that transactions that do not spend this UTXO cannot have any impact on the contract state inside the container. Therefore, to verify a certain state of a contract, we do not need to obtain all the data of the entire block. All we need is a series of Bitcoin transactions, which exist as evidence in a certain block, and the RGB state transitions promised by these Bitcoin transactions (paired with the relevant Bitcoin transactions). These data that can be linked into a chain should allow us to trace back to the initial state of the contract and enable us to identify the essence of this state.

For readers familiar with on-chain smart contract systems (such as Ethereum), one difficult aspect to understand is: how is the security of such a smart contract system ensured if it does not rely on the consensus of the blockchain (which means that the initial state of the contract and every state change will be verified by every node)? How can one ensure that the assets received are the ones they intended to receive, and how can one ensure that the assets have not been illegally increased?

The answer is simple, it's called "client-side validation". In the on-chain contract system, nodes verify each state transition operation and reject invalid operations based on publicly available state transition rules, thus calculating the latest state based on the initial state. However, as long as the state transition rules and initial state are known, verifying through on-chain consensus is not the only way. Users can verify whether each step of the state transition follows the originally defined state transition rules based on the information provided by the payment party. Through this method, the verifying party (assuming it is the recipient of the asset) can also detect illegal state transitions and reject them.

Finally, we use an example to demonstrate the characteristics of the RGB protocol:

Now, Alice owns UTXO A, which holds the asset Y of X units issued according to the RGB protocol, and she wants to transfer Y of Z units to Bob. This batch of assets has gone through 5 previous owners (including the asset issuer) before reaching Alice. Therefore, Alice needs to provide Bob with evidence of these 4 state transitions (the evidence for the first 3 transitions was provided to Alice by the previous owners), including the initial state and state transition rules of the contract, the Bitcoin transactions used for each transfer, the RGB transactions promised by each Bitcoin transaction, and the evidence that these Bitcoin transactions were confirmed by a certain block, all sent to Bob. Bob will verify that these 4 transfers do not violate the rules according to the state transition rules of the contract, and then decide whether to accept them. When Alice constructs the RGB transaction, since Z is less than X, she also needs to arrange a UTXO for herself to receive the remaining part. Finally, Alice embeds the hash value of this RGB transaction into the Bitcoin transaction that spends UTXO A, completing this payment.

Finally, due to the use of UTXO containers, the latest state of an RGB contract can be represented as a point on a directed acyclic graph with no descendants (each point represents a state stored in the UTXO container). Moreover, for owner P in the following figure, he will only know the process from the initial state G to his own state, i.e. the process marked in red, and knows nothing about the gray points:

RGB Advantages

Lightweight Verifiable State

As mentioned above, compared with the asset issuance protocol (off-chain contract system) previously appeared on Bitcoin, RGB significantly reduces the cost of verification (a state of a contract). When making a transaction, the receiver no longer needs to traverse all blocks to collect information about the change of contract state, but only needs to obtain a series of Bitcoin transactions, as well as the RGB transactions promised by these transactions. By including evidence in the blocks of these Bitcoin transactions (based on the Merkel proof of the block header), the receiver can be sure that the payer really owns a certain amount of a certain asset.

The reduction in the cost of this type of verification also greatly reduces the user's dependence (trust) on large infrastructure providers. In previous protocols, due to the high cost of verification, users were unable to calculate the latest status of the contract themselves, so users had to trust some providers (such as the contract status provider used by their own wallet); at the same time, because there are few providers who can afford such calculation costs, this also means centralization of providers. However, in RGB, users only need to use a Bitcoin light client to check part of the transaction with Bitcoin, and use the RGB protocol to check part of the RGB transaction, which they can afford themselves.

Compared with some on-chain contract systems, RGB appears to be more lightweight. This is reflected in the fact that RGB can selectively verify a specific state of a contract, while in systems that are not based on UTXO, any transaction can change any state without a mechanism to control access, making it almost impossible to selectively verify a specific state. Instead, one can only determine a specific state while calculating all the latest states, which is expressed as the "global state" feature, but should actually be called the "uniform state" feature. Although it provides the feature of cross-contract access, it also determines that its verification cost will be higher and it will be more difficult to obtain trustlessness.

One major optimization measure in these chain-based contract protocols is to require the block header to commit to the latest state ("state root"), allowing light clients to verify a certain state of a contract obtained from a full node based on these commitments. This is a method of reusing computations that have already occurred (computations that have already been run by full nodes), which is also very efficient. Therefore, if trustlessness is not considered, it can be considered more efficient than RGB. However, it still means that light nodes rely on full nodes for transaction-based verification and contract state calculation. In the RGB wallet that uses the Bitcoin light client, the trust assumption it relies on is that the relevant Bitcoin transactions are valid transactions, and the part related to the contract state is verified by the client itself, so trustlessness is better. The disadvantage is that the verification delay is longer and more data needs to be stored.

Scalability

The scalability of RGB is reflected in two aspects:

Only a hash value is embedded in Bitcoin transactions, which means that the volume of RGB transactions (except for custom rules of the contract) is not limited - even if you divide an RGB asset into 100 parts (the RGB transaction itself will be very large), only one hash value needs to be embedded in the Bitcoin transaction. As mentioned in Note 6, there are two ways to embed such hash values: one is to use the OP_RETURN output, which means it will consume on-chain space for a hash value; the other is to hide it on the script tree promised by the script public key in the Taproot output - which will not consume any on-chain space. This also means that users do not have to sacrifice economy for programmability - only considering on-chain transaction fees.

The latest state of the RGB contract is an independent point with no descendants on a directed acyclic graph - which means that these states can be changed independently and do not affect each other, allowing for concurrency. This is actually a feature inherited from UTXO. This also means that invalid changes (invalid transactions) that occur on one branch will not affect other branches, let alone cause the entire contract to freeze, so it can also be considered a security benefit.

One criticism of RGB's scalability is that every transfer requires the receiver to verify all transactions from the initial state to the payer's state - as the number of asset transfers increases, the verification burden on subsequent receivers will become heavier. This criticism is valid. However, optimizing it means finding a way to reuse previously performed operations. Proof system technologies (such as SNARKs) are expected to provide such solutions 7.

Asset Definition and Custody Mechanism Separation

The final benefit is still related to UTXO, depending on how we understand the locking script mechanism of UTXO.

Locking script can be used to program the unlocking conditions of a fund, thus enabling the implementation of custody rules. For example, if a locking script contains only one public key, it means that only the owner of the corresponding private key can control it. However, such custody rules are also the basis of Bitcoin contract-style protocol programming 8. For example, a UTXO that uses a 2-of-2 multisignature locking script can be a lightning channel; during the channel operation, the two parties can make almost countless mutual payments, and the on-chain form of the funds will not change. In other words, at this time, the 2-of-2 multisignature locking script constitutes a value transfer mechanism, allowing both parties to transfer value without changing the on-chain form of the funds.

This mechanism can be used for the Bitcoin value carried by UTXO, and of course, it can also be used for RGB assets carried by UTXO. We can issue an RGB asset and attach it to a 2-of-2 multisig UTXO, thereby utilizing the mechanism of Lightning Network to make unlimited mutual payments of this asset between the two parties 9. Similarly, RGB assets can also enter other Bitcoin script-based contracts.

Here, the functional differentiation between UTXO scripts and the RGB protocol is formed: the former is dedicated to implementing rules for value custody and transfer, while the latter focuses on asset definition. As a result, asset custody and asset definition can be separated. This is an important security enhancement and something that people have been striving for in contract systems on some other chains.

RGB has made the design

The above features actually apply to all protocols based on UTXO one-time sealing and client verification. However, on this basis, the RGB protocol has made further designs.

In the current development of the RGB protocol, developers are particularly concerned about the privacy of the protocol. Therefore, RGB has strengthened privacy in two aspects:

Blinding UTXO. In RGB transactions, the recipient only needs to use the obfuscated UTXO identifier to receive assets, without exposing the characteristics of the UTXO that actually receives the assets. This does not affect the recipient's ability to provide evidence to the next owner, while allowing subsequent asset recipients to resist the surveillance of previous asset owners.

Bulletproof. It can be used to hide the specific amount of each transaction. However, the subsequent asset owners can still verify that there has been no increase in issuance before.

Explorable Space

In this section, I will discuss the space that can still be explored with regards to the programmability of the RGB protocol.

Currently, all proposed RGB contract templates (schemas) are focused on asset issuance. However, due to RGB's use of the "client-side validation" paradigm, in reality, we can add any feature that can be ensured through client-side validation - limited only by the structure of UTXOs.

Restriction Terms

On the basis of UTXO, a concept that can expand programmability is called "covenants"  10. The original intention of covenants is to restrict the destination to which a fund can be transferred. With this ability, we can program many interesting applications, such as:

Non-interactive withdrawal fund pool. We can gather funds from many people into the same UTXO and use restrictive terms to ensure that anyone can withdraw their own funds without the help of others. This can help people withdraw from high-risk places at low cost when there is high demand for block space.

Safe deposit box contract. It requires a sum of money to be spent in a certain place and go through a time lock before it can be spent freely. During the time lock, the owner of the safe deposit box can use an emergency key to interrupt the process and immediately transfer the funds to another place. This device can provide great assistance for self-storage.

The current Bitcoin script does not have this capability, so enabling restriction clauses on the Bitcoin script requires a soft fork.

However, as long as we are willing to sacrifice some of the benefits brought by the "differentiation of asset definition and custody mechanism", we can experiment with such features on RGB assets. We can implement this functionality at the RGB contract level - although it only applies to RGB assets that use it (not Bitcoin), it will undoubtedly open up an interesting space.

Research on existing restriction clauses shows that they can expand the programming space for UTXO-based transactions and provide many features. However, these studies are mainly based on Bitcoin, and we are more conservative on protocols like Bitcoin. On RGB, we can boldly generalize the core ability of restriction clauses - the ability to read transactions that spend themselves at the script level - to provide more flexible programmability: the ability to cross-access contracts.

交叉访问

translates to

Cross Access

The minimum restriction clause means that when a UTXO is spent, its script can read the output of the spending transaction. However, a fully generalized restriction clause means that it can read all parts of the transaction that spends it. This means that it can also read other inputs of the transaction, and if we do not specify that other inputs must come from the same contract, it means that it can read the state of other contracts.

In RGB, we assume that each contract is an independent universe with its own directed acyclic graph. However, it is still possible for a user to hold the state of two different contracts at the same time. If RGB transactions allow spending assets from two different contracts at the same time, such cross-contract access may have use cases (although it can be imagined that it would make transaction verification more complex).

Actually, there are already on-chain contract systems based on UTXO-like structures (such as Nervos Network), which use this to achieve cross-contract access capabilities 11. This is a very new field, opening up areas that previous Bitcoin research has rarely touched, and perhaps there are some surprises hidden within.

Conclusion

In this article, readers will discover a concept that is frequently mentioned and runs through all the processes of reasoning and imagination: "UTXO". This is precisely my intention. If you do not understand UTXO, you cannot understand the starting point of the design of protocols such as RGB, nor can you understand the advantages of the design of RGB protocols, nor can you imagine how people use it. The characteristics of the RGB protocol are largely shaped by its UTXO, which is a one-time seal. Correspondingly, the research on UTXO accumulated in the Bitcoin research field can also be applied to the study of RGB.

This also explains why those who do not understand Bitcoin will find it difficult to understand RGB. Those who like Bitcoin, on the other hand, will appreciate the design that RGB has already made.

Due to excessive annotations in the article, please refer to the following link:

Source Link

Today, Casey Rodarmor, the founder of the Bitcoin NFT protocol Ordinals, proposed a new Bitcoin FT protocol design concept called "Rune", also known as the "Rune" protocol.

This agreement is different from the FT protocol on lightning networks such as BRC-20 and Taro/RGB. Why did Casey suddenly propose the idea of the "Rune" protocol? What progress has been made in less than a day since the idea was proposed?

BlockBeats will provide you with detailed information on all aspects of the "符文" protocol to date.

"符文"协议的设计出发点

(This is a title and a line break, which do not need to be translated.)

Casey Rodarmor summarized the biggest feature of the "符文" protocol in one sentence - a simple, UTXO-based FT protocol that enables Bitcoin users to have a good user experience.

Casey believes that if the on-chain "footprint" of the protocol is small and it promotes trusted UTXO management, then compared to the existing Bitcoin FT protocol, it may reduce "harm". At least, the popularity of BRC-20 has already created a large number of "garbage" UTXOs.

Casey compared the "符文" protocol with other existing Bitcoin FT protocols in the following 4 aspects:

- Complexity: How complex is the protocol? Is it easy to implement? Is it easy to be widely adopted?- User experience: Will any implementation details have a negative impact on user experience? In particular, the protocol for data under the dependency chain has a light on-chain "footprint" but introduces significant complexity. Additionally, users either run their own servers or discover existing servers and interact with them.

- State Model: UTXO-based protocols are more natural for Bitcoin and promote UTXO set minimization by avoiding the creation of "garbage" UTXOs.

- Native Token: Obtaining the native token required for protocol operations is cumbersome and extractive, so it is naturally unlikely to be widely adopted.

The translation of the given content is: "The result of the comparison is:"

- BRC-20: Not based on UTXO and quite complex, as it requires the use of the Ordinals protocol for certain operations.

- RGB: Very complex, dependent on underlying data chains, has been developed for a long time but has not been widely adopted.- Counterparty: Some operations require the use of native tokens instead of UTXO-based tokens.- Omni Layer: Some operations require the use of native tokens instead of UTXO-based tokens.

- Taproot Assets(Taro): It's a bit complicated and relies on data under the chain.

So how will the "Rune" protocol be implemented to solve the above pain points?

"符文" Protocol Implementation

Overview

"Rune" tokens are directly included in UTXOs, which can contain any number of "Rune" tokens.

If a transaction contains an output, and the pubkey script of that output contains an OP_RETURN followed by a data output representing the uppercase letter "R" in ASCII, then the transaction contains a protocol message. The protocol message is everything after the first data output.

If invalid protocol messages and "rune" tokens are inserted into a transaction, the "rune" tokens will be burned. This will allow the "rune" protocol to be upgraded in the future, avoiding allocation errors in the old version protocol for already created/allocated "rune" tokens.

Encode integers as prefix variables, where the starting part of the variable determines the byte length of the "rune" token.

Transfer of "Rune" Tokens

The first data output in the protocol message is decoded as a sequence of integers, which will contain three types of information: "ID", "OUTPUT", and "AMOUNT". If the number of decoded integers is not a multiple of 3, the protocol message will be considered invalid.

ID: Specifies which "rune" token is being transferred. Each "rune" token is assigned an ID when it is created, starting from 1. The earlier a "rune" token is created, the smaller its ID value.

OUTPUT: Determines which output to allocate to.

Why did Casey suddenly propose the "Rune" protocol?

In the official manual of the Ordinals protocol, we can see that Casey's vision for the Ordinals protocol is to create "digital artifacts" or "NFTs" through Bitcoin. However, with the development of the Ordinals protocol, the number of inscriptions related to BRC-20 has accounted for more than 85% of the total number of inscriptions.

Casey has been dissatisfied with BRC-20 for a long time, especially after his recent controversial tweets, which further highlight his negative attitude towards BRC-20:

My most desired Christmas gift is for speculators to discover Taproot Assets (Taro), so they can stop minting BRC-20 Tokens.

Can't we engrave the "transfer inscription" to lock the balance of BRC-20 token holders, so that they have to send the transfer inscription to themselves in order to unlock the balance?

In Casey's view, the "art gallery" he created has become a playground for speculators, which makes him very uncomfortable. Not only has his "art gallery" turned into a "big casino," but Casey also has a negative attitude towards FT itself.

In the blog post proposing the Rune protocol, Casey expressed at the end of the article that "the world of FT is almost an irreparable abyss full of deception and greed."

The proposal of the Rune protocol can be regarded as Casey's "tough medicine" for the Ordinals protocol - although as the founder of the protocol, he cannot unilaterally kill the "tumor" BRC-20 that he believes is parasitic on the Ordinals protocol in the world of Web3. So he came up with this idea - this is the "art gallery", if you want to continue Degen, I have an idea, everyone go to the "big casino" Degen OK or not?

That being said, Casey is merely proposing a concept of the Rune protocol for Bitcoin FT, and he himself has no intention of implementing it. However, Casey's influence is evident, and we can already see how excited players are in less than a day.

1 Day Later, What Developments Has the Rune Protocol Made?

Bitcoin NFT trading market Ordinals Wallet announced the deployment of the first token $RUNE of the Rune protocol at 3pm.

However, someone pointed out in the comments of the tweet that this seems to be an invalid deployment...

In addition, @TO also launched a public reward, and the first team to create a Rune protocol indexer will receive a reward of $100,000.

Here it is important to remind everyone to pay special attention to the fact that there is no conclusion on the validity of the deployment of $RUNE, because the protocol is currently only Casey's idea, and there are no relevant standards or code drafts. Beware of all kinds of scams!

Conclusion

Casey's idea is more of a helpless plea to everyone - I have a better way than BRC-20, would you consider letting Ordinals return to its original development direction?

So will BRC-20 "die"? I don't think we need to be too pessimistic. Over the past few months, BRC-20 has attracted a large number of teams to build on it, and these teams will not give up just because of Casey's idea. Moreover, BRC-20 is also dynamically developing. Can it be combined with the Lightning Network to solve some of the current pain points? These are all things we can look forward to.

Finally, Casey's soul questioning -

99.9% of FTs are memes and scams. I'm not sure if creating a new FT protocol for Bitcoin is really a good idea.

Original title: "The Whole Process of Brc20 Token Practical Casting (Mother-Level Feeding Tutorial)"

Original Author: @CG_BRC20

What is Brc20?

brc20 is a homogeneous token protocol issued on the BTC original chain against  erc20 , the first token is ordi, authored by the author< issued by a href="https://twitter.com/domodata" rel="noreferrer" target="_blank">@domo, currently popular tokens include pepe, punk, bayc, domo, etc. etc. Although they are all  meme  tokens, they have all been minted, and OTC transactions are very active.

The most representative $Ordi

It has the value of the creation attribute, and the current market Extra price 500 ! (At that time, the basic cost was in the range of  3-5U ) It has already made a hundredfold profit!

On March 9, 2023 Twitter user Bitcoin's experimental fungible token standard created by @domodata.

Tutorial begins

One: Download wallet plug-in

Recommended UniSat  (open source plug-in Ordinals wallet), currently the most convenient one in the industry, the light of domestic products.

Create a wallet, back up the mnemonic, when selecting the address, select the following as  m/86/0/0/0, and then confirm.

Just mention  BTC  from Binance to the address starting with this bc1p . (The address at the beginning of this  bc1p  is also the receiving address of the casting inscription later)

Two: Brc20 real-time casting Query and Asset Query

It is recommended to use UniSat  to view the inscription casting information in real time. (text and number minted, amount minted, holder, etc.)

Three: Casting inscription bot recommendation

1, idclub  (preferred recommendation, super cheap price-performance ratio)

2, looksordinal (alternate, same as above, cheaper)

3, unisat (not recommended, expensive!)

recommended here With idclub , which I currently use the most. (Currently the cheapest casting tool on the whole network, and it is very convenient)

Example operation:

1, open  UniSat  to view the inscription casting information.

This sexy generation Take coins as an example, here we can see that about 74% of them have been minted, and the holders are not very healthy, there are only 202 people, and the chips are a bit concentrated. (Because the casting is more than half, it may be completed soon)

Click to see the details

Click Mint oirectly

Select mint, then copy the token name and quantity below.

2, openidclub Casting Tools

Method 1: Fill in the token and quantity just copied

< br>

Method 2 (recommended): No need to copy UniSat , directly search the token name in the first column and click it to fill in automatically (the new function is super convenient and can’t be filled in wrongly). Here I choose to mint 1 token as an example.

Click Next

Fill in your address at the beginning of bc1p to receive the inscription.

3, when you get here, you need to Open  mempool  to query real-time GAS on the chain

At present, the fastest GAS is 8 Satoshi, and the minimum is 7 Satoshi.

Here I choose 7 satoshi demo.

(If this brc20 is not up for grabs, it is recommended to choose 2-5 Satoshi, which can save a lot of costs. For example, in the fomo stage, it is recommended to check mempool  After real-time gas, choose the highest satoshi or higher satoshi to grab the inscription, remember fomo At this stage, don’t miss the inscription just to save that little gas fee, because you can’t add GAS if you type it out) Deep painful lesson!

Click to pay and choose a service fee of 100 Satoshi
< /p>

Copy the address and amount (do not close the page)

4, open the uni wallet plug-in, click Send< /b>

After filling in the address and amount copied above, click Next

Click Sign&Send

Show sending completed

6, at this time idclub shows that the payment is successful, click to view the order

This side shows waiting for inscription (Need to wait for a while)

Waiting to show that it is engraving is waiting for the block to be produced on the chain. You can click on the engraving to view the block production status.

Check where your inscription is, wait for the triangular arrow to reach the blue side, it means block, indicating your transaction It worked. (At this time, the GAS suddenly pulled up, and the queue is very late, so we need to wait for a while)

Note: Block  ;It is a square in the picture. If the yellow square contains your inscription, and passes through the middle line, it turns into a blue square, which means that your inscription is out

At this time, if you check brc20 assets on unisat, it will show that there are already sexy assets, but they are not yours yet, because your inscription has not yet been produced, so you need to wait patiently. (unisat will display the inscription of the inner pool, so it will display the assets in advance, and finally look at the block generation on the chain)