SNICKER kunne være det næste værktøj i Bitcoins voksende privatlivsværktøjskasse.

Selvom Satoshi Nakamoto’s hvidt papir antyder, at privatlivets fred var et designmål for Bitcoin-protokollen, blockchain-analyse kan ofte bryde brugernes privatliv i dag. Dette er et problem. Bitcoin-brugere ønsker måske ikke nødvendigvis, at verden skal vide, hvor de bruger deres penge, hvad de tjener, eller hvor meget de ejer, mens virksomheder måske ikke ønsker at lække transaktionsoplysninger til konkurrenterne – for at nævne et par eksempler.

Heldigvis kommer Bitcoin-udviklere og forskere med flere og flere løsninger, som brugerne kan genvinde deres privatliv. En af disse mestre for Bitcoin-privatliv er Adam “waxwing” Gibson, måske bedst kendt for sine bidrag til JoinMarket, en protokol, der lader brugere blande deres mønter – og giver en økonomisk belønning for at deltage i sådanne blandinger.

For nylig præsenterede Gibson en ny idé: SNICKER (Simple Non-Interactive Coinjoin with Keys for Encryption Reused). Nu indsendt som en forslag til Bitcoin-forbedringsforslag (BIP), SNICKER giver mulighed for møntblanding uden synkronisering eller interaktion: Der ville ikke være behov for brugere at koordinere eller være online på samme tid.

CoinTilmeld dig

SNICKER er baseret på den nu veletablerede bitcoin-blandeteknik CoinJoin. Nogle af de mest populære blandingsløsninger, der er tilgængelige i dag, bruger allerede dette trick, herunder Wasabi Wallet (ZeroLink), Samourai Wallet (Whirlpool) og JoinMarket.

Yderligere læsning: Hvad er Bitcoin Mixers?

CoinJoin er i det væsentlige et værktøj til at flette flere transaktioner til en. Så lad os sige, at Alice vil betale Carol en bitcoin, og Bob vil betale Dave en bitcoin. I dette eksempel kan Alice og Bob samarbejde om at skabe en stor transaktion, hvor begge bruger en bitcoin (to i alt), og Carol og Dave hver modtager en bitcoin. En blockchain-spion vil ikke være i stand til at fortælle, hvem af afsenderne, der betalte, hvilken af ​​modtagerne, hvilket gavner privatlivets fred for alle.

I virkeligheden er mængderne af bitcoin, der behandles, ofte privatlivslækage. Hvis Alice ønsker at betale Carol en bitcoin, men Bob vil betale Dave to bitcoin, vil det være indlysende, hvem der betalte hvem ved at matche afsendelses- og modtagelsesbeløbet.

Derfor bruges CoinJoin mere typisk til blanding. I stedet for at betale en anden sender Alice og Bob begge en bitcoin til sig selv. Ved at fusionere dette i en transaktion kan blockchain-spioner ikke fortælle, hvem der fik hvilken mønt tilbage: Mønterne er blandede og beskytter både Alice og Bobs privatliv fremover.

CoinJoin-mixere fungerer i dag, men de har en ulempe: De kræver interaktivitet. En CoinJoin-transaktion er kun gyldig, hvis alle deltagende brugere underskriver hele transaktionen – men for at underskrive hele transaktionen skal de deltagende brugere først have tilføjet alle deres mønter og nye modtageradresser til den. Dette betyder typisk, at de har brug for at overføre transaktionen et par gange og normalt kræver, at de alle er online på samme tid.

Sådanne krav er lidt af en forhindring for mange brugere, hvilket er en af ​​grundene til, at CoinJoin-transaktioner ikke er meget almindelige. Disse krav er, hvad SNICKER får omkring.

SNICKER version 1

Protokollen beskrevet i dette afsnit er den første foreslåede version af SNICKER. Denne version er lidt lettere at forstå end alternative versioner, men det er vigtigt at bemærke, at det faktisk ikke er den bedste version af protokollen eller den version, der sandsynligvis implementeres. (Mere om alternative versioner senere.)

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

