SNICKER voi olla seuraava työkalu Bitcoinin kasvavassa tietosuojatyökalupaketissa.

Vaikka Satoshi Nakamoton valkoinen paperi viittaa siihen, että yksityisyys oli Bitcoin-protokollan suunnittelutavoitteena, blockchain-analyysi voi usein rikkoa käyttäjien yksityisyyttä tänään. Tämä on ongelma. Bitcoinin käyttäjät eivät välttämättä halua maailman tietävän, mihin he käyttävät rahaa, mitä ansaitsevat tai kuinka paljon omistavat, kun taas yritykset eivät halua vuotaa tapahtumien yksityiskohtia kilpailijoille – luetellakseen muutamia esimerkkejä.

Onneksi Bitcoin-kehittäjät ja tutkijat keksivät yhä enemmän ratkaisuja käyttäjille yksityisyyden palauttamiseksi. Yksi näistä Bitcoin-yksityisyyden puolustajista on Adam “vahavauva” Gibson, joka tunnetaan ehkä parhaiten panoksestaan ​​JoinMarket-protokollaan, jonka avulla käyttäjät voivat sekoittaa kolikoitaan – ja tarjoaa taloudellisen palkkion osallistumisesta tällaisiin sekoituksiin..

Viime aikoina Gibson esitteli uuden idean: SNICKER (Simple Non-Interactive Coinjoin with Keys for Encryption Reused). Lähetetty nyt a luonnos Bitcoinin parannusehdotuksesta (BIP), SNICKER sallisi kolikoiden sekoittamisen ilman synkronointia tai vuorovaikutusta: Käyttäjien ei tarvitse olla koordinoivia tai olla online-tilassa samanaikaisesti.

KolikkoLiity

SNICKER perustuu nyt hyvin vakiintuneeseen bitcoin-sekoitustekniikkaan CoinJoin. Jotkut nykypäivän suosituimmista sekoitusratkaisuista käyttävät jo tätä temppua, kuten Wasabi Wallet (ZeroLink), Samourai Wallet (Whirlpool) ja JoinMarket.

Lisätietoja: Mitä ovat Bitcoin-sekoittimet?

CoinJoin on pohjimmiltaan työkalu yhdistää useita tapahtumia yhdeksi. Joten sanotaan, että Alice haluaa maksaa Carolille yhden bitcoinin ja Bob haluaa maksaa Davelle yhden bitcoinin. Tässä esimerkissä Alice ja Bob voivat yhteistyössä luoda yhden suuren tapahtuman, jossa molemmat käyttävät yhden bitcoinin (kaksi yhteensä), ja Carol ja Dave saavat molemmat yhden bitcoinin. Blockchain-vakooja ei pysty kertomaan, kuka lähettäjistä maksoi kumpi vastaanottajista hyödyttäen kaikkien yksityisyyttä.

Todellisuudessa transaktioiden määrät ovat usein yksityisyyden vuotoja. Jos Alice haluaa maksaa Carolille yhden bitcoinin, mutta Bob haluaa maksaa Davelle kaksi bitcoinia, on ilmeistä kuka maksoi kuka sovittamalla lähettävät ja vastaanottavat summat.

Siksi CoinJoinia käytetään tyypillisesti sekoittamiseen. Sen sijaan, että Alice ja Bob maksaisivat toiselle, molemmat lähettävät itselleen yhden bitcoinin. Yhdistämällä tämä yhdessä tapahtumassa, blockchain-vakoojat eivät voi kertoa kuka sai minkä kolikon takaisin: Kolikot ovat sekoitettuja ja suojaavat sekä Alice- että Bob-yksityisyyttä eteenpäin.

