<ol>
<li><p>If service1 trusts service0's green address implicitly, it can send the coins immediately; there is no advantage to waiting. The recipient can then decide how many blocks to wait for before treating the payment as confirmed.</p>

<p>If service0's green address isn't trusted, service1 needs to take into account that if service0 double-spends, service1 will be liable for the reversed transaction to service2. He can remedy it by resending with different coins, but it still won't look good.</p></li>
<li><p>The inputs of a transaction can reference outputs of transactions in the same block. So the block will include (interspersed with other transactions) a sequence of transactions where each one references the previous one.</p></li>
<li><p>As far as I know, no. An input can only reference the output of a previous transaction, where "previous" is either in a previous block or an earlier (in listing order) transaction in the same block. I couldn't find a definite confirmation for this, however.</p>

<p>Why - it makes sense and it makes sure there can be no cycles.</p>

<p>How - I suppose that when a client builds the list of transactions to include in a block, it puts aside any transactions which reference a transaction which was not yet included. Afterwards it can go back to add these transactions (multiple passes may be needed if there is a chain of multiple consecutive transactions).</p></li>
</ol>

CC BY-SA 3.0
2013-01-02T12:19:47.107Z
(2) and (3) are correct. The transactions in a block are processed in order, and later transactions can reference outputs of earlier transactions in the same block. There would be no advantage to allowing them to be out of order, as you'd need cycle detection to prevent loops.
Pieter Wuille
CC BY-SA 3.0
2015-03-17T01:51:37.263Z
Green address transactions are not always on-chain?!
vi.su.
CC BY-SA 3.0
2012-12-31T19:14:34.290Z
2013-01-02T09:45:27.317Z
2013-01-02T09:45:27.317Z
Meni Rosenfeld
<p>Suppose a user pays for a service (<code>service1</code>) using a "green address" (0 confirmations required) and <code>service1</code> needs to immediately respend it using it's own green address  </p>

<ul>
<li>How many blocks should the service wait before respending that money to a normal Bitcoin-QT user?  (assuming the QT client doesn't recognize Green addresses)</li>
</ul>

<p>Suppose the service sends the funds to another service  (<code>service2</code>) that recognizes it's coming from a green address.  There are still zero confirmations.</p>

<ul>
<li><p>What would the block chain look like?  (Specifically can the multiple transactions appear in the same block?)</p></li>
<li><p>Can the multiple zero confirmations appear out of order?  (I know the answer is "no", but I'd like to know how &amp; why)</p></li>
</ul>

<bitcoin-core><doublespend><green-address>
Double spending from "green addresses" & mitigation
makerofthings7
# Double spending from "green addresses" & mitigation

(Asked by: username_0 on 2012-12-31)

Suppose a user pays for a service (`service1`) using a "green address" (0 confirmations required) and `service1` needs to immediately respend it using it's own green address

* How many blocks should the service wait before respending that money to a normal Bitcoin-QT user? (assuming the QT client doesn't recognize Green addresses)

Suppose the service sends the funds to another service (`service2`) that recognizes it's coming from a green address. There are still zero confirmations.

* What would the block chain look like? (Specifically can the multiple transactions appear in the same block?)
* Can the multiple zero confirmations appear out of order? (I know the answer is "no", but I'd like to know how & why)

**Tags:** bitcoin-core, doublespend, green-address


---

## 1 answers

### Answer by username_1 on 2012-12-31. Score: 4 | Accepted answer

1. If service1 trusts service0's green address implicitly, it can send the coins immediately; there is no advantage to waiting. The recipient can then decide how many blocks to wait for before treating the payment as confirmed.

   If service0's green address isn't trusted, service1 needs to take into account that if service0 double-spends, service1 will be liable for the reversed transaction to service2. He can remedy it by resending with different coins, but it still won't look good.
2. The inputs of a transaction can reference outputs of transactions in the same block. So the block will include (interspersed with other transactions) a sequence of transactions where each one references the previous one.
3. As far as I know, no. An input can only reference the output of a previous transaction, where "previous" is either in a previous block or an earlier (in listing order) transaction in the same block. I couldn't find a definite confirmation for this, however.

   Why - it makes sense and it makes sure there can be no cycles.

   How - I suppose that when a client builds the list of transactions to include in a block, it puts aside any transactions which reference a transaction which was not yet included. Afterwards it can go back to add these transactions (multiple passes may be needed if there is a chain of multiple consecutive transactions).

> **Comments:**
> **username_2**: (2) and (3) are correct. The transactions in a block are processed in order, and later transactions can reference outputs of earlier transactions in the same block. There would be no advantage to allowing them to be out of order, as you'd need cycle detection to prevent loops.  
> **username_3**: Green address transactions are not always on-chain?!  

---

