SNICKER kan vara nästa verktyg i Bitcoins växande integritetsverktygslåda.

Även om Satoshi Nakamoto vitt papper föreslår att integritet var ett designmål för Bitcoin-protokollet, blockchain-analys kan ofta bryta användarnas integritet idag. Det här är ett problem. Bitcoin-användare vill inte nödvändigtvis att världen ska veta var de spenderar sina pengar, vad de tjänar eller hur mycket de äger, medan företag kanske inte vill läcka transaktionsinformation till konkurrenter – för att lista några exempel.

Lyckligtvis kommer Bitcoin-utvecklare och forskare med fler och fler lösningar för att användare ska kunna återfå sin integritet. En av dessa mästare för Bitcoin-integritet är Adam “waxwing” Gibson, kanske mest känd för sina bidrag till JoinMarket, ett protokoll som låter användare blanda sina mynt – och erbjuder en ekonomisk belöning för att delta i sådana mixar.

Nyligen presenterade Gibson en ny idé: SNICKER (Simple Non-Interactive Coinjoin with Keys for Encryption Reused). Nu inlämnad som en utkast till Bitcoinförbättringsförslag (BIP), skulle SNICKER möjliggöra myntblandning utan synkronisering eller interaktion: Det skulle inte finnas något behov av användare att samordna eller vara online samtidigt.

CoinJoin

SNICKER är baserad på den nu väletablerade bitcoinblandningstekniken CoinJoin. Några av de mest populära blandningslösningarna som finns idag använder redan detta trick, inklusive Wasabi Wallet (ZeroLink), Samourai Wallet (Whirlpool) och JoinMarket.

Ytterligare läsning: Vad är Bitcoin Mixers?

CoinJoin är i huvudsak ett verktyg för att slå samman flera transaktioner till en. Så låt oss säga att Alice vill betala Carol en bitcoin, och Bob vill betala Dave en bitcoin. I det här exemplet kan Alice och Bob samarbeta för att skapa en stor transaktion, där båda spenderar en bitcoin (två totalt), och Carol och Dave får var och en en bitcoin. En blockchain-spion kommer inte att kunna berätta vilken av avsändarna som betalade vilken av mottagarna, vilket gynnar allas integritet.

I själva verket är emellertid mängderna av transaktioner ofta sekretessläckage. Om Alice vill betala Carol ett bitcoin, men Bob vill betala Dave två bitcoin, kommer det att vara uppenbart vem som betalade vem genom att matcha de sändande och mottagande beloppen.

Det är därför CoinJoin används oftare för blandning. Istället för att betala någon annan skickar Alice och Bob båda en bitcoin till sig själva. Genom att slå samman detta i en transaktion kan blockchain-spioner inte berätta vem som fick tillbaka vilket mynt: Mynten är blandade och skyddar både Alice och Bobs integritet framöver.

CoinJoin-blandare fungerar idag, men de har en nackdel: De kräver interaktivitet. En CoinJoin-transaktion är endast giltig om alla deltagande användare signerar hela transaktionen – men för att signera hela transaktionen måste deltagande användare först ha lagt till alla sina mynt och nya mottagningsadresser till den. Detta innebär vanligtvis att de måste skicka transaktionen några gånger och vanligtvis kräver att alla är online samtidigt.

Sådana krav är lite av ett hinder för många användare, vilket är en anledning till att CoinJoin-transaktioner inte är så vanliga. Dessa krav är vad SNICKER får.

SNICKER Version 1

Protokollet som beskrivs i detta avsnitt är den första föreslagna versionen av SNICKER. Den här versionen är något lättare att förstå än alternativa versioner men det är viktigt att notera att det faktiskt inte är den bästa versionen av protokollet eller den version som sannolikt kommer att implementeras. (Mer om alternativa versioner senare.)

Med det sagt så här fungerar SNICKER version 1:

Säg att Alice har en bitcoin hon vill mixa, representerad av en outnyttjad transaktionsutgång (UTXO) på blockchain. Det första hon gör är att skicka denna bitcoin igen … till samma adress. Det stämmer, i den här versionen av SNICKER återanvänder hon en adress som bryter mot Bitcoins bästa praxis. Men det kommer till nytta: Det markerar UTXO offentligt som (potentiellt) tillgängligt för blandning.

Detta betyder inte att Alice förresten inte kan använda myntet. Den sitter fortfarande i hennes plånbok, redo att spenderas när som helst. Det är bara markerat, om någon bryr sig.

Bob har också ett mynt att blanda. (I själva verket behöver beloppen inte vara lika i förväg – Bob behöver bara ha minst lika mycket som Alice.) Bob känner inte Alice, men han vet att användare som Alice är där ute och markerar sina UTXOs. som blandbar. Så Bob genomsöker blockchain efter potentiella matchningar. Han hittar Alice’s UTXO, och förmodligen några fler matchande UTXOs, inklusive falska positiva (inte alla återanvända adresser är verkligen tillgängliga för blandning). Men låt oss, för enkelhetens skull, anta att Bob bara hittar en matchning: Alice’s UTXO. (Vi återkommer till andra potentiella matchningar och falska positiva resultat senare.)