CoinJoin-sekoittimet toimivat tänään, mutta niillä on haittapuoli: Ne vaativat vuorovaikutteisuutta. CoinJoin-tapahtuma on voimassa vain, jos kaikki osallistuvat käyttäjät allekirjoittavat koko tapahtuman – mutta allekirjoittaakseen koko tapahtuman osallistuvien käyttäjien on ensin lisättävä siihen kaikki kolikot ja uudet vastaanotto-osoitteet. Tämä tarkoittaa tyypillisesti sitä, että heidän on läpäistävä tapahtuma muutaman kerran, ja yleensä edellyttää, että ne kaikki ovat verkossa samanaikaisesti.

Tällaiset vaatimukset ovat hieman este monille käyttäjille, mikä on yksi syy siihen, että CoinJoin-tapahtumat eivät ole kovin yleisiä. SNICKER kiertää näitä vaatimuksia.

SNICKER-versio 1

Tässä osiossa kuvattu protokolla on SNICKERin ensimmäinen ehdotettu versio. Tämä versio on hieman helpommin ymmärrettävissä kuin vaihtoehtoiset versiot, mutta on tärkeää huomata, että se ei todellakaan ole protokollan paras versio tai todennäköisesti toteutettava versio. (Lisää vaihtoehtoisista versioista myöhemmin.)

Tämän sanottuasi SNICKER-versio 1 toimii seuraavasti:

Sano, että Alicella on yksi bitcoin, jonka hän haluaa sekoittaa, jota edustaa käyttämätön tapahtumalähtö (UTXO) lohkoketjussa. Ensimmäinen asia, jonka hän tekee, on lähettää tämä bitcoin uudelleen … samaan osoitteeseen. Aivan oikein, tässä SNICKER-versiossa hän käyttää uudelleen osoitetta, mikä rikkoo Bitcoinin parhaita käytäntöjä. Mutta se on kätevä: Se merkitsee UTXO: n julkisesti (mahdollisesti) sekoitettavaksi.

Tämä ei tarkoita, että Alice ei muuten voi käyttää kolikkoa. Se istuu edelleen hänen lompakossaan, valmis kulutettavaksi milloin tahansa. Se on vain merkitty, jos joku välittää.

Bobilla on myös yksi kolikko sekoitettavaksi. (Todellisuudessa määrien ei tarvitse olla yhtä suuret etukäteen – Bobilla on oltava vähintään vähintään yhtä paljon kuin Alice.) Bob ei tunne Aliceä, mutta hän tietää, että Alicen kaltaiset käyttäjät ovat siellä, merkitsemällä UTXO: t yhtä sekoitettavissa. Joten Bob etsii estoketjua mahdollisten otteluiden varalta. Hän löytää Alicen UTXO: n ja luultavasti lisää yhteensopivia UTXO: ita, mukaan lukien vääriä positiivisia tietoja (kaikkia uudelleen käytettyjä osoitteita ei ole tosiasiallisesti mahdollista sekoittaa). Oletetaan nyt, että yksinkertaisuuden vuoksi oletetaan, että Bob löytää vain yhden ottelun: Alice’s UTXO. (Palataan myöhemmin muihin potentiaalisiin otteluihin ja vääriä positiivisia tuloksia.)

Ottelun myötä Bob ottaa nyt uudelleen käytetyn osoitteen vastaavan julkisen avaimen. Tämä on mahdollista juuri siksi, että osoitetta käytetään uudelleen: Alice julkaisi kyseisen julkisen avaimen blockchainissa viettämällä sen ensimmäisen kerran. (Julkiset avaimet tulevat näkyviin lohkoketjussa, kun kolikot on käytetty, kun taas osoitteet ovat aina näkyvissä.)

Tässä vaiheessa Bobilla on Alicen UTXO (koska hän merkitsi sen) ja julkinen avain (koska hän käytti kerran osoitteestaan).