Sig, at Alice har en bitcoin, hun vil blande, repræsenteret af en ubrugt transaktionsoutput (UTXO) på blockchain. Den første ting hun gør er at sende denne bitcoin igen … til hendes samme adresse. Det er rigtigt, i denne version af SNICKER genbruger hun en adresse, der overtræder Bitcoins bedste praksis. Men det kommer praktisk: Det markerer UTXO offentligt som (potentielt) tilgængeligt til blanding.

Dette betyder ikke, at Alice forresten ikke kan bruge mønten. Det sidder stadig i hendes tegnebog, klar til at blive brugt når som helst. Det er bare markeret, hvis nogen bekymrer sig.

Bob har også en mønt at blande. (I virkeligheden behøver beløbene ikke være ens på forhånd – Bob skal bare have mindst lige så meget som Alice.) Bob kender ikke Alice, men han ved, at brugere som Alice er derude og markerer deres UTXO’er. som blandbar. Så Bob scanner blockchain for potentielle kampe. Han finder Alice’s UTXO og sandsynligvis nogle flere matchende UTXO’er, inklusive falske positive (ikke alle genbrugte adresser er virkelig tilgængelige til blanding). Men lad os for enkelhedens skyld antage, at Bob kun finder en match: Alice’s UTXO. (Vi vender tilbage til de andre potentielle matches og falske positive senere.)

Med kampen tager Bob nu den offentlige nøgle svarende til den genbrugte adresse. Dette er muligt nøjagtigt, fordi adressen genbruges: Ved at bruge den første gang offentliggjorde Alice den offentlige nøgle på blockchain. (Offentlige nøgler bliver synlige på blockchain, når mønterne er brugt, mens adresser altid er synlige.)

På dette tidspunkt har Bob Alice’s UTXO (fordi hun markerede det) og sin offentlige nøgle (fordi hun brugte fra sin adresse en gang).

Nu bruger Bob Alice’s offentlige nøgle og kombinerer den med sin egen private nøgle (for den mønt, han vil blande) for at skabe en “delt hemmelighed.” Helt bogstaveligt talt det ældste trick i kryptografibogen, denne hemmelighed deles, fordi kun Alice og Bob kan generere den: Bob med sin private nøgle og Alice’s offentlige nøgle og Alice med hendes private nøgle og Bobs offentlige nøgle (svarende til de mønter, han vil have at blande).

Så nu har Bob Alice’s UTXO og hendes offentlige nøgle og en delt hemmelighed (fordi han genererede den med Alice’s offentlige nøgle og sin private nøgle).

Bob bruger den delte hemmelighed på en ny måde. Han bruger det til matematisk at “finjustere” Alices offentlige nøgle. Denne tweaking skaber faktisk en ny offentlig nøgle. Bortset fra … ingen har den private nøgle til det. Endnu.

Interessant, takket være en anden smule kryptomagi, kan den tweaked private nøgle til den tweaked public key også blive opdaget af Alice! Hvis hun tilpasser sin oprindelige private nøgle med den samme delte hemmelighed, svarer den resulterende tweaked private nøgle til den tweakede offentlige nøgle.

Med andre ord kan Bob generere en ny offentlig nøgle og derfor en ny Bitcoin-adresse til Alice, som kun hun kan bruge på. Selv uden at hun vidste lige nu!

Så Bob har nu Alice’s UTXO og hendes offentlige nøgle, en delt hemmelighed og en ny Bitcoin-adresse til Alice (genereret med hendes offentlige nøgle og den delte hemmelighed).

Dette er næsten nok til at oprette en gyldig CoinJoin-transaktion. Specifikt tager Bob Alice’s UTXO og tilføjer UTXO til sin egen mønt, så der er to input. Derefter tilføjer han Alice’s nye adresse og en egen adresse som output (samt gebyrer og nogle andre detaljer, som en skiftadresse for ham selv, hvis det er nødvendigt). Og han underskriver transaktionen.

