Bitcoin Forum
September 19, 2019, 07:28:56 AM *
News: If you like a topic and you see an orange "bump" link, click it. More info.
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Chiarimenti full node e light node  (Read 173 times)
pf55351
Jr. Member
*
Offline Offline

Activity: 44
Merit: 1


View Profile
October 30, 2018, 12:22:43 PM
 #1

Salve a tutti ragazzi, grazie per le risposte dei post precedenti, ho ripreso lo studio del sistema bitcoin ed ho un po di dubbi che elenco di seguito:
  • Non è detto che un nodo della rete bitcoin faccia anche da miner?
  • Un wallet è un nodo della rete che può essere di tipo full (scarica tutta la blockchain per intero) o light (scarica solo gli header dei blocchi) ?
  • Quando invio una transazione questa si propaga prima a tutti i nodi della rete e poi viene minata?
  • Nel momento in cui invio la transazione automaticamente il ricevente vede il suo credito aggiornarsi se ha un nodo full mentre se ha un nodo light deve attendere che la transazione sia validata e inclusa in un blocco?
  • Che controlli applica un nodo per bloccare una transazione che utilizzi un importo già speso ma non ancora confermato?

Grazie a tutti
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1568878136
Hero Member
*
Offline Offline

Posts: 1568878136

View Profile Personal Message (Offline)

Ignore
1568878136
Reply with quote  #2

1568878136
Report to moderator
1568878136
Hero Member
*
Offline Offline

Posts: 1568878136

View Profile Personal Message (Offline)

Ignore
1568878136
Reply with quote  #2

1568878136
Report to moderator
1568878136
Hero Member
*
Offline Offline

Posts: 1568878136

View Profile Personal Message (Offline)

Ignore
1568878136
Reply with quote  #2

1568878136
Report to moderator
Plutosky
Sr. Member
****
Offline Offline

Activity: 658
Merit: 478


View Profile
October 30, 2018, 06:03:56 PM
Merited by Micio (4)
 #2

Salve a tutti ragazzi, grazie per le risposte dei post precedenti, ho ripreso lo studio del sistema bitcoin ed ho un po di dubbi che elenco di seguito:
  • Non è detto che un nodo della rete bitcoin faccia anche da miner?
  • Un wallet è un nodo della rete che può essere di tipo full (scarica tutta la blockchain per intero) o light (scarica solo gli header dei blocchi) ?
  • Quando invio una transazione questa si propaga prima a tutti i nodi della rete e poi viene minata?
  • Nel momento in cui invio la transazione automaticamente il ricevente vede il suo credito aggiornarsi se ha un nodo full mentre se ha un nodo light deve attendere che la transazione sia validata e inclusa in un blocco?
  • Che controlli applica un nodo per bloccare una transazione che utilizzi un importo già speso ma non ancora confermato?

Grazie a tutti

1)Un nodo può essere tale anche senza fare mining

2)Si. In particolare un full node usa la propria copia della blockchain per verificare che tutti gli input di tutte le transazioni non siano stati precedentemente spesi. In più verifica che ogni blocco e ogni transazione rispetti le regole del consenso (es. ogni blocco non può essere più grande di 1mb, ogni blocco non deve dare una ricompensa maggiore di 12,5..). Se un blocco o una transazione non rispettano le regole del consenso questi vengono respinti e non instradati, nonostante altri nodi li ritengono validi. I full nodes rispondo alla regola base del processo di consenso distribuito "Don't trust, verify": essi mettono in dubbio qualsiasi informazione gli venga passata da un nodo vicino non potendo sapere, in una rete aperta e ad accesso libero, se il nodo vicino è onesto o disonesto. I "light" node si basano sulla  tecnica SPV (Simple Payment Verification) e usano gli header per verificare che la propria transazione sia inclusa in un particolare blocco e verificare solo quella (tramite il merkle tree).

3)Si, in particolare una transazione instradata ma non confermata finisce nella mempool (memory pool) da dove poi il miner che ha "vinto" la proof of work la preleva  e la include nel blocco appena minato . Usualmente i miner danno la precedenza alle le transazioni con fee più alte (in modo da incrementare la loro ricompensa)

4)In base al wallet che usi l'aggiornamento è immediato nel saldo anche se per il momento non spendibile fino ad un numero sufficiente di conferme (di solito 6)

5)Anche qui dipende dal wallet. Una transazione trasmessa ma non ancora confermata in teoria può essere "doppio spesa" inviando un uguale ammontare a se stessi con una fee più alta in modo che i miners la accodino alla blockchain prima della transazione originale. Ma molti wallet impediscono questa azione.

