Een voorstel dat nu circuleert onder bijdragers aan Zcash, de privacygerichte cryptocurrency, zou het mechanisme verwijderen dat bij elke netwerkupgrade (NU) ondertekende transacties ongeldig maakt, nadat de meest recente activatie wallets verhinderde te kunnen uitgeven totdat ze nieuwe releases of firmware uitbrachten.

Een nieuwe klacht, met een vers voorbeeld

In een forumbericht van 9 november somde de developer ValarDragon het verwijderen van consensus branch ID-updates op als een van zeven doelen voor NU8, de volgende upgrade, met als uitgesproken doel een einde te maken aan het patroon van "brekende wallets bij elke NU."

De klacht heeft een vers voorbeeld. NU7 werd vorige week geactiveerd op blok 3.543.405 zonder het transactieformaat aan te passen, maar, zoals forumlid strahncryptography in dezelfde thread opmerkte, had elke wallet nog een nieuwe release of nieuwe firmware nodig voordat er weer kon worden uitgegeven. Iedereen met een air-gapped telefoon of een niet-ondersteund apparaat zat vast.

De volgende ochtend had de thread drie standpunten opgeleverd: het mechanisme laten vallen, behouden maar gebruikers laten afzien, of accepteren dat het echte probleem verouderende wallets zijn en niet verlopende handtekeningen. Een vault-developer liet toen zien waarom de keuze niet academisch is.

Wat er precies breekt

