Silent Payments: come Taproot ha reinventato la privacy di Bitcoin

Un problema che Bitcoin non ha mai risolto: il riuso degli indirizzi

Bitcoin viene spesso descritto come anonimo, ma è più corretto parlare di pseudonimato pubblico: ogni transazione resta scritta per sempre in un registro che chiunque può consultare con un semplice block explorer. Il problema pratico, fin dai primi anni, è stato il riuso degli indirizzi. Quando lo stesso indirizzo riceve più pagamenti nel tempo, un osservatore esterno può collegarli tra loro, stimare il saldo di un utente e, incrociando i dati con un exchange che applica il KYC, risalire alla sua identità reale. Le società di analisi on-chain costruiscono interi prodotti commerciali proprio su euristiche di questo tipo, la più nota delle quali raggruppa tutti gli indirizzi usati come input della stessa transazione sotto un unico proprietario presunto.

Nel 2026, a quasi cinque anni dall’attivazione di Taproot (14 novembre 2021), la conversazione pubblica attorno a quell’aggiornamento si è spostata su altri fronti: i covenant, Ordinals, il rischio quantistico. Ma una delle applicazioni più interessanti nate dalla stessa architettura è passata quasi inosservata fuori dai circoli tecnici, le Silent Payments, un protocollo che permette di ricevere pagamenti privati su un singolo indirizzo statico senza comunicare nulla al mittente, né prima né dopo l’operazione. Sono lo stesso trio di proposte, i BIP 340, 341 e 342, che ha permesso a Casey Rodarmor di costruire Ordinals: qui però la flessibilità di Taproot viene piegata verso l’esatto opposto, nascondere un pagamento invece di renderlo pubblicamente visibile come un’iscrizione.

Il tema della privacy on-chain, del resto, non è mai stato soltanto tecnico. Negli Stati Uniti i fondatori di Samourai Wallet, Keonne Rodriguez e William Lonergan Hill, sono stati arrestati nell’aprile 2024 e successivamente condannati per aver gestito senza licenza un servizio di CoinJoin, Whirlpool, accusato di aver contribuito a riciclare fondi di origine illecita, come riportato da CoinDesk. Il caso ha mostrato quanto sia esposto un modello che dipende da un coordinatore identificabile, per quanto il wallet sottostante restasse non custodial. Le Silent Payments seguono una strada strutturalmente diversa: non esiste alcun servizio centrale da individuare, alcun coordinatore da citare in giudizio, alcun server che orchestri le transazioni di più utenti insieme. Il protocollo vive interamente nella matematica di ogni singolo wallet, esattamente come Taproot stesso.

Cosa sono le Silent Payments e perché nascono da Taproot

Le Silent Payments sono specificate nel BIP-352, un documento tecnico finalizzato il 9 marzo 2023 da tre sviluppatori: josibake (Josie Baker, contributor di Bitcoin Core e co-fondatore del collettivo no-profit 2140), Ruben Somsen e Sebastian Falbesoner. Il concetto era stato proposto da Somsen già l’anno prima, in una nota che descriveva l’obiettivo con una frase che resta ancora oggi la sintesi più efficace del progetto: «ricevere pagamenti privati da chiunque su un unico indirizzo statico, senza richiedere alcuna interazione o costo aggiuntivo on-chain», scriveva Somsen nella sua proposta originale.

A differenza di un indirizzo Bitcoin tradizionale, un indirizzo Silent Payment, che inizia con il prefisso sp1q ed è codificato in Bech32m, non viene mai scritto sulla blockchain. Serve solo come punto di incontro pubblico: chi vuole pagare lo legge, esegue un calcolo crittografico in autonomia e genera un indirizzo Bitcoin nuovo di zecca per quel singolo pagamento. Il destinatario individua i pagamenti a lui destinati scandagliando la blockchain con la propria chiave privata, senza che il mittente debba comunicargli nulla prima, durante o dopo la transazione.

Il vantaggio pratico si vede meglio con qualche esempio concreto. Un content creator può pubblicare un solo indirizzo di donazione sul proprio sito per anni, senza che ogni sostenitore finisca collegato agli altri. Un libero professionista può fatturare dieci clienti diversi con lo stesso codice, invece di dover generare e comunicare un indirizzo nuovo ogni volta, un problema tipico di chi gestisce un hardware wallet e non ama esporre indirizzi diversi a ogni fattura. Un exchange può liquidare i prelievi dei propri utenti senza che l’insieme dei prelievi diventi una mappa leggibile della propria tesoreria. In tutti questi casi il costo aggiuntivo, per chi paga, è zero: la transazione ha le stesse dimensioni e la stessa commissione di un pagamento Bitcoin ordinario.

