<blockquote>
<p>My question is, if that is the case, why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain?</p>
</blockquote>
<p>A node has no concept of who controls certain outputs. So there is no way to 'check all of Alice's outputs', how would the node be able to ascertain which outputs belong to her?</p>
<p>Rather, the normal operation of a node is to check <em>all</em> transactions, to ensure that no transaction has spent coins that were previously spent (and to check that new coins aren't being created against the network's rules, etc). In doing this check, the node creates an index of unspent transaction outputs (UTXOs), which it will use to help check validity of new transactions.</p>

CC BY-SA 4.0
2020-06-24T12:36:51.067Z
A full node knows ownership of all existing bitcoins in the sense that every sane full node keeps a database for the whole UTXO set, however obviously the UTXO set still comes from the blockchain, which contains all transactions.
Chris Chen
CC BY-SA 4.0
2020-06-25T01:38:39.617Z
@ChrisChen right, a node is aware of the lock that is put on each UTXO, but is not aware of *who* may own the key to that lock, or which locks may be owned by the same user. OP's question seems to imply that a node could 'only consider transactions signed by user X', but of course with that information being un-knowable, the node must actually check *every* historical transaction for validity, in order to determine the validity of any one specific transaction.
chytrik
CC BY-SA 4.0
2020-06-25T02:09:16.333Z
I thought the OP assumed that a full node would intensively read historical blocks during the validation process.
Chris Chen
CC BY-SA 4.0
2020-06-25T04:56:06.523Z
Ah, I understand your comment better now. Made a slight edit so that my answer is less ambiguous in that sense.
chytrik
CC BY-SA 4.0
2020-06-25T05:29:27.180Z
I see scantxoutset of Bitcoin Core displaying block height, so that it's indeedly an index, however I would rather think it as the implied "final balance" of the blockchain ledger (which contains "transaction history" only). By the way I think block height can help a wallet tied to a local pruned node to recover the final balance directly without rescanning the blockchain. (although there's issue like unknown child key index) This also seems to help in the recent hardware wallet compatibility issue caused by fixing the BIP143 vulnerability.
Chris Chen
CC BY-SA 4.0
2020-06-24T01:43:03.600Z
2020-06-25T04:54:53.873Z
2020-06-25T04:54:53.873Z
chytrik
<p>To be short:</p>
<p>Without a ledger recording everything, it won't be possible to know whether Alice had ever signed another double-spending transaction. Even if we have a ledger, or even better, a tamper-evident, append-only ledger (which is the inherent nature of blockchain), it's still enough, because the ledger itself could still be maliciously truncated &amp; appended with dishonest new records. Therefore we need a consensus mechanism to allow every participant of the system to know which ledger is valid without a central authority. In Bitcoin, such mechanism is Proof-of-Work, aka PoW or mining.</p>
<p>Note that if a full node doesn't check everything, it would allow much more malicious things including inflation/counterfeit/theft.</p>
<hr />
<blockquote>
<p>why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain?</p>
</blockquote>
<blockquote>
<p>Why can’t it just check against Alice’s other transactions since you know she controls that coin.</p>
</blockquote>
<p>In reality a full node checks everything in the blockchain, including Alice's ones. <strong>Only after checking every transaction in the blockchain can a full node know all Alice's transactions.</strong> (in the beginning I didn't notice this point, thanks to @chytrik!)</p>
<p>Once Alice spent some of her bitcoins, any sane &amp; in-sync full node would delete corresponding UTXO entry from its UTXO set database, so that if Alice wants to spend the same coins once again, any sane full node would spot its violation against rules &amp; discard such transaction.</p>
<hr />
<blockquote>
<p>Would it be correct to say that the full nodes check to see if the sender(Alice’s) signature is valid. And they check against double spends by seeing if the hash value that is included (of the transaction where Alice received the bitcoin) has ever been used an another transaction?</p>
</blockquote>
<p>Yes, it's correct. In reality it has been done in a much more efficient way without intensively reading the blockchain.</p>
<p>Validation of the blockchain of Bitcoin is progressive in real world, which still matches the &quot;checking against the entire blockchain&quot; criteria in theory.</p>
<p>The Bitcoin blockchain is simply a ledger containing &quot;transaction history&quot; only. The &quot;final/historical balance&quot; is not (yet) committed to the blockchain. Although Satoshi Nakamoto's whitepaper didn't mention these terms, essentially <strong>the blockchain itself is the &quot;transaction history&quot;</strong>, and <strong>the UTXO set</strong> (which is recalculated from the blockchain by each full node on its own. In other words it's &quot;implied&quot; by the blockchain) is the <strong>&quot;final balance of everyone&quot;</strong> or &quot;fully-detailed <strong>ownership</strong> information of all <strong>existing</strong> bitcoins&quot;.</p>
<p><strong>&quot;Ownership&quot;</strong> means what it literally means. It's technically the scriptPubkey of each transaction output, which is a script validating digital signature against a public key hash in most cases.</p>
<p><strong>&quot;Existing&quot;</strong> means that spending a bitcoin is essentailly deleting corresponding UTXO entry in the database. Oh, in most cases it also creates new UTXO entries, which are the actual payment to the payee and the change sent back to the payer generally.</p>
<p>In reality, the blockchain validation is a progressive process that, the full node just query &amp; update the UTXO set database while reading each block, so that the historical block could be even directly deleted, which is exactly what the currently implemented &quot;blockchain pruning&quot; feature actually does.</p>
<p><strong>Why the historical blocks can be simply discarded? Because, the historical blocks are no longer needed at all in the follow-up validation process, where only the UTXO set needs to be queried &amp; updated. In other words, the &quot;effects&quot; of each transaction in each block is actually reflected on the UTXO set already.</strong></p>
<p><strong>Generally, a full node downloads &amp; verifies the whole blockchain from the genesis block</strong> (oh, the genesis block itself is hard-coded), so that even if the blockchain pruning feature is enabled (so that all old block files are simply deleted), <strong>it still matches the &quot;checking against the entire blockchain&quot; criteria in theory.</strong></p>
<p>(However there's still a detail that the <code>assumevalid</code> feature is enabled by default, so that a full node won't actually check everything of the blockchain. <code>assumevalid</code> is basically a block hash hard-coded by the developers, which means at least the developers themselves have fully validated all previous blocks before it, let alone thousands of other running full nodes all around the world. If you want the full node software to do real full validation that all historical blocks would be still fully validated, you need to turn off this feature)</p>
<hr />
<p>However, preventing double-spending is not as simple as checking everything within a (individual &quot;forked branch&quot; of) blockchain. Even if a full node checks everything in the blockchain, Alice could still make up a &quot;forked branck&quot; of the blockchain ledger where she sent her bitcoins to herself, instead of the original payee, if she wants to double-spend - that's exactly why Bitcoin needs a consensus mechanism, which is Proof-of-Work, aka PoW or mining.</p>
<p>(PoW or consensus mechanism is actually not a simple thing like that. For example, an attacker can DoS the network by making infinite forks as well)</p>
<p>Anyone can be a miner, however any block needs some work (mining, which consumes electricity) accumulated on it to be accepted by other participants (full node or SPV) of the network, so that making up lies (invalid blocks) would inevitably have real costs. Making valid blocks also has costs, however this would be &quot;compensated&quot; by the rewards, including newly-issued bitcoins and transaction fees.</p>
<p><strong>Double-spending (forked branch of) blockchain is (inevitably) valid against the rules as well</strong> (not like the case that an invalid blockchain always violates the rules), <strong>however being &quot;valid&quot; doesn't mean being &quot;winning&quot;</strong>.</p>
<p>A valid blockchain has to accumulate the most work at same time to be the winning one, otherwise it still won't be accepted by a full node.</p>
<p>That's the well-known <strong>&quot;the longest chain rule&quot;</strong> (which was actually a tiny but serious mistake corrected by Satoshi himself, to be then changed to &quot;the most accumulated work rule&quot;). Together with other validation rules enforced by every full node, the ruleset incentivises miners to keep honest (only making valid blocks at the chain tip to extend the valid &amp; winning chain even longer).</p>
<p>(Note that SPV client cannot validate the blockchain on its own, therefore it would simply follow the chain with the most accumulated work blindly, however it can still notice whether more than one forks are present)</p>
<p>A malicious miner doing the double-spending faces the risk that his forked chain could be eventually rejected by the network if he won't be able to keep his forked chain to accumulate the most work (among all forked branches, including the &quot;honest&quot; one) on it.</p>
<p>According to the calculations in Satoshi's whitepaper, an attacker (including both miners as an attackers themselves and &quot;dishonest&quot; miners in collusion with the attacker) with more than 50% of hashpower theoretically has 100% probability to be succeed, if he can maintain this for a long enough time. If the attacker doesn't have more than 50% of hashpower, he would inevitably face exponentially dropping success probability as the confirmation number grows.</p>

CC BY-SA 4.0
2020-06-24T11:43:56.047Z
2020-06-25T02:11:00.813Z
2020-06-25T02:11:00.813Z
Chris Chen
<p>Simply, the block chain is to prevent double spending. Otherwise Alice could present different transactions to different people, all with valid signatures, that spend the same money in alternate ways. With a ledger containing every transaction that has been executed, we know that the money can be spent exactly once.</p>

CC BY-SA 4.0
2020-06-24T12:28:47.853Z
The blockchain itself as a tamper-evident, append-only ledger cannot prevent double spending, unless the "blockchain" means not only a ledger, but a whole system including a consensus mechanism like PoW.
Chris Chen
CC BY-SA 4.0
2020-06-24T01:10:10.050Z
2020-06-24T01:10:10.050Z
Claris
<p>I am fairly new to crypto and had some questions about how transactions are verified by the nodes</p>
<p>Would it be correct to say that the full nodes check to see if the sender(Alice’s) signature is valid. And they check against double spends by seeing if the hash value that is included (of the transaction where Alice received the bitcoin) has ever been used an another transaction?</p>
<p>My question is, if that is the case, why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain?</p>
<p>Why can’t it just check against Alice’s other transactions since you know she controls that coin.</p>

CC BY-SA 4.0
2020-06-24T20:44:37.143Z
How do you know that Bob doesn't also control that coin? I can make a transaction output that anyone can claim if I want to.
David Schwartz
<blockchain><transaction-verification>
Basic question about transaction verification
vf990
# Basic question about transaction verification

(Asked by: username_0 on 2020-06-24)

I am fairly new to crypto and had some questions about how transactions are verified by the nodes

Would it be correct to say that the full nodes check to see if the sender(Alice’s) signature is valid. And they check against double spends by seeing if the hash value that is included (of the transaction where Alice received the bitcoin) has ever been used an another transaction?

My question is, if that is the case, why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain?

Why can’t it just check against Alice’s other transactions since you know she controls that coin.

**Tags:** blockchain, transaction-verification

> **Comments:**
> **username_1**: How do you know that Bob doesn't also control that coin? I can make a transaction output that anyone can claim if I want to.  

---

## 3 answers

### Answer by username_2 on 2020-06-24. Score: 3

> My question is, if that is the case, why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain?

A node has no concept of who controls certain outputs. So there is no way to 'check all of Alice's outputs', how would the node be able to ascertain which outputs belong to her?

Rather, the normal operation of a node is to check *all* transactions, to ensure that no transaction has spent coins that were previously spent (and to check that new coins aren't being created against the network's rules, etc). In doing this check, the node creates an index of unspent transaction outputs (UTXOs), which it will use to help check validity of new transactions.

> **Comments:**
> **username_3**: A full node knows ownership of all existing bitcoins in the sense that every sane full node keeps a database for the whole UTXO set, however obviously the UTXO set still comes from the blockchain, which contains all transactions.  
> **username_2**: @username_3 right, a node is aware of the lock that is put on each UTXO, but is not aware of *who* may own the key to that lock, or which locks may be owned by the same user. OP's question seems to imply that a node could 'only consider transactions signed by user X', but of course with that information being un-knowable, the node must actually check *every* historical transaction for validity, in order to determine the validity of any one specific transaction.  
> **username_3**: I thought the OP assumed that a full node would intensively read historical blocks during the validation process.  
> **username_2**: Ah, I understand your comment better now. Made a slight edit so that my answer is less ambiguous in that sense.  
> **username_3**: I see scantxoutset of Bitcoin Core displaying block height, so that it's indeedly an index, however I would rather think it as the implied "final balance" of the blockchain ledger (which contains "transaction history" only). By the way I think block height can help a wallet tied to a local pruned node to recover the final balance directly without rescanning the blockchain. (although there's issue like unknown child key index) This also seems to help in the recent hardware wallet compatibility issue caused by fixing the BIP143 vulnerability.  

---

### Answer by username_3 on 2020-06-24. Score: 1

To be short:

Without a ledger recording everything, it won't be possible to know whether Alice had ever signed another double-spending transaction. Even if we have a ledger, or even better, a tamper-evident, append-only ledger (which is the inherent nature of blockchain), it's still enough, because the ledger itself could still be maliciously truncated & appended with dishonest new records. Therefore we need a consensus mechanism to allow every participant of the system to know which ledger is valid without a central authority. In Bitcoin, such mechanism is Proof-of-Work, aka PoW or mining.

Note that if a full node doesn't check everything, it would allow much more malicious things including inflation/counterfeit/theft.

---

> why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain?

> Why can’t it just check against Alice’s other transactions since you know she controls that coin.

In reality a full node checks everything in the blockchain, including Alice's ones. **Only after checking every transaction in the blockchain can a full node know all Alice's transactions.** (in the beginning I didn't notice this point, thanks to @username_2!)

Once Alice spent some of her bitcoins, any sane & in-sync full node would delete corresponding UTXO entry from its UTXO set database, so that if Alice wants to spend the same coins once again, any sane full node would spot its violation against rules & discard such transaction.

---

> Would it be correct to say that the full nodes check to see if the sender(Alice’s) signature is valid. And they check against double spends by seeing if the hash value that is included (of the transaction where Alice received the bitcoin) has ever been used an another transaction?

Yes, it's correct. In reality it has been done in a much more efficient way without intensively reading the blockchain.

Validation of the blockchain of Bitcoin is progressive in real world, which still matches the "checking against the entire blockchain" criteria in theory.

The Bitcoin blockchain is simply a ledger containing "transaction history" only. The "final/historical balance" is not (yet) committed to the blockchain. Although Satoshi Nakamoto's whitepaper didn't mention these terms, essentially **the blockchain itself is the "transaction history"**, and **the UTXO set** (which is recalculated from the blockchain by each full node on its own. In other words it's "implied" by the blockchain) is the **"final balance of everyone"** or "fully-detailed **ownership** information of all **existing** bitcoins".

**"Ownership"** means what it literally means. It's technically the scriptPubkey of each transaction output, which is a script validating digital signature against a public key hash in most cases.

**"Existing"** means that spending a bitcoin is essentailly deleting corresponding UTXO entry in the database. Oh, in most cases it also creates new UTXO entries, which are the actual payment to the payee and the change sent back to the payer generally.

In reality, the blockchain validation is a progressive process that, the full node just query & update the UTXO set database while reading each block, so that the historical block could be even directly deleted, which is exactly what the currently implemented "blockchain pruning" feature actually does.

**Why the historical blocks can be simply discarded? Because, the historical blocks are no longer needed at all in the follow-up validation process, where only the UTXO set needs to be queried & updated. In other words, the "effects" of each transaction in each block is actually reflected on the UTXO set already.**

**Generally, a full node downloads & verifies the whole blockchain from the genesis block** (oh, the genesis block itself is hard-coded), so that even if the blockchain pruning feature is enabled (so that all old block files are simply deleted), **it still matches the "checking against the entire blockchain" criteria in theory.**

(However there's still a detail that the `assumevalid` feature is enabled by default, so that a full node won't actually check everything of the blockchain. `assumevalid` is basically a block hash hard-coded by the developers, which means at least the developers themselves have fully validated all previous blocks before it, let alone thousands of other running full nodes all around the world. If you want the full node software to do real full validation that all historical blocks would be still fully validated, you need to turn off this feature)

---

However, preventing double-spending is not as simple as checking everything within a (individual "forked branch" of) blockchain. Even if a full node checks everything in the blockchain, Alice could still make up a "forked branck" of the blockchain ledger where she sent her bitcoins to herself, instead of the original payee, if she wants to double-spend - that's exactly why Bitcoin needs a consensus mechanism, which is Proof-of-Work, aka PoW or mining.

(PoW or consensus mechanism is actually not a simple thing like that. For example, an attacker can DoS the network by making infinite forks as well)

Anyone can be a miner, however any block needs some work (mining, which consumes electricity) accumulated on it to be accepted by other participants (full node or SPV) of the network, so that making up lies (invalid blocks) would inevitably have real costs. Making valid blocks also has costs, however this would be "compensated" by the rewards, including newly-issued bitcoins and transaction fees.

**Double-spending (forked branch of) blockchain is (inevitably) valid against the rules as well** (not like the case that an invalid blockchain always violates the rules), **however being "valid" doesn't mean being "winning"**.

A valid blockchain has to accumulate the most work at same time to be the winning one, otherwise it still won't be accepted by a full node.

That's the well-known **"the longest chain rule"** (which was actually a tiny but serious mistake corrected by Satoshi himself, to be then changed to "the most accumulated work rule"). Together with other validation rules enforced by every full node, the ruleset incentivises miners to keep honest (only making valid blocks at the chain tip to extend the valid & winning chain even longer).

(Note that SPV client cannot validate the blockchain on its own, therefore it would simply follow the chain with the most accumulated work blindly, however it can still notice whether more than one forks are present)

A malicious miner doing the double-spending faces the risk that his forked chain could be eventually rejected by the network if he won't be able to keep his forked chain to accumulate the most work (among all forked branches, including the "honest" one) on it.

According to the calculations in Satoshi's whitepaper, an attacker (including both miners as an attackers themselves and "dishonest" miners in collusion with the attacker) with more than 50% of hashpower theoretically has 100% probability to be succeed, if he can maintain this for a long enough time. If the attacker doesn't have more than 50% of hashpower, he would inevitably face exponentially dropping success probability as the confirmation number grows.


---

### Answer by username_4 on 2020-06-24. Score: 1

Simply, the block chain is to prevent double spending. Otherwise Alice could present different transactions to different people, all with valid signatures, that spend the same money in alternate ways. With a ledger containing every transaction that has been executed, we know that the money can be spent exactly once.

> **Comments:**
> **username_3**: The blockchain itself as a tamper-evident, append-only ledger cannot prevent double spending, unless the "blockchain" means not only a ledger, but a whole system including a consensus mechanism like PoW.  

---

