<blockquote>
  <p>1) When i send transaction who validate it ? Here I think, who can check and found that I haven't got enough money in my wallet. Example; I send 100 BTC but I have only 50.</p>
</blockquote>

<p>All full nodes validate every single block and transaction they receive. Once a node validates each block and transaction, the block or transaction is forwarded to the nodes that it is connected.</p>

<p>A number of things are checked to ensure that a transaction is legitimate. One of the things checked is the sum of the outputs being spent (i.e. the inputs) is greater than or equal to the sum of the outputs being created. It does this by looking up the outputs that are being spent. Presumably the transactions that those outputs were a part of has already been validated and the node remembers that it determined that transaction to be valid. So when it sees your invalid transaction, it will immediately see that the sum of the outputs being created is greater than the sum of the outputs being spent, which means it is invalid. Your transaction will then be marked invalid and rejected.</p>

<blockquote>
  <p>2) Can one transaction go by mistake in two blocks, and who prevent this ?</p>
</blockquote>

<p>No, a transaction cannot go in two blocks. This is prevented by full nodes which validate every single block and transaction they receive.</p>

CC BY-SA 3.0
2017-10-24T18:12:22.293Z
2017-10-24T18:12:22.293Z
Ava Chow
<p>1) Let's say you are running some sort of malicious client that tries to hoodwink the bitcoin system by pushing transactions to other nodes that aren't 'correct' ie spending coins you don't have. To do so, you would need know what a transaction looks like:</p>

<p>A transaction always moves ALL bitcoin on a number of spending (input) bitcoin addresses to other receiving (output) bitcoin addresses. The word ALL is relevant here; you can't leave some bitcoin on an address, you have to send all or nothing. There is only a distinction between input and output in regards to this transaction, the system only knows addresses. The client spreads the coins from the input addresses out over the output addresses as you decree, but can't send more coins than the sum of all input addresses contain. It can send less, the miner will use the difference as fee.</p>

<p>When your malicious client sends the transaction to the rest of the world, each other bitcoin client will check your transaction for validity. It will check whether or not it outputs more coins than you've input, and it checks the balance on each of the addresses. That last check will flag your transaction as malicious, since all other clients in the world know that your 100btc claim is false, and that only 50btc are on that address.</p>

<p>2) Each transaction is atomic, in the sense that it is a complete entity on its own. Your transaction can't be chopped in pieces (because the system would not know how to do that for an arbitrary transaction) and will thus always be in a single block. </p>

CC BY-SA 3.0
2017-10-24T18:04:54.580Z
This is incorrect. The system only knows inputs and outputs, not addresses. There is no need for you to spend the entire balance associated with an address. You don't spend from an address, you spend Unspent Transaction Outputs which are outputs created by other transactions. These must be spent fully.
Ava Chow
CC BY-SA 3.0
2017-10-24T13:23:20.670Z
2017-10-24T13:23:20.670Z
BlackBeltBob
<p>Short answer, the miners verify and validate your transactions.  The new block that they produce starts the validation for any new broadcast transactions that they choose to accept (if enough fee has been paid. ) </p>

<p>You are the one who validates your own transactions in your client as to whether you can broardcast them at the start.  ie when you broadscast the transaction you provide a hash for that.  that is only valid if you have the correct funds in various addresses to send to the new address.  If you did not have enough funds then your client will not let you broardcast the transaction.  If you try to fudge a transaction then the miners will reject it as it is seen to have a different invalid hash to be accepted on the network.  </p>

CC BY-SA 3.0
2017-10-24T13:03:47.197Z
2017-10-24T13:03:47.197Z
Fuzzybear
<p>Miners check your transaction for balance of: UTXO (unspent transaction outputs), fees and how much you send. If it is OK, TX goes to new block.</p>

CC BY-SA 3.0
2017-10-24T18:27:31.737Z
2017-10-24T22:33:25.550Z
2017-10-24T22:33:25.550Z
Denis Leonov
<p>I'm trying to understand verifying Bitcoin transaction but I can't find this part anywhere. Summary, the process before forming blocks. My questions is:</p>

<p>1) When I send transaction, who validates it ? Here I think, who can check and found that I haven't got enough money in my wallet. Example; I send 100 BTC but I have only 50. 
The problem is bigger because in my prior transactions, refund come back on "new" wallet and who can trace all my wallet to sum how much I have in that situation. I don't speak here on double spending. I understand that part. </p>