Det eneste der mangler nu er Alice’s underskrift.

Nå Alice

Det sidste trin – at nå Alice – er faktisk lettere end det lyder, men kræver et sidste trick.

Bob kunne simpelthen offentliggøre den næsten komplette CoinJoin-transaktion et sted, hvor Alice kunne finde. For eksempel på et opslagstavle dedikeret til SNICKER-brugere; helst en på en Tor-skjult tjeneste eller på anden måde garanteret at tilbyde udgivere anonymitet.

Men hvis det gøres i almindelig tekst, ville dette stadig ikke være ideelt. Hvis en spion holder øje med opslagstavlen, kunne de trivielt se, hvilket input der tilhører forslagsstilleren (i dette tilfælde Bob), og hvilket input, der tilhører den, der tager (i dette tilfælde Alice): Den underskrevne er forslagsstillerens. Dette kan være en privatlivslækage i sig selv. Men det ville være endnu værre, hvis Bob fremsætter flere forslag om at blande forskellige mønter. I så fald kan spionen muligvis forbinde alle de forskellige UTXO’er til Bob, for eksempel fordi hans batch af forslag blev sendt til opslagstavlen på samme tid.

Så i stedet krypterer Bob CoinJoin-transaktionen … med Alice’s offentlige nøgle! På den måde er det kun Alice, der kan dekryptere transaktionen, og spionen kan ikke lære noget.

Efter at have sendt den krypterede transaktion på opslagstavlen, har Bob gjort alt hvad han behøver at gøre. Han kan forsvinde online, hvis han ønsker det.

Alice’s Turn

Da CoinJoin-transaktionen nu er krypteret, introducerer dette en sidste, lille komplikation. Mens Alice ved, hvor hun skal kigge efter pakken – på SNICKER-opslagstavlen – ved hun ikke, hvad hun skal se efter: Alle CoinJoin-transaktioner på opslagstavlen ligner krypterede klatter.

Der er kun én udvej. Alice skal prøve at dekryptere alle pakker med sin private nøgle og håber, at en af ​​dem bliver til noget nyttigt.

Men når Bobs krypterede blob bliver til en CoinJoin-transaktion, har Alice alt hvad hun har brug for for at fuldføre blandingen. Hun bruger sin private nøgle og Bobs offentlige nøgle (som er inkluderet i hans input) til at generere den delte hemmelighed, som hun igen kan bruge til at oprette sin nye, tweaked private nøgle. Efter at have kontrolleret, at den nye nøgle svarer til hendes nye modtagelsesadresse i output, underskriver hun og sender transaktionen til Bitcoin-netværket.

Alice og Bob blandede deres mønter, selvom de aldrig interagerede, og de behøvede ikke engang at være online på samme tid.

Og mens processen måske lyder lidt besværlig i tekst, skal du huske på, at det hele kan abstraheres af software, oversættes til et par knapper på en bærbar eller telefonskærm eller endda automatiseres fuldstændigt..

SNICKER version 2

SNICKER, som hidtil forklaret, er den første version af forslaget. Allerede har Gibson foreslået en anden version, og andre variationer er også på bordet.

Den anden SNICKER-version er ens, men undgår behovet for genbrug af adresser – på bekostning af lidt mere kompleksitet.

I denne anden version får Bob ikke Alice’s offentlige nøgle fra en genbrugt adresse. I stedet tager Bob den offentlige nøgle fra et input fra den samme transaktion, der oprettede Alice’s UTXO. Bob antager, at mindst et af inputene i den transaktion blev oprettet af Alice selv, og at hun stadig har de private nøgler til disse.

