Bitcoin Forum
December 07, 2016, 12:48:41 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: z  (Read 1626 times)
znort987
Early bitcoin miner
VIP
Member
*
Offline Offline

Activity: 74



View Profile
z
April 14, 2012, 12:30:49 AM
 #1

z

1Fj3WdCLXhYtKY25xZAdBv38mLoPfoHry
1481114921
Hero Member
*
Offline Offline

Posts: 1481114921

View Profile Personal Message (Offline)

Ignore
1481114921
Reply with quote  #2

1481114921
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481114921
Hero Member
*
Offline Offline

Posts: 1481114921

View Profile Personal Message (Offline)

Ignore
1481114921
Reply with quote  #2

1481114921
Report to moderator
1481114921
Hero Member
*
Offline Offline

Posts: 1481114921

View Profile Personal Message (Offline)

Ignore
1481114921
Reply with quote  #2

1481114921
Report to moderator
twobitcoins
Full Member
***
Offline Offline

Activity: 144


View Profile
April 14, 2012, 03:51:06 AM
 #2

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
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
April 14, 2012, 07:14:53 PM
 #3

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? Smiley) 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...

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
DeepBit
Donator
Hero Member
*
Offline Offline

Activity: 532


We have cookies


View Profile WWW
April 14, 2012, 07:57:21 PM
 #4

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 ?

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
twobitcoins
Full Member
***
Offline Offline

Activity: 144


View Profile
April 14, 2012, 08:35:43 PM
 #5

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
Donator
Hero Member
*
Offline Offline

Activity: 532


We have cookies


View Profile WWW
April 14, 2012, 09:20:36 PM
 #6

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.

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 Offline

Activity: 14


View Profile
May 05, 2012, 01:26:12 PM
 #7

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
Legendary
*
expert
Offline Offline

Activity: 1064


View Profile
May 05, 2012, 04:48:12 PM
 #8

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 05, 2012, 05:11:33 PM
 #9

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

How often do you get the chance to work on a potentially world-changing project?
lazyranma
Newbie
*
Offline Offline

Activity: 14


View Profile
May 06, 2012, 12:38:36 PM
 #10

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
*
qt
Offline Offline

Activity: 1470


View Profile
May 06, 2012, 08:37:04 PM
 #11

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, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 07, 2012, 07:04:53 AM
 #12

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
Hero Member
*****
Offline Offline

Activity: 722


Libertas a calumnia


View Profile WWW
May 08, 2012, 07:32:57 AM
 #13

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?

Articoli bitcoin: Il portico dipinto
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
May 08, 2012, 07:43:18 AM
 #14

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!