<p>1, 2 and 3. </p>

<p>Transactions that arrive through inventory announcements on the network are validated completely by checking the form of the transaction for sanity, executing the script, checking signatures, ensuring that the outputs they are spending actually exist, and that the transaction doesn't end up making negative values anywhere. If they are accepted they are added to the nodes memory pool where they wait for inclusion in a block.</p>

<ul>
<li><p>Additionally, non-consensus rules are applied to bare transactions known as IsStandard. On the production network only a small subset of transaction types are "standard", this includes P2SH (pay to script hash) and P2PKH (pay to pubkey hash, or an address), but not raw multisignature and other scripts. Transactions that do not pass are not accepted but relaying a non standard transaction is not a bannable offense.</p></li>
<li><p>After validation, IsMine is run to check if the nodes wallet (if it exists) has the keys which own these transactions, of it they have been added as a watching address, if they do they are marked as unconfirmed in the wallet file. </p></li>
</ul>

<p>Transactions that arrive in a block are completely validated, along with the rest of the structure of the block. The proof of work is checked, the size and form of the block is checked, the merkle tree is validated to contain all the transactions it claims to and that it connects properly with the header. Every transaction is validated, same as if it had arrived from the network. If they are found to be invalid the entire block is thrown out and the peer who relayed the block is banned from connecting. If the block is valid, it is committed and written to the unspent outputs database, additional undo data is written to file if the accepted block is ever needed to be undone.</p>

<ul>
<li><p>IsStandard does not apply here, any transaction that is valid is acceptable when it is included in a block. </p></li>
<li><p>IsMine is run to filter out any transactions relevant to the wallet or watch address (if present), and updates the wallet with confirmations if necessary.</p></li>
</ul>

CC BY-SA 3.0
2015-06-26T03:01:44.600Z
i updated my question slightly. it might have been unclear that i was referring to blockchain transactions. anyway, i think this does not alter your answer. thanks for giving such a comprehensive response!
mulllhausen
CC BY-SA 3.0
2015-06-26T03:40:23.723Z
Transactions in the block chain would be the second portion, when transactions are received in a block. The term block chain just refers to many interlinking blocks so the answer applies cleanly to it as well.
Claris
CC BY-SA 3.0
2015-07-03T06:29:34.007Z
are you sure about this actually? greg maxwell says in a talk i just watched that bitcoind "skips verifying signatures deep in the blockchain because it would take too long" https://youtu.be/Twynh6xIKUc?t=28m20s
mulllhausen
CC BY-SA 3.0
2015-07-03T12:44:31.377Z
What is being talked about there is unique to Bitcoin Core and only happens during the initial sync when `checkpoints` is not disabled in the configuration, once nodes are caught up to the most recent checkpoint they do the full blown verification for all content. It's an unfortunate and inelegant solution to the reality that ECDSA is nasty slow to verify on this sort of scale (much slower than to sign somewhat interestingly).
Claris
CC BY-SA 3.0
2015-07-04T01:36:04.070Z
ah thanks. that's not obvious from his discussion. do you know if checkpoints are on by default? also does the node keep track of the block it has verified upto so it doesn't have to go from the start each time?
mulllhausen
CC BY-SA 3.0
2015-07-04T04:24:40.277Z
Yes checkpoints are on by default. The node only validates from where it left off, but it will roll back the chain slightly and re-validate some previous blocks in an attempt to catch chain state corruption. In current builds this is 288, but was previously 2500 in much older versions of the software. It can be altered with `checkblocks`, and the intensity can be altered with `checklevel`.
Claris
CC BY-SA 3.0
2015-06-25T20:33:19.307Z
2015-06-25T22:40:49.313Z
2015-06-25T22:40:49.313Z
Claris
<p>which types of transactions does bitcoind v0.10 perform checksig validation on?</p>

<ol>
<li>blockchain transactions belonging to a wallet with known private key</li>
<li>blockchain transactions belonging to watch-only-wallet addresses</li>
<li>all transactions in the blockchain</li>
</ol>

