Can two transactions; one spending the output of another be in the same block?

[No_2]

Can two transactions, one spending the output of the other be broadcast to the network in close succession and end up in the same block?

If this is true, then it is true for larger numbers of transactions? I.e. five transactions in the same block with four dependencies between them? Is there a limit for the number of transactions which can be mined per block in this way?

[1715508717]

1715508717

[1715508717]

1715508717

[1715508717]

1715508717

[1715508717]

1715508717

[PolarPoint]

I have seen it before, so the answer is yes. As long as they are valid transactions on their own with fees, parent and child transactions can be accepted in the same block.

[amaclin]

Can two transactions, one spending the output of the other be broadcast to the network in close succession and end up in the same block?

yes

If this is true, then it is true for larger numbers of transactions?

yes

I.e. five transactions in the same block with four dependencies between them?

yes

Is there a limit for the number of transactions which can be mined per block in this way?

no, there is no such limit.

[zebedee]

Yes, but coins being spent must have been provided in an earlier block, or earlier in the same block (coinbase special of course).  Order matters, in other words.  Chain length unrestricted.

[DannyHamilton]

Can two transactions, one spending the output of the other be broadcast to the network in close succession and end up in the same block?

yes

However, it is important to understand that (due to transaction malleability) the hash of the first transaction can be changed without your consent before it is confirmed.  If this happens and the modified transaction is confirmed, then the second transaction will no longer be valid.  It would need to be re-sent using the new transaction hash to define the input.

For this reason, it is generally not a good idea to spend bitcoins from unconfirmed transactions.

If this is true, then it is true for larger numbers of transactions?

yes

I.e. five transactions in the same block with four dependencies between them?

yes

Is there a limit for the number of transactions which can be mined per block in this way?

no, there is no such limit.

If the transaction hash is modified in any of the transactions in the chain of transactions, then all the transactions after it will become invalid and will all need to be re-sent.

[yakuza699]

I wanted to make my own topic but since this not off-topic then: What miners have implemented child pays for parent(without f2pool and Eligius).Also lets say that I have this kind of tx:A sends to B 0.2BTC the coins are not old enough and pays 0 fee than we have a spending tx from B to C same 0.2 but this time it pays 0.001 fee and both transactions together are less than 1000Bytes. How to get them both confirmed since fee is x10 more but for some reason neither do Eligius neither f2pool confirm them. Why?

[DannyHamilton]

I wanted to make my own topic but since this not off-topic then: What miners have implemented child pays for parent(without f2pool and Eligius).

It's impossible to know.

Even if a pool said they implemented it (or said that they didn't implement it), they could be lying.

Also lets say that I have this kind of tx:A sends to B 0.2BTC the coins are not old enough and pays 0 fee than we have a spending tx from B to C same 0.2 but this time it pays 0.001 fee and both transactions together are less than 1000Bytes. How to get them both confirmed since fee is x10 more but for some reason neither do Eligius neither f2pool confirm them.

Your choices are:

• Wait for a miner or pool to confirm the transactions
• Stop broadcasting the transactions, and after they drop from the memory pools of most peers you can send the first transaction with a fee
• Contact the operator of a large pool, and convince them to confirm the transaction for you

Why?

That's a question for f2pool and for Eligius.  You'll have to ask them.  Perhaps they have a bug in their code and don't realize it?  Perhaps they are lying about implementing child-pays-for-parent? Perhaps there is something about your transaction that is effected by some other decision that they've made?

[amaclin]

What miners have implemented child pays for parent?
[...]
fee is x10 more but for some reason neither do Eligius neither f2pool confirm them. Why?

Because nobody wants to implement it.
(In fact this is the main reason of everything on our planet)
You are welcome to setup your own pool with this feature.
Why are you spending your time asking questions on forum instead of setting up pool with child-pays-for-parent feature?

[yakuza699]

Why are you spending your time asking questions on forum instead of setting up pool with child-pays-for-parent feature?

Maybe because there are already good trusted and reliable pools. And no one will switch to my pool that is untrusted new and has no hashing power just because it has one extra feature(which in fact doesn't benefit them except extra fees from tx's).An easier way out is to convince an operator of a already existing mining pool to implement it.Also even more easier way is to ask core devs to implement it so miners can then switch to it.
Edit: Lets try a different approach https://bitcointalk.org/index.php?topic=952340.msg10427553#msg10427553