Vad händer i varje process när du spelar labitbu? Lång varning, viss kunskap om kryptografi och bitcoinhandel krävs Labitbu är en liten bild av Bitcoins huvudnät som börjar klockan 2 på natten idag, till skillnad från tidigare inskriptions- eller kvasi-inskriptionsprotokoll, förlitar det sig på taproot-protokollet för att lagra laddningsinformation Projektet utvecklades av @stutxo, den andra vinnaren av årets @PlebFi hackathon, och det verkar som att hackathonet har deltagande av utvecklare från Bitcoin Wizard och Ordinals, och det har fortfarande ett visst guldinnehåll GitHub-lagringsplats: Det finns tre steg när du castar en webbplats: 1. Anslut din plånbok och generera en slumpmässig labitbu. 2. Överför till P2TR-adressen från och med bc1p, webbplatsen kommer att överföra 10 000 sats till denna adress som standard; 3. Slutför präglingen, fyll i bc1p-adressen som motsvarar plånbokens offentliga nyckel i inmatningsrutan och skicka in präglingstransaktionen till kedjan. Anslut först till plånboken för att få den offentliga nyckeln till bc1p-plånboken och generera sedan Labitbu baserat på den offentliga nyckeln. Enligt json-filen i repo kan det vara känt att det finns 8 stilar för varje labitbu, och den största skillnaden är färgen. Men om det är en 10k NFT-kollektion verkar färgen inte räcka till för att särskilja många labitbu? Eftersom varje labitbu genereras baserat på plånbokens offentliga nyckel, kommer teoretiskt sett alla labitbu som präglas av varje plånbok att vara i samma stil (men ibland kommer det att finnas ett fall där plånboken präglas i en annan stil under själva präglingen tidigt på morgonen, vilket kan bero på vissa utelämnanden eller svimning 😇 på morgonen) Efter föregående steg konverteras den genererade labitbu till en bytedatanyttolast, och webbsidan bygger ett kontrollblock baserat på denna nyttolast. Det kallas build här, och det faktiska kontrollblocket är [control byte] + [index public key] + [image payload]. I det faktiska taproot-skriptet är kontrollblocket [control byte] + [internal public key] + [Merkle path], och labitbu använder bildnyttolasten direkt som Merkle-sökvägen. Innehåll relaterat till Taproot Control Block: Efter att ha använt nyttolast som Merkle-sökväg och plånbokens offentliga nyckel som låsskript kan en P2TR-adress genereras, vilket är BC1P-adressen på webbsidan, och processen att skicka BTC till denna plånbok kan betraktas som en commit i inskriptionsprotokollet. Slutligen måste du fylla i din bc1p-adress och plånbok för att slutföra den slutliga präglingen. I den här processen låses fronten upp med bildnyttolasten som kontrollblock, och låsskriptet för den offentliga nyckeln används som utdata från inlösenskriptet, och plånboken används för att signera och skicka den slutliga transaktionen, som liknar avslöjandetransaktionen i inskriptionsprotokollet. Ovanstående är det tekniska innehållet i processen att gjuta labitbu-protokollet, de tekniska detaljerna för konstruktionen av taproot-skriptet och genereringen av adresser är inte skrivna, intresserade vänner kan kontrollera informationen och ta en titt Präglingsprocessen av labitbu liknar mer inskriptioner, men fördelen med inskriptioner är att begåvningen av präglingsprocessen inte behöver generera en ny adress som ett relä, och hela präglingsprocessen kan slutföras med en enda plånbok, vilket är bekvämare i viss utsträckning. Det finns dock en begränsning i att kontrollblockets storlek är 4 kb, vilket begränsar storleken på den bildbelastning som kan lagras. I GitHub använder dev en fast intern offentlig nyckel för myntning för enkel indexering, så det kan ses att dev också planerar att genomföra nästa steg i indexeringen, och om det kan implementeras för transaktioner kan bara väntas.

Vid denna tidpunkt bör präglingsvolymen överstiga 10k, och enligt tidigare erfarenhet är antalet små bildsamlingar vanligtvis 10k, så det rekommenderas inte att fortsätta prägla nu