SNICKER kan være det neste verktøyet i Bitcoins voksende personvernverktøykasse.

Selv om Satoshi Nakamoto’s hvitt papir antyder at personvern var et designmål for Bitcoin-protokollen, blockchain-analyse kan ofte bryte brukernes privatliv i dag. Dette er et problem. Bitcoin-brukere vil kanskje ikke nødvendigvis at verden skal vite hvor de bruker pengene sine, hva de tjener eller hvor mye de eier, mens bedrifter kanskje ikke vil lekke transaksjonsdetaljer til konkurrentene – for å liste noen eksempler.

Heldigvis kommer Bitcoin-utviklere og forskere med flere og flere løsninger for brukere å gjenvinne sitt privatliv. En av disse mestrene for Bitcoin-personvern er Adam “waxwing” Gibson, kanskje best kjent for sine bidrag til JoinMarket, en protokoll som lar brukerne blande myntene sine – og gir en økonomisk belønning for å delta i slike mikser..

Mer nylig presenterte Gibson en ny idé: SNICKER (Simple Non-Interactive Coinjoin with Keys for Encryption Reused). Nå sendt inn som en utkast til forslag til forbedring av Bitcoin (BIP), SNICKER vil tillate myntblanding uten synkronisering eller interaksjon: Det ville ikke være behov for brukere å koordinere eller være online samtidig.

CoinJoin

SNICKER er basert på den nå veletablerte bitcoin-blandeteknikken CoinJoin. Noen av de mest populære blandeløsningene som er tilgjengelige i dag, bruker allerede dette trikset, inkludert Wasabi Wallet (ZeroLink), Samourai Wallet (Whirlpool) og JoinMarket.

Videre lesing: Hva er Bitcoin Mixers?

CoinJoin er egentlig et verktøy for å slå sammen flere transaksjoner i en. Så la oss si at Alice vil betale Carol en bitcoin, og Bob vil betale Dave en bitcoin. I dette eksemplet kan Alice og Bob samarbeide om å skape en stor transaksjon, hvor begge bruker en bitcoin (to totalt), og Carol og Dave hver mottar en bitcoin. En blockchain-spion vil ikke kunne fortelle hvem av avsenderne som betalte hvem av mottakerne, noe som drar fordel av personvernet til alle.

I virkeligheten er imidlertid transaksjonene av bitcoin ofte personvernlekkasjer. Hvis Alice ønsker å betale Carol en bitcoin, men Bob vil betale Dave to bitcoin, vil det være åpenbart hvem som betalte hvem ved å matche sende- og mottaksbeløpet.

Derfor brukes CoinJoin mer typisk til miksing. I stedet for å betale noen andre sender Alice og Bob begge en bitcoin til seg selv. Ved å slå dette sammen i en transaksjon, kan ikke blockchain-spioner fortelle hvem som fikk hvilken mynt tilbake: Myntene er blandet, og beskytter både Alice og Bobs privatliv fremover.

CoinJoin-miksere fungerer i dag, men de har en ulempe: De krever interaktivitet. En CoinJoin-transaksjon er bare gyldig hvis alle deltakende brukere signerer hele transaksjonen – men for å signere hele transaksjonen, må deltakende brukere først ha lagt til alle myntene sine og nye mottaksadresser til den. Dette betyr vanligvis at de må overføre transaksjonen et par ganger, og vanligvis krever at de alle er online samtidig.

Slike krav er litt av et hinder for mange brukere, og det er en grunn til at CoinJoin-transaksjoner ikke er veldig vanlige. Disse kravene er hva SNICKER får rundt.

SNICKER versjon 1

Protokollen beskrevet i denne delen er den første foreslåtte versjonen av SNICKER. Denne versjonen er litt lettere å forstå enn alternative versjoner, men det er viktig å merke seg at det faktisk ikke er den beste versjonen av protokollen, eller den versjonen som mest sannsynlig vil bli implementert. (Mer om alternative versjoner senere.)

