Broadcasting transaction with unconfirmed input(s)

[phedny]

Because of an invitation to a hackathon, I started thinking to work out an idea I had, so it could be implemented during the hackathon weekend.

Relevant for the idea is a question about the following scenario:

I am going to create two transactions, A and B. In B, I need an input that refers to an output with a specific amount, so in tx A I want to create that output.

1. In tx A, I create two outputs: one that holds the exact amount required for tx B and one that holds the change.
2. In tx B, I refer to the output of tx A

I now broadcast both transactions right after each other into the Bitcoin network. How will existing clients (miners) react to tx B, while it is not yet confirmed? Will both transactions be included in the same block, will tx B be rejected altogether until tx A has been confirmed or will client accept tx B, but hold it until A has been confirmed?

[1714172889]

1714172889

[1714172889]

1714172889

[1714172889]

1714172889

[pieppiep]

Do you mean what satoshi dice does?
http://www.satoshidice.com/

[deepceleron]

A transaction will not be included in the blockchain unless the address(es) that are funding it have a confirmed balance equal to or above the input amount. You can see many transactions here that are funded with unconfirmed coins Here - (bitcoincharts.com - warning-10MB web page). Just search for "1dice" and you will see that "Satoshi Dice" is paying out with unconfirmed coins (creating possibly 1000+ transactions that will never complete).
If the second transaction uses an input address with no previous balance, then it will remain pending until the first transaction (that pays adequate funds to that address) is included in the blockchain.

[EhVedadoOAnonimato]

If the second transaction uses an input address with no previous balance, then it will remain pending until the first transaction (that pays adequate funds to that address) is included in the blockchain.

They may be included both at once though, in the same block.

[phedny]

They may be included both at once though, in the same block.

Actually, this is the answer I hoped to get

Is this also the way most implementations work right now?

What I'm working on looks much like https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts and since adding an output to hold the change in the group transaction makes the protocol more complex (and making it two-phase), this is not desired. Adoption of the idea might however be difficult if it requires multiple blocks before the confirmation of tx B is finished.

[nibor]

See transactions for:
http://satoshidice.com/full.php?tx=e5cdfea713b511f993d36a6cad0ab6fe0e4d03ae4f17b3a5ccadb91c610230aa

Both incoming bet and outgoing payment are in same block:
http://blockchain.info/block-index/257078

[jgarzik]

Transactions that cannot be connected to the main chain are known as "orphans."  The standard bitcoin client will keep up to 10,000 orphans in memory, before randomly deleting them to keep that at or below 10,000.

Connect-able transactions are stored in the "memory pool" -- the zero-confirmation state -- until they appear in a block.

Assuming that A is broadcast as well as B, you are connected to the chain, and your transactions will not be orphans.  Nodes will relay A and B for you.

As another poster noted, A and B may appear in the same block.

[phedny]

Okay, cool. Thanks for the answers.

Based on these answers I'm going for the one-phase protocol.

[Mike Hearn]

Are you implementing assurance contracts? Would you give us more details?

As the author of that page I'm interested in anyone who is working on code for it.