Post #17080

613dd6c197a2aba72beb51a17541259728355ef77a42c643d74c78ade7506da3
e2927058f7856b9df236b05c0f3ab27c7f40585d0bf7b84ef69ba21e206bf19c
Signature not verified

This entry might be using an old signature, or it was signed by a key that does not exist on the server.

{"entry_date":1579872665,"post_data":{"edit_count":1,"last_edit_date":1579872631,"last_edit_user_id":81,"message_sha512":"4c01fc38c1160f363f14c3e8a6895f2022bb32719aa43ef83384ae4e0f565dbd2f1fd6b0b565b58c681c80ea873ae966f3483f87c71dd6e510a80f12122b7f2c","node_id":67,"post_date":1562429291,"thread_id":1724,"user_id":81},"post_link":"https:\/\/factomize.com\/forums\/index.php?threads\/1724#post-17080"}
The entry content as it exists in the database. This should be verified against the blockchain entry.
Explanation of Messages (IMsg)
For anyone looking for byte level descriptions of the messages, I'm working to draft that here: [URL]https://hackmd.io/@9jEhmQ9vTMGWUph4GvlVlA/H1e8rS3lr[/URL]

hopefully we can merge this with all of Who's work and start putting together an official spec for the protocol

EDIT: In case that site goes away, here is the source:
[CODE]# Message Data-structures

## Directory Block Syncing

### DBState
A message containing all blocks within a DirectoryBlock. Originally, all entry data was included, but as the network grew, this information was no longer put into the messages.

- first byte is the message type (always 20)
- next bytes are the marshalled Directory Block
- next bytes are the marshalled Admin Block
- next bytes are the marshalled Factoid Block
- next bytes are the marshalled Entry Credit Block
- next 4 bytes are the number of Entry Blocks following
- next bytes are the aforementioned marshalled Entry Blocks
- next 4 bytes are the number of Entries following (NOT IN ANYMORE?)
- next bytes are all of the Entries, marshalled as: (NOT IN ANYMORE?)
- 4 bytes size of the Entry
- marshalled Entry itself
- next bytes are the number of signatures
- next bytes are all of the signature pairs, marhsalled as:
- 64 bytes signature
- 32 byte public key

### DBState Request
A request for missing dbstates.

- first byte is the message type (always 21)
- next 6 bytes are the timestamp
- next 4 bytes are the block height start
- next 4 bytes are the block height end

### Block Request
An unimplemented message. I assume for requesting single blocks of any type.
- first byte is the message type (always 14)
- next 6 bytes are a timestamp


## Entry Syncing

### Missing Data Request
A request for an entry or entry block.

- first byte is the message type (always 17)
- next 6 bytes are the timestamp
- next 32 bytes are the entry hash or entry block keymr being requested

### Missing Data Response
A response to a MissingDataRequest, including the Entry or Entry Block requested.

- first byte is the message type (always 18)
- second byte is the object type: 0 for Entry, 1 for Entry Block
- remaining bytes are the marshalled Entry or Entry Block that was requested


## Missing Messages

### Request
- first byte is the message type (always 16)
- next 6 bytes are the timestamp
- next 32 bytes are the asker hash (?)
- next byte is the VM index
- next 4 bytes are the directory block height
- next 4 bytes are the system height
- next 4 bytes are the number of missing message process list heights
- next X bytes are a series of 4 byte process list heights
-
### Response
- first byte is the message type (always 19)
- next 6 bytes are the timestamp
- TODO... figure out the rest of that code that has no comments

## Transactions

### Factoid Transaction
A message holding a Factoid Transaction

- first byte is the message type (always 9)
- next bytes are the marshalled Factoid Transaction object

### Chain Commit
A message holding a ChainCommit object.

- first byte is the message type (always 5)
- next bytes are the marshalled Chain Commit object
- next 64 bytes are the signature
- next 32 bytes are the public key

### Entry Commit
- first byte is the message type (always 6)
- next bytes are the marshalled Entry Commit object
- next 64 bytes are the signature
- next 32 bytes are the public key

### Entry Reveal
A message holding an Entry object to be revealed (can reveal a Chain as well)

- first byte is the message type (always 13)
- next 6 bytes are the timestamp
- next bytes are the marshalled Entry itself


## Server Management

### Add Server
Add the identity as a Federated or Audit server

- first byte is the message type (always 22)
- next 6 bytes are a timestamp
- next 32 bytes are the server's identity chain id
- next byte is the server type (0 == Federated, 1 == Audit)
- next 32 bytes are the public key signing this message
- next 64 bytes are the signature

### Change Server Key
Change the key for the specified server identity

- first byte is the message type (always 23)
- next 6 bytes are a timestamp
- next 32 bytes are the server's identity chain id
- next byte is Admin Block Change
- next byte is the key type
- next byte is the key priority
- next 32 bytes are the new public key for the identity
- next 32 bytes are the public key signing this message
- next 64 bytes are the signature

### Remove Server
Remove the identity as a Federated or Audit server

- first byte is the message type (always 24)
- next 6 bytes are a timestamp
- next 32 bytes are the server's identity chain id
- next byte is the server type (0 == Federated, 1 == Audit)
- next 32 bytes are the public key signing this message
- next 64 bytes are the signature


## Heartbeat
- first byte is the message type (always 10)
- next 6 bytes are the timestamp
- next 4 bytes are a secret number
- next 4 bytes are the directory block height
- next 32 bytes are the directory block hash
- next 32 bytes are the server's identity chain id
- next 32 bytes are the signing public key
- next 64 bytes are the signature

## Block Seals

### End of Minute
- first byte is the message type (always 10)
- next 6 bytes are the timestamp
- next 32 bytes are the server's identity chain id
- next byte is the minute number
- next byte is the vm index
- next byte is the factoid vm index
- next 4 bytes are the directory block height
- next 4 bytes are the system height
- next 32 bytes are the system hash
- next byte is unknown.. but if its greater than 0, then the pubkey + signature must be next
- next 32 bytes are the signing public key
- next 64 bytes are the signature

### Directory Block Signature
- first byte is the message type (always 7)
- next 6 bytes are the timestamp
- next 4 bytes are the system height
- next 32 bytes are the system hash
- next 4 bytes are the directory block height
- next byte is the vm index
- next bytes are the marshalled directory block header
- next 32 bytes are the server's identity chain id
- next 32 bytes are the header signing public key (actual dbsig, goes in next adminblock)
- next 64 bytes are the header signature (actual dbsig, goes in next adminblock)
- next 32 bytes are the signing public key
- next 64 bytes are the signature


## Ack
- first byte is the message type (always 1)
- next byte is the vm index
- next 6 bytes are the timestamp
- next 8 bytes are the salt
- next 4 bytes are the salt number
- next 32 bytes are the message hash being acknowledged
- next 32 bytes are the full message hash
- next 32 bytes are the leader chain id
- next 4 bytes are the directory block height
- next 4 bytes are the process list height TODO: is this actually the process list height?
- next byte is the minute
- next 32 bytes are the serial hash
- next varint bytes are the data area size
- next X bytes are the data area:
- TODO: unmarshal the data area in Ack message
- next 32 bytes are the public key
- next 64 bytes are the signature[/CODE]
This is the raw content, without BBCode parsing.
Top