De Bitcoin Optech-nieuwsbrief biedt lezers een samenvatting op het hoogste niveau van de meest belangrijk technisch nieuws in Bitcoin, samen met bronnen die hen helpen meer te leren. Om onze lezers te helpen up-to-date te blijven met Bitcoin, publiceren we het laatste nummer van deze nieuwsbrief hieronder opnieuw. Vergeet niet om je te abonneren om deze inhoud rechtstreeks in je inbox te ontvangen.
De nieuwsbrief van deze week vat twee voorgestelde BIP’s samen met betrekking tot portemonnee-ondersteuning voor taproot en bevat onze reguliere secties met een beschrijving van geselecteerde vragen en antwoorden op de Bitcoin Stack Uitwisseling, hoe u zich kunt voorbereiden op penwortel en opmerkelijke wijzigingen in populaire Bitcoin-infrastructuurprojecten.
Nieuws
- PSBT-extensies voor penwortel: Andrew Chow plaatste een voorgestelde BIP aan de Bitcoin-Dev-mailinglijst die nieuwe velden definieert voor PSBT’s om te gebruiken bij het uitgeven of creëren van taproot-outputs. De velden breiden zowel de originele versie 0 PSBT’s als de voorgestelde versie 2 PSBT’s uit (zie Nieuwsbrief #128). Zowel keypath-als scriptpath-uitgaven worden ondersteund.
De voorgestelde BIP beveelt ook aan dat P2TR-invoer in een PSBT kopieën van eerdere transacties kan weglaten, omdat taproot de aanval op te hoge vergoedingen tegen v0 segwit-invoer corrigeert (zie Nieuwsbrief #101). - Key afleidingspad voor single-sig P2TR: Andrew Chow ook plaatste een tweede voorgestelde BIP aan de Bitcoin-Dev-mailinglijst met suggestie voor een BIP32 afleidingspad om te gebruiken voor portemonnees die single-sig taproot-adressen maken. Chow merkt op dat de BIP erg lijkt op BIP49 voor P2SH-verpakte P2WPKH-adressen en BIP84 voor native P2WPKH-adressen.
Geselecteerde Q&A van Bitcoin Stack Exchange
Bitcoin Stack Exchange is een van de eerste plaatsen waar Optech-bijdragers antwoorden zoeken op hun vragen, of wanneer we een paar vrije momenten hebben om nieuwsgierige of verwarde gebruikers. In deze maandelijkse functie belichten we enkele van de meest gestemde vragen en antwoorden die zijn gepost sinds onze laatste update.
Voorbereiding op taproot #2: is taproot zelfs de moeite waard voor single-sig?
Een wekelijkse serie over hoe ontwikkelaars en serviceproviders zich kunnen voorbereiden op de aanstaande activering van penwortel op blokhoogte 709.632.
Met behulp van Optech’s rekenmachine voor transactiegrootte, we kunnen de grootte van verschillende soorten transacties met één enkele sig vergelijken. Zoals verwacht zijn transacties met P2WPKH-invoer en-uitvoer veel kleiner dan die met P2PKH-invoer en-uitvoer, maar, misschien verrassend, zijn P2TR-transacties iets groter dan equivalente P2WPKH-transacties.
| P2PKH (verouderd) | P2WPKH (segwit v0) | P2TR (taproot/segwit v1) | |
|---|---|---|---|
|
Uitvoer |
34 |
31 |
43 |
|
Invoer |
148 |
68 |
57,5 |
|
2-in, 2-uit tx |
374 |
208.5 |
211.5 |
Dat lijkt misschien contraproductief voor single-sig-portefeuilles om penwortel-uitgaven te implementeren ter voorbereiding op blok 709.632, maar bij nadere beschouwing blijkt dat er een aantal voordelen zijn aan het gebruik van P2TR voor single-sigs, zowel voor portemonnee-gebruikers als voor het netwerk als geheel.
- Goedkoper om uit te geven: het kost ongeveer 15% minder op inputniveau om een single-sig P2TR UTXO uit te geven dan om een P2WPKH UTXO uit te geven. Een al te eenvoudige analyse zoals de bovenstaande tabel verbergt het detail dat de spender niet kan kiezen welke adressen hij moet betalen, dus als u op P2WPKH blijft en alle anderen upgraden naar P2TR, zal de werkelijke typische grootte van uw 2-in-2-out-transacties zullen 232,5 vbytes zijn, terwijl alle P2TR-transacties nog steeds slechts 211,5 vbytes zullen zijn.
- Privacy: hoewel er enige privacy verloren gaat wanneer early adopters overstappen op een nieuw scriptformaat, schakelen gebruikers ook over op taproot direct een privacyboost krijgen. Uw transacties zullen niet te onderscheiden zijn van mensen die aan nieuwe LN-kanalen werken, efficiënter DLC’s, beveilig multisignatures, verschillende slimme back-upherstelschema’s voor portemonnees, of honderd andere baanbrekende ontwikkelingen.
Door P2TR voor single-sig te gebruiken, kan uw portemonnee nu ook upgraden naar multisignatures, tapscripts, LN-ondersteuning, of andere functies later zonder de privacy van uw bestaande gebruikers aan te tasten. Het maakt niet uit of een UTXO is ontvangen in een oude versie of een nieuwe versie van uw software-beide UTXO’s zien er in de keten hetzelfde uit. - Handiger voor hardware-signing-apparaten: sinds de herontdekking van de aanval met te veel betaalde vergoeding, hebben verschillende hardware-ondertekeningsapparaten geweigerd een transactie te ondertekenen, tenzij elke UTXO die aan die transactie is besteed, vergezeld gaat van metadata die een kopie bevatten van belangrijke delen van de volledige transactie die tot die UTXO heeft geleid. Dit verhoogt de verwerking in het slechtste geval die hardware-ondertekenaars moeten uitvoeren aanzienlijk en is vooral problematisch voor hardware-ondertekenaars die QR-codes van beperkte grootte als hun primaire communicatiemedium gebruiken. Taproot elimineert de kwetsbaarheid die ten grondslag ligt aan de aanval van te hoge vergoedingen en kan zo de prestaties van hardwareondertekenaars aanzienlijk verbeteren.
- Meer voorspelbare tarieven: ECDSA-handtekeningen voor P2PKH en P2WPKH UTXO’s kunnen in grootte variëren (zie Nieuwsbrief #3). Aangezien wallets de feerate van een transactie moeten kiezen voordat ze de handtekening maken, gaan de meeste wallets uit van de slechtste handtekeninggrootte en accepteren ze dat ze de feerate iets te veel betalen wanneer een kleinere handtekening wordt gegenereerd. Voor P2TR is de exacte grootte van de handtekening van tevoren bekend, waardoor de portemonnee op betrouwbare wijze een precieze prijs kan kiezen.
- Help volledige knooppunten: de algehele beveiliging van het Bitcoin-systeem hangt af van een aanzienlijk percentage Bitcoin-gebruikers het verifiëren van elke bevestigde transactie met hun eigen knooppunten. Dat omvat het verifiëren van de transacties die uw portemonnee maakt. Taproot’s schnorr-handtekeningen kunnen efficiënt batchgewijs worden geverifieerd, het met ongeveer 1/2 verminderen het aantal CPU-cycli dat nodes nodig hebben bij het verifiëren van handtekeningen tijdens het inhalen van eerdere blokken. Zelfs als je elk ander punt op deze lijst hebt afgewezen, overweeg dan om je voor te bereiden op het gebruik van taproot ten behoeve van mensen die volledige nodes gebruiken.
Opmerkelijke code-en documentatiewijzigingen
Opmerkelijke veranderingen 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 #22154 voegt code toe waarmee de gebruiker bech32m-adressen voor P2TR-scripts nadat taproot is geactiveerd in blok 709.632, b.v. door getnewaddress””bech32m te bellen. Als een transactie bech32m-adressen bevat na activering van de taproot, zal de descriptorportefeuille ook een P2TR-wijzigingsuitvoer gebruiken. De functie is alleen van toepassing op portemonnees met penworteldescriptors (zie Nieuwsbrief #152).
- Bitcoin Core #22166 voegt ondersteuning toe voor het afleiden van taproot tr()-descriptors uit uitvoer, waarmee de basisondersteuning voor taprootdescriptors wordt voltooid. Descriptor-inferentie wordt gebruikt om nauwkeurigere informatie te verstrekken in reacties op RPC-oproepen zoals listunspent.
- Bitcoin Core #20966 verandert de naam en het formaat van het opgeslagen banlist-bestand van banlist.dat (gebaseerd op geserialiseerde P2P-protocol addr-berichten) in banlist.json. Dankzij de update van de bestandsindeling kan de nieuwe lijst ban-items opslaan voor peers op Tor v3 en peers op andere netwerken met adressen van meer dan 128 bits breed-de maximale breedte die originele addr-berichten kunnen bevatten.
- Bitcoin Core #21056 voegt een nieuwe parameter-rpcwaittimeout toe aan bitcoin-cli. De bestaande parameter-rpcwait vertraagt het verzenden van een opdracht (RPC-aanroep) totdat de bitcoind-server is gestart. De nieuwe parameter stopt het wachten na het aangegeven aantal seconden, waardoor een fout wordt geretourneerd.
- C-Lightning #4606 maakt het mogelijk om facturen te maken van meer dan 0,043 BTC, na een vergelijkbare wijziging in LND (zie Nieuwsbrief #93) en de wijziging in de specificatie beschreven in de volgende item.
- BOLTs #877 verwijdert de oorspronkelijk geïntroduceerde limiet per betaling op protocolniveau om aanzienlijke verliezen als gevolg van implementatiebugs te voorkomen. Dit volgt op de wijdverbreide implementatie van option_support_large_channel in 2020, die (indien ingeschakeld) de limiet per kanaal verwijderde. Zie het onderwerp op grote kanalen voor meer informatie over deze twee limieten.
Vind de originele post hier.
Alstublieft abonneer u rechtstreeks op de Bitcoin Optech-nieuwsbrief om deze inhoud elke maand rechtstreeks in uw inbox te ontvangen.
