It appears that the protocol uses routing determined by the sender. If so, how big will my "hosts" file have to be. It also appears that each hop requires a tool. If so how do I route around "highway robbers".
More importantly, is there an implementation?
Is there an implementation: Not yet. I have a prototype implementation of a link layer and I've prototyped parts of the network layer and transport layer. But only enough to convince me that the general isochronous design is workable.
Yes it uses Source Routing: I've spent the last few months working on the (extremely important) scalability question. Section 13 of the spec deals with this in detail, essentially specifying the 'BGP' of IsoGrid (HashMatchLogMap) so that nodes don't have to specify their own 'hosts' file. I think I've come up with a protocol that scales O(log(N)), where N is the number of nodes on the network. It will definitely have a large constant: The base algorithm starts with just always tracking the 10k or more nodes that are cheapest to access. The algorithm scales because the addresses of nodes contain a Geolocation component, which means it's easy to ask for directions from nodes that you already know about that are both physically and logically (HashMatch) closer to a desired node. My next step is to start implementing this protocol such that I can test it on a simulated large network (I'm thinking I'll build the simulated network dataset from OpenStreetMap).
Not sure what you mean by 'tool', but micropayments are sent along with the data. If a node only has one link to the IsoGrid (Comcast), then they are doing it wrong: The node should use the cheapest routes that meet the desired latency/bandwidth requirements. Competition means that "highway robbery" should cease to become a viable business model. If a node along a route decides to just steal the entire micropayment (rather than just their part) then data stops flowing on that route: The source uses other routes and the robber ended up stealing from it's own neighbors.