Het probleem met de OP_RETURN-limiet die ervoor zorgt dat deze verandert en niet duidelijk wordt gearticuleerd: Het is al heel lang consensus dat er zelden een reden is om veel meer dan een 40-byte hash on-chain op te slaan voor een L2-protocol dat bovenop Bitcoin draait, daarom was de relay-limiet 80 bytes. Hoewel het waar is dat het altijd zo is geweest dat metaprotocols altijd profiteerden van het opslaan van meer gegevens binnen Bitcoin zelf, zijn deze gebruiksgevallen grotendeels genegeerd omdat ze geen monetaire gebruiksgevallen van de BTC-asset zijn: Over het algemeen maken metaprotocols zoals deze gebruik van de Bitcoin *blockchain*, maar hun regels/logica kunnen niet direct met de BTC-asset interageren. Dus ze zijn niet "belangrijk" om rekening mee te houden voor de Bitcoin blockchain. Dit veranderde met het BitVM-werk 2 jaar geleden. Nu, voor het eerst, is het mogelijk om L2-protocollen te bouwen die direct met de bitcoin-asset interageren terwijl ze gebruikmaken van meer exotische technieken (zoals ZK-bewijzen en DA). Dit is waarom de use case van Citrea een publiek kon krijgen bij Core. Als Citrea gewoon een Ethereum-sidechain had gebouwd die met niet-verwante activa van bitcoin interageert, zou het nooit invloed hebben gehad op hoe Core zijn standaard relay-limieten instelt. Maar omdat BitVM bestaat, en ZK-bewijzen en DA daarom een directe impact hebben op de regels waarlangs echte bitcoins door de logica van de blockchain reizen, wordt deze klasse van L2 nu voor het eerst overwogen wanneer Core hun relay-limieten beoordeelt, in plaats van alleen maar rekening te houden met Lightning. Na 9 jaar van custodiale trends die Lightning domineren, kun je ze echt de schuld geven dat ze ervoor zorgen dat channel-free L2's worden meegenomen in de standaardinstellingen voor relay? Extra huiswerk: Het gaat niet eens om "zorgen voor Citrea", Citrea kan de gegevens die ze nodig hebben al in Bitcoin embedden met behulp van onbruikbare outputs, het kost Citrea praktisch niets om dit te doen, Core past zich gewoon aan zodat *Bitcoin* niet wordt geschaad door onnodige UTXO-bloat door de groei van Citrea-achtige protocollen bovenop Bitcoin, uiteindelijk gaat het om zorgen voor *Bitcoin*, maar ik heb mensen dit een miljoen keer zien proberen uit te leggen aan Knots-mensen zonder succes, dus ik bied een alternatieve invalshoek aan.