Når det er sagt, her er hvordan SNICKER versjon 1 fungerer:

Si at Alice har en bitcoin hun vil blande, representert ved en ubrukt transaksjonsoutput (UTXO) på blockchain. Det første hun gjør er å sende denne bitcoin på nytt til samme adresse. Det stemmer, i denne versjonen av SNICKER bruker hun en adresse på nytt, som bryter med Bitcoins beste praksis. Men det kommer godt med: Det markerer UTXO offentlig som (potensielt) tilgjengelig for miksing.

Dette betyr ikke at Alice forresten ikke kan bruke mynten. Den sitter fortsatt i lommeboken hennes, klar til å bli brukt når som helst. Det er bare merket, i tilfelle noen bryr seg.

Bob har også en mynt å blande. (I virkeligheten trenger ikke beløpene å være like på forhånd – Bob trenger bare å ha minst like mye som Alice.) Bob kjenner ikke Alice, men han vet at brukere som Alice er der ute og markerer deres UTXO-er. som blandbar. Så Bob skanner blockchain for potensielle kamper. Han finner Alice’s UTXO, og sannsynligvis noen flere matchende UTXOs, inkludert falske positive (ikke alle gjenbrukte adresser er virkelig tilgjengelige for miksing). Men la oss for enkelhets skyld anta at Bob bare finner en kamp: Alice’s UTXO. (Vi kommer tilbake til de andre potensielle kampene og falske positive senere.)

Med kampen tar Bob nå den offentlige nøkkelen som tilsvarer den gjenbrukte adressen. Dette er mulig akkurat fordi adressen blir gjenbrukt: Ved å bruke den første gangen publiserte Alice den offentlige nøkkelen på blockchain. (Offentlige nøkler blir synlige på blokkjeden når myntene er brukt, mens adresser alltid er synlige.)

På dette tidspunktet har Bob Alice’s UTXO (fordi hun markerte den) og hennes offentlige nøkkel (fordi hun brukte fra adressen sin en gang).

Nå bruker Bob den offentlige nøkkelen til Alice og kombinerer den med sin egen private nøkkel (for mynten han vil blande) for å skape en “delt hemmelighet.” Ganske bokstavelig talt det eldste trikset i kryptografiboken, denne hemmeligheten deles fordi bare Alice og Bob kan generere den: Bob med sin private nøkkel og Alice’s offentlige nøkkel, og Alice med hennes private nøkkel og Bobs offentlige nøkkel (tilsvarende myntene han vil ha å blande).

Så nå har Bob Alice’s UTXO og hennes offentlige nøkkel, og en felles hemmelighet (fordi han genererte den med Alice’s offentlige nøkkel og sin private nøkkel).

Bob bruker den delte hemmeligheten på en ny måte. Han bruker den til å matematisk “finjustere” den offentlige nøkkelen til Alice. Denne justeringen oppretter faktisk en ny offentlig nøkkel. Bortsett fra … ingen har den private nøkkelen til det. Ennå.

Interessant, takket være en annen bit kryptomagi, kan den finjusterte private nøkkelen for den tweaked offentlige nøkkelen også oppdages av Alice! Hvis hun tilpasser sin opprinnelige private nøkkel med den samme delte hemmeligheten, vil den resulterende finjusterte private nøkkelen tilsvare den tweaked offentlige nøkkelen.

Med andre ord kan Bob generere en ny offentlig nøkkel og derfor en ny Bitcoin-adresse for Alice, som bare hun kan bruke på. Selv uten at hun visste akkurat nå!

Så, Bob har nå Alice’s UTXO og hennes offentlige nøkkel, en delt hemmelighet og en ny Bitcoin-adresse for Alice (generert med hennes offentlige nøkkel og den delte hemmeligheten).

Dette er nesten nok til å opprette en gyldig CoinJoin-transaksjon. Spesielt tar Bob Alice’s UTXO og legger til UTXO for sin egen mynt, så det er to innganger. Deretter legger han til Alice sin nye adresse og en egen adresse som utganger (i tillegg til gebyrer og noen andre detaljer, som en endringsadresse for seg selv, om nødvendig). Og han signerer transaksjonen.

