Fake Transactions on Blockchain.info

[kolloh]

Does anyone know how this transaction and string of transactions is showing up on Blockchain.info when they don't exist on the network?

https://blockchain.info/tx/cbe60842c6b0d98042c680ffff172db55fe5ad48ac90c31ed61bd4e30ce1eb51

Is this some bug with multisig transactions that makes blockchain.info think the transactions is legitimate? I tried decoding the transaction but I don't know enough about raw transactions to further investigate the actual cause.

There is a scammer going around that is able to make fake transactions appear on blockchain and is using it to attempt to scam people by making them think he made a payment to them.

[1715059465]

1715059465

[1715059465]

1715059465

[1715059465]

1715059465

[achow101]

The transaction is not fake, rather it is a segwit transaction. However, segwit transactions currently are considered non-standard so these transactions are being rejected so these transactions are not propagating well.

[Quickseller]

However, segwit transactions currently are considered non-standard

Are they non-standard, or invalid (until if/when SegWit is activated)?

IIRC, amaclin had claimed to get BC.I to display a SegWit transaction that was "from" an address whose private key he did not control/have possession of.

[achow101]

Are they non-standard, or invalid (until if/when SegWit is activated)?

IIRC, amaclin had claimed to get BC.I to display a SegWit transaction that was "from" an address whose private key he did not control/have possession of.

They are non-standard because old nodes will still accept segwit transactions if they are included in a block.

[Quickseller]

Are they non-standard, or invalid (until if/when SegWit is activated)?

IIRC, amaclin had claimed to get BC.I to display a SegWit transaction that was "from" an address whose private key he did not control/have possession of.

They are non-standard because old nodes will still accept segwit transactions if they are included in a block.

What about nodes running 13.2? If a miner included a SegWit transaction in a block today, would a 13.2 node accept or reject the block?

[achow101]

What about nodes running 13.2? If a miner included a SegWit transaction in a block today, would a 13.2 node accept or reject the block?

It should accept the block as it will still recognize that the segwit rules have not activated yet.

[Quickseller]

What about nodes running 13.2? If a miner included a SegWit transaction in a block today, would a 13.2 node accept or reject the block?

It should accept the block as it will still recognize that the segwit rules have not activated yet.

Did you mean to write "shouldn't"? (feel free to delete this if yes)

[achow101]

Did you mean to write "shouldn't"? (feel free to delete this if yes)

If the block contained a segwit transaction in segwit format, then it should reject the block.

If the block contained a segwit transaction in legacy format, then it shouldn't reject the block and accept it.

[kolloh]

Are they non-standard, or invalid (until if/when SegWit is activated)?

IIRC, amaclin had claimed to get BC.I to display a SegWit transaction that was "from" an address whose private key he did not control/have possession of.

They are non-standard because old nodes will still accept segwit transactions if they are included in a block.

So why does BC.I accept this transaction while almost all other nodes reject it? Are they running an older/newer node or something?

Other nodes give errors such as "Error sending transaction: Error running script for input 0 referencing 725c1a127e66c6e9ebc97ef065d5fff8cb43234651ef4e1fe5eec29175ff28e7 at 1: Script was NOT verified successfully.." when attempting to push this TX.

[AgentofCoin]

So why does BC.I accept this transaction while almost all other nodes reject it? Are they running an older/newer node or something?
...

Blockchain.info is likely running a node version that understands SegWit.
Other blockexplorer nodes are likely running older non-SegWit versions.

[amaclin]

Are they non-standard, or invalid (until if/when SegWit is activated)?

Today they are valid and non-standard.

IIRC, amaclin had claimed to get BC.I to display a SegWit transaction that was
"from" an address whose private key he did not control/have possession of.

true.

So why does BC.I accept this transaction while almost all other
nodes reject it? Are they running an older/newer node or something?

Because the policy VERIFY_CLEAN_STACK is not set on bc.i

Blockchain.info is likely running a node version that understands SegWit.
Other blockexplorer nodes are likely running older non-SegWit versions.

Wrong