When resolve keys to addresses started with "1" or started with "3"?

[Frodek]

I have transaction: https://blockchain.info/en/tx/eb3ee64977be2b62a8686149dceba26fe74e588298f1ef6126b32108f306d7d6
output has two addresses: 38sfJZYsggfpJ7mtXHPTetSkA4jHsWKCJK - (Unspent) and 35Trh6XGzvBVkZRBzHZaLoSxKq4cD7Q6cL - (Spent)
Two output script are similar:
Output Scripts
OP_HASH160 4ecc3e38233076d0022e29ba0cb74722d20105d8 OP_EQUAL
OK
OP_HASH160 296363a6e5238c1bf0e9de6038801c83d0a8f34e OP_EQUAL
Why first is unspent and second is spent?

Second transaction to compare is https://blockchain.info/tx/759ef485052e07291db63cd6f0fd81afa5009cf05f3f4139ec385a7f62fc233d
output has two addresses: 18bJXurUBvWJVANAgexqQebVxSCVF2mSo5 - (Spent) and 1AEWGx6DBsFr8qbkqXRCpc7x6Md88ozbUr - (Spent)
where
OP_DUP OP_HASH160 5345a8b18bf108c4d6fb60d4ef0e2af6e47c6ba1 OP_EQUALVERIFY OP_CHECKSIG
OK
OP_DUP OP_HASH160 6546fa22d641c847e54c6f3bb114c75dc9cb8769 OP_EQUALVERIFY OP_CHECKSIG

In both cases is OP_HASH160 followed by 20 bytes of key. Why in first case addresses started with "3" and in second case started with "1"?
I wanna write blockAnalyzer which works standalone without bitcoind.

[1714179982]

1714179982

[1714179982]

1714179982

[1714179982]

1714179982

[1714179982]

1714179982

[1714179982]

1714179982

[ArcCsch]

The "3" addresses are send-to-script-hash transactions, while the "1" addresses are standard "send to public key hash" addresses.
To spend the output of a "send to public key hash" transaction, a digital signature must be provided that matches the public key hash.
To spend a send-to-script-hash, however, a script must be provided that fits the hash, as well as an input that evaluates to true.
Those may be multisignature addresses (used for escrow), or some other type of smart contract.
As to why one is unspent, it is simply because the bearer of the data necessary to spend it has not spent it yet.

[Frodek]

If after key data is OP_CHECKSIG then "digital signature must be provided that matches the public key hash" - keys started with "1..."
else if is only OP_EQUAL (or OP_EQUALVERIFY?) it is "script must be provided that fits the hash, as well as an input that evaluates to true"
- kwy started with "3.." ?

[achow101]

If after key data is OP_CHECKSIG then "digital signature must be provided that matches the public key hash" - keys started with "1..."
else if is only OP_EQUAL (or OP_EQUALVERIFY?) it is "script must be provided that fits the hash, as well as an input that evaluates to true"
- kwy started with "3.." ?

Pay-to-pubkey-hash (p2pkh) has a standard format. It is

Code:

OP_DUP OP_HASH160 <20 byte hash> OP_EQUALVERIFY OP_CHECKSIG

p2pkh outputs correspond to '1...' addresses.

Pay-to-script-hash (p2sh) also has a standard format. It is

Code:

OP_DUP <20 byte hash> OP_EQUAL

p2sh outputs correspond to '3...' addresses.

The 20 byte hash is not a key. It is the ripemd160 hash of the sha256 hash of a public key.

[Frodek]

But is several nonstandard script format, for example: https://blockchain.info/tx/bcdc61cbecf6137eec5c8ad4047fcdc36710e77e404b17378a33ae605920afe1
and even is rare OP_HASH256 https://blockchain.info/tx/af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d
but better https://blockexplorer.com/tx/759ef485052e07291db63cd6f0fd81afa5009cf05f3f4139ec385a7f62fc233d
OP_HASH256 mean: it is average koded: already hash256 but no ripemd160 yet?
has two addresses 18bJXurUBvWJVANAgexqQebVxSCVF2mSo5 and 1AEWGx6DBsFr8qbkqXRCpc7x6Md88ozbUr

[achow101]

But is several nonstandard script format, for example: https://blockchain.info/tx/bcdc61cbecf6137eec5c8ad4047fcdc36710e77e404b17378a33ae605920afe1

That is not non-standard. That is pay-to-pubkey (p2pk). This output type is standard but deprecated as it is both large and difficult to tell people what address to send to. The address can be calculated from the public key as well as from the hash160. An address is an encoding of the hash160 of the public key so it must get that hash first, either calculating it directly from the public key, or being given it directly.

and even is rare OP_HASH256 https://blockchain.info/tx/af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d

Notice how the output has no address associated with it. Non-standard scripts are perfectly fine and allowed so long as they are valid. Input and outputs scripts do not have to follow any standard format.

but better https://blockexplorer.com/tx/759ef485052e07291db63cd6f0fd81afa5009cf05f3f4139ec385a7f62fc233d
OP_HASH256 mean: it is average koded: already hash256 but no ripemd160 yet?
has two addresses 18bJXurUBvWJVANAgexqQebVxSCVF2mSo5 and 1AEWGx6DBsFr8qbkqXRCpc7x6Md88ozbUr

What are you talking about? There is no OP_HASH256 in that transaction.

[pebwindkraft]

Really an unusual set of trx.
Looking here, and "turning on" the scripts, indeed show HASH_256 as the first two hex chars of the script:

https://blockchain.info/tx/af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d?show_adv=true

OP_HASH256 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f OP_EQUAL

The TX_Out script would be :
AA20000000000019D6689C085AE165831E934FF763AE46A2A6C172B3F1B60A8CE26F87

so 0xaa is interpreted as HASH256.

I have once created a picture of the most common used scripts, and those with HASH160 are well known, but this is the first time I see HASH256. Hope the picture helps.

[achow101]

I have once created a picture of the most common used scripts, and those with HASH160 are well known, but this is the first time I see HASH256. Hope the picture helps.

It's not as if the OP codes are secret. There is a list of all of them with descriptions of what they do on bitcoin.it: https://en.bitcoin.it/wiki/Script. You can also look at the code for the script interpreter to see what the op codes are and what they do: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L248