-
-
Notifications
You must be signed in to change notification settings - Fork 9
Kryptoradio protocol
Kryptoradio protocol consists of data link protocol (Kryptoradio link) and a session protocol (Kryptoradio resource channel). In addition to that, we define multiple protocols for applications, like Bitcoin/Kryptoradio.
Kryptoradio link packet (KLP) length is always 178 bytes and it will be transmitted in a single PES packet. It may start with sync packet and is followed by one or multiple Kryptoradio Resource Fragments (KRF).
| Byte | 0 | 1 |
|---|---|---|
| Data | 0x00 | Version (0-127) |
Though there are 8 bits reserved for version, the MSB is reserved for future extensions and the allowed range is 0–127. The rest of the documentation describes behaviour when version is 0.
Sync timeout occurs every 60 seconds. When timeout happens KRP must be transferred completely before. If there is extra space left at the end of a KLP packet after sending the KRP, the rest should be padded. Then full flush is performed on all zlib compression engines and the next KLP must start with sync packet.
One Kryptoradio Resource Packet (described later) is composed of multiple Kryptoradio Resource Fragments (KRF) which are concatenated in the order as they are received.
First byte of KRF defines how many bytes there is in the fragment. After length comes the payload.
| Byte | 0 | 1 ... |
|---|---|---|
| Data | Length/type | Payload |
Length/type is one of the follownig
- 0 is never used (reserved for sync indicator).
- 1–177 indicate that this is the last fragment of KRP and its length is the number of bytes.
- 254 indicates that the rest of the KLP is padding and it should be ignored.
- 255 indicates that this fragment consumes all remaining bytes in a KLP and the KRP continues in the next KLP.
Kryptoradio resource packet contains the final payload. The payload is ECDSA signed. Resource IDs are pre-registered.
| Byte | 0 | 1 ... | 1 + siglen | 2 + siglen ... |
|---|---|---|---|---|
| Data | ECDSA signature length (siglen) | Signature | Resource ID (0-127) | Payload |
Payload is zlib encoded. Sync flush is performed at the end of a packet and trailing 0x00 0x00 0xFF 0xFF byte sequence is stripped. In reception, it must be re-inserted. This is similar to SLIP compression.
Bitcoin has resource ID 1. Bitcoin packet may contain blocks or transactions, depending on type flag.
| Byte | 0 | 1 ... |
|---|---|---|
| Data | 0x01 | Transaction data |
Transaction contents are defined at Bitcoin specification. https://en.bitcoin.it/wiki/Protocol_specification#tx
| Byte | 0 | 1 ... | ... |
|---|---|---|---|
| Data | 0x02 | Block headers | Transactions hashes |
Block transactions are replaced with their transaction hashes. The implementation must ensure that the transaction is already trasmitted. If not, it must be transmitted immediately after transmitting block.
Block headers are defined Bitcoin specification https://en.bitcoin.it/wiki/Protocol_specification#block
Bitcoin exchange rates. In future this may include other kinds of securities, as well. The format used is CSV.
Typical data content:
BITSTAMP,XBT,USD,T,306.74,1.9
BITSTAMP,XBT,USD,T,306.74,0.07090329
BITPAY,XBT,AED,R,1124.0592
CSV record definition in field order:
- Market name: BITSTAMP and BITPAY are currently used.
- Security name: Bitcoin (XBT) is the only one currently.
- Currency: ISO 4217 currency code, e.g. USD
- Action type: T = trade, A = ask (buy order), B = bid (sell order), R = rate (exchange rate. only used if market is not providing live data this is a snapshot of a price)
- Price level: the price level in question. In case of T and R it is the current price, otherwise it's the order book position.
- Amount: amount of securities (bitcoins) in question. in case of R this is empty and in case of A and B empty field indicates 0
NB: A and B are not there because Bitstamp servers are broken currently.