1

I ran tezos-baker with the -l option to see all the RPC calls it makes to construct a block. Eventually, I see this:

>>>>220: http://10.10.10.203:20001/keys/tz1efSQdjbTut8NyqE6VEj6CcyRP5mL97SNi
  "01458aa8370000975c013df5a63ff9be180cec1769d316cd8623a60b32f6d365fcf996228cc7ff1e01cc000000005da772d20487083189e81a9e5b90313b7f1da145e4bf6fdfdf0189d842652d83392169d7d500000011000000010100000008000000000000975b1c3f3042b3a504e1e5a91179a7c5e245c163cde8f94cf5407cda36e15e8dfbc60000b87319134abf41d100"
<<<<220: 200 OK
  { "signature":
      "edsigtYxuYK1FJqatLVocMo5epJZKAQdqRzR5kYqVT3A44LEuGqqo6T6EK61mdsfJ6doR2bTKypg7WZjPaofG7JLmZcwqGsvfGm" }

The payload/operation, to be signed, (in hexadecimal) begins with 01, indicating this operation is a block, followed by 458aa837, which is the chain id (babylonnet in this case). The remainder is the actual block to be signed by the http tezos-signer running on port 20001. The signature returned is shown too.

How can I decode the remaining payload to see the actual contents?

An attempt with some python code is giving unparsable results:

operationHex = payload[11:]
operationBytes = bytes.fromhex(operationHex)
print("OperationBytes:", operationBytes)

ValueError: non-hexadecimal number found in fromhex() arg at position 283

The hexadecimal number at 283 is '9'. Removing from that to the end produces a bytestring:

OperationBytes: b'\x00\tu\xc0\x13\xdfZc\xff\x9b\xe1\x80\xce\xc1v\x9d1l\xd8b:`\xb3/m6_\xcf\x99b(\xcc\x7f\xf1\xe0\x1c\xc0\x00\x00\x00\x05\xdaw- Hp\x83\x18\x9e\x81\xa9\xe5\xb9\x03\x13\xb7\xf1\xda\x14^K\xf6\xfd\xfd\xf0\x18\x9d\x84&R\xd83\x92\x16\x9d}P\x00\x00\x01\x10\x00\x00\x00\x10\x10\x00\x00\x00\x80\x00\x00\x00\x00\x00\tu\xb1\xc3\xf3\x04+:PN\x1eZ\x91\x17\x9a|^$\\\x16<\xde\x8f\x94\xcfT\x07\xcd\xa3n\x15\xe8\xdf\xbc`\x00\x0b\x871

I believe the 9-to-end is a checksum of some kind.

I'm unsure how to convert this bytestring into, what I believe should be JSON. If I hex this, I just get back what I started with, so that's no help. Attempting to base58 decode this bytestring gives error: "Invalid encoding, prefix or length mismatch" Any thoughts? Much appreciated.

  • Hexadecimal strings have to have even lengths, pairs of hexadecimal digits encode a byte. Removing the 11 first characters doesn't make sense, you probably wanted to remove the first 10 characters – Arthur B Oct 17 at 8:13
3

You can use the tezos-codec binary from the latest mainnet-staging branch to parse these bytes. So, signing request are indeed prefixed by the tag 1 + <chain_id> for the block cases. The remaining part is the unsigned block header itself which can be decoded :

./tezos-codec decode 005-PsBabyM1.block_header.unsigned from 0000975c013df5a63ff9be180cec1769d316cd8623a60b32f6d365fcf996228cc7ff1e01cc000000005da772d20487083189e81a9e5b90313b7f1da145e4bf6fdfdf0189d842652d83392169d7d500000011000000010100000008000000000000975b1c3f3042b3a504e1e5a91179a7c5e245c163cde8f94cf5407cda36e15e8dfbc60000b87319134abf41d100
{ "level": 38748, "proto": 1,
  "predecessor": "BLBa1WbcNYG2qEgHAaktZTFwFyoonVX8BFeQc8E33ePK8LdZfrw",
  "timestamp": "2019-10-16T19:43:14Z", "validation_pass": 4,
  "operations_hash": "LLoaMBDyNbTVQyspAhW3ftJbwmHGS8Snq3gPpwKVxdPxM2xo34dSm",
  "fitness": [ "01", "000000000000975b" ],
  "context": "CoUrkPCSQ7MUau7vuFDq77e7nsYSeRUWiTBMmtB1NRNXwbLiFcJD",
  "priority": 0, "proof_of_work_nonce": "b87319134abf41d1" }

You may also describe its schema:

./tezos-codec describe 005-PsBabyM1.block_header.unsigned binary schema

N.B.: Your protocol might no be the same depending on which branch of the project / protocol you use. Still, you may retrieve the list of supported ids using ./tezos-codec list encodings.

  • Wow! Thanks! Out of curiosity, have you been able to decode an op manually? (and by manually, I mean some python/go tool). – utdrmac Oct 17 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.