Non tenete in euro più soldi di quelli che siete disposti a perdere.
www.bitcoinedintorni.org
arulbero
Legendary
*
Offline Offline

Activity: 1282
Merit: 1305


View Profile
October 31, 2018, 07:38:33 AM
Last edit: October 31, 2018, 12:05:32 PM by arulbero
Merited by Micio (4)
 #3

Salve a tutti ragazzi, grazie per le risposte dei post precedenti, ho ripreso lo studio del sistema bitcoin ed ho un po di dubbi che elenco di seguito:

  • Che controlli applica un nodo per bloccare una transazione che utilizzi un importo già speso ma non ancora confermato?

...
3)Si, in particolare una transazione instradata ma non confermata finisce nella mempool (memory pool) da dove poi il miner che ha "vinto" la proof of work la preleva  e la include nel blocco appena minato . Usualmente i miner danno la precedenza alle le transazioni con fee più alte (in modo da incrementare la loro ricompensa)

4)In base al wallet che usi l'aggiornamento è immediato nel saldo anche se per il momento non spendibile fino ad un numero sufficiente di conferme (di solito 6)

5)Anche qui dipende dal wallet. Una transazione trasmessa ma non ancora confermata in teoria può essere "doppio spesa" inviando un uguale ammontare a se stessi con una fee più alta in modo che i miners la accodino alla blockchain prima della transazione originale. Ma molti wallet impediscono questa azione.

Aggiungo che non solo è possibile spendere gli output non spesi di una transazione non confermata, ma in diversi casi l'operazione si rende proprio necessaria.

Quando la mempool è piena, e si vuole sbloccare una transazione non confermata a causa delle fee troppo basse, ci sono sostanzialmente 2 metodi: CPFP (Child Pays for Parents) e RBF (Replace by Fee).

Il metodo CPFP (accelerazione della ricezione*) consiste proprio nello spendere gli output di una tx "sospesa" (non confermata) con una seconda tx. Se sto attendendo un pagamento, e questo non viene confermato causa le fee troppo basse, posso spendere gli output non spesi della prima tx (la tx "madre") con una seconda (la tx "figlia"), inserendo in quest'ultima fee sufficienti a rendere appetibile ai miner l'introduzione della coppia di tx in un blocco (nota bene che non sarebbe possibile inserire solo la seconda tx senza la prima). Così si sblocca il pagamento.

