This is a bit long - please bare with me, i want to understand exactly what a full node and SPV does in verifying transactions and some other things:

  1. Transaction start, A wants to send B, 1 BTC of value.
  2. Lets assume A's wallet controls 2 UTXOs which reference 1.1 of BTC of value in total (0.5 BTC & 0.6 BTC). At this point in time, pre any transaction from A to B, I assume full nodes will have recorded that these UTXOs are indeed unspent so far (?)
  3. A goes ahead and creates this transaction: the inputs to the transaction will refer to the transaction which contains the first 0.5 UTXO as an output with a reference number and a signature (to indeed unlock and spend this UTXO which has been locked to A's public key hash), same for the second UTXO we want to spend (?) The outputs are just one to B (ignoring the 0.1 change back to A), which has the satoshi value being moved, 100m Sats in this case and also a script lock to B's public key hash (?)
  4. The transaction is now sent on to the network.
  5. Full nodes verify: the signature from A does indeed unlock the outputs he wants to spend. These outputs have not been double spent (i.e. they still exist in the set of UTXOs). Inputs >= Outputs (lets ignore tx fees) and some other cursory checks (i.e. size <=21m BTC etc) (?)
  6. Once verified by a full Node (and accepted) they propagate the tx onwards to others they are connected to. They update their state of all UTXOs (removing those which are 'spent' and updating to the new ones created by this tx, which remain unspent).
  7. The tx sits in a pool waiting to be picked up by a miner. Even if this tx in particular is not picked up by any miners for the next block it remains considered 'spent' (?)
  • Lets say it gets mined in block 1000, current block height is 1005.

  • Now moving to SPVs:

  1. B wants to verify that the tx from A->B has indeed gone through.
  2. B runs an SPV node and queries a full node to check this. The full node (for his address) returns him a merkle path and the blockheaders from 1000 to 1005 to verify this.
  3. B, given the tx id, can indeed verify that given the Merkle Path & tx id he can recreate the Merkle Root (so the tx is in the block 1000) (?)
  4. Are the remaining block headers just used for him to verify that given he has verified the Merkle Root in the block header of 1000, he can now hash that, to verify that the next block header (1001) does indeed contain the previous block hash (i.e. that of 1000) (?) to make sure that the block has been built upon and now has 5 confirmations?
  • In point 3 there will be 2 outputs: 1 BTC for B and 0.1 BTC for A (the change).
    – bordalix
    Mar 8 at 7:05
  • yep! sorry thats my typo.
    – user132898
    Mar 8 at 8:36
  • i guess another question would be: before the tx is included in a block the full node probably doesn't drop it from its UTXO set, as it could be in the tx pool for some time before it is picked up. Does part of the full nodes verification of a transaction therefore rely on checking that the current UTXO set does include the UTXO being referenced and also has not already been consumed in the temp tx pool?
    – user132898
    Mar 8 at 10:12


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.