What happens in every process of playing labitbu? Long warning, certain knowledge of cryptography and bitcoin trading is required Labitbu is a small picture of the Bitcoin mainnet starting at 2 a.m. today, unlike previous inscription or quasi-inscription protocols, it relies on the taproot protocol to store load information The project was developed by @stutxo, the second winner of this year's @PlebFi hackathon, and it seems that the hackathon has the participation of devs from Bitcoin Wizard and Ordinals, and it still has a certain gold content github repo: There are three steps when casting a website: 1. Connect your wallet and generate a random labitbu. 2. Transfer to the P2TR address starting with bc1p, the website will transfer 10,000 sats to this address by default; 3. Complete minting, fill in the bc1p address corresponding to the wallet public key in the input box and submit the minting transaction to the chain. First, connect to the wallet to obtain the public key of the bc1p wallet, and then generate Labitbu based on the public key. According to the json file in the repo, it can be known that there are 8 styles for each labitbu, and the biggest difference is the color. But if it's a 10k NFT collection, the color doesn't seem to be enough to distinguish many labitbu? Since each labitbu is generated based on the wallet public key, theoretically all labitbu minted by each wallet will be the same style (but occasionally there will be a case where the wallet is minted in a different style during the actual minting in the early morning, which may be due to some omissions or fainting 😇 in the morning) After the previous step, the generated labitbu is converted into a byte data payload, and the web page builds a control block based on this payload. It's called build here, and the actual control block is [control byte] + [index public key] + [image payload]. In the actual taproot script, the control block is [control byte] + [internal public key] + [Merkle path], and labitbu uses the image payload directly as the Merkle path. taproot control block related content: After using payload as the Merkle path and the wallet public key as the lock script, a P2TR address can be generated, which is the BC1P address on the web page, and the process of sending BTC to this wallet can be regarded as a commit in the inscription protocol. Finally, you need to fill in your bc1p address and wallet to complete the final minting operation. In this process, the front is unlocked with the image payload as the control block, and the public key lock script is used as the output of the redeem script, and the wallet is used to sign and send the final transaction, which is similar to the reveal transaction in the inscription protocol. The above is the technical content in the process of casting the labitbu protocol, the technical details of the construction of the taproot script and the generation of addresses are not written, interested friends can check the information and take a look The minting process of labitbu is more similar to inscriptions, but the advantage of inscriptions is that the commit of the minting process does not need to generate a new address as a relay, and the entire minting process can be completed with a single wallet, which is more convenient to a certain extent. However, there is a limitation that the control block size is 4kb, which limits the size of the image load that can be stored. In GitHub, dev uses a fixed internal public key for minting for easy indexing, so it can be seen that dev also plans to carry out the next step of indexing, and whether it can be implemented for transactions can only be waited.

At this time, the minting volume should exceed 10k. Based on past experience, a small image collection usually consists of 10k, so it is not recommended to continue minting now.