Bob antager denne antagelse, fordi Alice’s UTXO denne gang er endnu tydeligere markeret som tilgængelig til blanding, og det ville kun være så tydeligt markeret, hvis Alice styrer de private nøgler, der svarer til input. SNICKER BIP specificerer ikke, hvordan den oprindelige markering ville blive udført, men antyder, at visse tegnebøger (som JoinMarket-tegnebøger) umiskendeligt afslører sådanne oplysninger. Alternativt kunne Alice bare sende en besked på opslagstavlen, der annoncerede for sin UTXO.

Men endnu bedre: Når SNICKER begynder at blive brugt, skal det være meget lettere at finde nye match. Dette skyldes, at SNICKER-transaktioner i sig selv ville være trivielle at genkende, og eksisterende SNICKER-brugere sandsynligvis vil blande deres mønter igen. Med andre ord, efter en indledende bootstrapping-fase, ville ikke-blandede mønter blive blandet med tidligere blandede mønter, hvilket resulterede i flere blandede mønter, som igen kunne anvendes til mere blanding.

Udfordringer og muligheder

Som nævnt ovenfor er SNICKER BIP stadig kun et udkast og genstand for gennemgang og potentiel forbedring. (Allerede har ideen udviklet sig i nogle aspekter, siden den først blev foreslået offentligt af Gibson i en blogindlæg.) Forslaget er nu indsendt til at blive en BIP, så det kan standardiseres og, nede, gøres kompatibelt mellem forskellige tegnebøger.

SNICKER står også over for nogle åbne spørgsmål og udfordringer, selvom ingen af ​​disse synes uoverstigelige. Disse inkluderer for eksempel hvilke UTXO’er der skal vælges som matches, og især hvordan man begrænser antallet af falske positive. Udover genbrugte adresser kan potentielle matches for eksempel filtreres for beløb, alder af UTXO eller bestemte typer af tegnebøger, der bruges.

Men som antydet tidligere i denne artikel, selvom der er flere matches (inklusive falske positive), er dette sandsynligvis kun et lille problem. Tilbudsgivere (“Bob”) kunne simpelthen oprette kandidattransaktioner for dem alle. Selvom disse forslag er i konflikt (fordi Bob bruger sin samme UTXO for alle), betyder det simpelthen, at den første taker (den første “Alice”), der reagerer, får mixet – andre potentielle deltagere finder, at de var for sent, men ingen skade ville være færdig. For falske positive er der heller ikke sket nogen reel skade, Bobs tilbud vil bare sidde på opslagstavlen, ignoreret for evigt (eller indtil det er fjernet).

Hvad der dog kan være et særligt vigtigt problem, er spam. Fordi opslagstavlen ville være vært for krypterede dataopslag, ville det være umuligt at filtrere “falske” forslag ud: tilfældig pladder sendt af en angriber for at forstyrre SNICKER-protokollen. Gibson foreslog nogle løsninger på dette problem i sit udkast til BIP, men disse ville præsentere nye afvejninger, som en pris for at sende et forslag.

På bagsiden tilbyder SNICKER også nogle fordele, der hidtil er blevet udeladt af forklaringen for enkelheds skyld. En sådan fordel er, at tilbydere) kan tilføje nogle midler til en tagers produktion og tilføje noget økonomisk incitament til at acceptere blandingen. Det kan også være muligt at gennemføre SNICKER-blandinger med mere end to brugere på samme tid – selvom dette vil gøre tricket meget mere komplekst.

Og nøjagtigt fordi protokollen er ikke-interaktiv, mener Gibson, at SNICKER ville være relativt let at implementere i tegnebøger sammenlignet med nogle andre fortrolighedsteknologier, som JoinMarket. Indtil videre har Electrum-tegnebogen vist interesse for at vedtage forslaget – selvom den faktiske implementering af det stadig kan være langt væk.

For mere information og baggrund om SNICKER, se udkast til BIP, følg bitcoin-dev-postlisten diskussion eller læs Gibsons (lidt forældet) blogindlæg på forslaget.