Glossario / Riferimento per sviluppatori
MSG_FILTERED_WITNESS_BLOCK
- Che cos'è MSG_FILTERED_WITNESS_BLOCK?
- Il tipo di blocco filtrato con witness figura nella lista riservata del BIP144 e nell'enum del codice sorgente di Bitcoin Core, senza alcuna implementazione dietro in nessuno dei due casi.
Specificato nel BIP-144.
MSG_FILTERED_WITNESS_BLOCK è il codice di inventario 0x40000003, riservato quando nel 2016 sono state scritte le regole peer di segwit, e mai implementato. Bitcoin Core lo riporta come voce dell'enum, con un commento che registra esattamente questo. La funzione per wallet leggeri che avrebbe esteso, il filtraggio bloom del BIP37, è stata disattivata per impostazione predefinita in Bitcoin Core 0.19.0, e questo conta per te solo se il wallet del tuo smartphone vi si appoggia ancora.
Come funziona
Stato: riservato e mai realizzato. Il BIP144 ha dato il nome al tipo; Bitcoin Core lo riporta come voce dell'enum in src/protocol.h, con un commento che registra che non esiste alcun gestore. Il filtraggio BIP37 che avrebbe servito è disattivato per impostazione predefinita a partire da Bitcoin Core 0.19.0, a novembre 2019, e i filtri compatti per blocco dei BIP157 e BIP158 sono il sostituto.
Capire la lacuna significa capire che cos'era un blocco filtrato. Un client leggero che usa il BIP37 invia un messaggio filterload che descrive, in modo approssimativo, gli indirizzi che gli interessano. Poi richiede il tipo di inventario 3, MSG_FILTERED_BLOCK, e il nodo che lo serve risponde con un messaggio merkleblock: l'intestazione del blocco da 80 byte, un conteggio delle transazioni, un ramo di Merkle parziale e un bitfield che indica da che parte percorrere l'albero. Le transazioni corrispondenti seguono come messaggi separati. Il client verifica che ciascuna penda davvero dalla radice di Merkle dell'intestazione, e lo fa usando solo i txid.
I witness non sono mai entrati in quel calcolo. Poiché la radice di Merkle è costruita dai txid, un client leggero può provare l'inclusione senza una sola firma, perciò le transazioni successive venivano inviate senza dati witness. Il tipo riservato 3 con l'aggiunta del flag witness, 0x40000003, avrebbe permesso a un client di chiedere quelle transazioni per intero. Nessuno l'ha realizzato, perché nessuno che producesse wallet leggeri voleva altro BIP37.
La ragione è la privacy, non lo sforzo. Il filtro che un client carica dice al nodo che lo serve, all'incirca, quali indirizzi gli appartengono, e le ricerche condotte fino alla metà degli anni 2010 hanno mostrato che quei filtri divulgavano molto più del previsto. La risposta di Bitcoin Core è stata smettere di servirli per impostazione predefinita invece di riparare il progetto. Il BIP158 inverte il flusso: il nodo costruisce un piccolo filtro per blocco con codifica Golomb, tarato su un tasso di falsi positivi di uno su 784.931, e lo pubblica. Il client scarica i filtri, li verifica in locale e scarica un blocco intero solo in caso di corrispondenza, così il server non apprende nulla su quali indirizzi interessassero.
Dove lo vedi
Quasi da nessuna parte, che è la risposta onesta per chiunque trovi MSG_FILTERED_WITNESS_BLOCK in una tabella di riferimento.
Cerca la costante in Bitcoin Core con grep e trovi un solo membro dell'enum. Implementazioni alternative come btcd riportano il nome nei loro pacchetti wire per completezza, anche in questo caso senza alcun comportamento dietro. Nessun wallet l'ha mai inviato.
Dove l'argomento tocca davvero un acquirente è nel modo in cui un wallet mobile ottiene i suoi dati. Se un wallet si descrive come SPV e si connette a nodi pubblici casuali con filtri bloom, sta usando un meccanismo che l'implementazione di riferimento ha smesso di servire per impostazione predefinita anni fa, e sta dicendo a quei nodi qualcosa sui tuoi indirizzi. I wallet basati sui filtri compatti per blocco, il progetto alla base di Neutrino di lnd, chiedono molto meno. Un wallet collegato al server del proprio fornitore è la terza opzione, e la più comune: veloce, privato verso gli estranei e del tutto visibile al fornitore.
MSG_FILTERED_WITNESS_BLOCK vs blocco di Merkle
Un blocco di Merkle è la risposta; MSG_FILTERED_WITNESS_BLOCK è una richiesta che non è mai stata collegata a produrne uno. Il messaggio merkleblock è una struttura reale e implementata che prova che un insieme di transazioni appartiene a un blocco senza inviare il blocco. La variante witness riservata avrebbe cambiato solo ciò che veniva dopo quella prova, cioè se le transazioni corrispondenti arrivavano con le loro firme. Poiché le prove di inclusione si basano sui txid, la funzione mancante non è costata nulla a nessuno.