Med matchen tar Bob nu den offentliga nyckeln som motsvarar den återanvändade adressen. Detta är möjligt exakt för att adressen återanvänds: Genom att spendera den första gången publicerade Alice den offentliga nyckeln i blockkedjan. (Offentliga nycklar blir synliga på blockkedjan när mynten har spenderats, medan adresser alltid är synliga.)

Vid denna tidpunkt har Bob Alice’s UTXO (för att hon markerade det) och sin offentliga nyckel (för att hon spenderade från sin adress en gång).

Nu använder Bob Alice: s offentliga nyckel och kombinerar den med sin egen privata nyckel (för det mynt han vill blanda) för att skapa en “delad hemlighet.” Ganska bokstavligen det äldsta tricket i kryptografiboken, den här hemligheten delas för att bara Alice och Bob kan generera den: Bob med sin privata nyckel och Alices offentliga nyckel och Alice med sin privata nyckel och Bobs offentliga nyckel (motsvarande de mynt han vill ha att blanda).

Så nu har Bob Alice’s UTXO och hennes offentliga nyckel, och en delad hemlighet (för att han genererade den med Alices offentliga nyckel och sin privata nyckel).

Bob använder den delade hemligheten på ett nytt sätt. Han använder den för att matematiskt ”finjustera” Alis offentliga nyckel. Denna tweaking skapar faktiskt en ny offentlig nyckel. Förutom … ingen har den privata nyckeln för det. Än.

Intressant, tack vare en annan bit kryptomagi kan den finjusterade privata nyckeln för den tweaked offentliga nyckeln också upptäckas av Alice! Om hon skulle justera sin ursprungliga privata nyckel med samma delade hemlighet, skulle den resulterande tweaked privata nyckeln motsvara den tweaked offentliga nyckeln.

Med andra ord kan Bob generera en ny offentlig nyckel och därför en ny Bitcoin-adress för Alice, som bara hon kan spendera på. Även utan att hon vet det just nu!

Så har Bob nu Alice’s UTXO och hennes offentliga nyckel, en delad hemlighet och en ny Bitcoin-adress för Alice (genererad med hennes offentliga nyckel och den delade hemligheten).

Detta räcker nästan för att skapa en giltig CoinJoin-transaktion. Specifikt tar Bob Alice’s UTXO och lägger till UTXO för sitt eget mynt, så det finns två ingångar. Han lägger sedan till Alice nya adress och en egen adress som utdata (samt avgifter och några andra detaljer, som en bytesadress för sig själv, om det behövs). Och han undertecknar transaktionen.

Det enda som saknas nu är Alice’s signatur.

Nå Alice

Det sista steget – att nå Alice – är faktiskt enklare än det låter men kräver ett sista trick.

Bob kunde helt enkelt publicera den nästan fullständiga CoinJoin-transaktionen någonstans för Alice att hitta. Till exempel på en anslagstavla tillägnad SNICKER-användare; helst en på en Tor-dold tjänst eller på annat sätt garanterat att erbjuda anonymitet för utgivare.

Men om det görs i klartext skulle det fortfarande inte vara perfekt. Om en spion håller ett öga på anslagstavlan kan de trivialt se vilken ingång som tillhör förslagsställaren (i det här fallet Bob) och vilken ingång som tillhör upptagaren (i det här fallet Alice): Den undertecknade är förslagsställaren. Detta kan vara en integritetsläcka i sig. Men det skulle vara ännu värre om Bob kommer med fler förslag för att blanda olika mynt. I så fall kan spionen kunna ansluta alla de olika UTXO: erna till Bob, till exempel eftersom hans grupp av förslag publicerades på anslagstavlan samtidigt.

Så istället krypterar Bob CoinJoin-transaktionen … med Alices offentliga nyckel! På det sättet är det bara Alice som kan dekryptera transaktionen och spionen kan inte lära sig någonting.

Efter att ha lagt upp den krypterade transaktionen på anslagstavlan har Bob gjort allt han behöver göra. Han kan försvinna online, om han vill.

Alice’s Turn

Eftersom CoinJoin-transaktionen nu är krypterad introducerar detta en sista, liten komplikation. Medan Alice vet var man ska leta efter paketet – på SNICKER anslagstavla – vet hon inte vad man ska leta efter: Alla CoinJoin-transaktioner på anslagstavlan ser ut som krypterade blobbar.

Det finns bara en väg ut. Alice måste försöka dekryptera alla paket med sin privata nyckel och hoppas att en av dem blir till något användbart.

Men när Bobs krypterade blob förvandlas till en CoinJoin-transaktion har Alice allt hon behöver för att slutföra mixen. Hon använder sin privata nyckel och Bobs offentliga nyckel (som ingår i hans input) för att skapa den delade hemligheten, som hon i sin tur kan använda för att skapa sin nya, tweaked privata nyckel. Efter att ha kontrollerat att den nya nyckeln motsvarar hennes nya mottagningsadress i utgången, signerar och sänder hon transaktionen till Bitcoin-nätverket.