Lo stesso principio si applica a scenari più quotidiani: un servizio in abbonamento può addebitare più clienti nel tempo senza costruire, addebito dopo addebito, una mappa pubblica delle proprie entrate; una piattaforma di rimesse internazionali può liquidare beneficiari diversi in paesi diversi senza che l’insieme dei pagamenti in uscita riveli volumi o controparti a chiunque osservi la blockchain. Sono casi d’uso meno spettacolari di un’iscrizione Ordinals o di un covenant, ma probabilmente più vicini a come la maggior parte delle persone finirà per usare Bitcoin nella vita di tutti i giorni.

La crittografia sotto il cofano: chiave di scansione e chiave di spesa

Un indirizzo Silent Payment non è una singola chiave, ma la concatenazione di due chiavi pubbliche distinte per un totale di 66 byte: la scan key, chiave di scansione, e la spend key, chiave di spesa. La separazione non è un dettaglio implementativo, è il cuore del modello di sicurezza del protocollo. La scan key serve solo per individuare i pagamenti in arrivo attraverso un calcolo ECDH (Elliptic Curve Diffie-Hellman) e può restare su un dispositivo connesso a internet, per esempio un telefono, perché da sola non permette di spendere un solo satoshi. La spend key, quella che autorizza davvero il movimento dei fondi, può restare offline, su un hardware wallet o in cold storage, ed entra in gioco solo al momento di firmare una transazione in uscita.

Questa architettura ricorda da vicino il modello dei wallet watch-only, ma applicato in modo nativo a un intero protocollo di pagamento. Per un privato significa poter tenere un’app di scansione sempre accesa sul telefono senza esporre le chiavi che contano davvero. Per un exchange o una tesoreria aziendale significa poter delegare il monitoraggio dei fondi in arrivo a un sistema con privilegi limitati, riservando l’autorizzazione di spesa a un processo separato e più protetto, uno schema che si sposa bene con i requisiti di segregazione interna che molte istituzioni finanziarie devono comunque rispettare.

Vale la pena notare che questa separazione non è unica delle Silent Payments: è lo stesso principio che rende sicuri i wallet watch-only usati da anni per il monitoraggio contabile, applicato qui non a un singolo indirizzo ma a un intero flusso di pagamenti futuri e imprevedibili, generati da chiunque possieda semplicemente l’indirizzo pubblico.

Come nasce un pagamento: dall’input del mittente all’output univoco

Il meccanismo di generazione dell’indirizzo è la parte più elegante del protocollo. Quando Alice vuole pagare Bob, non genera un indirizzo dal nulla: usa le chiavi private degli input che sta effettivamente spendendo in quella transazione. Sommando quelle chiavi ed eseguendo uno scambio ECDH con la scan key pubblica di Bob, Alice ottiene un segreto condiviso che nessun altro può calcolare, nemmeno osservando la blockchain, perché richiede di conoscere o la chiave privata di Alice o quella di Bob. Quel segreto viene combinato con dati specifici della transazione, in modo che resti unico anche se Alice paga Bob più volte nella stessa transazione o in transazioni diverse nel tempo, e sommato alla spend key pubblica di Bob per produrre un output Taproot completamente nuovo, mai apparso prima sulla blockchain e mai destinato a riapparire.

Bob, per riconoscere il pagamento, ripete lo stesso calcolo dal suo lato: prende le chiavi pubbliche aggregate degli input della transazione, un’informazione già presente e pubblica sulla blockchain, le combina con la propria scan key privata e verifica se il risultato corrisponde a uno degli output della transazione. Se la risposta è sì, il pagamento è suo e può spenderlo in qualsiasi momento con la spend key. Il tutto senza che Alice e Bob si siano mai scambiati un messaggio, un indirizzo aggiuntivo o una notifica di alcun tipo, e senza che la transazione contenga un solo byte in più rispetto a un pagamento Bitcoin ordinario.

