<p>Just to expand on Jannes's answer: before including a transaction in a block, a miner does effectively check that all inputs to this transaction are already in this block or some previous block, as well as all inputs to those transactions, and so on recursively back to where the coins were created.  In fact, every full node on the network performs this same check on every transaction in every new block they receive, because this is a requirement for the block to be accepted as valid.</p>

<p>But the miner or node can accomplish this without rescanning the block chain every time.  When they first downloaded the block chain, they created a local index of all valid transactions, which is stored on disk.  A new transaction is not entered into this index unless all its inputs are already in the index.  If you think about the recursive nature of the check for a moment, you'll see that finding a transaction in the index implies that it, and all of its parents, are valid - and so the check can be done in very little time.</p>

CC BY-SA 3.0
2015-07-23T16:07:11.800Z
2015-07-23T16:07:11.800Z
Nate Eldredge
<p>They don't have to be on the same block, but as they do depend on each other the BobD->Bob transaction can only be mined if Alice->BobD is already in the same or an earlier block. If not, the entire block would be invalid and noone would accept it.</p>

<p>Note that smart miners would add up the fees for both transactions and on the basis of that decide whether to include it in a block or not. So Alice->BobD might have 0 fee and therefore not be interesting for miners, but if BobD->Bob pays enough fee to compensate for it, a miner might include both transactions in the same block. This is known as Child Pays For Parent or CPFP. I don't think it's very common yet for miners to have this implemented at the moment. <a href="https://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-large-miners-running-child-pays-for-parent-patch">Are there any pools or large miners running &quot;child pays for parent&quot; patch?</a></p>

CC BY-SA 3.0
2015-07-23T15:56:53.817Z
2015-07-23T15:56:53.817Z
2017-04-13T12:47:33.610Z
Jannes
<p>My question in quite conceptual:</p>

<p>For creating a raw transaction, I just need the txid from the older transaction and the address to send it. Put the funds, the change, what's left is the fee. Sign it and broadcast it.</p>

<p>Let's say Alice sends to Bob's disposable address some funds. Bob has a "master address". Whatever funds he gets on the disposables addressess he sends to his master one. Bob runs a full node and get the transaction before it gets confirmed on the blockchain.</p>

<p>When Bob receives the broadcasted Alice transaction, Bob gets the raw transaction sent to his disposable address, get the txid, put the funds, put the address of his "master" address, change, fee, sign it and broadcast a new transaction, getting the funds sent from Alice to his master address.</p>

<p>So, now, Alice sends to BobDisp (Bob's disposable address) that sends to Bob. All those transactions have 0 confirmations and are both valid.</p>

<p>For the point of the argument. Alice sent the transaction with 0 (ZERO) fee. Bob signed his transaction with a 'standard' fee (let's say 0.0003 BTC), which has a high priority.</p>

<p>When miners get the transactions to mine, do they know that both have to be on the same block? Or what happens if the block is mined with only 'BobD -> Bob' transaction (without the Alice -> BobD)? Is the block invalid? </p>

<p>The miners won't rescan the whole blockchain to know that the 'BobD -> Bob' uses the funds of a new transaction, right? The Alice transaction could be 50000 blocks old or, in this case, a new one. </p>

<p>PS: not sure if it is clear. thanks</p>

<transactions><blockchain><transaction-fees><block><transaction-id>
Sending funds on same block of received funds. Confirm sending not received?
anonimou
# Sending funds on same block of received funds. Confirm sending not received?

(Asked by: username_0 on 2015-07-23)

My question in quite conceptual:

For creating a raw transaction, I just need the txid from the older transaction and the address to send it. Put the funds, the change, what's left is the fee. Sign it and broadcast it.

Let's say Alice sends to Bob's disposable address some funds. Bob has a "master address". Whatever funds he gets on the disposables addressess he sends to his master one. Bob runs a full node and get the transaction before it gets confirmed on the blockchain.

When Bob receives the broadcasted Alice transaction, Bob gets the raw transaction sent to his disposable address, get the txid, put the funds, put the address of his "master" address, change, fee, sign it and broadcast a new transaction, getting the funds sent from Alice to his master address.

So, now, Alice sends to BobDisp (Bob's disposable address) that sends to Bob. All those transactions have 0 confirmations and are both valid.

For the point of the argument. Alice sent the transaction with 0 (ZERO) fee. Bob signed his transaction with a 'standard' fee (let's say 0.0003 BTC), which has a high priority.

When miners get the transactions to mine, do they know that both have to be on the same block? Or what happens if the block is mined with only 'BobD -> Bob' transaction (without the Alice -> BobD)? Is the block invalid?

The miners won't rescan the whole blockchain to know that the 'BobD -> Bob' uses the funds of a new transaction, right? The Alice transaction could be 50000 blocks old or, in this case, a new one.

PS: not sure if it is clear. thanks

**Tags:** transactions, blockchain, transaction-fees, block, transaction-id


---

## 2 answers

### Answer by username_1 on 2015-07-23. Score: 2 | Accepted answer

Just to expand on username_2's answer: before including a transaction in a block, a miner does effectively check that all inputs to this transaction are already in this block or some previous block, as well as all inputs to those transactions, and so on recursively back to where the coins were created. In fact, every full node on the network performs this same check on every transaction in every new block they receive, because this is a requirement for the block to be accepted as valid.

But the miner or node can accomplish this without rescanning the block chain every time. When they first downloaded the block chain, they created a local index of all valid transactions, which is stored on disk. A new transaction is not entered into this index unless all its inputs are already in the index. If you think about the recursive nature of the check for a moment, you'll see that finding a transaction in the index implies that it, and all of its parents, are valid - and so the check can be done in very little time.


---

### Answer by username_2 on 2015-07-23. Score: 2

They don't have to be on the same block, but as they do depend on each other the BobD->Bob transaction can only be mined if Alice->BobD is already in the same or an earlier block. If not, the entire block would be invalid and noone would accept it.

Note that smart miners would add up the fees for both transactions and on the basis of that decide whether to include it in a block or not. So Alice->BobD might have 0 fee and therefore not be interesting for miners, but if BobD->Bob pays enough fee to compensate for it, a miner might include both transactions in the same block. This is known as Child Pays For Parent or CPFP. I don't think it's very common yet for miners to have this implemented at the moment. [Are there any pools or large miners running "child pays for parent" patch?](https://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-large-miners-running-child-pays-for-parent-patch)


---