Nyt Bob käyttää Alicen julkista avainta ja yhdistää sen omaan yksityiseen avaimeensa (kolikolle, jonka hän haluaa sekoittaa) luodakseen “jaetun salaisuuden”. Kirjaimellisesti vanhin temppu salauskirjassa, tämä salaisuus on jaettu, koska vain Alice ja Bob voivat luoda sen: Bob yksityisellä avaimellaan ja Alicen julkisella avaimella sekä Alice yksityisellä avaimellaan ja Bobin julkisella avaimella (vastaa haluamiaan kolikoita) sekoittaa).

Joten nyt Bobilla on Alicen UTXO ja hänen julkinen avain sekä jaettu salaisuus (koska hän loi sen Alicen julkisella avaimella ja yksityisellä avaimellaan).

Bob käyttää jaettua salaisuutta uudella tavalla. Hän käyttää sitä matemaattisesti “säätämään” Alicen julkista avainta. Tämä säätäminen luo todella uuden julkisen avaimen. Paitsi… kenellekään ei ole yksityistä avainta sitä varten. Vielä.

Mielenkiintoista on, että toisen salausmaagian ansiosta myös Alice voi löytää mukautetun yksityisen avaimen viritetylle julkiselle avaimelle! Jos hän muuttaisi alkuperäistä yksityistä avainta samalla jaetulla salaisuudella, tuloksena oleva muutettu yksityinen avain vastaisi viritettyä julkista avainta.

Toisin sanoen, Bob voi luoda uuden julkisen avaimen ja siten uuden Bitcoin-osoitteen Alicelle, josta vain hän voi käyttää rahaa. Jopa ilman, että hän tiesi juuri nyt!

Joten, Bobilla on nyt Alicen UTXO ja hänen julkinen avain, jaettu salaisuus ja uusi Bitcoin-osoite Alicelle (luotu hänen julkisella avaimellaan ja jaetulla salaisuudellaan).

Tämä on melkein tarpeeksi kelvollisen CoinJoin-tapahtuman luomiseksi. Erityisesti Bob ottaa Alicen UTXO: n ja lisää UTXOn omalle kolikolleen, joten syötteitä on kaksi. Sitten hän lisää Alicen uuden osoitteen ja oman osoitteen tuotoksiksi (samoin kuin palkkiot ja muut yksityiskohdat, kuten tarvittaessa muutososoitteen itselleen). Ja hän allekirjoittaa kaupan.

Ainoa asia, joka nyt puuttuu, on Alicen allekirjoitus.

Tavoittaa Alice

Viimeinen vaihe – tavoittaa Alice – on todella helpompaa kuin miltä se kuulostaa, mutta vaatii viimeisen temppun.

Bob voisi yksinkertaisesti julkaista melkein täydellisen CoinJoin-tapahtuman jonnekin Alice löytää. Esimerkiksi SNICKER-käyttäjille omistetulla ilmoitustaululla; mieluiten Torin piilotetussa palvelussa tai muuten taattu tarjoamaan kustantajien nimettömyys.

Jos se kuitenkin tehdään pelkkänä tekstinä, se ei silti olisi ihanteellinen. Jos vakooja seuraa ilmoitustaulua, he voisivat triviaalisesti nähdä, mikä panos kuuluu ehdokkaalle (tässä tapauksessa Bob) ja mikä syötteen tekijälle (tässä tapauksessa Alice): Allekirjoitettu on ehdotuksen tekijä. Tämä voi olla yksityisyyden vuoto sinänsä. Mutta olisi vielä pahempaa, jos Bob tekee enemmän ehdotuksia erilaisten kolikoiden sekoittamiseksi. Tällöin vakooja voi pystyä yhdistämään kaikki erilaiset UTXO: t esimerkiksi Bobiin, koska hänen ehdotuseränsä lähetettiin ilmoitustaululle samaan aikaan.

Joten sen sijaan Bob salaa CoinJoin-tapahtuman … Alicen julkisella avaimella! Tällä tavoin vain Alice voi purkaa tapahtuman ja vakooja ei voi oppia mitään.

Lähetettyään salatun tapahtuman ilmoitustaululle, Bob on tehnyt kaiken tarvittavan. Hän voi kadota verkossa, jos niin haluaa.

