znort987 (OP)
Early bitcoin miner
VIP
Member
Offline
Activity: 72
Merit: 12
|
|
April 14, 2012, 12:30:49 AM Last edit: April 23, 2013, 07:22:55 PM by znort987 |
|
z
|
|
|
|
twobitcoins
|
|
April 14, 2012, 03:51:06 AM |
|
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
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
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...
|
|
|
|
DeepBit
Donator
Hero Member
Offline
Activity: 532
Merit: 501
We have cookies
|
|
April 14, 2012, 07:57:21 PM |
|
I've spotted a bunch of "unusual" transactions. http://blockexplorer.com/tx/3793b35c4714250cbba396bbdfb481bc3ba5c621aa4bc7784839c374479d4c40For 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): ============================================================= 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 ?
|
Welcome to my bitcoin mining pool: https://deepbit.net ~ 3600 GH/s, Both payment schemes, instant payout, no invalid blocks ! Coming soon: ICBIT Trading platform
|
|
|
|
DeepBit
Donator
Hero Member
Offline
Activity: 532
Merit: 501
We have cookies
|
|
April 14, 2012, 09:20:36 PM |
|
|
Welcome to my bitcoin mining pool: https://deepbit.net ~ 3600 GH/s, Both payment schemes, instant payout, no invalid blocks ! Coming soon: ICBIT Trading platform
|
|
|
lazyranma
Newbie
Offline
Activity: 14
Merit: 0
|
|
May 05, 2012, 01:26:12 PM |
|
============================================================= 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
Legendary
Offline
Activity: 1120
Merit: 1159
|
|
May 05, 2012, 04:48: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...
|
|
|
|
Gavin Andresen
Legendary
Offline
Activity: 1652
Merit: 2301
Chief Scientist
|
|
May 05, 2012, 05:11:33 PM |
|
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
lazyranma
Newbie
Offline
Activity: 14
Merit: 0
|
|
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?
|
|
|
|
jgarzik
Legendary
Offline
Activity: 1596
Merit: 1099
|
|
May 06, 2012, 08:37:04 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?
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.
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1134
|
|
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 ...
|
|
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5362
Merit: 13340
|
|
May 08, 2012, 07:43:18 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.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
|