How this guy spent pending transaction output multiple times in the same block?

[newbieshi]

hey,

I have seen a strange activity ,a guy sent 37.7 btc from wallet A to wallet B, wallet B sent to C, C to D , D to E...... almost 100 tx to's to wallet Z at the same block.
How was this possible, same block pending tx receiver sending to another wallet which sent to another wallet that sent to another.

Transaction is below, wallets sent to each other this 37.7 btc ,from wallet a to b, b to c, c to d..... at the same block 935580, is it double spending like situatiıon?

wallet a:
https://mempool.space/address/1Ct4GW3Qst8g7n4MNgfECUztpTELbzbXeX

wallet b:
https://mempool.space/address/17AJ2axuHQ9oR1VbtWyy2VWVU7d9jPKZFK

wallet c:
https://mempool.space/address/1LVuM3V4uVoVNUpZTEQ5HL4snkhmiX9qpm
.......................................................

[LoyceV]

is it double spending like situatiıon?

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.

[EL MOHA]

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

[LoyceV]

This is simply what we call child pay for parent (CPFP)

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

[khaled0111]

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).

[Cricktor]

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.

Bitcoin Core 0.12 also introduces new default policy limits on the length and size of unconfirmed transaction chains that are allowed in the mempool (generally limiting the length of unconfirmed chains to 25 transactions, with a total size of 101 KB). These limits can be overriden using command line arguments; see the extended help (--help -help-debug) for more information.

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.

[Livingleged]

This is simply what we call child pay for parent (CPFP)

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

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.

[Cricktor]

...

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.

[hosemary]

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.

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.

[pooya87]

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:

Code:

[tx0] [coinbase]
[tx1] [...]
[tx2] [inputs]{input from previous blocks}  [outputs]{output_1}{output_2}
[tx3] [inputs]{output_2}                    [outputs]{output_3}{output_4}{output_5}
[tx4] [inputs]{output_1}                    [outputs]{output_6}
[tx3] [inputs]{output_5}{output_6}          [outputs]{output_7}{output_8}

This consensus rule is what allows us to have features such as CPFP.

[nc50lc]

Transaction is below, wallets sent to each other this 37.7 btc ,from wallet a to b, b to c, c to d..... at the same block 935580, is it double spending like situatiıon?

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:1

Its 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:1

Then 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.