Dal punto di vista di un wallet, l’intero processo richiede solo qualche operazione di crittografia a curve ellittiche in più rispetto a una transazione normale, un costo computazionale trascurabile per qualunque dispositivo moderno lato mittente. È lato destinatario, come si vedrà più avanti, che il conto da pagare diventa più interessante.

Perché deve essere un output Taproot: la privacy stenografica

Il protocollo impone che l’output finale sia sempre un indirizzo Taproot (P2TR), e non è un vincolo casuale. Limitare le Silent Payments a un solo tipo di output massimizza quello che i crittografi chiamano l’insieme di anonimato: ogni pagamento privato si mescola in modo indistinguibile con tutti gli altri output Taproot della rete, quelli di un wallet qualunque, di un canale Lightning, di un multisig MuSig2. Un osservatore che guarda la blockchain non può nemmeno stabilire se una certa transazione abbia usato le Silent Payments oppure no: è una privacy stenografica, perché nasconde non solo il contenuto ma l’esistenza stessa dello strumento usato. È lo stesso principio, applicato in direzione opposta, che ha reso possibile la nascita di Ordinals e Runes: la stessa capacità di Taproot di trattare ogni output come intercambiabile ha aperto la porta sia all’anonimato delle Silent Payments sia alla piena visibilità pubblica delle iscrizioni.

Una precisazione è d’obbligo, perché il tema torna spesso quando si parla di Taproot nel 2026: essendo comunque un output P2TR standard, un pagamento Silent Payment condivide lo stesso profilo di esposizione della chiave pubblica al centro del dibattito sul rischio quantistico emerso con forza nel 2026. Le Silent Payments non risolvono né aggravano quel dibattito, ne sono semplicemente indipendenti. Chi vuole approfondire quella parte della storia, incluso il caso delle monete di Satoshi, può leggere il nostro pezzo dedicato.

Non è la prima idea del genere: da BIP-47 alle stealth address

L’idea di un indirizzo statico che generi pagamenti sempre diversi non è nuova. Concetti simili, genericamente chiamati stealth address, circolavano nella comunità tecnica già da qualche anno, ma la prima proposta formalizzata e ampiamente adottata arriva nel 2015, quando Justus Ranvier presenta il BIP-47, i cosiddetti reusable payment codes. Nel suo schema, Alice e Bob si scambiano un codice di pagamento pubblico, ma prima di poter ricevere fondi è necessaria una transazione di notifica speciale e visibile sulla blockchain, che stabilisce il canale privato tra i due. Dopo quella singola notifica, le due parti possono scambiarsi fino a oltre quattro miliardi di pagamenti derivando indirizzi diversi dallo stesso segreto condiviso, senza ulteriori notifiche.

Le Silent Payments risolvono il limite principale di quell’approccio, eliminando del tutto la transazione di notifica. Non serve alcun evento on-chain dedicato per attivare il canale tra due utenti, perché il segreto condiviso viene ricavato direttamente dagli stessi input che il mittente sta già spendendo per pagare. Il risultato è che, a differenza del BIP-47, nessun osservatore può individuare nemmeno il momento in cui due utenti hanno iniziato a scambiarsi pagamenti privati: semplicemente non esiste alcuna transazione fuori dall’ordinario da cercare.

Etichette e resto: i dettagli che rendono l’esperienza utilizzabile

Oltre al meccanismo base, il BIP-352 introduce le etichette (labels), varianti dell’indirizzo che permettono di distinguere l’origine dei pagamenti pur mantenendo una sola coppia di chiavi pubblicata. Un exchange, per esempio, potrebbe generare un’etichetta diversa per ogni cliente partendo da un’unica scan key, senza dover gestire un database di indirizzi separati per ciascuno di essi, mantenendo comunque la possibilità di riconciliare automaticamente ogni deposito con l’utente corretto.

Un’etichetta speciale, riservata per convenzione, gestisce anche il resto (change) delle transazioni: quando il wallet del mittente restituisce a se stesso la parte non spesa di una transazione, lo fa usando lo stesso meccanismo Silent Payment invece di una tradizionale derivazione BIP32, il che semplifica non poco il codice dei wallet che adottano il protocollo e riduce il numero di percorsi di derivazione delle chiavi da gestire e sottoporre a backup.

Il vero costo delle Silent Payments: la scansione della blockchain

