<p>Their assumption is correct: if you send a transaction that gets orphaned, and then send another transaction that goes into the block, the other transaction automatically becomes invalid.</p>

<p>Transactions don't have a timestamp embedded, so miners don't have a way of knowing which transaction came first. They just include the one that first reaches them, which in your scenario will be the second one.</p>

CC BY-SA 3.0
2013-04-26T17:56:11.360Z
But it would depend on how much it was orphaned, correct? If it was temporarily orphaned just because it isn't high enough priority to get space in a block, but had been relayed to miners, then the second transaction would be ignored as a double spend. If it was orphaned because it was so low priority that most clients would not relay it, then the above would apply (and it would be invalid once the second transaction is confirmed). Am I correct?
David Ogren
CC BY-SA 3.0
2013-04-26T18:12:57.153Z
Yes, that is correct. Miners just build a block based on what they got in their memory, there's not much more to it.
Tom van der Woerdt
CC BY-SA 3.0
2013-04-26T17:22:51.030Z
2013-04-26T17:22:51.030Z
Tom van der Woerdt
<p>When there are two blocks both at the same height, each can include the same transaction as each doesn't know about the other.</p>

<p>If there are no double spend conflicts the same transaction would generally exist in both sides of a fork, presuming enough nodes were on each side to relay the transaction to miners of each.</p>

CC BY-SA 3.0
2013-04-27T08:14:30.213Z
2013-04-27T08:14:30.213Z
Stephen Gornick
<p>Here is a scenario someone posed to me and I'd like to check the answer:</p>
<blockquote>
<p>If I send a transaction that gets orphaned and I then issue another transaction from the same address (but include a fee) and this second transaction gets added to the block chain (I have &gt;no reason to see why it wouldn't....there's a good chance other nodes wouldn't even know &gt;about the orphaned block as it may not have been relayed. Can the first transaction be put in a block? When does the transaction get time stamped?</p>
<p>I presumed the answer is that the original transaction will become invalid as it would not be confirmable.  Also, during the orphaned period, the private key could be imported to another &gt;wallet and another transaction issued from that address (AFAIK, no wallet will intentionally &gt;let you construct double spends).</p>
</blockquote>

CC BY-SA 3.0
2013-04-27T08:11:34.467Z
Orphaned is the wrong term for a transaction.  Are you referring to a transaction that was in a block that no longer is in the chain with the greatest height?
Stephen Gornick
<transactions>
Transaction Questions
Charles Hoskinson
# Transaction Questions

(Asked by: username_0 on 2013-04-26)

Here is a scenario someone posed to me and I'd like to check the answer:

> If I send a transaction that gets orphaned and I then issue another transaction from the same address (but include a fee) and this second transaction gets added to the block chain (I have >no reason to see why it wouldn't....there's a good chance other nodes wouldn't even know >about the orphaned block as it may not have been relayed. Can the first transaction be put in a block? When does the transaction get time stamped?
>
> I presumed the answer is that the original transaction will become invalid as it would not be confirmable. Also, during the orphaned period, the private key could be imported to another >wallet and another transaction issued from that address (AFAIK, no wallet will intentionally >let you construct double spends).

**Tags:** transactions

> **Comments:**
> **username_1**: Orphaned is the wrong term for a transaction.  Are you referring to a transaction that was in a block that no longer is in the chain with the greatest height?  

---

## 2 answers

### Answer by username_2 on 2013-04-26. Score: 0 | Accepted answer

Their assumption is correct: if you send a transaction that gets orphaned, and then send another transaction that goes into the block, the other transaction automatically becomes invalid.

Transactions don't have a timestamp embedded, so miners don't have a way of knowing which transaction came first. They just include the one that first reaches them, which in your scenario will be the second one.

> **Comments:**
> **username_3**: But it would depend on how much it was orphaned, correct? If it was temporarily orphaned just because it isn't high enough priority to get space in a block, but had been relayed to miners, then the second transaction would be ignored as a double spend. If it was orphaned because it was so low priority that most clients would not relay it, then the above would apply (and it would be invalid once the second transaction is confirmed). Am I correct?  
> **username_2**: Yes, that is correct. Miners just build a block based on what they got in their memory, there's not much more to it.  

---

### Answer by username_1 on 2013-04-27. Score: 0

When there are two blocks both at the same height, each can include the same transaction as each doesn't know about the other.

If there are no double spend conflicts the same transaction would generally exist in both sides of a fork, presuming enough nodes were on each side to relay the transaction to miners of each.


---

