What happened with this guy's multiple transaction outputs in one block?

hey, I spotted something pretty weird. So, this dude transferred 37.7 btc from wallet A to wallet B, then B sent it to C, C to D, D to E... basically around 100 transactions to wallet Z all in the same block. How did that work? It's like the pending tx was getting sent around from one wallet to another all in block 935580. Is this some sort of double spending situation or what? Here's the transaction info, the wallets were trading this 37.7 btc back and forth from A to B, B to C, and so on. wallet a: https://mempool.space/address/1Ct4GW3Qst8g7n4MNgfECUztpTELbzbXeX wallet b: https://mempool.space/address/17AJ2axuHQ9oR1VbtWyy2VWVU7d9jPKZFK wallet c: https://mempool.space/address/1LVuM3V4uVoVNUpZTEQ5HL4snkhmiX9qpm

No. It's someone who's paying multiple different addresses, and after each payments uses his own change to make another payment. You can have up to 25 (I think) unconfirmed "parents", and at the right fee they'll all be confirmed in the same block. It's normal. He could save on transaction fees by paying all destination addresses in one transaction.

This is simply what we call child pay for parent (CPFP) where you can use the incoming child transaction as a parent transaction but you have to spend more fees that can also get the first parent transaction confirmed, You can see that the Wallet A was sent to Wallet B and wallet B was sent to Wallet C and so on. So this is how it works, the first or initial parent transaction will be from wallet A, once it got sent to Wallet B, the wallet B proceed by sending to wallet C even before Wallet A transaction was confirmed and this was possible with a higher transaction fee than that of Wallet A, Then before the transaction got confirmed in wallet C it was immediately sent wallet D and that’s how it was done, since the transaction fees of the child transaction was higher all transactions were confirmed in same block, Had it been that the initial transaction (wallet A transaction) had a very lower transaction fee and wasn’t accepted in that block all transactions would have been invalid because they do not have a parent transaction. This is possible only if the all the wallet keys or seeds are actually with the sender, it is similar to RBF but you are actually just spending an unconfirmed parent transaction from the receiving wallet

It's not CPFP, all transactions pay the same (1.08 sat/vbyte).

I have spent some time looking into this (I didn’t check any of the transactions above) and it seems that we can call this a “chain of transactions.” At first glance, it looks like a CPFP transaction (I was about to start arguing about this) but it’s not. Loyce is right, it’s not a CPFP transaction (it certainly doesn’t look like one).

For many wallets this is an option which isn't enabled by default, I think: "Spend unconfirmed change" (Bitcoin Core, Expert options on Wallet tab) or similarly phrased like "Spend unconfirmed coins/UTXO" This means you can spend your own yet unconfirmed coins which are waiting in mempool to be mined in a block. If you create multiple such transactions and all have suitable transaction fees, they can and likely will be mined in one of the next upcoming blocks, depending on the paid transaction fees. I found this in release notes of Bitcoin Core 0.12.0 which confirms LoyceV statement in his first reply here. This is a longer tx chain spread over multiple blocks for whatever purpose and e.g. in block #935580 starts with tx 6f86230c...4c954812 spending to OP's first mentioned destination change address with a chain length of 19, so well within limits, and later continues in block #935584. I didn't follow the chain any further to earlier block #935573 or past #935584.

Are you saying what @Elmoha is saying is totally wrong? Because I was flowing with his explanation and I was so convinced it makes sense. now I don’t know what to take here and I really want to get the better explanation.

In block #935580 it is a linked and dependent chain of transactions which are likely mined as a package, but it's not really CPFP because the initial transaction already paid more than enough transaction fees to be mined in that block. There was no need to increase the transaction fees of the chain package by the descendant transactions, therefore strictly technically no CPFP because the initial parent already paid enough tx fees.

CPFP is used to increase the effective fee rate and make the transaction(s) get confirmed faster. Assume that you have an incoming unconfirmed transaction with the fee rate of 0.6 sat/vbyte. If you make a new transaction spending the funds received in the unconfirmed transaction with the fee rate of more than 0.6 at/vbyte, you increase the effective rate and you do CPFP (This is assuming both transactions have the same virtual size). If the fee rate you use for the new transaction is 0.6 sat/vbyte or less, it doesn't help the unconfirmed transaction to get confirmed and it's not CPFP.

