Topic: What happened in this transaction? (Read 176 times)

His account has absolutely been hacked then.

That's more or less irrelevant to your friend. Your friend completed his part of the deal, and there is blockchain evidence of that. He is not at fault and should receive whatever was agreed upon.

Based on how my friend described the buyer, he seems like a complete newbie, so it's very unlikely that he knows how to do anything aside from sending and receiving, but well, there is a chance that he is faking it, either ways, if he was lying then he lost no money if he was a careless newbie than sadly he lost about a thousand $ worth of BTC.




It indeed is, now I have more info on this matter, the buyer said he saw the transaction appears on his wallet for a few seconds and then it vanished, this adds more strength to the fact that there was a script doing all the work, and that was not on the blockchain.com wallet, so the hacker really knows how to get the job done, this is yet another reason why web-based wallets suck big time.

Of course, all of these assumptions are based on the fact that the buyer is telling the truth, for all we know, he could have those seeds imported somewhere else and he manually spent them since he knew when the transaction was going happen.

This is the case without any doubt. The seed were exported and restored with a wallet which allows writing script. And the script was just to send the coins to the given address when there is any new balance.

It did not necessarily have to be a script which sent the transaction on immediately. The owner of the address could manually have sent the coins on any time after the first transaction was broadcast. Since the timestamp on the block explorer is the time the transaction was mined, not the time it was broadcast, there could have been anything from a few second to several days between the first transaction being broadcast and it being mined, during which someone could have manually included it in a second transaction.

The first receiving address - 1GpuDxXn9mYUf3fiMy4YpvTgx7AKUsZbbV - is part of a blockchain.com wallet? As far as I am aware, blockchain.com does not allow users to spend unconfirmed inputs in their transactions. If 1GpuDxXn9mYUf3fiMy4YpvTgx7AKUsZbbV is indeed part of a blockchain.com wallet, then someone has exported the seed from blockchain.com and is using that address in a different wallet which does allow unconfirmed inputs. This makes it much more likely that the buyer has indeed been hacked.

The seller sent 0.09370169 BTC to 1GpuDxXn9mYUf3fiMy4YpvTgx7AKUsZbbV. This is a fact and is non-debatable. If the buyer is agreed that 1GpuDxXn9mYUf3fiMy4YpvTgx7AKUsZbbV is their address, then the seller has completed their part of the trade. If the buyer's wallet has been hacked or compromised, the seller is not at fault and should therefore receive the agreed upon amount of fiat.

I see two possibilities :
- maybe he is lying, he moved the coins and now denying having the coins in the address
- maybe his key was compromised and the hacker had this script to moved to his own wallet

Either way, he had the coins in the address he gave to the other guy.

Ok, so what happened here is that the moment he receipt/hacker/script got the unconfirmed outputs, they immediately spent it to 1GpXLNYGfi7jWgZxn7hDaQs39VD59WYtvg and since both transactions are signed properly then they can be confirmed in the same block by the nodes.


Yup, I am aware of that, it's all about whether or not it's considered valid, what I initially thought is that this can't be done in the same block, but now after reading's comment and when I think about it, nothing is stopping them from sending raw transactions to spend unconfirmed outputs.



My friend is neither the sender nor the recipient, he is just trying to solve a dispute between two parties so he only knows as much as we all now know, both parties agreed that the buyer's address was > 1GpuDxXn9mYUf3fiMy4YpvTgx7AKUsZbbV , they also agree on the amount received which was 0.09xxBTC, the buyer says his wallet is still empty while the seller says the transaction to 1GpuDxXn9mYUf3fiMy4YpvTgx7AKUsZbbV was confirmed so he says "I should take my money and leave".


Yup seems like the only fair way to go about this, get the seller out of the equation, and start figuring out what went wrong with the buyer's wallet, since this is a shitty web-based wallet, many things could have gone wrong, so a lot of digging on the buyer's wallet needs to be done.

Anyway, I have gotten the answer, I will keep this topic open for further discussion, I am sure other members will come up with different theories on what could have gone wrong with the buyer's wallet.


Thank you all.

Since you explained the situation, now it matters. My sense was in two separate tx it does not matter.
Which address your friend was given?


If this is 1GpuDxXn9mYUf3fiMy4YpvTgx7AKUsZbbV then your friend sent the coins to the correct address.

It seems the buyer's given address was 1GpuDxXn9mYUf3fiMy4YpvTgx7AKUsZbbV which means the BTC were sent to his given address. From the blockchain evidence it's clear so the seller gets his USD/fiat (if that was the transection form)

You can always spend unconfirmed outputs. But they won't be confirmed unless the previous transaction is confirmed.
If you cannot spend unconfirmed outputs, that's only because your wallet doesn't allow you. You can do it using other wallets.

---

In the blockchain, you can find many series of transactions all confirmed in a single block specially when CPFP (Child Pay For Parent) method is used. (That's not the case here, of course.)
When you accelerate a transaction using CPFP method, both transactions are confirmed in a single block.

Nope, it's valid. The rule pretty much only dictates that the inputs must be referenced and confirmed. It's fine to have an unconfirmed input as long as it is confirmed in the same block.

As long as the coin is confirmed and sent to the specified address, the deal is complete. I regard any deal which has a valid transaction to the specified address as complete. Whatever happens after that is out of the control of the sender. What wallet is the recipient using?
If the funds were sent to the correct address as dictated, there is no dispute. Wherever the funds are sent to is a separate matter entirely.

How would he be able to spend an input that hasn't been confirmed? won't the transaction be invalid at that point?


It does matter in this particular situation, if the buyer said that was his address then there would have been no dispute, but I agree that in general, it doesn't matter.

What I understand is that both were picked at the same block.
The receiver either has his address coded to send any receiving to the last address, or he manually made the tx to that last address.

@ranochigo, you were few seconds ahead :-P

It does not matter though.

It's likely just that someone has a script which automatically crafts a transaction to send the funds immediately to another address upon seeing it, confirmed or not. Both transactions were included in the same block


How would you know if the other address doesn't belong to the same wallet btw?

Transaction > https://blockchair.com/bitcoin/address/1GpuDxXn9mYUf3fiMy4YpvTgx7AKUsZbbV


The recipient is



What they received in the transaction


was immediately sent to


in this transaction


The last address doesn't belong to the wallet which generated the first address.

Both transactions have the same number of confirmations!