Elke Zcash-handtekening legt zich vast op een consensus branch ID, een label voor de geldende regeling. ZIP 200, een van de Zcash Improvement Proposals (ZIP's) die de protocolregels specificeren, introduceerde dit zodat een transactie die voor de ene keten is ondertekend niet kan worden herhaald op een fork met dezelfde geschiedenis. Wanneer een upgrade wordt geactiveerd, verandert het ID, en alles wat onder het oude ID is ondertekend is ter plekke ongeldig.

Het deployment-ZIP van NU7 spelled dit uit voor de upgrade die net heeft plaatsgevonden: versie 5- en versie 6-transacties behielden hun structuur, maar een transactie is nog steeds niet geldig over de activatie heen omdat de handtekeningen aan het branch ID zijn gebonden. Opgeslagen en offline ondertekende transacties, voegt het document toe, hebben dezelfde activatiecontroles nodig als live transacties.

Daarom moesten wallets updates uitbrengen voor een upgrade die niets veranderde aan hoe ze transacties opbouwen. Een wallet die het nieuwe ID niet kent, ondertekent voor een keten die niet meer bestaat.

De vault die niet op tijd kan ondertekenen

Daniel Gorgonha, die de Konclave t-of-n vault bouwt bij Deega Labs, beschreef later in de thread de praktische kosten. Konclave bouwt eerst de transactie en verzamelt daarna drempelhandtekeningen, dus elke vereiste ondertekenaar moet handelen binnen de verloopvenster van de transactie, ruwweg 50 minuten. Een upgrade die middenin dat venster plaatsvindt maakt het geheel ongeldig.

De 50 minuten komen uit ZIP 203, dat de standaardverloopduur bij drie wijzigingen van de bloktijd op ongeveer die lengte heeft gehouden. Sinds NU7 betekent dat 120 blokken bij een streefinterval van 25 seconden. Het is een walletstandaard, configureerbaar per node, en een transactie kan zelfs zonder verloop worden opgebouwd door het veld op nul te zetten.

De klok is dus al oplosbaar, tenminste waar de wallet de instelling beschikbaar stelt. De upgrade-grens niet. Een vault zou zijn leden een week kunnen geven om te ondertekenen en toch de transactie verliezen op het moment dat het branch ID omrolt. Gorgonha verzocht om de opt-out die nuttycom net had voorgesteld, zodat een groep handtekeningen kan verzamelen over uren of dagen op eigen risico.

Drie uitwegen, elk met een addertje

Het branch ID-commitment verwijderen. Dit is ValarDragon's oorspronkelijke voorstel. str4d, ingenieur bij Electric Coin Company (ECC), antwoordde dat replaybescherming een harde eis was van beurzen en andere ecosysteemspelers toen ZIP 200 werd geschreven, dus elke verwijdering heeft een vervangend mechanisme nodig, bij voorkeur een dat ook vijandige forks dekt die puur zijn gemaakt om de hoofdketen te verstoren.

Behouden als standaard, gebruikers laten afzien. nuttycom, ook bij ECC, stelde onder ZIP 248 ondertekenvarianten voor die zowel het branch ID als de verloophoogte overslaan. Gebruikers die ze kiezen geven enige replaybescherming op en krijgen transacties die een upgrade overleven. Het bestaande algoritme, waarvan nuttycom zei dat het prima werkt voor de overgrote meerderheid van transacties, zou de veilige standaard blijven. str4d had al opgemerkt dat zo'n variant eenvoudig te definiëren zou zijn zodra ZIP 248 actief is.

Betwijfelen of dat iets voor wallets oplost. strahncryptography betoogde dat de varianten de levensduur van transacties verhelpen maar niet de veroudering: als het branch ID niet hard-gecodeerd is, moet de gebruiker het juiste aanleveren, wat dezelfde last terugplaatst op de walletsoftware. Replaybescherming tegen vriendelijke forks heeft waarde, schreef hij, maar de voordelen moeten worden afgewogen.

De thread heeft het meningsverschil niet opgelost. Wat wel is gebeurd, is dat de vraag is versmald tot of een opt-in variant de moeite waard is voor de gebruikers die hem nodig hebben, en wat die gebruikers zouden opgeven.

Wat een opt-out zou kosten

Replayrisico is het makkelijkst voor te stellen met de upgrade die net heeft plaatsgevonden. Alleen voor NU7 schrapte ZIP 259 de gebruikelijke eis dat oude node-software zichzelf buiten gebruik stelt vóór activatie, waardoor operatoren die nooit hebben geüpgrade online kunnen blijven en een pre-NU7 branch kunnen blijven volgen. Een transactie waarvan de handtekening niet aan één branch is gebonden is precies het type dat op beide kan worden geaccepteerd.

De blootstelling betreft de reikwijdte van een autorisatie, niet de sleutels erachter. Een herhaalde transactie geeft dezelfde inputs uit op een andere keten die de ondertekenaar nooit wilde gebruiken; het staat niemand toe een nieuwe te vervalsen.

Het weglaten van de verloophoogte uit de handtekening heeft een tweede effect: een geautoriseerde betaling kan onbevestigd blijven liggen zolang zijn inputs ongebruikt zijn. Dat is de functie die een vault wil en het risico dat een individuele gebruiker mogelijk niet opmerkt.

nuttycom wees ook op een mogelijke verkleining van de anonimiteitsset. In een shielded systeem hangt privacy ervan af dat een transactie eruitziet als elke andere transactie; een transactie ondertekend met een zelden gebruikte variant biedt een kleinere menigte om in te verbergen. Het bericht kwantificeerde het effect niet, en er is nog geen variant gespecificeerd.

Een langlevende handtekening werkt geen oud apparaat bij

ZIP 248, het uitbreidbare transactieformaat waar alles hierop berust, is nog een concept. str4d zei dat het ontwerp al meer dan een half jaar stabiel is en dat hij de afgelopen week het bijwerkte voor sindsdien ingevoerde consensuswijzigingen. Het is niet aan een upgrade toegewezen, en de opt-out varianten bestaan er nog niet in.

Zelfs als dat zo is, heeft een hardware wallet of offline ondertekenaar nog steeds software nodig die het nieuwe formaat begrijpt. ZIP 248 verbiedt wallets componenten op te bouwen of te ondertekenen die ze niet kunnen parsen. Het compatibiliteitsvoordeel is echt, maar het komt via walletreleases, de stap die volgens strahncryptography steeds faalt.

Geen van dit alles helpt bovendien transacties in een buiten gebruik gesteld formaat. ZIP 259 merkt op dat het NU7-verbod op versie 4-transacties zowel transparante als Sapling-uitgaven dekt, evenals Sprout, en dat herondertekening ze niet kan redden; de enige oplossing is de betaling opnieuw opbouwen in een ondersteunde versie. Coindoo behandelde vorige week het moeilijkere geval van Sprout-munten zonder enig vervangend formaat.

Konclave heeft ook zijn eigen onafgemaakte stuk. Zijn open issue over asynchroon ondertekenen scheidt in de loop van de tijd verzamelde goedkeuringen van de interactieve drempelceremonie die de vault nu draait. Een transactie die een upgrade overleeft verwijdert één obstakel; de workflow die leden laat bijdragen naarmate ze online komen moet nog worden geschreven en beoordeeld.

Praktische richtlijnen

Als je een groepswallet beheert:

• Activatie is een blokhoogte, geen datum; het deployment-ZIP van elke upgrade publiceert deze vooraf.
• Open geen ondertekenronde die over die hoogte heen kan lopen.
• Alles wat vóór de activatie is voorbereid moet daarna opnieuw worden opgebouwd, ook al heeft nog niemand ondertekend.

Als je munten op een oud apparaat bewaart:

• Controleer of de firmware of app NU7-ondersteuning heeft uitgebracht voordat je probeert uit te geven.
• Een vastgelopen uitgave vanuit een ondersteunde pool is een walletprobleem, geen verloren fondsen.
• Versie 4-transacties die vóór 6 november zijn opgeslagen, kunnen niet door herondertekening geldig worden gemaakt.

Coindoo's eerdere beschouwing van walletzijdige betalingsverbeteringen behandelde de kloof tussen het opbouwen van een transactie en het bevestigen ervan. Deze thread voegt daartussen een derde fase toe: de autorisatie in leven houden terwijl mensen en apparaten inhaalen.

Wat nu

Eind januari is ValarDragon's streefdatum, geen vast schema. str4d betwijfelde in dezelfde thread of tweeëneenhalve maand genoeg is voor de Tachyon-pool op dezelfde lijst, en het branch ID-item heeft van alle zeven de scherpste tegenstand gekregen. Of NU8 met een opt-out verschijnt, een vervanging voor replaybescherming, of geen van beide, zal worden beslecht in het ZIP-proces, niet op het forum.