Topic: Chiarimenti full node e light node (Read 280 times)

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?

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).

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.

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.

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???

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.

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.

...
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.

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