This is one of those less known features of Bitcoin. Transactions have an order inside a block and when you verify them you do it in that order (coinbase, tx1, tx2, ...). Each time you verify a transaction, you can add the outputs of that tx to your UTXO set and those UTXOs can be spent in that same block in transactions that come after that initial tx. And that "chain of transactions" can go on until the block is full or the standard rules allow. You can have something like this in your block: This consensus rule is what allows us to have features such as CPFP.

This isn't ELI5 but should be easily understandable enough; Pointers first: Each Bitcoin Nodes have a "mempool" where they store unconfirmed transactions, that include nodes that are miners.A transaction consist of UTXO (Unpent Transaction Output), ones that are to-be-spent (inputs) and the new ones that will be created from it (outputs).Most wallets can already create and broadcast transactions that spend UTXO that aren't already in a block, those are just temporarily kept in mempools. So, when a miner selects which transaction to include to his block, he'll get the ones that have the highest fee rate, in this case it happens that those transactions that were in his mempool have high enough fee to be prioritized together. (considering that the parent can't be left out) In cases where the first unconfirmed transaction A (parent) has lower fee rate, his node will check the effective fee rate if it includes those that spent its output (Transaction B+) is high enough to be prioritized. Now for your double-spend concern, it's best to visualize UTXO and transactions, let's write it like how it's presented in a serialized transaction: "txid:vout" - txid = transaction id / vout = the output of that transaction's index number (1st output, 2nd output...) From your example (-> = UTXO used by the next transaction):Transaction A 908685b66b552f812cfb51fd0a0ef999dbdc4d1b906c3e0a76a5693562f3ef24 (UTXO that it spent, Input-0) 6f86230c33b3bad0e2016587df292fb2b64d20ae584be5fa375ba2504c954812:0 (UTXO that it created, Output-0) 908685b66b552f812cfb51fd0a0ef999dbdc4d1b906c3e0a76a5693562f3ef24:0 -> (UTXO that it created, Output-1) 908685b66b552f812cfb51fd0a0ef999dbdc4d1b906c3e0a76a5693562f3ef24:1Its first output is spent by transaction B: Transaction B 5a6f51435a1702f2baa5a923f4ca3b72c3a2403976855fac3c11522607f5ecca (UTXO that it spent, Input-0) -> 908685b66b552f812cfb51fd0a0ef999dbdc4d1b906c3e0a76a5693562f3ef24:0 (UTXO that it created, Output-0) 5a6f51435a1702f2baa5a923f4ca3b72c3a2403976855fac3c11522607f5ecca:0 -> (UTXO that it created, Output-1) 5a6f51435a1702f2baa5a923f4ca3b72c3a2403976855fac3c11522607f5ecca:1Then transaction B's first output is spent by transaction C: Transaction C 84e05154b6ef9274348f00d53dbcd4946927b115687c425d1d3f25bb954d5e70 (UTXO that it spent, Input-0) -> 5a6f51435a1702f2baa5a923f4ca3b72c3a2403976855fac3c11522607f5ecca:0 (UTXO that it created, Output-0) 84e05154b6ef9274348f00d53dbcd4946927b115687c425d1d3f25bb954d5e70:0 (UTXO that it created, Output-1) 84e05154b6ef9274348f00d53dbcd4946927b115687c425d1d3f25bb954d5e70:1 ->...As you can see, each transactions' input points to a UTXO that's not used by other transactions. In case the green-highlighted output is also spent by transaction C instead of the purple-highlighted UTXO (tried to "double-spend" it), only one of those will be included to a block, not both.

This is very different from double spending. Double spending would involve two transactions attempting to spend the same UTXO in a conflicting manner. But in this situation, each transaction is spending a valid output created by the previous one. Take it to be sequencing and nit a conflict. This is very correct. The transactions are dependent. Each transaction spends the change output from the previous one before their parent transaction is confirmed. Yes, the default ancestor limit is 25. There is not uncertainty. It is a policy