Il metodo RBF (accelerazione dell'invio) si applica quando si vuole accelerare la conferma invece di una tx inviata, non ricevuta. In quel caso si invia una seconda tx uguale alla prima eccetto il fatto che ha una fee maggiorata. Il miner che vede 2 tx uguali tranne che per le fee scarta la prima tx dalla mempool e utilizza la seconda. RBF (nella variante "Opt-in RBF" -> https://bitcoincore.org/en/faq/optin_rbf/) può essere utilizzata solo se la prima tx era stata taggata da chi l'aveva inviata come "replaceable" nel momento in cui era stata creata, non si può fare insomma a posteriori. Ci sono comunque diverse varianti di RBF -> https://en.bitcoin.it/wiki/Replace_by_fee.

Esempio di wallet che permette entrambe le opzioni (e dal cui sito ho preso la mia spiegazione):
https://support.conio.com/hc/it/articles/360008901213-Come-faccio-a-fare-arrivare-i-Bitcoin-più-velocemente-


*EDIT: a ben vedere il metodo CPFP può essere utilizzato anche da colui che invia i bitcoin, a patto che tra gli output della transazione ci sia almeno un output da lui controllato (di solito il famoso indirizzo del resto):

https://data-dive.com/unconfirmed-bitcoin-transactions-electrum
pf55351
Jr. Member
*
Offline Offline

Activity: 44
Merit: 1


View Profile
October 31, 2018, 11:14:15 AM
Merited by Micio (1)
 #4

Grazie ad entrambi per le risposte, sempre molto gentili.
Vorrei capire meglio però un passaggio relativo alla transazione e successiva conferma, riporto per semplicità un esempio:

Bob possiede nel suo wallet 3 btc derivati da transazione precedenti, per la precisione 1 btc dalla transazione X 1 btc dalla transazione Y e 1 Btc dalla transazione Z.
Ora Bob paga un caffe al bar dal costo di 1.4 btc + 0,4 di fee
Bot accede al suo wallet e nel caso di full wallet :
  • il wallet prepara come somma 2 btc dalla transazione  X e Y con resto di 0.2 da ritornare a lui
  • il wallet verificherà che la somma non è stata effettivamente spesa controllando con una ricerca in tutta la blockchain le transazioni degli indirizzi presenti nella transazioni X e Y o fa altro? e nel caso di light wallet?
  • appurato che la somma sia presente e la transazione passi indenna il controllo degli script questa viene accettata e propagata a tutti i nodi della rete, tra cui anche qualche nodo miner che l'inizierà a minare
  • il wallet del proprietario del BAR se ha un wallet full vede aggiornarsi il suo bilancio anche se questa non è stata confermata in quanto deve essere ancora minata, se è di tipo light cosa succede? Non vede il suo bilancio aggiornarsi fino a quando anche lui ad intervalli regolari non chiede ad un nodo full se ci sono nuove transazioni per i suoi indirizzi? Poi quando la transazione sarà minata il wallet potrà verificarla scaricando l header del nuovo blocco e verificando che la transazione sia nel merkel tree???

Spero di essere stato chiaro e grazie
F
 
arulbero
Legendary
*
Offline Offline

Activity: 1282
Merit: 1305


View Profile
October 31, 2018, 11:56:01 AM
Last edit: October 31, 2018, 04:12:13 PM by arulbero
Merited by Micio (2)
 #5

Grazie ad entrambi per le risposte, sempre molto gentili.
Vorrei capire meglio però un passaggio relativo alla transazione e successiva conferma, riporto per semplicità un esempio:

Bob possiede nel suo wallet 3 btc derivati da transazione precedenti, per la precisione 1 btc dalla transazione X 1 btc dalla transazione Y e 1 Btc dalla transazione Z.
Ora Bob paga un caffe al bar dal costo di 1.4 btc + 0,4 di fee
Bot accede al suo wallet e nel caso di full wallet :
  • il wallet prepara come somma 2 btc dalla transazione  X e Y con resto di 0.2 da ritornare a lui
  • il wallet verificherà che la somma non è stata effettivamente spesa controllando con una ricerca in tutta la blockchain le transazioni degli indirizzi presenti nella transazioni X e Y o fa altro? e nel caso di light wallet?
  • appurato che la somma sia presente e la transazione passi indenna il controllo degli script questa viene accettata e propagata a tutti i nodi della rete, tra cui anche qualche nodo miner che l'inizierà a minare
  • il wallet del proprietario del BAR se ha un wallet full vede aggiornarsi il suo bilancio anche se questa non è stata confermata in quanto deve essere ancora minata, se è di tipo light cosa succede? Non vede il suo bilancio aggiornarsi fino a quando anche lui ad intervalli regolari non chiede ad un nodo full se ci sono nuove transazioni per i suoi indirizzi? Poi quando la transazione sarà minata il wallet potrà verificarla scaricando l header del nuovo blocco e verificando che la transazione sia nel merkel tree???


Un full node man mano che riceve i blocchi aggiorna l'insieme degli output non spesi detti UTXO. Quindi non deve ogni volta che riceve una tx ricontrollare tutte le tx che costituiscono la storia dei bitcoin che sta ricevendo, gli basta controllare che stia ricevendo degli output non spesi guardando all'insieme degli utxo. Tutto lì. Quindi il suo bilancio si aggiorna subito, quando la tx ricevuta non è stata ancora confermata.

Per quanto riguarda gli SPV wallet, essi scaricano solo gli header dei blocchi, quindi verificano che la catena dei blocchi sia corretta, ma non conoscono le tx contenute nei vari blocchi. Quando una tx che lo riguarda raggiunge un full node, il nodo SPV tramite il merkle tree (che deve richiedere al full node) può solo verificare da sè in quale blocco quella tx è effettivamente inclusa. Da ciò si capisce perchè un nodo/wallet SPV deve aspettare almeno una conferma (in genere almeno 6) affinchè possa fidarsi, non essendo in alcun modo in grado di valutare da sè se un certo output che sta ricevendo non sia effettivamente mai stato speso.

Sul tempo minimo necessario, non esiste, io anche usando wallet su smartphone (quindi evidentemente SPV) ricevo di solito subito l'avviso di ricezione di una transazione quando ancora non è confermata. Il wallet SPV fa una richiesta permanente ai nodi a cui si collega (tramite bloom filter), e riceve di norma immediatamente la comunicazione di una tx che coinvolge un suo indirizzo.

Guarda questa risposta che è molto chiara:
https://bitcoin.stackexchange.com/questions/79075/light-clients-transaction-verification
Quote
How does a light node know which block its transaction got included in?
Most SPV wallets use BIP 37. The protocol defined in BIP 37 is roughly as follows:

Wallet sends to a full node a bloom filter which, when applied to transactions, indicates whether a transaction applies to that wallet.
Full nodes, for every block and transaction, applies the filter to see if there is a match.
If there is, relay the transactions to the wallet.
If there is a match for a transaction in a block, generate a merkle proof and send the proof with the transaction to the wallet.
Update the filter on matches.
When blocks are received, send the block header to the wallet.
This is generally how all SPV wallets work too, even ones that don't use BIP 37. They may not use bloom filters, but they use some kind of filter and rely on a full node to check things against the filter and then send along the things that match.

For privacy reasons, the filters do not match exactly. They have a false positive rate (but not a false negative rate) so some things are sent to the wallet that do not apply to it. The wallet just ignores those things.

Also, say a wallet program was loaded after a month of inactivity. Now the wallet needs to know the balance of its address? How does it go about reconstructing its balance after downloading the latest block headers?
It connects to a full node, sends it the filter to use, and then asks the node to send all of the transactions that match that filter that are in all blocks since block X where X is the latest block header the wallet has.

Sul funzionamento in generale di un SPV wallet, da  "Mastering bitcoin"
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch08.asciidoc
Quote
SPV nodes download only the block headers and do not download the transactions included in each block. The resulting chain of blocks, without transactions, is 1,000 times smaller than the full blockchain. SPV nodes cannot construct a full picture of all the UTXOs that are available for spending because they do not know about all the transactions on the network. SPV nodes verify transactions using a slightly different method that relies on peers to provide partial views of relevant parts of the blockchain on demand.

As an analogy, a full node is like a tourist in a strange city, equipped with a detailed map of every street and every address. By comparison, an SPV node is like a tourist in a strange city asking random strangers for turn-by-turn directions while knowing only one main avenue. Although both tourists can verify the existence of a street by visiting it, the tourist without a map doesn’t know what lies down any of the side streets and doesn’t know what other streets exist. Positioned in front of 23 Church Street, the tourist without a map cannot know if there are a dozen other "23 Church Street" addresses in the city and whether this is the right one. The mapless tourist’s best chance is to ask enough people and hope some of them are not trying to mug him.

SPV verifies transactions by reference to their depth in the blockchain instead of their height. Whereas a full blockchain node will construct a fully verified chain of thousands of blocks and transactions reaching down the blockchain (back in time) all the way to the genesis block, an SPV node will verify the chain of all blocks (but not all transactions) and link that chain to the transaction of interest.

For example, when examining a transaction in block 300,000, a full node links all 300,000 blocks down to the genesis block and builds a full database of UTXO, establishing the validity of the transaction by confirming that the UTXO remains unspent. An SPV node cannot validate whether the UTXO is unspent. Instead, the SPV node will establish a link between the transaction and the block that contains it, using a merkle path (see [merkle_trees]). Then, the SPV node waits until it sees the six blocks 300,001 through 300,006 piled on top of the block containing the transaction and verifies it by establishing its depth under blocks 300,006 to 300,001. The fact that other nodes on the network accepted block 300,000 and then did the necessary work to produce six more blocks on top of it is proof, by proxy, that the transaction was not a double-spend.

An SPV node cannot be persuaded that a transaction exists in a block when the transaction does not in fact exist. The SPV node establishes the existence of a transaction in a block by requesting a merkle path proof and by validating the Proof-of-Work in the chain of blocks. However, a transaction’s existence can be "hidden" from an SPV node. An SPV node can definitely prove that a transaction exists but cannot verify that a transaction, such as a double-spend of the same UTXO, doesn’t exist because it doesn’t have a record of all transactions. This vulnerability can be used in a denial-of-service attack or for a double-spending attack against SPV nodes. To defend against this, an SPV node needs to connect randomly to several nodes, to increase the probability that it is in contact with at least one honest node. This need to randomly connect means that SPV nodes also are vulnerable to network partitioning attacks or Sybil attacks, where they are connected to fake nodes or fake networks and do not have access to honest nodes or the real bitcoin network.
pf55351
Jr. Member
*
Offline Offline

Activity: 44
Merit: 1


View Profile
October 31, 2018, 03:25:17 PM
 #6

Ciao grazie mille per la risposta vediamo se ho capito:

Caso Full Node/Wallet:  il nodo/wallet all'inizio scarica e verifica tutta la blockchain facendosi una lista delle UTXO.
Nel momento in cui gli il wallet crea/genera una transazione verifica che l'input faccia parte delle UTXO in quel caso accetta la transazione la propaga a tutti i nodi della rete tra cui anche il nodo ricevente che aggiorna il suo bilancio ( caso in cui wallet ricevente sia un full node), bisogna attendere che la transazione venga minata e inclusa in un blocco al fine di essere considerata valida. Al nodo arriveranno cosi i nuovi blocchi che verificherà, aggiornera la UTXO e cosi via.....
Domanda se mi scollego dal mio wallet full e lo riaccendo dopo 2 giorni partirà da capo a scaricarsi la blockchain o solo la parte mancante?

Caso SPV: il wallet scarica solo gli header della blockchain e verifica hash.
Nel caso in cui deve verificare una transazione chiede ad un full node di inviargli il ramo del merkle tree contenente quella transazione per ricostruire il merkle root.
Non capisco pero come possa accettare/scartare transazioni visto che a differenza di un nodo full non ha la lista delle UTXO.Huh

Grazie
F
arulbero
Legendary
*
Offline Offline

Activity: 1282
Merit: 1305


View Profile
October 31, 2018, 04:07:28 PM
Last edit: October 31, 2018, 04:50:46 PM by arulbero
Merited by Micio (1)
 #7

Caso Full Node/Wallet:  il nodo/wallet all'inizio scarica e verifica tutta la blockchain facendosi una lista delle UTXO.
Nel momento in cui gli il wallet crea/genera una transazione verifica che l'input faccia parte delle UTXO in quel caso accetta la transazione la propaga a tutti i nodi della rete tra cui anche il nodo ricevente che aggiorna il suo bilancio ( caso in cui wallet ricevente sia un full node), bisogna attendere che la transazione venga minata e inclusa in un blocco al fine di essere considerata valida. Al nodo arriveranno cosi i nuovi blocchi che verificherà, aggiornera la UTXO e cosi via.....
Domanda se mi scollego dal mio wallet full e lo riaccendo dopo 2 giorni partirà da capo a scaricarsi la blockchain o solo la parte mancante?
Solo la parte mancante. Il database degli utxo si aggiorna in maniera incrementale, man mano che arrivano i blocchi. Quando il nodo è in funzione il database si trova in Ram, quando si spegne il nodo salva il database sull"hard disk e al riavvio parte da lì.


Caso SPV: il wallet scarica solo gli header della blockchain e verifica hash.
Nel caso in cui deve verificare una transazione chiede ad un full node di inviargli il ramo del merkle tree contenente quella transazione per ricostruire il merkle root.
Non capisco pero come possa accettare/scartare transazioni visto che a differenza di un nodo full non ha la lista delle UTXO.Huh

Non si basa sugli utxo ma semplicemente sul numero di conferme (depth) della tx. E' una conferma a posteriori, in base a quello che succede dopo la comparsa della tx, di fatto il wallet SPV si fida del giudizio degli altri full nodi che accettano e propagano questi blocchi e ne aggiungono altri sopra quello contenente la tx. I full node fanno viceversa, controllano innanzitutto il passato della tx (height), solo quello ti può garantire al 100% la validità di una tx. La garanzia a posteriori data dal solo numero di conferme fornisce invece solo un'indicazione probabilistica (seppur importante). Ti avevo già quotato la risposta alla tua domanda:

Quote
SPV verifies transactions by reference to their depth in the blockchain instead of their height. Whereas a full blockchain node will construct a fully verified chain of thousands of blocks and transactions reaching down the blockchain (back in time) all the way to the genesis block, an SPV node will verify the chain of all blocks (but not all transactions) and link that chain to the transaction of interest.

For example, when examining a transaction in block 300,000, a full node links all 300,000 blocks down to the genesis block and builds a full database of UTXO, establishing the validity of the transaction by confirming that the UTXO remains unspent. An SPV node cannot validate whether the UTXO is unspent. Instead, the SPV node will establish a link between the transaction and the block that contains it, using a merkle path (see [merkle_trees]). Then, the SPV node waits until it sees the six blocks 300,001 through 300,006 piled on top of the block containing the transaction and verifies it by establishing its depth under blocks 300,006 to 300,001. The fact that other nodes on the network accepted block 300,000 and then did the necessary work to produce six more blocks on top of it is proof, by proxy, that the transaction was not a double-spend.
pf55351
Jr. Member
*
Offline Offline

Activity: 44
Merit: 1


View Profile
October 31, 2018, 05:03:40 PM
 #8

Ciao arulbero e grazie per la risposta,
si, ho letto quanto mi avevi quotato ma pensavo che quel controllo tramite filtro lo facesse per verificare se una transazione che stava cercando fosse confermata o no.
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?
arulbero
Legendary
*
Offline Offline

Activity: 1282
Merit: 1305


View Profile
October 31, 2018, 06:23:51 PM
Last edit: October 31, 2018, 06:35:05 PM by arulbero
 #9

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).
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!