Post
Topic
Board Italiano (Italian)
Re: Chiarimenti full node e light node
by
arulbero
on 31/10/2018, 18:23:51 UTC
Forse mi manca un pezzo, mettiamo che invio dei btc, il wallet full verifica il mio bilancio in base alla lista degli UTXO e crea la transazione, mentre nel caso di un wallet SPV come si comporta nel momento di creare una transazione?

Il wallet SPV non ha l'intero database di tutti gli UTXO della blockchain, ma ovviamente ha il sottoinsieme degli UTXO relativi ai propri indirizzi. Altrimenti in base a che cosa ti farebbe vedere il suo bilancio totale?

Più nel dettaglio come funziona l'uso del bloom filter nel colloquio tra un nodo SPV e uno full (qui per "peer" si intende un full node a cui il nodo SPV chiede informazioni):
Quote
Bloom filters are used to filter the transactions (and blocks containing them) that an SPV node receives from its peers, selecting only transactions of interest to the SPV node without revealing which addresses or keys it is interested in.

An SPV node will initialize a bloom filter as "empty"; in that state the bloom filter will not match any patterns. The SPV node will then make a list of all the addresses, keys, and hashes that it is interested in. It will do this by extracting the public key hash and script hash and transaction IDs from any UTXO controlled by its wallet. The SPV node then adds each of these to the bloom filter, so that the bloom filter will "match" if these patterns are present in a transaction, without revealing the patterns themselves.

The SPV node will then send a filterload message to the peer, containing the bloom filter to use on the connection. On the peer, bloom filters are checked against each incoming transaction. The full node checks several parts of the transaction against the bloom filter, looking for a match including:

The transaction ID

The data components from the locking scripts of each of the transaction outputs (every key and hash in the script)

Each of the transaction inputs

Each of the input signature data components (or witness scripts)

By checking against all these components, bloom filters can be used to match public key hashes, scripts, OP_RETURN values, public keys in signatures, or any future component of a smart contract or complex script.

After a filter is established, the peer will then test each transaction’s outputs against the bloom filter. Only transactions that match the filter are sent to the node.

In response to a getdata message from the node, peers will send a merkleblock message that contains only block headers for blocks matching the filter and a merkle path (see [merkle_trees]) for each matching transaction. The peer will then also send tx messages containing the transactions matched by the filter.

As the full node sends transactions to the SPV node, the SPV node discards any false positives and uses the correctly matched transactions to update its UTXO set and wallet balance. As it updates its own view of the UTXO set, it also modifies the bloom filter to match any future transactions referencing the UTXO it just found. The full node then uses the new bloom filter to match new transactions and the whole process repeats.

The node setting the bloom filter can interactively add patterns to the filter by sending a filteradd message. To clear the bloom filter, the node can send a filterclear message. Because it is not possible to remove a pattern from a bloom filter, a node has to clear and resend a new bloom filter if a pattern is no longer desired.

The network protocol and bloom filter mechanism for SPV nodes is defined in BIP-37 (Peer Services).