-
Notifications
You must be signed in to change notification settings - Fork 13
Transaction Format
The Slimcoin transaction format is based on Peercoin's format.
A transaction is normally stored in binary format and is displayed by the client in hexadecimal numbers. You can decode it into a human-readable (JSON) format with the decoderawtransaction command. The createrawtransaction command only supports a very basic transaction format. If you want to create more complex types (e.g. OP_RETURN, contracts, etc.) or want to read transactions from the raw blockchain data, you must bother with the hex format.
Note that in all items the bytes are stored in reverse order. For example, if you want to encode a value of 0.01 SLM (which is equivalent to 10000 minimal Slimcoin units - the equivalent of Bitcoin's "Satoshis" -, in hex format: 00 00 00 00 00 00 27 10), it becomes 10 27 00 00 00 00 00 00.
(This is a draft, so it may contain errors or imprecisions.)
- Transaction version (4 bytes). It is currently 01000000
- Transaction nTime (4 bytes)
- Number of inputs (1 byte)
- Output's transaction hash (32 bytes)
- Number of transaction output (4 bytes)
- Coinbase transaction ID length (1 byte)
- Coinbase transaction ID (variable length, defined in previous item)
- Script length (1 byte)
- Script (variable length, defined in previous item)
- Sequence (4 bytes) (seems to be not used currently, will mostly be FFFFFFFF )
- Number of outputs (1 byte)
- Value (8 bytes). Also called BTCnum in Bitcoin. Take into account that Slimcoin's "granularity" is 0.000001 SLM and not 0.00000001 and that consensus enforces a minimum of 0.01 SLM (plus a 0.01 SLM/kB transaction fee) per output.
- Scriptsig length (1 byte)
- Scriptsig (variable length, defined in the previous item)
- Block locktime (4 bytes)
This article is based on the Anatomy of the Genesis Block on the Slimcoin homepage, by Graham Higgins, and Bitcoins the Hard Way, by Ken Shirriff, and own investigations.