Condividi questo articolo

Il modello di sicurezza di Bitcoin: un'analisi approfondita

CoinDesk analizza nel dettaglio le funzionalità di sicurezza offerte e T offerte da Bitcoin.

Quando discutere i meccanismi di consenso per diverse criptovalute, ONE problema che spesso causa discussioni è la mancanza di comprensione (e definizione) del modello di sicurezza che forniscono per i dati storici nel registro. Mentre ogni modello di consenso mira a prevenire vari attacchi teorici, è importante comprendere gli obiettivi del modello.

Ogni modello di sicurezza ha due parti principali: ipotesi e garanzie. Se le ipotesi utilizzate come input sono vere, allora lo dovrebbero essere anche le garanzie che vengono emesse dal modello.

La storia continua sotto
Non perderti un'altra storia.Iscriviti alla Newsletter Crypto Daybook Americas oggi. Vedi Tutte le Newsletter

Analizziamo più approfonditamente il modello di sicurezza che sembra essere offerto agli utenti Bitcoin che gestiscono un nodo completo.

Alla ricerca della verità

“ONE dei punti di forza del bitcoin, il più importante Opinioni me, è il basso livello di fiducia di cui hai bisogno negli altri.” –Pietro Wuille

L'obiettivo dei registri distribuiti è quello di fornire una cronologia ordinata degli Eventi, perché nei sistemi distribuiti T ci si può semplicemente fidare di una marca temporale.

Quando un nuovo partecipante si unisce a una rete basata su blockchain, scarica tutti i blocchi disponibili e prende in considerazione ogni serie valida di blocchi che vede, a partire da un blocco genesi codificato in modo rigido.

ONE delle più grandi ipotesi fatte dal modello di sicurezza di bitcoin è che la maggior parte dei minatori siano onesti, ovvero che lavorino per proteggere la blockchain piuttosto che tentare di indebolirla. In pratica, questo è stato vero per tutta la storia di bitcoin a causa degli incentivi dei minatori, sebbene qualche domandase continuerà ad essere vero in futuro.

Dato questo presupposto, gli operatori di nodi completi possono essere completamente sicuri di diversi fatti:

  • Nessuno ha aumentato l'offerta di moneta, a parte i minatori, e solo secondo un programma ben definito.
  • Nessuno ha mai speso soldi senza avere le giuste chiavi private.
  • Nessuno ha mai speso due volte la stessa cifra.

Gli operatori full node possono essere ragionevolmente certi di diverse altre cose. C'è una forte garanzia che:

  • Ogni blocco nella catena è stato creato entro circa due ore dal timestamp del blocco.
  • Stanno sincronizzando la “vera” cronologia della blockchain.

A un livello più tecnico, ciò richiede una moltitudine di controlli:

Sicurezza termodinamica

Una volta che una transazione è confermata in un blocco, T può essere annullata senza che qualcuno spenda una minima quantità di energia per riscrivere la catena.

Finché nessun aggressore detiene più del 50% della potenza di calcolo della rete e i nodi onesti possono comunicare rapidamente, la probabilità che una transazione venga annullata diminuisce esponenzialmente con il numero di conferme ricevute. Ci sono altri attacchi,come l'attività mineraria egoistica, che possono ridurre questa richiesta di energia, anche se sembrano difficili da realizzare.

Fonte: "Il modello di sicurezza di Bitcoin rivisitato" di Yonatan Sompolinsky1 e Aviv Zohar
Fonte: "Il modello di sicurezza di Bitcoin rivisitato" di Yonatan Sompolinsky1 e Aviv Zohar

Considerando l'attuale lavoro cumulativo svolto dai minatori Bitcoin , ci vorrebbero circa 1026 hash per costruire una blockchain alternativa dalla genesi con una maggiore prova cumulativa del lavoro che i nodi completi considererebbero come la "vera" catena.

lavoro-sempre

Per fare qualche calcolo sui costi di un attacco del genere:

Un Antminer S9 funziona a 0,1 Joule per GH (109 hash)

1026 hash * 0,1 J / 109 hash = 1015 joule

1015 joule = 2.777.777.778 kWh * $0,10 kWh/ora = $277.777.778 di elettricità per riscrivere l'intera blockchain

Mentre al momento in cui scrivo un singolo blocco deve raggiungere un obiettivo di difficoltà di 253.618.246.641, il che richiederebbe approssimativamente:

253.618.246.641 * 248 / 65535 = 1,09 * 1021 hash