<p>2) Can one transaction go by mistake in two blocks, and who prevents this ? </p>

<transactions>
Bitcon transaction verify
noosorog
# Bitcon transaction verify

(Asked by: username_0 on 2017-10-24)

I'm trying to understand verifying Bitcoin transaction but I can't find this part anywhere. Summary, the process before forming blocks. My questions is:

1) When I send transaction, who validates it ? Here I think, who can check and found that I haven't got enough money in my wallet. Example; I send 100 BTC but I have only 50.
The problem is bigger because in my prior transactions, refund come back on "new" wallet and who can trace all my wallet to sum how much I have in that situation. I don't speak here on double spending. I understand that part.

2) Can one transaction go by mistake in two blocks, and who prevents this ?

**Tags:** transactions


---

## 4 answers

### Answer by username_1 on 2017-10-24. Score: 1

> 1) When i send transaction who validate it ? Here I think, who can check and found that I haven't got enough money in my wallet. Example; I send 100 BTC but I have only 50.

All full nodes validate every single block and transaction they receive. Once a node validates each block and transaction, the block or transaction is forwarded to the nodes that it is connected.

A number of things are checked to ensure that a transaction is legitimate. One of the things checked is the sum of the outputs being spent (i.e. the inputs) is greater than or equal to the sum of the outputs being created. It does this by looking up the outputs that are being spent. Presumably the transactions that those outputs were a part of has already been validated and the node remembers that it determined that transaction to be valid. So when it sees your invalid transaction, it will immediately see that the sum of the outputs being created is greater than the sum of the outputs being spent, which means it is invalid. Your transaction will then be marked invalid and rejected.

> 2) Can one transaction go by mistake in two blocks, and who prevent this ?

No, a transaction cannot go in two blocks. This is prevented by full nodes which validate every single block and transaction they receive.


---

### Answer by username_2 on 2017-10-24. Score: 0

1) Let's say you are running some sort of malicious client that tries to hoodwink the bitcoin system by pushing transactions to other nodes that aren't 'correct' ie spending coins you don't have. To do so, you would need know what a transaction looks like:

A transaction always moves ALL bitcoin on a number of spending (input) bitcoin addresses to other receiving (output) bitcoin addresses. The word ALL is relevant here; you can't leave some bitcoin on an address, you have to send all or nothing. There is only a distinction between input and output in regards to this transaction, the system only knows addresses. The client spreads the coins from the input addresses out over the output addresses as you decree, but can't send more coins than the sum of all input addresses contain. It can send less, the miner will use the difference as fee.

When your malicious client sends the transaction to the rest of the world, each other bitcoin client will check your transaction for validity. It will check whether or not it outputs more coins than you've input, and it checks the balance on each of the addresses. That last check will flag your transaction as malicious, since all other clients in the world know that your 100btc claim is false, and that only 50btc are on that address.

2) Each transaction is atomic, in the sense that it is a complete entity on its own. Your transaction can't be chopped in pieces (because the system would not know how to do that for an arbitrary transaction) and will thus always be in a single block.

> **Comments:**
> **username_1**: This is incorrect. The system only knows inputs and outputs, not addresses. There is no need for you to spend the entire balance associated with an address. You don't spend from an address, you spend Unspent Transaction Outputs which are outputs created by other transactions. These must be spent fully.  

---

### Answer by username_3 on 2017-10-24. Score: 0

Short answer, the miners verify and validate your transactions. The new block that they produce starts the validation for any new broadcast transactions that they choose to accept (if enough fee has been paid. )

You are the one who validates your own transactions in your client as to whether you can broardcast them at the start. ie when you broadscast the transaction you provide a hash for that. that is only valid if you have the correct funds in various addresses to send to the new address. If you did not have enough funds then your client will not let you broardcast the transaction. If you try to fudge a transaction then the miners will reject it as it is seen to have a different invalid hash to be accepted on the network.


---

### Answer by username_4 on 2017-10-24. Score: -1

Miners check your transaction for balance of: UTXO (unspent transaction outputs), fees and how much you send. If it is OK, TX goes to new block.


---

