[solved]How decode raw transaction?

[achow101]

1. How to fast find address in this case?

The same speed that it takes to find any address.

What is algorithm in this case? Usually are pushed two values: first 72-73 bytes, second 65 bytes - key, and we can change 65 key to address, but in this case it is impossible

What are you asking?

It is not impossible to change the 65 byte key to an address. It is done the same exact way that a 33 byte key is done. Read this: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses for details and an example. Note how the example uses a 65 byte key, but the same thing can be done with a 33 byte compressed key.

[Frodek]

But in this case we don't have 65 byte key (nor 33 byte key) but only push 72-73 byte value.

[achow101]

But in this case we don't have 65 byte key (nor 33 byte key) but only push 72-73 byte value.

Yes we do. You are not understanding how the scripting system works. The 73 bye value counter tells the software that the next 73 bytes of the transaction is for the output script. It is not part of the script itself. That script then pushes 65 bytes to the stack. Then OP_CHECKSIG. OP_CHECKSIG interprets the previous item on the stack as the public key and the item before that as the signature. There is nothing that marks then as being the signature or public key.

[fbueller]

OP is confusing two different serialization artifacts.

Outputs look like this:
[fixed 64bit integer][output script]

When writing a parser, your software needs to know how long the output script section is, so the length comes before it.
That way the system knows when it has finished, or if there was a problem. Assuming it's a valid transaction, the network
knows the 64bit integer is actually the number of satoshis, and second part is the output script.

The contents of output script are expressed as Bitcoin Script. This involves different length serialization, one involving PUSHDATA opcodes.

As OP saw, inside the output script, there's a public key with 0x41 (=65) as a length. If we start to use larger pieces of data, this would look like:
 PUSHDATA1 0xff [256 byte long input]
 PUSHDATA2 0xffff [65535 byte long input]

You don't have to explicitly declare the pushdata opcodes for short length, but for multi-byte length encoding, you use PUSHDATA1/2/4.