1,09 * 1021 hash * 0,1 J / 109 hash = 1,09 * 1011 joule

1,09 * 1011 joule = 30.278 kWh * $ 0,10 kWh/ora = $ 3.028 di elettricità per blocco

Ecco perché possiamo affermare che il Bitcoin è dimostrabilmente sicuro dal punto di vista termodinamico.

Ci sono alcune variabili che puoi modificare nel calcolo di cui sopra per ridurre i costi, ma possiamo essere certi che saranno necessari molti milioni di dollari di elettricità solo per riscrivere l'intera blockchain. Tuttavia, un aggressore con così tanta potenza di hash sarebbe nella peggiore delle ipotesi in grado di invertire le transazioni fino al 2014: approfondiremo il motivo a breve.

Si noti inoltre che questo T tiene conto dei costi necessari per ottenere e gestire attrezzature minerarie sufficienti per portare a termine un simile attacco.

Resistenza della Sibilla

Poiché il protocollo Bitcoin considera la vera catena ONE con la prova di lavoro cumulativa più elevata (non la catena più lunga, come spesso erroneamente si afferma), il risultato è che un nuovo peer che si unisce alla rete deve connettersi solo a un singolo peer onesto per trovare la vera catena.

Questo è anche noto come "resistenza Sybil", il che significa che non è possibile per qualcuno lanciare un attacco contro un nodo creando molti peer disonesti che gli forniscono informazioni false.

Nodi
Nodi

Qui è raffigurato uno scenario NEAR peggiore in cui il tuo nodo è stato attaccato massicciamente da Sybil ma ha ancora una singola connessione con un nodo onesto che è connesso alla vera rete Bitcoin . Finché un singolo peer onesto sta passando i veri dati della blockchain al tuo nodo completo, sarà abbastanza chiaro che tutti gli aggressori Sybil stanno tentando di ingannarti e il tuo nodo li ignorerà.

Consenso in tempo reale

Il protocollo Bitcoin crea una serie di altri attributi interessanti per quanto riguarda il mantenimento del consenso a livello di rete una volta che il nodo si trova all'estremità della blockchain.

Gli autori di “Prospettive di ricerca e sfide per Bitcoin e criptovalute" notare le seguenti proprietà che sono importanti per la stabilità di una Criptovaluta:

Consenso finaleIn qualsiasi momento, tutti i nodi conformi concordano su un prefisso di ciò che diventerà l'eventuale blockchain "vera".

Convergenza esponenziale. La probabilità di una biforcazione di profondità n è O(2−n). Ciò fornisce agli utenti un'elevata sicurezza che una semplice regola "k conferme" garantirà che le loro transazioni siano regolate in modo permanente.

VitalitàContinueranno ad essere aggiunti nuovi blocchi e le transazioni valide con commissioni appropriate saranno incluse nella blockchain entro un lasso di tempo ragionevole.

CorrettezzaTutti i blocchi nella catena con la prova di lavoro cumulativa più elevata includeranno solo transazioni valide.

EquitàUn minatore con X% della potenza di calcolo totale della rete estrarrà circa X% dei blocchi.

Gli autori dell'articolo sottolineano che il Bitcoin sembra avere queste proprietà, almeno supponendo che la maggior parte dei minatori rimanga onesta, che è ciò che le ricompense a blocchi, insieme alla prova del lavoro, cercano di incentivare.

Esistono molti altri algoritmi che possono essere utilizzati per mantenere il consenso nei sistemi distribuiti, ad esempio:

  • Prova di partecipazione
  • Prova dell'età della moneta
  • Prova di deposito
  • Prova di bruciatura
  • Prova di attività
  • Prova del tempo trascorso
  • Consenso federato
  • Tolleranza pratica ai guasti bizantini

Questi creano diversi modelli di sicurezza: la differenza più ovvia rispetto alla prova del lavoro è che il consenso di ciascuno dei sistemi alternativi è guidato a scapito delle risorse interne (monete o reputazione) piuttosto che delle risorse esterne (elettricità). Ciò crea un insieme molto diverso di incentivi per (e fiducia in) i validatori sulla rete che cambia drasticamente il modello di sicurezza.

Incomprensioni sul modello di sicurezza

Un presupposto errato comune è che esista un modello di sicurezza ben definito per Bitcoin.

