De Bitcoin Optech-nieuwsbrief biedt lezers een samenvatting op het hoogste niveau van het belangrijkste technische nieuws gebeurt in Bitcoin, samen met bronnen die hen helpen meer te leren. Om onze lezers te helpen op de hoogte te blijven van Bitcoin, publiceren we het laatste nummer van deze nieuwsbrief hieronder opnieuw. Vergeet niet om u te abonneren om deze inhoud rechtstreeks in uw inbox te ontvangen.
De nieuwsbrief van deze week viert de lock-in van de penwortel soft fork, beschrijft een concept-BIP voor het verbeteren van de transactieprivacy door de gebruikte velden te variëren om anti-fee sniping te implementeren, en bevat een artikel over de uitdagingen van het combineren van transactievervanging met betalingsbatch. Ook inbegrepen zijn onze reguliere secties met aankondigingen van nieuwe softwarereleases en releasekandidaten, plus opmerkelijke wijzigingen in populaire Bitcoin-infrastructuursoftware.
Nieuws
- Taproot opgesloten: de taproot soft fork en gerelateerde wijzigingen gespecificeerd in BIP’s 340, 341 en 342 werden afgelopen weekend opgesloten door mijnwerkers te signaleren. Taproot is veilig te gebruiken na blok 709.632, dat begin of midden november wordt verwacht. De vertraging geeft gebruikers de tijd om hun nodes te upgraden naar een release (zoals Bitcoin Core 0.21.1 of hoger) die de regels van taproot zal afdwingen, zodat geld dat wordt ontvangen voor taproot-scripts na blok 709.632 veilig is, zelfs als er een probleem is met miners.
Ontwikkelaars worden aangemoedigd om het implementeren van taproot zodat ze klaar kunnen zijn om te profiteren van meer efficiëntie, privacy en fungibiliteit zodra de activering is voltooid.
Lezers die de lock-in van taproot vieren, willen misschien ook om een korte thread over de oorsprong en geschiedenis van taproot door ontwikkelaar Pieter Wuille. - BIP stelde voor om portemonnees standaard nSequence in te stellen op taproot-transacties: Chris Belcher heeft een concept-BIP op de Bitcoin-Dev-mailinglijst geplaatst, waarin wordt gesuggereerd dat wallets op een alternatieve manier anti fee sniping. De alternatieve methode zou de privacy en fungibiliteit verbeteren van transacties die worden gedaan door gebruikers met één sig, gebruikers met meerdere handtekeningen en gebruikers van bepaalde contractprotocollen zoals LN met taproot of geavanceerde coinswaps.
Anti-fee sniping is een techniek die sommige portemonnees toepassen om miners te ontmoedigen om vergoedingen van elkaar te stelen op een manier die de hoeveelheid bewijs van het werk dat aan beveiliging is besteed, zou verminderen Bitcoin en beperk het vermogen van gebruikers om te vertrouwen op bevestigingsscores. Alle portefeuilles die tegenwoordig antifee-sniping implementeren, gebruiken nLockTime-hoogtevergrendelingen, maar het is ook mogelijk om dezelfde bescherming te implementeren met BIP68 nVolgorde hoogte vergrendelingen. Dit zou niet effectiever zijn in het voorkomen van fee sniping, maar het zou een goede reden zijn voor reguliere portemonnees om hun nSequence-waarden in te stellen op dezelfde waarden die vereist zijn voor transacties in bepaalde op meerdere handtekeningen gebaseerde contractprotocollen, zoals ideeën voor coinwaps en penwortel-enabled LN. Dit helpt om reguliere portemonneetransacties eruit te laten zien als contractprotocoltransacties en vice versa.
Belchers voorstel suggereert dat portemonnees willekeurig kiezen tussen het gebruik van nLockTime of nSequence met een waarschijnlijkheid van 50% wanneer beide opties beschikbaar zijn. Als het voorstel wordt geïmplementeerd, zullen gebruikers van reguliere transacties met één handtekening of ongecompliceerde meervoudige handtekeningen in het algemeen kunnen samenwerken met gebruikers van contractprotocollen om elkaars privacy en fungibiliteit wederzijds te verbeteren.
Veldrapport: RBF en Additive Batching gebruiken
door CardCoins
“Additive batching” is een schema waarbij extra output wordt toegevoegd aan niet-bevestigde transacties in de mempool. Dit veldrapport geeft een overzicht van de inspanningen CardCoins heeft een reorganisatie-en DoS-veilige implementatie van een dergelijk schema in de uitbetalingsworkflow voor klanten geïntroduceerd.
Vervangen door vergoeding (RBF, BIP125) en batching zijn twee belangrijke tools voor alle bedrijven die rechtstreeks interactie hebben met de mempool van Bitcoin. De tarieven gaan omhoog, de tarieven dalen, maar het bedrijf moet altijd vechten voor een efficiënt tarief.
Elke tool, terwijl krachtig, heeft zijn eigen complexiteit en nuances. Het batchgewijs opnemen van klanten kan bijvoorbeeld kosten besparen voor de onderneming, maar zal waarschijnlijk kind betaalt voor ouder (CPFP) onrendabel voor een klant die de transactie wil versnellen. Evenzo is RBF nuttig voor een onderneming die een strategie voor te weinig bieden hanteert (hun initiële transactie-uitzending begint tegen een lage vergoeding en wordt langzaam opwaarts geboden), maar het stelt hun klanten bloot aan mogelijke verwarring omdat hun opnametransactie in hun portemonnee wordt bijgewerkt. Het zou ook rommelig zijn voor de klant om geld uit te geven aan deze transactie terwijl deze nog niet bevestigd is, aangezien de onderneming zal moeten betalen voor deze kinderuitgaven bij een poging om de ouder te vervangen. Erger nog, de onderneming kan een opname hebben vastgezet door een andere service die de intrekking van de klant heeft ontvangen.
Bij het combineren van deze twee tools ontgrendelt een serviceprovider nieuwe functionaliteit, maar wordt hij op dezelfde manier blootgesteld aan nieuwe vormen van complexiteit. In het basisscenario draagt het combineren van RBF en een enkele, statische batch een eenvoudige combinatie van de complexiteiten die RBF en batching discreet met zich meebrengen. Wanneer u echter RBF en”additief batchen”combineert, doen zich opkomende randgevallen en gevaarlijke faalscenario’s voor.
Bij additieve RBF-batchverwerking introduceert de serviceprovider nieuwe outputs (en bevestigde inputs) voor een transactie in de mempool om opnames van nieuwe klanten op te nemen in een niet-bevestigde transactie. Dit stelt de serviceprovider in staat om gebruikers de ervaring van een onmiddellijke opname te bieden, terwijl ze toch een groot deel van de kostenbesparingen behouden door grote hoeveelheden klantopnames tegelijk te doen. Wanneer elke klant een opname aanvraagt, wordt een uitvoer toegevoegd aan de transactie in de mempool. Deze transactie wordt voortdurend bijgewerkt totdat deze bevestigt of een ander lokaal optimum bereikt.
Er zijn veel strategieën voor dit type additieve RBF-batchverwerking. Op CardCoins we hebben voor onze implementatie gekozen voor een veiligheidsbenadering (met behulp van Matthew Zipkin), waarvan we de details hebben beschreven in een blogpost, RBF-batching bij CardCoins: duiken in het donkere Reorg-bos van Mempool.
Releases en vrijgavekandidaten
Nieuwe releases en vrijgavekandidaten voor populaire Bitcoin-infrastructuurprojecten. Overweeg om te upgraden naar nieuwe releases of om te helpen bij het testen van releasekandidaten.
- Rust Bitcoin 0.26.2 is de nieuwste kleine release van het project. Vergeleken met de vorige hoofdversie bevat het verschillende API-verbeteringen en bugfixes. Zie de changelog voor details.
- Rust-Lightning 0.0.98 is een kleine release die verschillende verbeteringen en bugfixes bevat.
- LND 0.13.0-beta.rc5 is een release-kandidaat die ondersteuning toevoegt voor het gebruik van een gesnoeide volledige Bitcoin-node, waarmee betalingen kunnen worden ontvangen en verzonden met Atomic MultiPath (AMP), en verhoogt de PSBT-mogelijkheden, naast andere verbeteringen en bugfixes.
Opmerkelijke code-en documentatiewijzigingen
Opmerkelijke wijzigingen deze week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Roest Bitcoin, BTCPay-server, Bitcoin-verbeteringsvoorstellen (BIP’s) en Bliksemschichten.
- Bitcoin Core GUI #4 voegt initiële ondersteuning toe voor het gebruik van Hardware Wallet Interface (HWI) externe ondertekenaars via de GUI. Zodra deze functie is voltooid, kunnen gebruikers hun HWI-compatibele hardwareportefeuilles rechtstreeks vanuit de Bitcoin Core GUI gebruiken.
- Bitcoin Core #21573 werkt de versie van libsecp256k1 bij die is opgenomen in Bitcoin Core. De meest opvallende verandering is het gebruik van de geoptimaliseerde modulaire inverse code die wordt beschreven in Nieuwsbrieven #136 en #146. Prestatie-evaluaties die op de PR zijn geplaatst, hebben de verificatie van oude blokkeringen met ongeveer 10% versneld.
- C-Lightning #4591 voegt ondersteuning toe voor het ontleden van bech32m adressen. C-Lightning staat nu een peer die heeft onderhandeld over de functie option_shutdown_anysegwit toe om een v1+ native segwit-adres op te geven als een sluitings-of intrekkingsbestemming.
Vind de originele post hier.
Alsjeblieft schrijf u rechtstreeks in op de Bitcoin Optech-nieuwsbrief om deze inhoud elke maand rechtstreeks in uw inbox te ontvangen.