Non esiste pasto gratis in crittografia, e le Silent Payments non fanno eccezione. Il prezzo da pagare non è on-chain, non ci sono byte aggiuntivi né commissioni più alte, ma computazionale, e ricade quasi interamente sul destinatario. Poiché ogni output Silent Payment è indistinguibile da un normale output Taproot, il wallet di chi riceve non può limitarsi ad ascoltare un indirizzo noto come farebbe con un pagamento tradizionale: deve tentare il calcolo ECDH su ogni transazione potenzialmente rilevante di ogni nuovo blocco, verificando se il risultato corrisponde a un output che gli appartiene. Alcune ottimizzazioni riducono il carico, per esempio scartando in anticipo gli output che non sono Taproot, gli importi considerati polvere (Sparrow Wallet, per dire, applica di default una soglia di 5.000 satoshi per gli UTXO ricevuti via Silent Payment) e gli output già spesi, ma il costo resta significativamente più alto di quello di un wallet Electrum tradizionale, che si limita a interrogare un filtro compatto per un indirizzo specifico.

Per un nodo Bitcoin completo, con banda e potenza di calcolo abbondanti, l’operazione è onerosa ma del tutto gestibile. Per un wallet mobile, che si connette a intermittenza, ha poca banda e una batteria limitata, scandagliare l’intera blockchain blocco dopo blocco è semplicemente impraticabile. Ed è proprio qui che entra in gioco un nuovo tipo di infrastruttura di rete, pensata apposta per delegare questo lavoro senza sacrificare del tutto la fiducia minima che rende Bitcoin quello che è.

Frigate e la scansione delegata: la soluzione di Sparrow Wallet

La risposta più concreta al problema della scansione arriva da Craig Raw, sviluppatore di Sparrow Wallet, uno dei client desktop più usati da chi gestisce hardware wallet e configurazioni multisig. Raw ha costruito Frigate, un server sperimentale che estende il protocollo Electrum, lo stesso usato da anni per collegare i wallet leggeri a un nodo, con metodi RPC dedicati proprio alla scansione delle Silent Payments. In pratica, il client invia al server la propria scan key privata insieme alla spend key pubblica, ma solo per la durata della scansione: le chiavi restano in memoria, non vengono mai salvate su disco, un approccio che nella comunità tecnica viene chiamato ephemeral client key scanning, descritto in dettaglio in un caso di studio pubblicato dal centro di sviluppo Btrust. Il server fa il lavoro pesante di calcolo ECDH al posto del telefono dell’utente, senza diventare un custode permanente delle sue chiavi.

Un’istanza pubblica, gestita dal collettivo 2140 (lo stesso di Josie Baker) all’indirizzo frigate.2140.dev, è già integrata di default in Sparrow Wallet e ingerisce persino il mempool in tempo reale, così i pagamenti in arrivo diventano visibili ancora prima della conferma; alcune implementazioni sfruttano anche l’accelerazione GPU per velocizzare il calcolo sulle curve ellittiche. Raw stesso ha descritto il salto in avanti con parole nette: «Frigate è ancora sperimentale. Ma dimostra per la prima volta che i wallet per Silent Payments sono pratici per un’adozione su larga scala. Non si tratta solo di un aggiornamento atteso da tempo per i wallet Bitcoin, ma di un passo avanti significativo per la privacy», ha scritto sul proprio account.

Chi supporta già le Silent Payments nel 2026

L’adozione lato wallet è partita da Sparrow Wallet, che ha introdotto il supporto in più fasi ben documentate nel changelog ufficiale del progetto: l’invio verso indirizzi sp1 dalla versione 2.3.0 (ottobre 2023), insieme al supporto per i nomi leggibili via BIP-353 introdotto nella stessa release; i campi PSBT dedicati e la verifica delle prove DLEQ per i firmatari hardware con la versione 2.4.0 (febbraio 2024); infine la ricezione vera e propria, incluso il supporto per firmatari hardware airgapped, con la versione 2.5.0 (maggio 2024), la stessa release che ha reso Frigate il server Electrum predefinito per i wallet configurati con Silent Payments.

Altri progetti si sono mossi in parallelo. Cake Wallet e l’hardware wallet svizzero BitBox02 hanno aggiunto il supporto già nel 2024, Nunchuk ha introdotto la ricezione nel corso del 2026 e Silentium resta il wallet di riferimento pensato esplicitamente come prova di concetto per sviluppatori che vogliono studiare il protocollo. Bitcoin Core, nonostante uno degli autori del BIP-352 sia un suo contributor di lunga data, non ha ancora integrato alcun supporto nativo lato wallet: chi usa Bitcoin Core come wallet, e non solo come nodo, resta fuori dall’adozione per ora.