Det eneste som mangler nå er Alice’s signatur.

Nå Alice

Det siste trinnet – å nå Alice – er faktisk enklere enn det høres ut, men krever et siste triks.

Bob kunne ganske enkelt publisere den nesten fullstendige CoinJoin-transaksjonen et sted for Alice å finne. For eksempel på et oppslagstavle dedikert til SNICKER-brukere; helst en på en Tor-skjult tjeneste eller på annen måte garantert å tilby utgivere anonymitet.

Imidlertid, hvis det gjøres i ren tekst, vil dette fortsatt ikke være ideelt. Hvis en spion holder øye med oppslagstavlen, kan de trivielt se hvilke innspill som tilhører forslagsstiller (i dette tilfellet Bob), og hvilke innspill som tilhører opptakeren (i dette tilfellet Alice): Den signerte er forslagsstillerens. Dette kan være en personvernlekkasje i seg selv. Men det vil være enda verre hvis Bob kommer med flere forslag om å blande forskjellige mynter. I så fall kan spionen kanskje koble alle de forskjellige UTXO-ene til Bob, for eksempel fordi hans gruppe forslag ble lagt ut på oppslagstavlen samtidig.

Så i stedet krypterer Bob CoinJoin-transaksjonen … med Alices offentlige nøkkel! På den måten er det bare Alice som kan dekryptere transaksjonen, og spionen kan ikke lære noe.

Etter å ha lagt ut den krypterte transaksjonen på oppslagstavlen, har Bob gjort alt han trenger å gjøre. Han kan forsvinne på nettet, hvis han vil.

Alice’s Turn

Ettersom CoinJoin-transaksjonen nå er kryptert, introduserer dette en siste, liten komplikasjon. Mens Alice vet hvor hun skal se etter pakken – på SNICKER-anslagstavlen – vet hun ikke hva hun skal se etter: Alle CoinJoin-transaksjoner på oppslagstavlen ser ut som krypterte blobs.

Det er bare en vei ut. Alice trenger å prøve å dekryptere alle pakkene med sin private nøkkel, og håper at en av dem blir til noe nyttig.

Men når Bobs krypterte blob blir til en CoinJoin-transaksjon, har Alice alt hun trenger for å fullføre blandingen. Hun bruker sin private nøkkel og Bobs offentlige nøkkel (som er inkludert i hans innspill) for å generere den delte hemmeligheten, som hun igjen kan bruke til å lage sin nye, tweaked private nøkkel. Etter å ha sjekket at den nye nøkkelen tilsvarer hennes nye mottaksadresse i utgangen, signerer og sender hun transaksjonen til Bitcoin-nettverket.

Alice og Bob blandet myntene sine, selv om de aldri samhandlet, og de trengte ikke engang å være online samtidig.

Og selv om prosessen kan høres litt arbeidskrevende ut i tekst, må du huske at alt det kan trekkes ut av programvare, oversettes til noen få knapper på en bærbar PC eller telefonskjerm, eller til og med automatiseres helt.

SNICKER versjon 2

SNICKER som forklart så langt, er den første versjonen av forslaget. Allerede har Gibson foreslått en andre versjon, og andre variasjoner er også på bordet.

Den andre SNICKER-versjonen er lik, men unngår behovet for gjenbruk av adresser – på bekostning av litt mer kompleksitet.

I denne andre versjonen får ikke Bob den offentlige nøkkelen til Alice fra en gjenbrukt adresse. I stedet tar Bob den offentlige nøkkelen fra en innspill fra den samme transaksjonen som opprettet Alice’s UTXO. Bob antar at minst en av inngangene i den transaksjonen ble opprettet av Alice selv, og at hun fortsatt har de private nøklene for disse.

