z

[znort987]

z

[1715040630]

1715040630

[1715040630]

1715040630

[1715040630]

1715040630

[twobitcoins]

OP_HASH160 [20-byte-hash-value] OP_EQUAL is BIP 16, but the transactions you linked don't seem to be in that form.

[etotheipi]

I'm having a tough time matching the scripts that you listed compared to the tx that you posted.  However, you should be aware that if it's a TxOut script, there is no way for the nodes to confirm whether it's spendable or not (sound like a familiar statement? ) so the TxOut script will be accepted as long as it contains valid op-codes.    In many cases (as I found on the the testnet)... they are not spendable and ultimately the TxOuts are just locked forever.

For instance, I can push 21 bytes into a TxOut script where you would normally put the 20-byte PubKeyHash.  The network will accept it, but no matter what you put before the OP_HASH160 in a TxIn script, you're going to get 20 bytes which will fail OP_EQUALVERIFY compared to the 21-bytes on the stack.  Therefore that output will never be spent.  I noticed quite a few of those on the testnet...

[DeepBit]

I've spotted a bunch of "unusual" transactions.
http://blockexplorer.com/tx/3793b35c4714250cbba396bbdfb481bc3ba5c621aa4bc7784839c374479d4c40

For some of these, blockexplorer.com also seems to get the decompilation wrong ...

When I decompile these myself, either with my own implementation or with the standard
client's implementation, I get what is below (for example the last TX in the list above):

Code:

=============================================================
Disassembled with statoshi client code:

    OP_HASH160 433ec2ac1ffa1b7b7d027f564529c57197f9ae88 OP_EQUAL

Disassembled with my code:

    TX hash: 3793b35c4714250cbba396bbdfb481bc3ba5c621aa4bc7784839c374479d4c40
    time=Sun Apr  8 02:42:10 2012
    value=0.02000000
    script=    
        OP_HASH160
        OP_PUSHDATA(size=20=0x14, 0x433ec2ac1ffa1b7b7d027f564529c57197f9ae88)
        OP_EQUAL

=============================================================

This doesn't seem to fit any of the "standard" script templates ...
Can someone more knowledgeable than I am perhaps explain ?

Both BBE and blockchaininfo sites show those TXes as standard, like OP_DUP OP_HASH160 505810308c90f4ac56d0bebe8c004f495e6592b1 OP_EQUALVERIFY OP_CHECKSIG and there is no 0.02 value in outputs or inputs. Why your result is different ?

[twobitcoins]

You have an off-by-one error somewhere.  See block 174718 on Block Explorer.

Listed immediately after transaction 3793b35c4714250cbba396bbdfb481bc3ba5c621aa4bc7784839c374479d4c40 which you claim is strange, you will find transaction 7eaa56d72ef929deaf1323b18c1781b87ba203c2653a5278840b43aaa3f8586d which is the actual strange one, with the P2SH output "OP_HASH160 433ec2ac1ffa1b7b7d027f564529c57197f9ae88 OP_EQUAL".

[DeepBit]

You have an off-by-one error somewhere.  See block 174718 on Block Explorer.

Listed immediately after transaction 3793b35c4714250cbba396bbdfb481bc3ba5c621aa4bc7784839c374479d4c40 which you claim is strange, you will find transaction 7eaa56d72ef929deaf1323b18c1781b87ba203c2653a5278840b43aaa3f8586d which is the actual strange one, with the P2SH output "OP_HASH160 433ec2ac1ffa1b7b7d027f564529c57197f9ae88 OP_EQUAL".

Wow, cool.

[lazyranma]

Code:

=============================================================
Disassembled with statoshi client code:

    OP_HASH160 433ec2ac1ffa1b7b7d027f564529c57197f9ae88 OP_EQUAL

Disassembled with my code:

    TX hash: 3793b35c4714250cbba396bbdfb481bc3ba5c621aa4bc7784839c374479d4c40
    time=Sun Apr  8 02:42:10 2012
    value=0.02000000
    script=    
        OP_HASH160
        OP_PUSHDATA(size=20=0x14, 0x433ec2ac1ffa1b7b7d027f564529c57197f9ae88)
        OP_EQUAL

=============================================================

This doesn't seem to fit any of the "standard" script templates ...
Can someone more knowledgeable than I am perhaps explain ?

This is "password protected" transaction. Whoever knows or have guessed the password can claim the output.
ScriptSig would be a cleartext password, which is hashed (OP_HASH160), and the hash is compared to the expected value (OP_EQUAL).
Here is an example of claimed output: http://blockexplorer.com/tx/e5779b9e78f9650debc2893fd9636d827b26b4ddfa6a8172fe8708c924f5c39d#i5209086

[Peter Todd]

This is "password protected" transaction. Whoever knows or have guessed the password can claim the output.
ScriptSig would be a cleartext password, which is hashed (OP_HASH160), and the hash is compared to the expected value (OP_EQUAL).
Here is an example of claimed output: http://blockexplorer.com/tx/e5779b9e78f9650debc2893fd9636d827b26b4ddfa6a8172fe8708c924f5c39d#i5209086

Come to think of it, that means that a malicious node operator could write code to detect such transactions, not forward them, and then create a new transaction using the cleartext password to their own account...

[Gavin Andresen]

That's a BIP 16 transaction:  see https://en.bitcoin.it/wiki/BIP_0016

[lazyranma]

I don't really get this BIP16... Have it turned "pay to password" script into some special case of script?
If so, then why the linked above transaction was spent by providing password "22355"? Does BIP16 has some "turn on" switch?

[jgarzik]

I don't really get this BIP16... Have it turned "pay to password" script into some special case of script?
If so, then why the linked above transaction was spent by providing password "22355"? Does BIP16 has some "turn on" switch?

BIP16 means any script matching that hash is considered valid to spend.

It doesn't matter whether it is a simple password or a complex script that matches the hash.

[Mike Hearn]

The password based TX is not a BIP16 TX. It's a custom thing. Judging from the form of the password, maybe something involving custom hardware. Doesn't look very secure at all ...

[Dusty]

I hijack the thread to signal other two strange transactions, these ones in testnet:

362bbbf21f6d0b47ee2e45f975b4c2bd81ed49ba371cbd618835e91b00a66006
8a59d89496b8c0eef5ad7c3ed4b966a7e696fba0f0592cfa3736384e7a4a68b7

The problem with them is the version number: the former has 971503818 and the latter has 369576415.

Why these TXs have been accepted in the chain?

Is this a bug corrected since then (they appear in a block mined 2011-11-12) or must we expect to have random numbers in the version field?

[theymos]

I hijack the thread to signal other two strange transactions, these ones in testnet:

362bbbf21f6d0b47ee2e45f975b4c2bd81ed49ba371cbd618835e91b00a66006
8a59d89496b8c0eef5ad7c3ed4b966a7e696fba0f0592cfa3736384e7a4a68b7

The problem with them is the version number: the former has 971503818 and the latter has 369576415.

Why these TXs have been accepted in the chain?

Is this a bug corrected since then (they appear in a block mined 2011-11-12) or must we expect to have random numbers in the version field?

Bitcoin doesn't check tx and block version numbers. Sometimes (probably most of the time), this is the desired behavior. It allows some backward-compatible changes to be made. For example, IMO this would have been a better way to flag a transaction as using the P2SH feature.

Sipa had a nice proposal for splitting the version number into a "major" part which causes the block/tx to be immediately rejected when the version is unknown, and a "minor" part which does not. I don't know the current status of that proposal.