1

I am trying to understand what is contained in the blob portion of the rpc response to get_block.

In the daemon rpc docs for block 912345 the blob response is: "0102f4bedfb405b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff786e0600000195d83701ffd9d73704ee84ddb42102378b043c1724c92c69d923d266fe86477d3a5ddd21145062e148c64c5767700880c0fc82aa020273733cbd6e6218bda671596462a4b062f95cfe5e1dbb5b990dacb30e827d02f280f092cbdd080247a5dab669770da69a860acde21616a119818e1a489bb3c4b1b6b3c50547bc0c80e08d84ddcb01021f7e4762b8b755e3e3c72b8610cc87b9bc25d1f0a87c0c816ebb952e4f8aff3d2b01fd0a778957f4f3103a838afda488c3cdadf2697b3d34ad71234282b2fad9100e02080000000bdfc2c16c00"

I can separate that into below and am not sure about the lines with ? mark, also I am guessing the ? mark below minor version is the timestamp but how is that encoded?:

major_version: 01

minor_version:02

?: f4bedfb405

prev id: b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78

? : 6e0600000195d83701ffd9d73704ee84ddb42102

key:378b043c1724c92c69d923d266fe86477d3a5ddd21145062e148c64c57677008

?: 80c0fc82aa0202

key: 73733cbd6e6218bda671596462a4b062f95cfe5e1dbb5b990dacb30e827d02f2

?: 80f092cbdd0802

key: 47a5dab669770da69a860acde21616a119818e1a489bb3c4b1b6b3c50547bc0c

?: 80e08d84ddcb0102

key: 1f7e4762b8b755e3e3c72b8610cc87b9bc25d1f0a87c0c816ebb952e4f8aff3d

?:2b01fd0a778957f4f3103a838afda488c3cdadf2697b3d34ad71234282b2fad9100e02080000000bdfc2c16c00

jtgrassie
  • 19,111
  • 4
  • 14
  • 51
Satoshi Nakamonero
  • 11
  • 4

1 Answers1

1

The blob is the serialized block.

See: https://github.com/monero-project/monero/blob/9da6d2969bc50e028e59c4e9cd637ebe408294b7/src/cryptonote_basic/cryptonote_basic.h#L349 and https://github.com/monero-project/monero/blob/9da6d2969bc50e028e59c4e9cd637ebe408294b7/src/cryptonote_basic/cryptonote_basic.h#L366

It's essentially just binary data as a hex encoded string.

You also ask how the timestamp is encoded: it's a varint. See: https://developers.google.com/protocol-buffers/docs/encoding which describes varint encoding well.

UPDATE:

Given the long comment thread, here is the OP blob broken down.

Block blob for block at height 912345:

major version (varint): 01
minor version (varint): 02
timestamp (varint): f4bedfb405
prev ID: b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78
nonce (4 bytes): 6e060000
miner TX version (varint): 01
unlock time (varint): 95d837
vin count: 01
vin[0]:
  type (txin_gen): ff
  height (varint): d9d737
vout count: 04
vout[0]:
  amount (varint): ee84ddb421
  type (txin_to_key): 02
  key: 378b043c1724c92c69d923d266fe86477d3a5ddd21145062e148c64c57677008
vout[1]:
  amount (varint): 80c0fc82aa02
  type (txin_to_key): 02
  key: 73733cbd6e6218bda671596462a4b062f95cfe5e1dbb5b990dacb30e827d02f2
vout[2]:
  amount (varint): 80f092cbdd08
  type (txin_to_key): 02
  key: 47a5dab669770da69a860acde21616a119818e1a489bb3c4b1b6b3c50547bc0c
vout[3]:
  amount (varint): 80e08d84ddcb01
  type (txin_to_key): 02
  key: 1f7e4762b8b755e3e3c72b8610cc87b9bc25d1f0a87c0c816ebb952e4f8aff3d
extra size: 2b
extra: 01fd0a778957f4f3103a838afda488c3cdadf2697b3d34ad71234282b2fad9100e02080000000bdfc2c16c
end: 00

NB amounts are in atomic units, encoded as varints.
jtgrassie
  • 19,111
  • 4
  • 14
  • 51
  • yes i have seen the source code. but i am brainlet. so the blob is hex string of major_version,minor_version,timestamp,prev id, nonce, miner_tx, tx_hashes but why is coinbase transaction not in last string: 2b01fd0a778957f4f3103a838afda488c3cdadf2697b3d34ad71234282b2fad9100e02080000000bdfc2c16c00 and what are the strings beginning with 80 between miner_tx – Satoshi Nakamonero Oct 07 '18 at 18:19
  • miner_tx is the coinbase tx. – jtgrassie Oct 07 '18 at 19:54
  • The reason you are seeing strings with the 80s is you are not parsing the hex correctly. After the nonce, you have the miner tx, then an array of tx hashes. It's all in the linked sources. – jtgrassie Oct 07 '18 at 20:11
  • The strings with 80s are what is returned in the docs and my cli request I am not parsing anything manually. Also between vout keys and the tx_hashes should be coinbase/miner_tx in the string 2b01fd0a778957f4f3103a838afda488c3cdadf2697b3d34ad71234282b2fad9100e02080000000bdfc2c16c00 but is not? – Satoshi Nakamonero Oct 08 '18 at 06:16
  • I think these lines serialize data into blob: https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/cryptonote_boost_serialization.h#L181 but I don't know much about serialization and still don't understand my above comment – Satoshi Nakamonero Oct 08 '18 at 07:27
  • I don't understand your varint encoding. I used timestamp 1452793716 and encode with (n << 1) ^ (n >> 63) to get 2905587432. even if i turn that to hex it doesn't equal f4bedfb405. How is timestamp 1452793716 turned into f4bedfb405 – Satoshi Nakamonero Oct 08 '18 at 07:48
  • The miner tx is not a hash, it's a tx. That's why your subsequent parsing (breaking up) is off. – jtgrassie Oct 08 '18 at 11:36
  • Varint encoding: https://developers.google.com/protocol-buffers/docs/encoding#varints – jtgrassie Oct 08 '18 at 11:41
  • Note with varint decoding, you first do hex to bin, drop the most significant bit from each byte, then reverse the 7 bit groups (as outlined in the doc I linked) then convert the bin to decimal. So varint f4bedfb405 becomes 1452793716 in decimal. – jtgrassie Oct 08 '18 at 12:15
  • Any idea on the other ? encoding? Sorry for the long comments I can't access the chat – Satoshi Nakamonero Oct 08 '18 at 13:16
  • After timestamp, you have prev_id (64 chars), then nonnce (8 chars), then miner tx (variable length because it's a tx not a hash), then an array of tx hashes (for which there are none on block 912345). – jtgrassie Oct 08 '18 at 14:23
  • I am asking the formula or line of code in source that shows creation of blob. – Satoshi Nakamonero Oct 08 '18 at 18:21
  • The blob is simply serialized objects though. Hence the 2 links in my answer. The actual serialization (what fields are serialized) is determined by the macros and they are simply, in almost all cases, just converting the binary to hex strings. See BEGIN_SERIALIZE, END_SERIALIZE, FIELD, VARINT_FIELD etc in the linked sources. And please stop changing the original question as it looses context. – jtgrassie Oct 08 '18 at 18:39
  • i give up on this – Satoshi Nakamonero Oct 08 '18 at 18:41
  • Well I didn't give up on you ;) I've updated the answer with the full breakdown of the blob posted for you. – jtgrassie Oct 10 '18 at 11:43