Print Page

Title: z
Post by: znort987 on April 14, 2012, 12:30:49 AM

Title: Re: Can someone explain these weird TXs ?
Post by: twobitcoins on April 14, 2012, 03:51:06 AM

OP_HASH160 [20-byte-hash-value] OP_EQUAL is BIP 16 (https://en.bitcoin.it/wiki/BIP_0016), but the transactions you linked don't seem to be in that form.

Title: Re: Can someone explain these weird TXs ?
Post by: etotheipi on April 14, 2012, 07:14:53 PM

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

Title: Re: Can someone explain these weird TXs ?
Post by: DeepBit on April 14, 2012, 07:57:21 PM

Quote from: znort987 on April 14, 2012, 12:30:49 AM

I've spotted a bunch of "unusual" transactions.
http://blockexplorer.com/tx/3793b35c4714250cbba396bbdfb481bc3ba5c621aa4bc7784839c374479d4c40 (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 ?

Title: Re: Can someone explain these weird TXs ?
Post by: twobitcoins on April 14, 2012, 08:35:43 PM

You have an off-by-one error somewhere. See block 174718 (http://blockexplorer.com/block/0000000000000770f0f53d5f78933b3f9c0e97d406258baf0c436714bc639ccd) on Block Explorer.

Listed immediately after transaction 3793b35c4714250cbba396bbdfb481bc3ba5c621aa4bc7784839c374479d4c40 (http://blockexplorer.com/tx/3793b35c4714250cbba396bbdfb481bc3ba5c621aa4bc7784839c374479d4c40) which you claim is strange, you will find transaction 7eaa56d72ef929deaf1323b18c1781b87ba203c2653a5278840b43aaa3f8586d (http://blockexplorer.com/tx/7eaa56d72ef929deaf1323b18c1781b87ba203c2653a5278840b43aaa3f8586d) which is the actual strange one, with the P2SH output "OP_HASH160 433ec2ac1ffa1b7b7d027f564529c57197f9ae88 OP_EQUAL".

Title: Re: Can someone explain these weird TXs ?
Post by: DeepBit on April 14, 2012, 09:20:36 PM

Quote from: twobitcoins on April 14, 2012, 08:35:43 PM

Wow, cool.

Title: Re: Can someone explain these weird TXs ?
Post by: lazyranma on May 05, 2012, 01:26:12 PM

Quote from: znort987 on April 14, 2012, 12:30:49 AM

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

Title: Re: Can someone explain these weird TXs ?
Post by: Peter Todd on May 05, 2012, 04:48:12 PM

Quote from: lazyranma on May 05, 2012, 01:26:12 PM

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

Title: Re: Can someone explain these weird TXs ?
Post by: Gavin Andresen on May 05, 2012, 05:11:33 PM

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

Title: Re: Can someone explain these weird TXs ?
Post by: lazyranma on May 06, 2012, 12:38:36 PM

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?

Title: Re: Can someone explain these weird TXs ?
Post by: jgarzik on May 06, 2012, 08:37:04 PM

Quote from: lazyranma on May 06, 2012, 12:38:36 PM

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.

Title: Re: Can someone explain these weird TXs ?
Post by: Mike Hearn on May 07, 2012, 07:04:53 AM

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

Title: Re: Can someone explain these weird TXs ?
Post by: Dusty on May 08, 2012, 07:32:57 AM

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

362bbbf21f6d0b47ee2e45f975b4c2bd81ed49ba371cbd618835e91b00a66006 (http://blockexplorer.com/testnet/rawtx/362bbbf21f6d0b47ee2e45f975b4c2bd81ed49ba371cbd618835e91b00a66006)
8a59d89496b8c0eef5ad7c3ed4b966a7e696fba0f0592cfa3736384e7a4a68b7 (http://blockexplorer.com/testnet/rawtx/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?

Title: Re: Can someone explain these weird TXs ?
Post by: theymos on May 08, 2012, 07:43:18 AM

Quote from: Dusty on May 08, 2012, 07:32:57 AM

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.

Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: znort987 on April 14, 2012, 12:30:49 AM