Topic: Trying to understand chain of transactions within the same block (Read 145 times)

It doesn't matter in terms of fees, but it still creates blockchain bloat and still results in blocks filling up more quickly, delaying the confirmation of other transactions.

Perhaps. If I make a transaction with three outputs (two payments and one change), then it is obvious that is the same person paying both those third parties. However, I can make a transaction with two outputs and completely obfuscate which one of those outputs is the change output, then when I send that change output to another third party there would be no way for an outside observer to be sure that it was me making that transaction. There is no requirement for such transactions to be in the same block, though.

I think the most likely reason you will find chains of unconfirmed transaction in the same block are either a centralized service with poor automated systems as HCP has outlined, or a user spending unconfirmed change without understanding what they are doing.

The max limit is 25 unconfirmed parent transactions.

The main reason I can think of is some sort of service or custodial wallet that wishes to promote "instant" withdrawals... User clicks "confirm" on a withdrawal, they want to instantly see a transaction has been created and broadcast.

This is "fine" when the network isn't grossly overloaded and fees are ridiculous and/or the service actually creates transactions with "decent" fees so the transactions don't get stuck.

However, when the first big "flood" happened back in 2017... there were scores and scores of users creating "HELP! stuck transaction!"-type posts where their transaction was like #30 in a chain of unconfirmed transactions, because there were a number of services/wallets using really bad fee estimation (or none at all) and they were just creating enormous chains of unconfirmed transactions with low fees.

It seems that most of the very large sites seem to "batch" withdrawals now... and users seem to accept a "Pending" status for a while, while a number of withdrawals are collated and sent in one outgoing transaction... Although, I'm sure you'll now be able to find chains of unconfirmed "batched" transactions!

Yes I can imagine is pretty inefficient now. But it makes it interesting because in 2011 if you look at the transaction it has a zero fees. If you can get your transaction with zero fees then it doesn't matter if you use the transaction like this or if you use multiple-outputs in just one transaction.


Yes! And this is the kind of behavior that I'm trying to look for. For example if this kind of patterns are found in more recent transactions. Why you would do that? May be you are trying to increase privacy? Who knows.

Thank you again for the feedback!

Sure. In these cases it is probably a big centralized exchange or service processing multiple withdrawals in a row or something similar. As an aside, it's a very inefficient way to use bitcoin, since one transaction with 20 outputs is significantly cheaper than 20 transactions with 2 outputs each all chained together.

It is trivial to create a thousand new addresses, but yes, long chains like the one you have quoted above probably point to an automated process.

Yes I mean, for advanced users I understand is possible. But this particular pattern you have one unspent output, and one spent output chained to the next TX. And I have found chains as long as thousands of transactions chained each-other. For me that would imply some kind of automation.

I mean. You could "craft" a couple of transactions. But in the order of thousands it would imply that you need to generate a thousand new addresses to leave all of this "unspent" outputs. I'm right?

At the end what I'm trying to do is to infer common usage patterns so, probably this kind of very long chains will cluster itself set of users/implementations. Even if they still anonymous I'm just trying to apply this clustering of expending behaviors.

Great! Thank you very much! This clears everything for me regarding the consensus behavior.

You are looking for any wallet which will let you spend unconfirmed outputs. Most good wallets will let you do this, including the most popular wallets of Bitcoin Core and Electrum. You would simply sign and broadcast a transaction which has at least one change output back to your own wallet, and then immediately spend that unconfirmed change output in a new transaction. You can repeat this several times, up to a chain of 25 unconfirmed transactions.

Depending on the fees you choose for each transaction would depend on when they all get mined. If you keep the fees very low for all but the last transaction, and then pay a much higher fee for the last one, there is a good chance of them all being confirmed together in the same block.

Thanks! That's the part that I wanted to understand.


Essentially this is the kind of things that I'm trying to find because I suspect more advanced users (or specific implementations of the client) can be programmed to do this kind of things.