Cosa arriva dopo: BIP-353, BIP-375 e BIP-392

Le Silent Payments non vivono da sole: un piccolo insieme di proposte satellite sta rendendo il protocollo più comodo da usare nella pratica quotidiana. Il BIP-353 introduce nomi leggibili in stile indirizzo email, per esempio nome@dominio, che si risolvono tramite DNS in un indirizzo Bitcoin di qualsiasi tipo, incluso un indirizzo Silent Payment: Sparrow lo supporta fin dalla stessa versione che ha introdotto l’invio SP. Il BIP-375 aggiunge campi PSBT dedicati e prove crittografiche DLEQ che permettono a un hardware wallet di verificare in modo sicuro di star firmando davvero l’output derivato correttamente, senza dover fidarsi ciecamente del software che ha preparato la transazione, un requisito non banale quando la chiave di spesa vive su un dispositivo isolato.

L’ultimo tassello, ancora più recente, porta la firma dello stesso Craig Raw: il BIP-392, assegnato il 6 febbraio 2026 e per ora in stato di bozza, definisce un descrittore sp() che permette ai wallet di rappresentare, salvare e recuperare un indirizzo Silent Payment usando lo stesso linguaggio dei descrittori già in uso per altri tipi di output, come tr() per Taproot, semplificando backup e interoperabilità tra software diversi. Dalla discussione degli sviluppatori sulla mailing list è nata anche una proposta complementare per annotazioni facoltative, piccoli metadati come l’altezza di blocco di nascita del wallet o il numero di indirizzi da derivare in anticipo prima di fermarsi, pensate per rendere la scansione più efficiente senza alterare lo script effettivo generato dal descrittore.

I limiti: cosa le Silent Payments non risolvono

È bene essere onesti sui limiti, per evitare l’entusiasmo un po’ ingenuo che a volte accompagna i nuovi standard di privacy. Le Silent Payments non fanno nulla per gli UTXO già esistenti: se un indirizzo è stato riutilizzato in passato, quella storia resta scritta per sempre sulla blockchain, il protocollo protegge solo i pagamenti futuri, non ripulisce quelli già avvenuti. Non cambiano di una virgola il dibattito sul rischio quantistico di Taproot, dato che l’output finale resta un P2TR standard con lo stesso profilo di esposizione della chiave pubblica discusso altrove.

L’adozione, inoltre, resta concentrata su una manciata di wallet non custodial: senza il supporto nativo di Bitcoin Core, la maggior parte degli utenti che usano un wallet custodial o un exchange centralizzato non vede alcun beneficio diretto, perché è l’exchange stesso a gestire, e talvolta a riutilizzare, gli indirizzi sottostanti per conto dei propri clienti. Il costo di scansione, infine, spinge molti wallet mobile ad appoggiarsi a server terzi come Frigate: un compromesso ragionevole in termini di usabilità, ma pur sempre un piccolo passo indietro rispetto a scandagliare la blockchain con un nodo proprio, l’unico modo per non rivelare a nessuno, nemmeno al gestore del server di scansione, quali chiavi si stanno cercando. Anche l’interazione con altre tecniche di privacy, come le CoinJoin coordinate o i canali Lightning basati su Taproot Assets, resta un’area di ricerca attiva più che una soluzione già matura e integrata.

MiCA, Travel Rule e la view di Consob sulla privacy on-chain

Un protocollo che migliora la privacy attira quasi sempre una domanda regolamentare, ed è legittimo porsela anche per le Silent Payments. In Europa, il Regolamento (UE) 2023/1113, la cosiddetta Travel Rule, impone ai CASP, i fornitori di servizi in cripto-attività autorizzati sotto MiCA, di accompagnare ogni trasferimento con i dati verificati di chi invia e chi riceve, senza alcuna soglia minima, incluse le operazioni verso wallet non custodial. È una regola che si applica al fornitore di servizi, non al protocollo Bitcoin: né Consob né la Banca d’Italia possono autorizzare, vietare o modificare un BIP come il 352, esattamente come non potevano farlo con l’attivazione di Taproot nel 2021. La distinzione tra strato di rete e strato di servizio, già affrontata nella nostra mappa dei CASP autorizzati dopo MiCA, vale identica anche qui.