In realtà, il protocollo Bitcoin è stato e viene costruito senza una specifica o un modello di sicurezza formalmente definiti. Il meglio che possiamo fare è studiare gli incentivi e il comportamento degli attori all'interno del sistema per comprenderlo meglio e tentare di descriverlo.

Detto questo, ci sono alcune proprietà del protocollo Bitcoin che spesso vengono analizzate in modo errato.

Alcune blockchain hanno sofferto così tanto di attacchi che gli sviluppatori aggiungonoposti di blocco firmati trasmessi centralmentenel software del nodo, dicendo essenzialmente che "il blocco X è stato convalidato dagli sviluppatori come appartenente alla corretta catena storica". Questo è un punto di estrema centralizzazione.

Vale la pena notare che il Bitcoin ha 13 punti di controllo codificati, ma non modificano il modello di sicurezza nel modo in cui lo fanno i checkpoint trasmessi. L'ultimo checkpoint è stato aggiunto aVersione di Bitcoin CORE 0.9.3e si trova al blocco 295000, creato il 9 aprile 2014. Questo blocco aveva una difficoltà di 6.119.726.089 che richiederebbe approssimativamente:

6.119.726.089 * 248 / 65535 = 2,62 * 1019 hash

2,62 * 1019 hash * 0,1 J / 109 hash = 2,62 * 109 joule

2,62 * 109 joule = 728 kWh * $ 0,10 kWh/ora = $ 73 di elettricità da generare

Pertanto, se un aggressore Sybil circondasse completamente un nuovo nodo che si stava sincronizzando da zero, potrebbe creare alcune blockchain brevi a basse altezze a un costo quasi nullo, ma solo fino ai vari blocchi sottoposti a checkpoint.

Se avesse partizionato un nodo fuori dalla rete che si era sincronizzato oltre il blocco 295.000, sarebbe stato in grado di iniziare a alimentare blocchi falsi al costo di $ 73 per blocco, almeno fino a quando non avesse raggiunto un riaggiustamento della difficoltà. Tuttavia, più avanti il nodo vittima si era sincronizzato, maggiore sarebbe stato il costo per l'attaccante nel creare una catena con più lavoro cumulativo.

Entrambi Greg Maxwell E Pietro Wuille hanno dichiarato che sperano di rimuovere completamente i checkpoint un giorno. Il responsabile della manutenzione Bitcoin CORE , Wladimir van der Laan, ha osservato che i checkpoint sono un fonte costante di confusioneper le persone che cercano di comprendere il modello di sicurezza di Bitcoin.

Si potrebbe sostenere che questo significa che un nodo completo "si fida" degli sviluppatori CORE per quanto riguarda la validità della cronologia della blockchain fino al 9 aprile 2014, ma il nodo controlla ancora gli hash Merkle nell'intestazione di ogni blocco, il che significa che la solidità della cronologia delle transazioni è ancora garantita dalla proof of work. Questi vecchi checkpoint consentire un aumento delle prestazioni(saltando la verifica della firma) quando si sincronizza inizialmente la blockchain storica, sebbene l'introduzione di libsecp256k1 abbia resodifferenza di prestazioni meno significativa.

I posti di blocco rimangono

in atto per tre scopi:

  • Per impedire ai nodi diavere la memoria riempitacon intestazioni di blocco proof-of-work valide ma basse
  • Saltare le firme nei blocchi precedenti (miglioramento delle prestazioni)
  • Per stimare l'avanzamento della sincronizzazione

Mentre questo articolo veniva scritto Greg Maxwellproposto di sostituire i posti di bloccocon uncontrollo del lavoro cumulativoinvece. Una volta che un nodo ha una catena che contiene più di 5,4 * 1024 hash eseguiti, le catene con meno lavoro cumulativo verrebbero rifiutate. Ciò coincide con la quantità di lavoro eseguita fino a circa il blocco 320.000 a settembre 2014, punto in cui i singoli blocchi avevano una difficoltà di ~27.000.000.000.

difficoltà-3

L'estrazione di blocchi con una difficoltà di 27.000.000.000 richiederebbe circa

27.000.000.000 * 248 / 65535 = 1,16 * 1020 hash

1,16 * 1020 hash * 0,1 J / 109 hash = 1,16 * 1010 joule

1,16 * 1010 joule = 3.222 kWh * $ 0,10 kWh/ora = $ 322 di elettricità per blocco

