8
Optimized addresses are 22 bytes, which follows the following format:
The first byte is a tag, either 00 for implicit (tz) or 01 for originated (KT)
If the first byte is 00 and we are working with an implicit (tz) address, then:
The second byte describes the curve and therefore the prefix. This is either 00 (ed25519/tz1), 01 (secp256k1/tz2) or 02 (p256/...
7
Taquito can parse forged bytes using the parse() method in the @taquito/local-forging package.
TypeDocs are here. You can see the unit tests here.
Implementation to decode a signed transaction:
const { localForger } = require('@taquito/local-forging');
const sbytes = '...
7
You can use the tezos-codec binary to decode this:
tezos-codec decode 006-PsCARTHA.operation from ...
6
Those 22 bytes are:
2 bytes - encoded prefix (tz1, tz2, tz3, KT1);
20 bytes - depending on the address type:
for tz-addresses it's public key hash;
for KT-addresses it's hash of the origination operation (see details in @enforser's answer).
Here is a code on C#, I believe you will understand it :)
var bytes = Hex.Parse("...
6
1) About the ed25519 public key, and how it is in bytes:
From [1]:
Ed25519 keys start life as a 32-byte (256-bit) uniformly random binary seed (e.g. the output of SHA256 on some random input). The seed is then hashed using SHA512, which gets you 64 bytes (512 bits), which is then split into a “left half” (the first 32 bytes) and a “right half”. The left ...
6
There are some Python code to do that in this blog and a comment posted by Alain:
http://www.ocamlpro.com/2018/11/21/an-introduction-to-tezos-rpcs-signing-operations/
5
Your magicbyte seems to be wrong. If you take the decimal byte values from the original, convert them to hex, then pad it with a leading zero, you get
>>> struct.unpack('>L', b'\x00\x57\x52\x00')[0]
5722624
This value should produce the expected result:
>>> payload = '...
4
There is https://tezos.gitlab.io/whitedoc/micheline.html#binary-serialization which mostly tells to run tezos-codec describe alpha.script.expr binary schema for a complete description of the binary encoding.
More details are given here.
4
It looks like you are only actually grabbing 2 bytes of data (4 hex chars). I verified this by decoding the result you got, and it only returning two bytes of data for the given magic byte.
Try making the following change:
def get_chain_id(self):
chainid = bytes.fromhex(self.payload[2:10])
return bitcoin.bin_to_b58check(chainid, magicbyte=5722583)
4
When your originate a contract, you send an "operation" to the network. This operation is then serialized into byte format and a hash is derived - this is the operation hash for the given operation.
If an operation generates a new contract, you can manually calculate the new KT1 address by hashing the operation hash + an index byte (starting from 0). We use ...
3
I believe you should be able to make use of Stephen Andrews eztz library to access various tools from a js environment
I would speculate the function is this one where you use the KT prefix
b58cencode: function (payload, prefix) {
const n = new Uint8Array(prefix.length + payload.length);
n.set(prefix);
n.set(payload, prefix.length);
...
3
Something to note from the accepted answer is that the KT1 addresses do not have a "public key hash". The hash used there is the blake2b 20 byte digest hash of the operation group hash and the index of the origination operation within that group that created the address.
More details here: https://tezos.stackexchange.com/a/2270/5435.
@Groxan is ...
2
You can use the RPC endpoint: /chains/main/blocks/head/helpers/parse/operations to do that.
Example:
await axios.post(
`${nodeURL}/chains/main/blocks/head/helpers/parse/operations`,
parseOperationBytesData,
{
headers: {
'Content-Type': 'application/json'
}
}
...
2
First of all, many thanks! You've helped me with solving the block signature mystery :)
You can use pytezos.encoding package:
from pytezos.encoding import base58_encode
def get_chain_id(self):
chainid = bytes.fromhex(self.payload[2:10])
return base58_encode(chain_id, b'Net')
2
In Michelson, those types accept two different formats of data (as you mention) - optimized and readable. The readable versions are the base58-check encoded strings (edpk*, tz1*, edsig*, KT1* etc).
The optimized versions are hex bytes that conform to a specific format based on the type of data, for example public keys are either 33 or 34 bytes - a 1 byte ...
Only top voted, non community-wiki answers of a minimum length are eligible