Bitcoin (BTC) voorstellen voor signature aggregation verlagen vergoedingen met 27,3%
Drie conceptvoorstellen voor signature aggregation zijn begin november in de BIPs-repository gezet. De voorstellen tonen hoe sommige transacties kleiner kunnen worden en modelmatig lagere fees kunnen krijgen, tot 27,3%.
Meer nieuws over BTC
Wat er gebeurde
BIP 458 werd samengevoegd op 2 november, BIP 459 op 3 november en BIP 460 op 4 november. Het zijn conceptspecificaties. Het toevoegen aan de repository verandert de netwerkregels niet en maakt vandaag geen lagere fees beschikbaar.
BIP 458 beschrijft noninteractive half-aggregation. Daarmee worden handtekeningen gecombineerd zonder dat ondertekenaars in één gezamenlijke sessie hoeven te coördineren. BIP 459 specificeert full aggregation. Die kan handtekeningen samenvoegen tot één 64-byte handtekening maar vereist twee rondes van coördinatie tussen ondertekenaars. BIP 460 stelt voor de methoden over inputs toe te passen.
In een voorbeeld met tien handtekeningen daalt alleen de signature data van 640 bytes naar 352 bytes met half-aggregation of naar 64 bytes met full aggregation. Dat betreft alleen de signature data, niet de hele transactie.
Een modelvoorbeeld met tien inputs en tien outputs laat de totale transactionele grootte dalen van 1.016 vB naar 944 vB met half-aggregation of 872 vB met full aggregation. Bij hetzelfde fee rate komen dat modelmatig neer op fee-reducties van 7,1% en 14,2%.
Voor een voorbeeld dat honderd inputs naar één output consolideert, gaat de gemodelde grootte van 5.804 vB naar 5.012 vB of 4.220 vB. Bij hetzelfde fee rate betekenen die veranderingen modelmatig een fee-reductie van 13,6% of 27,3%. Deze voorbeelden veronderstellen dat alle inputs in één aggregatiegroep zitten en gebruiken standaard instellingen zoals default sighash en 34-byte output scripts. Ze vertegenwoordigen geen typische transacties en bieden vandaag geen concrete korting.
BIP 460 stelt een nieuwe SegWit witness-versie voor voor Taproot-stijl key-path spends en sluit script-path spends uit. Bestaande Taproot-uitgangen zouden niet automatisch aggregation krijgen. Wallets moeten het voorgestelde outputtype ondersteunen voordat gebruikers die outputs kunnen maken of besteden.
De concepten volgen een PISA-prototype dat gebaseerd is op BIP 460 en beperkt is tot regtest. Full aggregation kent een veiligheidsrisico: BIP 459 waarschuwt dat het hergebruiken van secret nonces de private key van een ondertekenaar kan blootstellen.
BIP 460 vraagt om een soft fork en laat activatieparameters over aan een toekomstige update. De voorstellen geven geen inzet- of uitrolschema.
Waarom dit telt
Voor beleggers in BTC betekent dit dat er technisch voorstel ligt om sommige transacties kleiner en daardoor modelmatig goedkoper te maken. Het zijn nog concepten en er is geen concrete uitvoering of schema.
Waar je op kunt letten
- Of en wanneer de voorstellen verder worden ontwikkeld of in een deployment-schedule komen
- Ondersteuning van wallets voor het nieuwe outputtype
- Beveiligingsdiscussies rond secret nonces en full aggregation