Pertanto, con questa modifica proposta, se un aggressore Sybil circondasse completamente un nuovo nodo che si stava sincronizzando da zero, sarebbe in grado di iniziare ad alimentare falsi blocchi a partire da qualsiasi blocco dopo la genesi, praticamente senza alcun costo. Se un aggressore Sybil circondasse completamente un nodo che si è sincronizzato oltre il blocco ~320.000, potrebbe iniziare ad alimentare una falsa catena da quel punto al costo di $ 322 per blocco.

In breve, entrambi i controlli per proteggere la sincronizzazione iniziale di un nodo sono relativamente poco costosi da attaccare se un'entità riesce a ottenere il controllo completo della connessione Internet del nodo; in caso T, il nodo ignorerà facilmente i blocchi dell'aggressore.

In una nota correlata, ogni sistema blockchain ha il suoblocco genesi codificatonel software del nodo. Si potrebbe sostenere che esista un contratto sociale per la "cronologia condivisa" che è il registro: una volta che un blocco è abbastanza vecchio, c'è un accordo tra tutti sulla rete che non verrà mai ripristinato. Pertanto, quando gli sviluppatori prendono un blocco molto vecchio e creano un checkpoint da esso, lo fanno più come un controllo di integrità concordato piuttosto che come un dettato della cronologia.

Oltre ai checkpoint, c'è anche la questione di come un nodo si auto-avvia. Il processo attuale per i nodi Bitcoin è di verificare se ha un database locale di peer di cui ha precedentemente appreso. In caso contrario, interrogherà un set di "DNS Seeds" che sono codificato nel softwareQuesti seed mantengono un elenco di nodi Bitcoin ben connessi che restituiscono al tuo nodo.

Come possiamo vedere dal codice, Bitcoin CORE 0.13 attualmente utilizza DNS Seeds gestiti da Pieter Wuille, Matt Corallo, Luke Dashjr, Christian Decker, Jeff Garzik e Jonas Schnelli. Chiunque può eseguire un DNS seed utilizzando Pieter Wuille's software di bitcoin seeder O Il software di Matt Corallo, anche se affinché possa essere utilizzato dai nuovi nodi dovresti convincere gli sviluppatori di ONE delle implementazioni complete del nodo ad aggiungere il tuo host DNS seed al loro software.

Potrebbe sembrare ancora una volta un punto di estrema centralizzazione che il processo di bootstrapping per un nuovo nodo si basi su appena sei semi DNS. Ricorda che il modello di sicurezza di bitcoin richiede solo che tu ti connetta a un singolo peer onesto per poter resistere agli attacchi Sybil.

Pertanto, un nuovo nodo deve solo essere in grado di connettersi a un singolo seed DNS che T sia compromesso e restituisca indirizzi IP di nodi onesti. Tuttavia, c'è un fallback se per qualche motivo tutti i seed DNS sono irraggiungibili: un elenco hard-codeddi indirizzi IP di nodi affidabili cheviene aggiornatoper ogni versione.

Il modello di sicurezza per questi vari parametri di inizializzazione non è che l'operatore del nodo completo si fidi di X semi DNS o di Y sviluppatori CORE per fornire loro dati onesti, ma piuttosto che almeno 1/X semi DNS non siano compromessi o 1/Y sviluppatori CORE siano onesti riguardo revisione della validità delle modifiche peer codificate.

Niente è perfettamente sicuro

A un livello ancora più profondo, quando esegui un nodo completo, probabilmente ti fidi in una certa misura dell'hardware e del software che stai utilizzando.

Esistono metodi per verificare il software tramiteverifica delle firme del tuo binariorispetto a quelli di van der Laan, ma è improbabile che molte persone si prendano la briga di passare attraverso questo processo. Per quanto riguarda l'hardware affidabile, è un problema difficile. La cosa più vicina a cui probabilmente arriverai a una soluzione hardware sicura è qualcosa comeORWL, che garantiva l'"autodistruzione" se qualcuno avesse tentato di manometterlo.

Hardware ORWL
Hardware ORWL

Tuttavia, dato che le architetture hardware per CPU, RAM e altri componenti hardware importanti tendono a essere proprietarie, non si può mai essere sicuri al 100% che T siano compromesse.

L’equilibrio di potere di Bitcoin

Le acque diventano ancora più torbide quando si comincia a indagare la relazione tra i diversi partecipanti al sistema.

Lo scopo di eseguire un nodo completo è proteggere la tua sovranità finanziaria. Ciò significa generalmente che installando ed eseguendo una versione specifica di un software, stai stipulando un accordo in base al quale rispetterai le regole di quel software e che tutti gli altri che utilizzano la rete devono rispettarle.

