Quote from: pf55351 on October 31, 2018, 11:14:15 AM

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 doesnt know what lies down any of the side streets and doesnt 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 tourists 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 transactions 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, doesnt exist because it doesnt 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.