0

Think about a bitcoin transaction:

Inputs: Address1: 2 BTC, Address2: 1 BTC

Output: Address3: 3 BTC

So the value of Address1 is because of two previous transactions where every one of those 2 transactions sent 1 BTC to Address1. How is a full node now be able to verify that the amount of "2" is correct for the transaction?

2

Transactions don't work like that, so this issue does not arise.

Inputs of a transaction don't specify addresses, they specify previous transactions; more precisely, a particular output from a previous transaction. The data included in an input is a transaction ID and an output index.

So in the example you cite, the transaction would have to have three inputs: one for each of the two Address1 transctions, and a third for the Address2 transaction.

  • Ok, so we can get a step forward. Think about the transaction X with value 2. The input references a transaction and we actually do not know in which block the referenced transaction is. How to prove that value of "2"? – Erhard Dinhobl Oct 6 '16 at 15:12
  • Edleredge: I know how transactions work, but you did not get my question. Some guys only want to get attention with the minimum amount of time spending in the answer. – Erhard Dinhobl Feb 16 '17 at 12:21
  • @ErhardDinhobl: Sorry I missed your previous comment. We have to actually find the referenced transaction in a block (or in the memory pool). This can be done very efficiently by a standard full node because it creates an index of all validated transactions, mapping a txid hash to the block, and offset within the block, where the transaction itself can be found. – Nate Eldredge Feb 16 '17 at 15:55

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.