IMO är det troligt att för många "would-be spammare" den potentiella vinsten från att göra en stor OP_RETURN var mindre än kostnaden (tid / ansträngning) för att kringgå det utbredda standardfiltret (främst för att en liknande sak uppnås till lägre kostnad med hjälp av inskriptionstricket), därav den relativt låga frekvensen av stora OP_RETURNs sett hittills, och den kraftiga nedgången vid filtertröskeln. Med preferenspeering och/eller direkt inlämning minskade kostnaden avsevärt. Dessutom, med all debatt och drama (och oundviklig framtida bevakning av nya användningsområden för stora OP_RETURNs) har den potentiella fördelen vuxit. Nu sjunker kostnaden till 0 (bortsett från kostnaden för social stigmatisering, som är begränsad till en mycket liten grupp). Det finns också ett stort värde i att dina transaktioner snabbt kommer in i kandidatblocket hos de allra flesta miners, och därför har fördelen ökat ytterligare. Av dessa skäl tror jag att det är troligt att vi kommer att se en ökning av frekvensen av stora OP_RETURNs under de kommande månaderna förutsatt att avgifterna förblir lika (löjligt) låga som de har varit de senaste månaderna. Som sagt, jag tror inte att detta är ett problem. En dålig OP_RETURN kommer inte att döda bitcoin, vilket är goda nyheter eftersom om det skulle döda bitcoin så skulle en välfinansierad angripare kunna göra det idag genom att bryta ett block. Det mest troliga som stora OP_RETURNs kommer att tränga undan är en massa mindre OP_RETURNs prägling av shitcoins (runor) eller inskriptions-txs. Detta är bara möjligt i den skala med vilken det händer eftersom avgifterna är historiskt låga. Detta är nedströms en minskad mängd "legitim" onchain-aktivitet - imo är detta den mycket viktigare "frågan" som förtjänar vår uppmärksamhet!

Sub 1 lör/vB sommaren kommer att studeras av kommande generationer

Ser några kommentarer som frågar vad som kan göras åt den här typen av datainbäddning (som har funnits länge). Det här är lite långt, men förhoppningsvis kommer det att vara användbart som en referens till den mer allmänna frågan om huruvida du kan ta itu med "problem" på protokollnivå på gruvarbetar-/policynivå. Realistiskt sett, förutom en mjuk gaffel finns det väldigt lite som kan göras tekniskt, och även det skulle ha allvarliga begränsningar och konsekvenser (det är hela poängen med denna grova protokolldesign). Den uppenbara första reaktionen är att be gruvarbetare att sluta bryta saker som detta. Det finns några sätt, men ett skulle vara att höja deras -dustrelayfee Som standard är det 0,00003 BTC/kB (3 sat/vB), vilket resulterar i en dammutgångsgräns på 330 sats för P2WSH. För denna transaktion med 1859 sådana utgångar är den totala summan låst i ospenderade utgångar 1859*330 = 613 470 sats ($736 @$120k/BTC) Låt oss säga att du framgångsrikt lobbar den stora majoriteten (95%) av miners till 10x detta konfigurationsvärde, avsändaren skulle behöva välja mellan att betala 6.1M sats ($7k) eller skicka som den är och vänta tills den lilla andelen miners (5%) använder den gamla standarden. De skulle förmodligen göra det senare eftersom det är tillräckligt med hashrate för att hitta 7 block/dag i genomsnitt, och vad är ruset? Efter att ha misslyckats med att stoppa detta på gruvarbetarnivå kan du nu frestas att lobba nodlöpare för att ändra sin standard och/eller ändra standarden i core v31. Säg att du lyckades och core v31 innehåller en högre standard. Avsändaren kan bara företrädesvis peer för att försöka nå miners i protokollet. Så du fördubblar och förfalskar preferenspeering så att den inte är tillräckligt tillförlitlig. Avsändaren har nu inget annat val än att betala en miner OOB - om de ska göra detta kan de lika gärna göra varje utgång till 0 sats. Detta kan faktiskt vara ömsesidigt ekonomiskt fördelaktigt för avsändaren och gruvarbetaren, eftersom de istället för att brännas som avgifter skulle flyta till gruvarbetaren / sparas av avsändaren. För att vara rättvis skulle det krävas ansträngning för att etablera dessa direkta skenor till gruvarbetare som uteslutande är ekonomiskt motiverade, men detta är en fast kostnad, och jag tvivlar inte på att det skulle göras och sedan integreras via API till centraliserade myntningstjänster. Således skulle problemet sannolikt bli värre än den situation vi har idag.