Alice’s Turn

Koska CoinJoin-tapahtuma on nyt salattu, tämä aiheuttaa viimeisen, pienen komplikaation. Vaikka Alice tietää, mistä pakettia voi etsiä – SNICKER-ilmoitustaululla – hän ei tiedä mitä etsiä: Kaikki ilmoitustaululla olevat CoinJoin-tapahtumat näyttävät salatuilta läiskiltä.

On vain yksi tie. Alicen on yritettävä purkaa kaikki paketit salauksella yksityisellä avaimellaan, toivoen, että yksi niistä muuttuu hyödylliseksi.

Mutta kun Bobin salattu möykky muuttuu CoinJoin-tapahtumaksi, Alicella on kaikki mitä tarvitsee sekoituksen loppuun saattamiseksi. Hän käyttää yksityistä avainta ja Bobin julkista avainta (joka sisältyy hänen syötteeseensä) jaetun salaisuuden luomiseen, jota hän puolestaan ​​voi käyttää uuden, mukautetun yksityisen avaimen luomiseen. Tarkistettuaan, että uusi avain vastaa hänen uutta vastaanotto-osoitetta lähdössä, hän allekirjoittaa ja lähettää tapahtuman Bitcoin-verkkoon.

Alice ja Bob sekoittivat kolikoitaan, vaikka he eivät olleet koskaan olleet vuorovaikutuksessa, eikä heidän tarvinnut edes olla verkossa samanaikaisesti.

Ja vaikka prosessi saattaa kuulostaa jonkin verran vaivalliselta tekstissä, pidä mielessä, että kaikki se voidaan poistaa ohjelmistolla, kääntää muutamaksi kannettavan tietokoneen tai puhelimen näytön painikkeeksi tai jopa automatisoida kokonaan.

SNICKER-versio 2

SNICKER on toistaiseksi selitetty ehdotuksen ensimmäinen versio. Jo Gibson on ehdottanut toista versiota, ja myös muut muunnelmat ovat pöydällä.

Toinen SNICKER-versio on samanlainen, mutta välttää osoitteen uudelleenkäytön tarpeen – hieman monimutkaisemman kustannuksella.

Tässä toisessa versiossa Bob ei saa Alicen julkista avainta uudelleenkäytetystä osoitteesta. Sen sijaan Bob ottaa julkisen avaimen saman tapahtuman syötteestä, joka loi Alicen UTXO: n. Bob olettaa, että ainakin yksi kyseisen tapahtuman syötteistä on Alice itse luonut ja että hänellä on edelleen yksityiset avaimet näille.

Bob tekee tämän oletuksen, koska tällä kertaa Alicen UTXO on vielä selkeämmin merkitty sekoitettavaksi, ja se olisi niin selvästi merkitty vain, jos Alice hallitsee tuloja vastaavia yksityisiä avaimia. SNICKER BIP ei täsmennä, miten alkuperäinen merkintä tehdään, mutta ehdottaa, että tietyt lompakot (kuten JoinMarket-lompakot) paljastavat tällaisen tiedon erehtymättä. Vaihtoehtoisesti Alice voisi yksinkertaisesti lähettää ilmoitustaululle UTXO: ta mainostavan viestin.

Mutta vielä parempi: Kun SNICKERiä käytetään, uusien otteluiden löytämisen pitäisi olla paljon helpompaa. Tämä johtuu siitä, että SNICKER-tapahtumia itsessään olisi triviaali tunnistaa, ja nykyiset SNICKER-käyttäjät haluavat todennäköisesti sekoittaa kolikoitaan uudelleen. Toisin sanoen alkuvaiheen käynnistysvaiheen jälkeen sekoittamattomat kolikot sekoitettaisiin aiemmin sekoitettuihin kolikoihin, mikä johtaisi enemmän sekakolikoihin, joita puolestaan ​​voitaisiin hyödyntää sekoittamisen lisäämiseksi.