In pratica, un utente che gestisce da solo un wallet Sparrow o Cake configurato per le Silent Payments non è un CASP e resta fuori da questo perimetro regolamentare. La Travel Rule scatta solo quando i fondi entrano o escono da un exchange autorizzato, e a quel punto l’operatore conosce comunque l’identità del proprio cliente grazie ai controlli KYC già svolti in fase di apertura del conto, indipendentemente dalla tecnica di privacy on-chain usata dalla controparte. In Italia il periodo transitorio per i vecchi operatori registrati come VASP si è chiuso il 1 luglio 2026: da quella data solo i soggetti autorizzati come CASP secondo il regolamento MiCAR possono offrire servizi in cripto-attività a clienti europei, e un comunicato congiunto di Consob e Banca d’Italia del 30 giugno 2026 registrava circa nove soggetti già abilitati nel Paese.

Uno sguardo al prezzo e al contesto di mercato

Al momento della pubblicazione di questo articolo, il 31 luglio 2026, Bitcoin viene scambiato intorno a 56.000 euro secondo i dati di CoinGecko. Vale la pena ricordarlo perché sviluppi come le Silent Payments procedono a un ritmo che non dipende affatto dal ciclo di mercato: il BIP è stato finalizzato nel 2023, in pieno mercato ribassista, ed è arrivato a un’adozione concreta nei wallet solo diversi anni dopo, quando prezzo e tassi di interesse avevano ormai seguito tutt’altre traiettorie. Chi segue più da vicino come le variabili macroeconomiche, dai tassi della Fed allo spread dei BTP, si riflettano sul prezzo di Bitcoin può approfondire l’argomento nel nostro pezzo dedicato alla curva dei rendimenti.

Domande frequenti

Cosa sono le Silent Payments di Bitcoin?

Le Silent Payments sono un protocollo definito nel BIP-352 che permette di ricevere pagamenti Bitcoin privati su un singolo indirizzo statico, con prefisso sp1q, senza che il mittente debba interagire in anticipo con il destinatario e senza aggiungere alcun costo o dato extra sulla blockchain. Ogni pagamento genera automaticamente un indirizzo Taproot nuovo e diverso, indistinguibile da qualsiasi altro output della rete.

Le Silent Payments hanno bisogno di Taproot?

Sì. Il protocollo richiede che l’output finale sia sempre un indirizzo Pay-to-Taproot (P2TR), la stessa tipologia di output introdotta dall’aggiornamento Taproot nel novembre 2021. Questo vincolo massimizza l’insieme di anonimato, perché un pagamento Silent Payment si mescola con tutti gli altri pagamenti Taproot ordinari della rete e non può essere identificato come tale da un osservatore esterno.

Quali wallet supportano già le Silent Payments nel 2026?

Sparrow Wallet è il client più completo, con invio e ricezione supportati da tempo e con il server Frigate integrato per la scansione delegata. Cake Wallet e l’hardware wallet BitBox02 supportano l’invio dal 2024, Nunchuk ha aggiunto la ricezione nel 2026 e Silentium resta un’implementazione di riferimento pensata per sviluppatori. Bitcoin Core non offre ancora alcun supporto nativo lato wallet.

Le Silent Payments rendono Bitcoin anonimo come Monero?

No. Le Silent Payments risolvono in modo specifico il problema del riuso degli indirizzi, ma non nascondono l’importo trasferito, non offuscano gli input di una transazione e non impediscono l’analisi delle transazioni una volta che i fondi vengono depositati su un exchange con obblighi KYC. È un miglioramento mirato di privacy, non un salto verso l’anonimato assoluto tipico delle valute progettate fin dall’origine per quello scopo.

Le Silent Payments risolvono anche il rischio quantistico legato a Taproot?

No. Poiché ogni output Silent Payment resta comunque un normale indirizzo Taproot, condivide lo stesso profilo di esposizione della chiave pubblica al centro del dibattito sul rischio quantistico che ha coinvolto Bitcoin nel 2026. Le Silent Payments migliorano la riservatezza dei pagamenti quotidiani, ma non intervengono in alcun modo sulla sicurezza crittografica di lungo periodo delle chiavi coinvolte.

A cura della redazione crypto di HOGE Wire.