How does SPV prevent double spending of UTXO?

3

3

I am new to Bitcoins. I have read about how double spending is prevented in Bitcoins.

Suppose A, a peer, receives 'B' BTCs from various transactions: B1,B2,B3, etc. Also, A had spent 'S' BTCs in various transactions S1,S2,S3, etc. Now, whenever a new transaction is initiated from A to B (eg: A wants to transfer X bitcoins to B), the transaction has to be verified as follows.

Fullnodes have the Unspent Transactions Output (UTXO) database. A's address is scanned in this database and checked if A has any unspent bitcoins. If there are at least X unspent bitcoins against A's address, then the transaction is legitimate.

Q 1) Where does SPV and Merkel trees come into picture during the above-mentioned verification process? I have read elsewhere on the internet that SPV nodes will query for the previous transactions B1,B2,B3, .. and S1,S2,S3 & check if whether A's claim is valid or not.

Q 2) How many previous transactions do usually SPVs look into? My understanding is that SPVs have to look at all the transactions associated with A's address. What if A does not input all its previous transactions? (Eg: A hides its some of its spending transactions, say, S1)

kasa

Posted 2017-05-08T17:30:59.440

Reputation: 131

Answers

5

In a bitcoin transaction, A's address is not scanned for spendable Unspent Transaction Outputs (UTXOs). Full nodes simply check if the inputs of the transaction are really unspent. There is no scanning of addresses involved.

UTXOs are stored as the transaction id (txid) and the output index of the transaction that created them. You cannot reference the outputs to be spent by address, the address merely specifies which private key must sign the input script in order to claim the UTXO.

Suppose you advertise addr1 for donations, and you receive 3 donations D1,D2 and D3 on that address. You have 3 UTXOs and not 1. The only thing is that they can be claimed by same private key. Hence, there is no looking around for previous transactions. Wallet has to specify which UTXOs it is consuming.

SPV allows a lightweight client to verify that a transaction is included in the Bitcoin blockchain, without downloading the entire blockchain. To verify that a transaction is in a block, a SPV client requests a proof of inclusion, in the form of a Merkle tree branch. It does not check for double-spend on it's own. Rather it relies on the full node servers it is connected to do so. To prevent from being cheated from single server, they connect to multiple servers to get the block headers. From Bitcoin Wiki:

The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.

You might also want to look into Fraud Proofs which would allow full nodes to prove that information propagated on the network is invalid, e.g. allow full nodes to point out double-spends to thin clients.

Another Reference: Thin Client Security

sanket1729

Posted 2017-05-08T17:30:59.440

Reputation: 755

one clarification: Is it possible to specify the how much fraction of each donation I can spend? For eg: I want to spend X BTC in total. It can be fetched in many ways from D1, D2 and D3. X = aD1+bD2+c*D3 and (a,b,c) is not unique. Does one specify (a,b,c) while transacting for X BTC? – kasa – 2017-05-10T09:39:39.537

All the UTXO in the input to transactions have to be consumed. The transaction would look something like. Inputs: D1,D2 and D3. Output: D4 and X.

with condition(D4<= D1 + D2 + D3 - X) Note that D1, D2 and D3 are no longer UTXO. All inputs to transactions must be completely consumed. Instead we have 2 new UTXO, namely X and D4. – sanket1729 – 2017-05-10T11:17:06.700

The donation amounts D1,D2 and D3 are not mixed. If X <= D1,D2,D3, then X BTC are transacted only from one of {D1,D2,D3}. Essentially after the BTC are spent, the contents of the wallet would look like {D1-X,D2,D3}, assuming X is consumed from D1. Please refer this link: https://www.cryptocoinsnews.com/bitcoin-transaction-really-works/

– kasa – 2017-05-11T03:07:21.790

Yes, there are many ways to spend inputs. In your example, it would not make sense to spend D2 and D3 since X<=D1. In a bitcoin transaction, all input UTXO's must be completely consumed. If you have UTXO's {D1,D2,D3,D4 ..} and you can choose any subset of it on condition that sum is greater than X. Say, you choose D2 and D4. The new UXTO set would be {D1,D3,O1 and O2} where O1 and O2 are outputs. Here, D1 and D3 are consumed All UTXO's which are input to Transaction must be completely spent. The article you linked explains the same. – sanket1729 – 2017-05-11T04:50:04.263

This is not an answer but a clarification. It does not address the problem of how SPV clients are secure against double spends. – Pieter Wuille – 2017-05-11T05:02:06.203

Edited the answer. Please comment if anything is incorrect/missing. – sanket1729 – 2017-05-11T06:10:16.163

Now it is just wrong. The merkle path proves that a transaction was included in a block. It cannot prove that it is not a double spend. – Pieter Wuille – 2017-05-11T09:35:27.603

@Pieter: You are right. It does not prove that it is not a double-spend. Ideally, one has to wait for at least 6 confirmations. However the rest of SanketKanjalkar 's explanation is correct. – kasa – 2017-05-11T09:55:27.607

Hello, I already mentioned in the answer that it cannot check double spend on it's own but relies on connected full nodes. – sanket1729 – 2017-05-11T10:14:33.377

@Pieter, can you please help me understand what part of the answer is wrong? – sanket1729 – 2017-05-11T10:37:43.133

I apologize, and misread. – Pieter Wuille – 2017-05-11T15:35:41.957

Hi Sanket, Nice answer! I've made a few small edits to your post to fix terminology, or make it a bit clearer. Please review my edit and check if it fits what you wanted your answer to say, otherwise please feel free to roll back or adapt further. Welcome to Bitcoin.Stackexchange.com. :) – Murch – 2017-05-12T14:31:54.190

Asked: 2017-05-08T17:30:59.440

Viewed: 795 times

Active: 2017-11-25T01:54:38.843