I want to share progress on current work -- only covering covering pre-protocol technical theory at this point.
- 1. Pricing mechanism -- IN PROGRESS
- 2. Payment confirmation mechanism
- 3. Transfer report mechanism
1. The pricing mechanism relies on a sender asking its neighbor node prices for a destination before sending packets. This node asks the next node etc. and finally a pricing table is aggregated back to the sender by TTL, delay time, and available bandwidth, but doesn't need to maintain any information about the intermediary nodes. Nodes have to adjust their price with usage, and the better they do it, the more money they will make and less packets they will drop, but they can't spend too much time inquiring about destinations or it will compete with their paid traffic, as neighbor destination traffic is always free. They can use simple mechanisms such as only advertising half of their unused bandwidth over a given TTL to account for changes in traffic. The final TTL can be influenced by physical layer contraints (roaming client), as well as node's available memory to maintain unexpired pricing tables. There is an implied consensus that a node advertising a price will honor that bandwidth up until the pricing TTL, so if they do a bad job of advertising their prices, they will start having to drop packets and lose trust from their neighbors, increasing the cost to reach them.
There are a lot of interesting things happening here, for example:
- If you have a short TTL you have more opportunity to adjust price with traffic, but on the other hand, nodes that go through you will be forced to frequently request your new prices, and since this traffic competes with packet delivery, they may charge more to transit low-TTL priced traffic.
- Frequently-reached destinations will usually be already in memory for a lot of nodes, leading to faster time-to-price, Nodes can also pre-request destinations to be first to return prices to a client. This is ultimately memory and bandwidth-constrained.
I am still working on the mechanism to stream back price aggregation, as nodes shouldn't need to wait to receive back all prices to start returning them to the sender, but new prices might change the aggregation total, so we can think of this as the price request stream which is before we get the TTL driven-prices, probably constrained by a cascading timeout.
I also have to figure out how it piggy backs onto existing routing protocols to avoid packets going in circles and follow the subnet to the destination, and how to report a correspondant which cannot be found or reached. This may requires using secure protocols to protect from attacks.
2. Payment confirmation mechanism: this is where the magic happens, and packet sizes is likely to impose short-lived payments and short signatures. The number of transactions is going to be beyond anything currently done, and will thus require some sort of ledger segmentation or payment channels.
Packets include a destination, payment, and requested delivery time, each node subtract their charge and the recipient must apply their signature for everybody to get paid. There is an implied consensus to drop a packet which cannot be delivered according to the price table. No time synchronisation protocol is needed as a late clock would induce packet drop on the next hop for the sender, and a forward clock would mean they will overpay for delivery. A node administrator can figure out if packet drops are his fault's or a neighbor's and act accordingly.
3. This is something that probably need to go on the "ledger" -- probably simply as part of 2. -- and am still figuring out. It is needed to verify delivery for derivative markets (futures and options), mining rewards, and monitoring packet drop. There also need to be some sort of Graph discovery mechanism, which can probably be simply done over the network using a traceroute-like mechanism at the cost of the requester.
PS: this topic was moved to Development & Technical Discussion