Haasteet ja mahdollisuudet

Kuten edellä mainittiin, SNICKER BIP on edelleen vain luonnos, jota voidaan tarkistaa ja mahdollisesti parantaa. (Ajatus on jo kehittynyt joissakin suhteissa siitä lähtien, kun Gibson ehdotti sitä ensimmäisen kerran julkisesti julkaisussa blogipostaus.) Ehdotus on nyt toimitettu rajatarkastusasemaksi, jotta se voidaan standardoida ja tehdä linjasta yhteensopiva eri lompakoiden kanssa.

SNICKERilla on myös avoimia kysymyksiä ja haasteita, vaikka mikään näistä ei vaikuta ylitsepääsemättömältä. Näitä ovat esimerkiksi se, mitkä UTXO: t tulisi valita vastaavuuksiksi, ja erityisesti kuinka vääräpositiivisten lukumäärää voidaan rajoittaa. Uudelleenkäytettyjen osoitteiden lisäksi potentiaaliset vastaavuudet voidaan suodattaa esimerkiksi summien, UTXO: n iän tai käytettyjen lompakotyyppien mukaan.

Mutta kuten tässä artikkelissa aiemmin viitattiin, tämä on todennäköisesti vain pieni ongelma, vaikka otteluita olisi useita (mukaan lukien vääriä positiivisia tuloksia). Tarjoajat (“Bob”) voivat yksinkertaisesti luoda ehdokasliiketoimia kaikille. Vaikka nämä ehdotukset olisivatkin ristiriidassa (koska Bob käyttää samaa UTXO: ta kaikille), se tarkoittaa yksinkertaisesti sitä, että ensimmäinen vastaaja (ensimmäinen “Alice”), joka vastaa, saa sekoituksen – muut potentiaaliset ottajat huomaavat, että he olivat liian myöhässä, mutta ei haittaa olisi tehty. Vääristä positiivisista tiedoista ei myöskään aiheudu todellista vahinkoa, Bobin tarjous istuu vain ilmoitustaululle, ohitettuna ikuisesti (tai kunnes se poistetaan).

Mikä voi olla erityisen merkittävä ongelma, on roskaposti. Koska ilmoitustaulu isännöi salattuja tietoja, on mahdotonta suodattaa väärennettyjä ehdotuksia: hyökkääjän lähettämä satunnainen katkera SNICKER-protokollan häiritsemiseksi. Gibson ehdotti joitain ratkaisuja tähän ongelmaan BIP-luonnoksessaan, mutta ne tuottavat uusia kompromisseja, kuten kustannukset ehdotuksen julkaisemisesta..

Kääntöpuolella SNICKER tarjoaa myös joitain etuja, jotka on toistaiseksi jätetty selityksestä yksinkertaisuuden vuoksi. Yksi tällainen etu on, että tarjoajat) voivat lisätä varoja ostajan tuotokseen lisäämällä taloudellista kannustinta hyväksyä sekoitus. Voi olla myös mahdollista suorittaa SNICKER-sekoituksia useamman kuin kahden käyttäjän kanssa samanaikaisesti – vaikka tämä tekee temppusta paljon monimutkaisemman.

Ja juuri siksi, että protokolla ei ole vuorovaikutteinen, Gibson uskoo, että SNICKER olisi suhteellisen helppo toteuttaa lompakkoihin verrattuna joihinkin muihin tietosuojatekniikoihin, kuten JoinMarket. Toistaiseksi Electrumin lompakko on osoittanut kiinnostusta ehdotuksen hyväksymiseen – vaikka sen varsinainen toteuttaminen voi olla vielä kaukana.

Lisätietoja ja taustaa SNICKERistä, katso luonnos rajatarkastusasemaksi, noudata bitcoin-dev-postituslistaa keskustelu tai lukea Gibsonin (hieman vanhentunut) blogipostaus ehdotuksesta.