Pertanto, se le persone vogliono cambiare le regole in modo tale che non siano retrocompatibili, devi accettare esplicitamente la modifica delle regole eseguendo una nuova versione del software. D'altro canto, le modifiche delle regole retrocompatibili possono essere implementate e applicate senza il tuo consenso.

Una descrizione estremamente semplificata delle dinamiche di potenza in Bitcoin:

[incorporato]https://twitter.com/lopp/status/786241843436544002[/embed]

È importante notare che il software full node non si aggiorna automaticamente, e questo è voluto. Gli aggiornamenti automatici sposterebbero notevolmente l'equilibrio di potere sugli sviluppatori, consentendo loro di forzare i cambiamenti di regole sui nodi e sui miner senza il loro permesso.

Sfortunatamente, mentre una modifica di una regola può essere tecnicamente retrocompatibile, abbiamo Imparare nel corso degli anni che soft fork sufficientemente creativi possono effettivamente implementare modifiche che sono chiaramente al di fuori dell'intento della versione precedente delle regole. Vitalik Buterin ha dimostrato questocon una descrizione di un modo per ridurre gradualmente il tempo di blocco di bitcoin da 10 minuti a 2 minuti, il che ovviamente accelererebbe anche il programma di emissione di nuovi bitcoin.

C'è ONE carta vincente che i full node hanno per combattere contro i soft fork indesiderati: quella di fare hard fork lontano dai miner che hanno implementato il soft fork. Questa è difficile da eseguire (per progettazione) e solleva molte domande sulla misurazione del consenso e sulla ricerca dei nodi economicamente importanti.

Tecnicamente, potrebbe essere fatto cambiando l'algoritmo del miner da doppio SHA256 a una funzione hash diversa, rendendo così tutti gli ASIC SHA256 inutili per il mining di bitcoin. È per questo motivo che gli operatori di nodi dovrebbero rimanere vigili sui cambiamenti nell'ecosistema e ricordare ai miner che possono essere sostituiti se superano la loro autorità.

Molta teoria dei giochi è coinvolta nella discussione delle operazioni dei minatori e della loro minaccia alla sicurezza di bitcoin, e ho ipotizzato come potrebbe cambiare l'ecosistema del miningin un articolo precedente. Sebbene il mining Bitcoin sia più centralizzato di quanto la maggior parte di noi vorrebbe, sembra comunque funzionare bene perché i minatori Bitcoin hanno investito molto capitale: T possono rischiare di distruggere il loro investimento agendo in modo malizioso in un sistema in cui tutti stanno guardando.

Sicurezza SPV

Molti utenti Bitcoin utilizzano un client leggero per accedere alla rete anziché un nodo completo, poiché quest'ultimo richiede molte meno risorse pur garantendo un elevato livello di sicurezza.

Un client che impiega la Simplified Payment Verification (SPV) scarica una copia completa delle intestazioni per tutti i blocchi nell'intera catena. Ciò significa che i requisiti di download e archiviazione aumentano linearmente con la quantità di tempo trascorso dall'invenzione Bitcoin . Ciò è descritto nella sezione 8 del whitepaper Bitcoin.

schermata-11-11-2016-alle-9-12-35-am
schermata-11-11-2016-alle-9-12-35-am

Satoshi ha scritto che un client SPV "T può controllare la transazione da solo, ma collegandola a un punto della catena, può vedere che un nodo della rete l'ha accettata e i blocchi aggiunti dopo confermano ulteriormente che la rete l'ha accettata". SPV presuppone che una transazione profonda X blocchi sarà costosa da falsificare.

SPV sembra offrire garanzie simili alla sicurezza completa del nodo, ma con un'ulteriore ipotesi che qualsiasi blocco con un'intestazione valida e una prova di lavoro contenga sempre transazioni valide. Poiché i client SPV T controllano tutte le regole di consenso indicate nella prima sezione di questo articolo, stanno supponendo che le regole di consenso vengano controllate dal/dai nodo/i da cui Request transazioni.

Un'ulteriore, piccola differenza di sicurezza riguarda i peer che trattengono informazioni da te. Quando esegui un nodo completo, i peer possono trattenere transazioni e blocchi non confermati da te. Tuttavia, una volta ricevuto un blocco da qualsiasi peer, non è possibile per nessuno trattenere le transazioni in quel blocco da te. D'altro canto, è possibile per un peer fornire un'intestazione di blocco a un client SPV e quindi trattenere informazioni sulle transazioni in quel blocco.

