Prometheus Messaging System
The Prometheus messaging protocol combines elements from the Interchange File Format ( IFF ) FourCC Data Chunks, EMV Type-Length-Value ( TLV ) payment messages, and Internet Relay Chat ( IRC ) Commands.
This messaging protocol, which is used in Bitcoin, was designed before the name "Bitcoin" ever existed.
When the main project was called Prometheus.
It was designed to use both a FourCC ( Four Character Code ) and TLV ( Tag-Length-Value ) for any data sent down the wire.
A FourCC was to allow multiple message classes on the same port so that other nodes can ignore and skip a class they don’t understand.
The FourCC field was chosen from the Interchange File Format used on the Amiga 500 computer in the late 1980s.
https://en.wikipedia.org/wiki/FourCC
It originally used four ASCII characters to represent the type of data contained within the message and was changed to the upper Ascii non-printable-characters to be more searchable within a byte stream for the Bitcoin proof-of-concept implementation.
The start of a message was the FourCC, then the Command type, the size of the message payload, a checksum for the payload, and lastly the payload itself.
The checksum was added later after data corruption was found to be sent over the network.
Each message is thought of as a chunk of data, whether for payment, information interchange, or otherwise.
The communication tech was designed before confirming it would work in an electronic payment system.
Having it be used as a payment system didn't come first.
Each part of the Bitcoin tech can be used independently.
The base Peer-To-Peer system was designed to be used as a generic template for all possible P2P communication for any data.
It was supposed to be generic enough so that the exact same communication protocol could be used across many networks - public or private.
One message class could be specific to quotation and invoicing clients, allowing a business owner to retain business records on their end within their own business database.
The Bitcoin payment message class is only for use to assist in the making of payments and checking that payments have been made, and any messages which help with those tasks.
This includes transactions timestamped into blocks of data which are chained together.
Messages could also be paired.
One for an unknown FourCC message class.
One as a payment for that message to be embedded into the distributed Payments database.
The Commands are ASCII text based upon IRC commands.
A Command fits within twelve characters.
They were originally zero-terminated strings and only a maximum eleven characters were useable.
This allowed the pointer to the command to be used directly in C language print functions in early debugging.
Over time this changed to using C++ string objects and all twelve characters became usable.
Swapping of Version and VerAck can also swap FourCC types that a node understands to allow for message routing solving.
Node software could be built to allow payments to relay through the Bitcoin network and private message data to only be sent between companies and customers.
Any voting system could also be sent within its own messaging protocol.
The network topography was supposed to generate a small world graph.
The PoC released in 2009 only connected to random nodes.
To generate a small world graph it would be helpful to record latency to and location of peer nodes whenever possible.
Location can be at the regional, state, or city level to protect users.
From this data half a dozen nearby nodes can be connected then a few randomly distant nodes.
When two node connect they both send a Version command which contain the types of command services the node understands.
Both nodes, on receiving the other's Version command, send a VerAck command to confirm agreement.
Any node which starts sending commands without a received VerAck will be disconnected.
A node may now send an addr command which has that node's IP address in the payload.
This allows peer nodes to relay the existence of a new node across the network.
The getaddr command may also be sent to discover any other available nodes.
After a while the node needs to check whether the other node is still up and running.
The node sends a Ping command.
If the result is a connection error or timeout then close this connection and find another node.
Later on a Pong command was added by developers to help finding disconnected nodes as downloading the database was single-threaded and these disconnected nodes slowed everything down.
IP lookup can be utilised to discover the latitude, longitude, city, state, and country of an IP address at that particular dateTime.
Dynamic IPs get reused over time so storage of location data should not be a fully trusted source of truth.
The Onion Router ( TOR ) IPs could also be in use, including Virtual Private Networks ( VPNs ) and proxies.
The vast majority of users just run the client software without TOR or VPNs.
Location of TOR exit IP addresses is similar to a gopher hole appearing randomly in a field.
If that's the location the user wishes to show to the world as their connection IP, then that's also the location ( and latency ) that will be used by the network.
If you can connect to a few nodes within your own city, a couple in your state, one from across the country, and a couple half a world away, then an efficient small world graph will form.
The messages sent across the network can be anything at all.
Some nodes may find unknown commands to be spam and would be justified in disconnecting from nodes sending unknown commands.
There's a kind of social consensus whereby groups of client developers agree on the Version Service bits and will only send specific Commands if the connected node also has those Service bits set.
When the Bitcoin PoC was first released there was only the one service: NODE_NETWORK.
This covered commands from Version, Ping, Inv[entory], Transaction(tx) and block data.
There was also the beginning of an anonymous market place for users to subscribe to sellers and merchants could publish their products to subscribers.
As more services were added and the initial services expanded upon, it was expected there would be many more service bits used by those wishing to have their own private or custom public messages sent across the network.
Or their own sub-network for their own service messages while still using the majority network for the base level networking payment message service.
Any unknown commands would just be ignored.
The payload ( value ) of a message can have all or some of its data encrypted so that only the recipient is able to decrypt and read the private data.
From this messaging system any and all types of communication can be made across a peer-to-peer network.
Using it for a payment system was only the very first, and most important, use of the technology which will allow us to scale into a planetary civilisation without regard to anyone's or any state's permission.
Cover image from https://en.wikipedia.org/wiki/File:Small-world-network-example.png
Small world network example
Authored by Schulllz
