Double spending from "green addresses" & mitigation 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 &amp; why)
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.
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.
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).