I client SPV possono effettuare una query per Imparare informazioni sulle transazioni che interessano un determinato indirizzo e, sebbene sarebbe costoso per i peer mentire loro sull'esistenza di transazioni false confermate (richiederebbe di estrarre un blocco con PoW sufficiente), potrebbero mentire per omissione affermando che non ci sono risultati per il filtro bloom utilizzato per la query sulle transazioni. Vale anche la pena notare che SPV è terribilmente non valido dal punto di vista Privacya causa di difetti nei filtri bloom.

BitcoinJ ha unottimo articolodel modello di sicurezza SPV. Per quanto riguarda le transazioni non confermate, notano:

"In modalità SPV, l'unica ragione per cui devi credere che la transazione sia valida è il fatto che i nodi a cui ti sei connesso hanno inoltrato la transazione. Se un aggressore potesse garantire che eri connesso ai suoi nodi, ciò significherebbe che potrebbe fornirti una transazione completamente non valida (speso denaro inesistente) e verrebbe comunque accettata come se fosse valida."

La sicurezza SPV è probabilmente "abbastanza buona" per l'utente medio, anche se potrebbe essere migliorata con SPV Fraud Proofs. C'è statoqualche discussione Di questo concettoma non implementatoproposteper integrarli nel protocollo.

Non c'è posto come 127.0.0.1

Se T stai eseguendo un nodo completo (e non lo stai effettivamente utilizzando per convalidare le transazioni), allora stai esternalizzando almeno un certo livello di fiducia a terze parti, con conseguente diverso modello di sicurezza per il tuo utilizzo di Bitcoin. Nota che questo non richiede necessariamente che tutti gli utenti e le aziende sviluppino il loro software direttamente sulla RPC API di Bitcoin Core.

Alcune configurazioni infrastrutturali alternative potrebbero includere, ma non sono limitate a:

1) Utilizzando un portafoglio mobile comePortafoglio Bitcoin per Android,Indirizzo verde, O Nascondiglioche ti consente di configurare il portafoglio in modo che interroghi solo il tuo nodo completo.

btc-sicurezza-grafica
btc-sicurezza-grafica

2) Creare app su librerie di nodi SPV come BitcoinJ e configurarle per connettersi solo ai nodi completi che gestisci. In BitcoinJ questo può essere realizzato definendo il tuoSeedPeersche passi al tuoGruppo di paridurante l'inizializzazione. Con libbitcoin puoi definire una connessione di rete a un nodo specificousando questo esempio.

3) Costruire un server proxy compatibile con l'API JSON-RPC di Bitcoin Core che invia alcune chiamate a servizi di terze parti ma verifica anche automaticamente i dati che restituiscono effettuando chiamate a un nodo completo locale. Per un esempio, vedere Software BitGoD di BitGoQuesto modello ibrido può offrirti il meglio di entrambi i mondi: puoi sfruttare le funzionalità avanzate offerte da terze parti mantenendo comunque la tua sovranità finanziaria.

Nodi completi per la libertà

È chiaro che eseguire il proprio nodo completo offre una sicurezza superiore con il minor numero di ipotesi richieste. Considerando che è possibile costruire un computer in grado di eseguire un nodo completo affidabile per solo poche centinaia di dollari, fai i calcoli e determina se proteggere la tua sovranità finanziaria vale il prezzo.

Grazie a Kristov ATLAS, Eric Martindale, Andrew Miller e Kiara Robles per aver rivisto e fornito feedback su questo articolo.

Immagine in evidenza tramiteDanilo Notti per CoinDesk. Altre immagini come da didascalia.

Jameson Lopp

Jameson Lopp è il CTO e co-fondatore di Casa, un servizio di autocustodia. Un cypherpunk il cui obiettivo è quello di creare Tecnologie che dia potere alle persone, ha creato portafogli Bitcoin multifirma dal 2015. Prima di fondare Casa, è stato il responsabile dell'infrastruttura presso BitGo. È il fondatore del Bitcoin Special Interest Group di Mensa, del Triangle Blockchain and Business meetup e di diversi progetti Bitcoin open source. In tutto questo tempo ha lavorato per istruire gli altri su ciò che ha imparato a sue spese, scrivendo software robusto in grado di resistere sia agli avversari che agli utenti finali inesperti.

Jameson Lopp