Om een asset als goed ruilmiddel te kunnen gebruiken, moet het vervangbaar zijn, wat inhoudt dat het volkomen inwisselbaar is voor een gelijke hoeveelheid van dezelfde soort. Gezien de bitcoin-blockchain is te analyseren, is het mogelijk voor een bedrijf om bitcoins met een bepaalde geschiedenis te markeren als ‘aangetast’, en deze niet te accepteren voor een betaling. Blockchain-analysebedrijven proberen de oorsprong en het bezit van bitcoins te traceren, wat de privacy van gebruikers schaadt en de mogelijkheid om vrij te ruilen verhindert. Als de privacy niet kan worden gewaarborgd bij normale bitcoin-transacties, gaat dit ten koste van de vervangbaarheid.
Deelnemers van een community-workshop hebben recentelijk nagedacht over hoe we de privacy van normale bitcoin-transacties kunnen verbeteren. Dit is een samenvatting van het werk van deze groep. Dit geeft wallet-ontwikkelaars een idee van hoe ze zich kunnen verdedigen tegen veelvoorkomende methodes die blockchain-analysebedrijven hanteren, om zo de inwisselbaarheid van bitcoin te verbeteren.
De groep hoopt dat dit gesprekken in de community stimuleert en de weg vrijmaakt voor een standaard manier voor wallets en betalingsverwerkers om met meer privacy gebruik te maken van de blockchain.
Het breken van tools voor blockchain-analyse
Meiklejohn et al. hebben in hun paper van 2013 een belangrijke methode uiteengezet voor het verbinden van adressen in de bitcoin-blockchain. Ze observeerden dat de “verschillende publieke sleutels die in een transactie voor inputs worden gebruikt, worden beheerd door dezelfde gebruiker”. Dit is het voornaamste principe voor blockchain-analyse.
De opmaak van een normale bitcoin-transactie biedt daardoor een beginpunt voor analysebedrijven die een adres en de gebruiker in de gaten willen houden. Dit was dit principe dat de workshop probeerde te breken.
Een belangrijk punt is dat het niet nodig is voor elke transactie om mee te doen aan een gestelde oplossing om de aanname dat alle inputs van dezelfde gebruiker zijn, te ontkrachten. Er hoeven enkel genoeg transacties te bestaan met inputs van meerdere gebruikers om dat te bewerkstelligen. Gezien deze techniek centraal staat in blockchain-analyse, is het redelijk om aan te nemen dat blockchain-analyse geheel onmogelijk wordt als een oplossing actief in gebruik wordt genomen.
Deze aanpak gaf de groep een duidelijk doel:
Een manier vinden om te zorgen dat transacties met inputs van meerdere mensen vaak genoeg voorkomen dat de aanname dat elke input van dezelfde gebruiker komt, ongeldig wordt.
De essentiële ingrediënten
Er zijn veel verschillende voorstellen gedaan, en vele ervan hadden soortgelijke pijnpunten. Zonder in detail te treden bij elk voorstel en ze te bekritiseren, kunnen de problemen worden samengevat in de zoektocht naar een geldige oplossing die de volgende karakteristieken moet bevatten:
- Er moet een interactief proces plaatsvinden tussen de participanten.
- De impact van ‘UTXO snooping’-aanvallen (waar de zender herhaaldelijk gefaalde pogingen initieert om UTXO’s van de ontvanger te achterhalen) wordt gereduceerd of voorkomen.
- De impact van geen-respons-aanvallen wordt gereduceerd.
Het ‘Pay to EndPoint’-voorstel (P2EP)
Na verschillende ideeën te hebben besproken, kwam ‘Pay to EndPoint’ (P2EP) boven tafel. Het heeft ook nadelen, maar bereikt de doelen die we hebben gesteld. Het maakt het onmogelijk om aan te nemen dat alle inputs van dezelfde gebruiker afkomstig zijn en is een interactief proces dat voldoende maatregelen bevat om aanvallen te voorkomen.
Het uitgangspunt van P2EP is dat zowel de zender als ontvanger worden geacht inputs toe te voegen aan een transactie. Dit gebeurt aan de hand van interactie die tot stand wordt gebracht door de ontvanger via een URI in de stijl van BIP 21.
Voor P2EP zijn er geen veranderingen nodig aan het bitcoin-protocol, en de transacties die er gebruik van maken zijn vrijwel niet te achterhalen omdat ze er hetzelfde uitzien als normale transacties.
De beste manier om het uit te leggen, is door de stappen te volgen die nodig zijn om een transactie met P2EP te maken:
Stap 1
De ontvanger (een bedrijf of gebruiker) creëert een URI aan de hand van BIP 21, met een aanvullende parameter die hun P2EP-eindpunt aangeeft. Gezien BIP 21 momenteel onbekende variabelen toestaat, breekt dit niet de compatibiliteit met bestaande wallet-implementaties. Het adres van het eindpunt hoeft niet per definitie een .onion-adres te zijn. Het kan de URI van elk compatibel eindpunt zijn.
Hier volgt een voorbeeld-URI (aangepast uit voorbeelden in BIP 21):
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?p2ep=3j4tau93wkc8mh32.onion
Stap 2
De zender start de interactie met de ontvanger door te verifiëren dat het eindpunt beschikbaar is. Zo niet, dan wordt de transactie op normale wijze verzonden, door het te sturen naar het normale bitcoin-adres in BIP 21. Als het eindpunt van de ontvanger beschikbaar is, stuurt de zender een transactie met signature naar de ontvanger om te bewijzen dat het daadwerkelijk een UTXO bezit.
Stap 3
De ontvanger stuurt vervolgens een aantal transacties naar de zender, die allemaal moeten worden voorzien van een signature. Tussen al deze transacties is er slechts één UTXO bijgevoegd die de ontvanger daadwerkelijk bezit. De rest kan worden gekozen uit de gehele UTXO set. Deze transacties kunnen vervolgens opeenvolgend of allemaal tegelijk naar de zender worden verstuurd. Beide methodes hebben voordelen en nadelen qua privacy en interactiesnelheid, dus er zou nog een discussie kunnen plaatsvinden over wat de beste implementatie is.
Opeenvolgend: elke verstuurde transactie zou die van de ontvanger kunnen zijn. De kans daarop is afhankelijk van het aantal transacties dat de ontvanger heeft aangemaakt, en hoe de volgorde is gerandomiseerd. De interactie eindigt zodra de zender een transactie met de daadwerkelijke UTXO van de ontvanger van een signature voorziet.
Tegelijk: alle transacties van de ontvanger worden tegelijk naar de zender verstuurd. De zender heeft nu een set transacties in handen, en één ervan zou echt van de ontvanger moeten zijn. De kans dat de zender kan raden welke echt is, hangt af van hoeveel transacties de ontvanger heeft aangemaakt en opgestuurd. De zender voorziet ze allemaal van een signature en stuurt ze direct terug.
Het huidige voorstel is dat de ontvanger 100 transacties verstuurt voor beide methodes. Dit geeft een balans tussen privacy en hoeveel data er moet worden verzonden en verwerkt aan beide kanten van de samenwerking.
Het is het vermelden waard dat Bulletproofs misschien in de toekomst kunnen worden gebruikt ter vervangen van de huidige methode van UTXO-uitwisseling.
Stap 4
Voor beide bovenstaande gevallen krijgt de ontvanger uiteindelijk een transactie die inputs van beide partijen bevat. De ontvanger voorziet deze transactie van een signature en stuurt hem door naar het netwerk.
Mocht het P2EP-proces om wat voor reden dan ook falen, dan kan de transactie altijd naar het netwerk worden doorgestuurd als een normale transactie.
Een voorbeeld van een P2EP-transactie
Stel Alice wil 1 BTC aan Bob betalen:
- Alice voegt een input van 3 BTC toe aan een transactie.
- Bob voegt een input van 5 BTC toe aan dezelfde transactie.
- Alice ontvangt 2 BTC (haar wisselgeld).
- Bob ontvangt 6 BTC (zijn wisselgeld, en de 1 BTC van Alice).
Van de bovenstaande transactie is niet te zeggen dat de inputs van dezelfde gebruiker komen, en hij kan op meerdere manieren worden geïnterpreteerd. Men zou bijvoorbeeld kunnen denken dat Alice 6 BTC betaalt aan Bob, en dat de inputs van 3 BTC en 5 BTC, in totaal 8 BTC, van haar zijn en ze 2 BTC terugkrijgt als wisselgeld.
De voordelen en nadelen van P2EP
Voordelen:
- Breekt de aanname dat alle inputs van dezelfde gebruiker afkomstig zijn. Cumulatief effect waar zelfs minimale adoptie zorgt voor verbeterde privacy voor ‘niet-P2EP’-transacties.
- Breekt analyse van de som van een subset.
- Doordat een UTXO van de ontvanger wordt verbruikt, kan dit de groei van de UTXO set reduceren.
- De ontvanger kan P2EP gebruiken om zijn UTXO’s samen te voegen.
- In tegenstelling tot traditionele coinjoin-transacties met vaste hoeveelheid, is er geen duidelijke ‘fingerprint’ voor dit soort transacties, want normale transacties zien er veelal hetzelfde uit.
- Wallets die fungeren als zender kunnen lichtgewicht zijn.
- De zender en ontvanger krijgen allebei verbeterde privacy.
Nadelen:
- De zender en ontvanger moeten allebei online zijn om een P2EP-transactie uit te voeren.
- Gezien P2EP interactief is, duurt het iets langer om de transactie naar het netwerk door te sturen.
- De ontvanger heeft een ‘hot wallet’ nodig om de transactie van een signature te kunnen voorzien.
- De zender betaalt wellicht meer omdat de transactie groter wordt. Misschien is de ontvanger bereid hiervoor te betalen, omdat het tevens zijn UTXO’s samenvoegt.
- Wallets moeten meer werk verrichten dan voor een gewone transactie.
- De ontvanger heeft toegang nodig tot een full node.
Wat volgt er voor Pay to Endpoint?
P2EP bevindt zich in een vroeg stadium van review door de community, en er moeten nog aanpassingen worden gemaakt voordat er een volledig voorstel is.
Het is mogelijk dat het idee kan worden uitgebreid om andere transactiesoorten te ondersteunen, zoals gesplitste betalingen of simpele ‘coin swaps’.