Bob antar denne antagelsen fordi denne gangen er Alice’s UTXO enda tydeligere merket som tilgjengelig for miksing, og det ville bare være så tydelig merket hvis Alice kontrollerer de private nøklene som tilsvarer inngangene. SNICKER BIP spesifiserer ikke hvordan den første merkingen skulle gjøres, men antyder at visse lommebøker (som JoinMarket-lommebøker) umiskjennelig avslører slik informasjon. Alternativt kunne Alice bare legge ut en melding på oppslagstavlen som annonserte hennes UTXO.

Men enda bedre: Når SNICKER begynner å bli brukt, bør det bli mye enklere å finne nye treff. Dette er fordi SNICKER-transaksjoner i seg selv ville være trivielle å gjenkjenne, og eksisterende SNICKER-brukere vil sannsynligvis blande myntene sine igjen. Med andre ord, etter en innledende bootstrapping-fase, ville ikke-blandede mynter bli blandet med tidligere blandede mynter, noe som resulterte i flere blandede mynter som igjen kunne utnyttes for mer blanding..

Utfordringer og muligheter

Som nevnt ovenfor er SNICKER BIP fortsatt bare et utkast og gjenstand for gjennomgang og potensiell forbedring. (Allerede har ideen utviklet seg i noen aspekter siden den først ble foreslått offentlig av Gibson i en blogg innlegg.) Forslaget er nå sendt inn for å bli en BIP slik at det kan standardiseres og, på linjen, gjøres kompatibelt mellom forskjellige lommebøker.

SNICKER står også overfor noen åpne spørsmål og utfordringer, selv om ingen av disse virker uoverstigelige. Disse inkluderer for eksempel hvilke UTXO-er som skal velges som treff, og spesielt hvordan man kan begrense antall falske positive. I tillegg til gjenbrukte adresser, kan potensielle treff for eksempel filtreres for beløp, alder på UTXO eller bestemte typer lommebøker som brukes.

Men som antydet tidligere i denne artikkelen, selv om det er flere treff (inkludert falske positive), er dette sannsynligvis bare et lite problem. Tilbudsgivere (“Bob”) kan ganske enkelt opprette kandidattransaksjoner for dem alle. Selv om disse forslagene er i konflikt (fordi Bob bruker sin samme UTXO for alle), betyr det ganske enkelt at den første som tar (den første “Alice”) som svarer, får en blanding – andre potensielle brukere vil oppleve at de var for sent, men ingen skade ville blitt gjort. For falske positive gjøres det heller ingen reell skade, Bobs tilbud vil bare sitte på oppslagstavlen, ignorert for alltid (eller til det er fjernet).

Det som kan være et spesielt betydelig problem, er imidlertid spam. Fordi oppslagstavlen vil være vert for krypterte datablokker, ville det være umulig å filtrere ut “falske” forslag: tilfeldig bråk lagt ut av en angriper for å forstyrre SNICKER-protokollen. Gibson foreslo noen løsninger på dette problemet i sitt utkast til BIP, men disse ville presentere nye kompromisser, som en kostnad for å legge ut et forslag.

På baksiden tilbyr SNICKER også noen fordeler som har blitt utelatt av forklaringen så langt for enkelhets skyld. En slik fordel er at tilbydere) kan legge til litt penger i takets produksjon, og legge til et økonomisk incitament til å akseptere blandingen. Det kan også være mulig å gjennomføre SNICKER-mikser med mer enn to brukere samtidig – selv om dette vil gjøre kunsten mye mer kompleks.

Og akkurat fordi protokollen er ikke-interaktiv, mener Gibson at SNICKER ville være relativt enkelt å implementere i lommebøker, sammenlignet med noen andre personvernteknologier, som JoinMarket. Så langt har Electrum-lommeboken vist interesse for å vedta forslaget – selv om den faktiske implementeringen av den fortsatt kan være langt unna.

For mer informasjon og bakgrunn om SNICKER, se utkast til BIP, følg bitcoin-dev-postlisten diskusjon eller les Gibsons (litt utdatert) blogg innlegg på forslaget.