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!

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.

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?

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.