Alice och Bob blandade sina mynt, även om de aldrig interagerade, och de behövde inte ens vara online samtidigt.

Och även om processen kan låta lite ansträngande i text, kom ihåg att allt kan tas bort av programvara, för att översättas till några knappar på en bärbar dator eller telefonskärm eller till och med automatiseras helt.

SNICKER Version 2

SNICKER som förklarats hittills är den första versionen av förslaget. Redan har Gibson föreslagit en andra version, och andra variationer finns också på bordet.

Den andra SNICKER-versionen är liknande men undviker behovet av återanvändning av adresser – på bekostnad av något mer komplexitet.

I den andra versionen får Bob inte Alis offentliga nyckel från en återanvänd adress. Istället tar Bob den offentliga nyckeln från en inmatning av samma transaktion som skapade Alices UTXO. Bob antar att minst en av ingångarna i den transaktionen skapades av Alice själv och att hon fortfarande har privata nycklar för dessa.

Bob antar detta antagande eftersom den här gången är Alice UTXO ännu tydligare markerad som tillgänglig för blandning, och det skulle bara vara så tydligt markerat om Alice kontrollerar de privata nycklarna som motsvarar ingångarna. SNICKER BIP specificerar inte hur den ursprungliga märkningen skulle göras men föreslår att vissa plånböcker (som JoinMarket-plånböcker) omedelbart avslöjar sådan information. Alternativt kan Alice helt enkelt lägga upp ett meddelande på anslagstavlan som annonserar för hennes UTXO.

Men ännu bättre: När SNICKER börjar användas bör det bli mycket enklare att hitta nya matchningar. Det beror på att SNICKER-transaktioner i sig skulle vara triviala att känna igen, och att befintliga SNICKER-användare sannolikt vill blanda sina mynt igen. Med andra ord, efter en initial bootstrapping-fas, skulle oblandade mynt blandas med tidigare blandade mynt, vilket skulle resultera i fler blandade mynt som i sin tur kunde utnyttjas för mer blandning.

Utmaningar och möjligheter

Som nämnts ovan är SNICKER BIP fortfarande bara ett utkast och föremål för granskning och potentiell förbättring. (Redan har idén utvecklats i vissa aspekter sedan den först föreslogs offentligt av Gibson i en blogginlägg.) Förslaget har nu lämnats in för att bli en BIP så att det kan standardiseras och, längs linjen, göras kompatibelt mellan olika plånböcker.

SNICKER står också inför några öppna frågor och utmaningar, även om inget av dessa verkar oöverstigligt. Dessa inkluderar till exempel vilka UTXO som ska väljas som matchningar, och i synnerhet hur man begränsar antalet falska positiva. Förutom återanvända adresser kan till exempel matchningar filtreras för mängder, ålder för UTXO eller specifika typer av plånböcker som används.

Men som antyds tidigare i den här artikeln, även om det finns flera matchningar (inklusive falska positiva), är detta sannolikt bara ett litet problem. Erbjudare (”Bob”) kan helt enkelt skapa kandidattransaktioner för dem alla. Även om dessa förslag strider mot varandra (eftersom Bob använder samma UTXO för alla), betyder det helt enkelt att den första tagaren (den första “Alice”) som svarar får mixen – andra potentiella användare kommer att tycka att de var för sent, men ingen skada skulle göras. För falska positiva resultat görs inte heller någon verklig skada, Bobs erbjudande kommer bara att sitta på anslagstavlan, ignoreras för alltid (eller tills det tas bort).

Vad som kan vara ett särskilt viktigt problem är dock skräppost. Eftersom anslagstavlan skulle vara värd för krypterade datahoppar skulle det vara omöjligt att filtrera bort “falska” förslag: slumpmässigt gibberish från en angripare för att störa SNICKER-protokollet. Gibson föreslog några lösningar på detta problem i sitt utkast till BIP, men dessa skulle presentera nya avvägningar, som en kostnad för att lägga upp ett förslag.

På baksidan erbjuder SNICKER också några fördelar som hittills har utelämnats av förklaringen för enkelhets skull. En sådan fördel är att anbudsgivare) kan lägga lite pengar till en tagares produktion och lägga till ett ekonomiskt incitament att acceptera mixen. Det kan också vara möjligt att genomföra SNICKER-mixer med mer än två användare samtidigt – även om detta kommer att göra tricket mycket mer komplext.

Och precis för att protokollet är icke-interaktivt, tror Gibson att SNICKER skulle vara relativt lätt att implementera i plånböcker, jämfört med vissa andra sekretesstekniker, som JoinMarket. Hittills har Electrum-plånboken visat intresse för att anta förslaget – men det faktiska genomförandet av det kan fortfarande vara långt borta.

För mer information och bakgrund till SNICKER, se utkast till BIP, följ bitcoin-dev-e-postlistan diskussion eller läs Gibsons (något föråldrad) blogginlägg på förslaget.