<p>my guesses for answers would be 1 - yes, 2 - yes, 3 - no. however i would like confirmation of this.</p>

CC BY-SA 3.0
2015-06-25T21:46:25.660Z
1, 2, 3, and 4: transaction seen on the network but not yet in a block
Pieter Wuille
<bitcoind><validation>
which transactions does bitcoind validate?
mulllhausen
# which transactions does bitcoind validate?

(Asked by: username_0 on 2015-06-25)

which types of transactions does bitcoind v0.10 perform checksig validation on?

1. blockchain transactions belonging to a wallet with known private key
2. blockchain transactions belonging to watch-only-wallet addresses
3. all transactions in the blockchain

my guesses for answers would be 1 - yes, 2 - yes, 3 - no. however i would like confirmation of this.

**Tags:** bitcoind, validation

> **Comments:**
> **username_1**: 1, 2, 3, and 4: transaction seen on the network but not yet in a block  

---

## 1 answers

### Answer by username_2 on 2015-06-25. Score: 5 | Accepted answer

1, 2 and 3.

Transactions that arrive through inventory announcements on the network are validated completely by checking the form of the transaction for sanity, executing the script, checking signatures, ensuring that the outputs they are spending actually exist, and that the transaction doesn't end up making negative values anywhere. If they are accepted they are added to the nodes memory pool where they wait for inclusion in a block.

* Additionally, non-consensus rules are applied to bare transactions known as IsStandard. On the production network only a small subset of transaction types are "standard", this includes P2SH (pay to script hash) and P2PKH (pay to pubkey hash, or an address), but not raw multisignature and other scripts. Transactions that do not pass are not accepted but relaying a non standard transaction is not a bannable offense.
* After validation, IsMine is run to check if the nodes wallet (if it exists) has the keys which own these transactions, of it they have been added as a watching address, if they do they are marked as unconfirmed in the wallet file.

Transactions that arrive in a block are completely validated, along with the rest of the structure of the block. The proof of work is checked, the size and form of the block is checked, the merkle tree is validated to contain all the transactions it claims to and that it connects properly with the header. Every transaction is validated, same as if it had arrived from the network. If they are found to be invalid the entire block is thrown out and the peer who relayed the block is banned from connecting. If the block is valid, it is committed and written to the unspent outputs database, additional undo data is written to file if the accepted block is ever needed to be undone.

* IsStandard does not apply here, any transaction that is valid is acceptable when it is included in a block.
* IsMine is run to filter out any transactions relevant to the wallet or watch address (if present), and updates the wallet with confirmations if necessary.

> **Comments:**
> **username_0**: i updated my question slightly. it might have been unclear that i was referring to blockchain transactions. anyway, i think this does not alter your answer. thanks for giving such a comprehensive response!  
> **username_2**: Transactions in the block chain would be the second portion, when transactions are received in a block. The term block chain just refers to many interlinking blocks so the answer applies cleanly to it as well.  
> **username_0**: are you sure about this actually? greg maxwell says in a talk i just watched that bitcoind "skips verifying signatures deep in the blockchain because it would take too long" https://youtu.be/Twynh6xIKUc?t=28m20s  
> **username_2**: What is being talked about there is unique to Bitcoin Core and only happens during the initial sync when `checkpoints` is not disabled in the configuration, once nodes are caught up to the most recent checkpoint they do the full blown verification for all content. It's an unfortunate and inelegant solution to the reality that ECDSA is nasty slow to verify on this sort of scale (much slower than to sign somewhat interestingly).  
> **username_0**: ah thanks. that's not obvious from his discussion. do you know if checkpoints are on by default? also does the node keep track of the block it has verified upto so it doesn't have to go from the start each time?  
> **username_2**: Yes checkpoints are on by default. The node only validates from where it left off, but it will roll back the chain slightly and re-validate some previous blocks in an attempt to catch chain state corruption. In current builds this is 288, but was previously 2500 in much older versions of the software. It can be altered with `checkblocks`, and the intensity can be altered with `checklevel`.  

---