Do you know if there is any kind of common practice or client that allows you to do this kind of chained-transactions?

It's not odd at all. This is normal behavior and occurs quite frequently.

Essentially, yes.

T2 cannot be confirmed until T1 is confirmed. T2 will wait in the mempool until T1 is confirmed, and will be confirmed either at the same time as T1, or in a later block than T1.

What you have described - T2 paying a much higher fee than T1 - is what is known as a "child pays for parent" transaction. If T1 is currently stuck in the mempool with too low a fee, you can make T2 with a much higher fee to effectively "boost" the fee of T1. A miner which wants to mine T2 to claim the high fee will also have to include T1 in the same block. Both transactions will then be mined in the same block, with the T2 child transaction incentivizing the miner to mine the T1 parent transaction, hence, "child pays for parent".

There's no such thing as "broadcasting them at the same time", because there's always a timing race condition induced by network speeds and conditions when you broadcast the transactions. That means that some nodes will receive (T1) first and some will receive (T2) first. The ones that receive (T2) first will reject it until some other nodes which have received (T1) first also send them (T2) once they receive that too.

But for this to work the transactions shouldn't be broadcasted more than a few hundred milliseconds apart from each other, which is only possible if you automate the transaction sending, so it will never be possible to "mouse-click" broadcast them both at once.

Hi all! This is my first post here.

I have recently started to explore the historical bitcoin transactions for analysis. I'm following on the work of applying clustering to map different kind of users based on their transaction behaviors. I'm still on a early-exploratory stage of the analysis and I have found some transaction chains with a behavior that looks confusing to me. I tried to use the search here to found someone talking about this before but found nothing.

If you look at this transaction set from 2011 (Just a small sample):

(a) 71ae7f0ee983b257bd8ef0fecf11be3e3c5aa610988a286bec12fa98d1ef726f
(b) 067807fe9ce6cf33e0fab8912e5a6a15e4e990df50e92a20f0ab898386ed94f6
(c) 5c9ac4770895f00e0c6988689a1a5c5a6ae9b6a182dbce8ca46f3854b8523750
(d) e46e1463321d6adbf65a877634a75ff3cc519905e5670fb8f2a175a402e91350
(e) b76fefcbb5f637b62607091d579ce66c2078a7be627d46f54984a13d16aa3168

It looks like

...->(a)->(b)->(c)->(d)->(e)-> ...

You'll notice that each one of this transactions spends the change from the previous transaction. I think is the normal behavior.  I might suspect this chain of transactions was included by the miner in a low-demand point in time.

What I seem a little bit odd is that all of this very long chain of transactions is included on the same block 72624.

And you can easily infer this from looking at the whole block:
000000000024e041a4600f8ac4a55047457b2c2bc55d1993d755fe60cb5bfc04

I understand that each message is broadcasted independently so this could be a miner splitting his earnings into several addresses (You can see that many of them still unspent). However it's interesting that they can broadcast this chain of transactions and get included on the same block. I was looking at the code of bitcoind and apparently the existence of previous transactions is checked before considering a TX valid.

https://github.com/bitcoin/bitcoin/blob/master/src/consensus/tx_check.cpp

My question then would be: The consensus algorithm also checks against unconfirmed transactions in the mempool?

How this behaviour is handled today and in high-traffic situations? I.E:

I prepare a transaction (T1) (a)->(b) where (a) is an unspent output already verified in a previous block.
But I also prepare another transaction (T2) (b)->(c) that obviously depends on (T1) that is not confirmed yet.

What happens if I broadcast both transactions at the same time and I specify a really high fee for T2 so it can get a higher priority than T1. It's rejected?

I can imagine in 2011 doing this kind of things with low traffic could work, but today I don't know how the consensus algorithm would handle this kind of cases.

Thanks in advance for all the help! If it's a a newbie question please help me to figure where I can find more detailed information for similar cases here in the forum. If this is a common behavior of some specific implementation of bitcoin I would be happy to learn about it.