Dit is een opinieredactioneel commentaar van Shinobi, een autodidactische onderwijzer in de Bitcoin-ruimte en technisch georiënteerde Bitcoin-podcasthost.
Grote verrassing, Bitcoiners maken woedend ruzie over een voorgesteld voorstel wijzigingsset die wordt opgenomen in de volgende release van Bitcoin Core. Opt-in Replace-by-Fee (RBF) is een mempool-beleidsfunctie die in 2015 werd voorgesteld om gebruikers een hulpmiddel te bieden om te gaan met snelle pieken in vergoedingen die ertoe leiden dat hun transacties onbevestigd vast komen te zitten in de mempool voor lange tijd.
Het is duidelijk dat dit een probleem zal zijn voor elk gebruik van Bitcoin als het transactievolume gemiddeld constant hoger wordt dan het aantal transacties dat in de blockchain kan worden verwerkt, dus tenzij u denkt dat dit nooit zal gebeuren dit is een benodigde functionaliteit op het netwerk.
Vervanging van de transactie was eigenlijk inbegrepen en mogelijk in de oorspronkelijke release van de software voordat Satoshi Nakamoto verdween. Hij schakelde de functie uiteindelijk uit omdat de manier waarop hij deze oorspronkelijk implementeerde een vector creëerde voor denial-of-service-aanvallen tegen knooppunten. Zijn implementatie maakte het mogelijk om elke transactie te vervangen zonder een hogere vergoeding te betalen, wat in wezen gebruikers in staat zou hebben gesteld een transactie te verzenden en vervolgens een onbeperkt aantal vervangingen naar het netwerk uit te zenden. Dit zou uiteraard het spammen van nodes mogelijk maken met enorme hoeveelheden data waarvoor geen proof-of-work nodig was en zou de kosten van het runnen van een node onbetaalbaar verhogen.
In de loop der jaren een paar verschillende voorstellen voor een vernieuwde en veiligere transactievervanging regeling besproken. We zullen deze allemaal snel doornemen.
Volledige RBF
De eenvoudigste variant van RBF. Elke transactie kan worden vervangen zolang voor de vervanging van de oorspronkelijke transactie een hoger tarief wordt betaald dan voor de vervanging. Op die manier zijn transacties allemaal vervangbaar, maar de vereiste om elke keer dat u er een vervangt een hogere vergoeding te betalen, voorkomt een oneindige spam van nieuwe versies van de transactie-overbelastingsknooppunten.
First-Seen-Safe RBF
Hierbij werd voorgesteld om alle transacties in de mempool te laten vervangen, met één speciaal voorbehoud; alle outputs van de oorspronkelijke transactie moeten ook worden opgenomen in de vervangingstransactie, inclusief de output van de wijziging. Het vereist nog steeds een verhoging van de vergoeding om een transactie te vervangen, maar de vereiste om dezelfde outputs te behouden betekent dat je een nieuwe input moet toevoegen en een tweede output moet wijzigen, omdat geen van de originele outputs kan worden gewijzigd. Dit resulteert in grotere transacties die meer in totaal moeten betalen om ervoor te zorgen dat de vervanging een hoger tarief betaalt.
Vertraagde RBF
Hier was een voorstel om elke transactie in de mempool te laten vervangen, maar pas nadat een bepaald aantal blokken was verstreken sinds het knooppunt de oorspronkelijke transactie zag. Het idee was dat hierdoor vastgelopen transacties in omgevingen met hoge kosten sneller konden worden vervangen en bevestigd, maar de vertraging in hoe snel het zou kunnen worden vervangen, zou pogingen tot dubbele uitgave zonder bevestiging voorkomen.
Opt-In RBF
Dit is wat werd geïmplementeerd in 2016 zoals gedefinieerd in BIP 125. Transacties kunnen alleen worden vervangen als ze een specifieke vlag in de transactie hebben gezet en ervoor kiezen om te worden vervangen, of als een van hun voorouders dit heeft gedaan in het geval van een reeks niet-bevestigde transacties, zodat mensen die geld ontvangen, weten of een onbevestigde transactie al dan niet wordt uitgevoerd. vervangbaar in de mempool.
De grote controverse vandaag is dat de volgende release van Core, 0.24, een volledige RBF-mempoolbeleidsvlag zal introduceren. Wat betekent dit? Het geeft gebruikers een configureerbare optie om hun lokale mempool-beleid te wijzigen van opt-in RBF naar volledige RBF; standaard wordt de optie weggelaten (de knooppunten gebruiken volledige RBF). Dus waarom zijn mensen in de war over deze verandering? Bedrijven die nulbevestigingstransacties accepteren, zijn afhankelijk van de overgrote meerderheid van de mempools van knooppunten die weigeren transacties die niet zijn aangemeld voor RBF te vervangen door een transactiemarkering. Dit doen ze door hun node tactisch te verbinden met een groot aantal andere nodes verspreid over het netwerk. Hierdoor kunnen ze zeer snel de aanwezigheid van een dubbele uitgave-transactie op het netwerk detecteren, omdat het vrijwel onmiddellijk moet worden gedaan als een transactie niet wordt gemarkeerd als RBF om een goede kans te maken om de miners te bereiken. Het is ook de moeite waard om erop te wijzen dat elk bedrijf op het netwerk dit niet kan doen zonder het netwerk effectief te sybiling. Deze bedrijven beweren dat volledige RBF hun bedrijfsmodel voor het gebruik van RBF”breekt”. Sommigen hebben zelfs bekritiseerde kernontwikkelaars omdat ze een wijziging”dwingen”die een negatieve invloed heeft op deze bedrijven.
De simpele realiteit is dat dubbele uitgaven altijd mogelijk zijn en blijven, opt-in RBF of volledige RBF verandert hier niets aan. Bovendien dicteert het eenvoudigweg creëren van een optie om uw eigen lokale mempoolbeleid te wijzigen (die standaard is uitgeschakeld) op geen enkele manier verandering aan iemand, het is een optie die aan gebruikers wordt gegeven om voor zichzelf een keuze te maken. Aan het eind van de dag, als het gaat om welke transacties daadwerkelijk in het volgende blok worden opgenomen, zijn de enige mempools die er toe doen de miners. De mempools van individuele gebruikersknooppunten zijn niets anders dan een serie geheugenopslag met het uiteindelijke doel om al die onbevestigde transacties naar de miners te verspreiden, zodat ze uiteindelijk in een blok kunnen worden opgenomen.
Mempool-beleid wordt gebruikt als een soort zacht veiligheidsmechanisme om denial-of-service-aanvallen op knooppunten te voorkomen en gebruikers te beschermen tegen zichzelf in de voet schieten met gecompliceerde transacties en scripts. Veel soorten transacties zijn geldig bij consensus, mogen in een blok worden opgenomen, maar worden niet doorgegeven door het standaard mempool-beleid van nodes. Dit weerhoudt een vastberaden gebruiker er echter helemaal niet van om een transactie die door knooppunten op het netwerk zou worden genegeerd, rechtstreeks door te sturen naar een mijnwerker.
Dat is de kern van de zaak. Het enige dat nodig is, is dat miners een API opzetten om transacties rechtstreeks naar hen door te sturen, wat velen al hebben, en de beperkingen van het mempool-beleid over het netwerk doen er niet toe. Je kunt gewoon een transactie rechtstreeks aan de miners geven en elke regel omzeilen over wanneer iets kan worden vervangen in de mempool van andere knooppunten. Denk eens na over de prikkels daarvan-als er geld te verdienen is door een bepaalde categorie transacties te minen, maar mempools over het netwerk zullen ze niet doorgeven, wat zou je dan doen als mijnwerker? Accepteer ze gewoon direct. Hoe meer de subsidie afneemt en de transactiekosten als percentage van de inkomsten van mijnwerkers toenemen, hoe onvermijdelijker het wordt dat mijnwerkers gewoon rechtstreeks vervangingen accepteren die hogere kosten betalen als knooppunten op het netwerk ze niet indirect doorsturen. Het is onontkoombaar.
Deze wijziging verandert niets aan het standaard mempool-beleid voor Bitcoin Core, het biedt alleen een optie voor een individuele node-operator om hun lokale mempool-beleid te wijzigen als ze dat willen.
En ik zou kunnen toevoegen dat dit een keuze is die altijd beschikbaar was als gebruikers ervoor kozen hun client te wijzigen. Het enige dat het doet, is een keuze maken die voor gebruikers altijd eenvoudiger was om te doen. De prikkels leiden onvermijdelijk tot een staat waarin alle transacties vervangbaar zullen zijn als mijnwerkers op een economisch rationele manier handelen-het is onvermijdelijk. De enige vraag van de zaak is of de software die prikkels moet weerspiegelen, zodat individuele gebruikers zelf kunnen beslissen welk beleid ze voor hun mempool gebruiken, of moeten mensen gewoon blijven zitten en de verspreiding van transacties laten centraliseren rond directe indiening aan mijnwerkers zich?
Het eindresultaat is hetzelfde, maar wachten tot miners aangetrokken worden tot het direct indienen van transacties, zal zeer negatieve gevolgen hebben. Het zou privacy-implicaties hebben voor mensen die transacties naar het netwerk uitzenden, en het zou zeer negatieve gevolgen kunnen hebben voor het vermogen van gebruikers om te beslissen welke vergoeding ze voor een transactie moeten betalen. Als grote delen van lopende transacties niet langer publiekelijk via het netwerk worden uitgezonden, hebben gebruikers een onvolledig beeld van tegen wie ze bieden voor opname in een blok. Mijnwerkers kunnen zelfs liegen over de verdeling van de vergoedingen om gebruikers te stimuleren meer te betalen dan nodig is.
Het enige echte nadeel van het beschikbaar maken van deze optie is dat volledige RBF mogelijk niet consistent werkt als slechts een klein deel van het netwerk, inclusief mijnwerkers, ervoor kiest om volledige RBF in te schakelen. Dit is echter fundamenteel niet anders in termen van overgang dan de upgrade naar SegWit was. Tijdens die overgangsperiode zouden niet-geüpgradede nodes geen SegWit-transacties doorgeven omdat ze deze niet konden valideren, dus in die periode was er dezelfde dynamiek van verspreiding die inconsistent was totdat genoeg gebruikers een upgrade hadden uitgevoerd. Maar uiteindelijk veranderde dat niets aan het feit dat upgraden een beslissing was van individuele gebruikers.
Uiteindelijk vechten tegen volledige RBF ontkent gewoon de realiteit van de prikkels op het netwerk. Er wordt niemand gedicteerd, een configuratieoptie is eenvoudigweg individuele gebruikers een keuze bieden die ze zelf moeten maken. Ik vind het vreemd dat tegelijkertijd zoveel mensen de realiteit van prikkels negeren om te beweren dat een onveilige manier om betalingen te ontvangen veilig kan worden gehouden in weerwil van prikkels, net zoals mensen beweren dat softwaregebruikers geen keuze mogen hebben in hoe om hun eigen software te configureren.
Mijn node, mijn regels, toch?
Dit is een gastpost van Shinobi. De geuite meningen zijn geheel van henzelf en komen niet noodzakelijk overeen met die van BTC Inc of Bitcoin Magazine.