Looking at the white paper, and there are sections that I'd like to learn more about.
Inboxes - How will two users route to the same inbox, only knowing each other's public key?
Runechain - What does the flow of a message through the runechain look like? How does each node verify that a user has sufficient funds to forward a packet to the next node? Will this require waiting for a block between hops?
Posted Jun 4, 2018, 11:06 PM UTC
So the whole runechain set up is being entirely overhauled in the V3 paper. Essentially in V3 each user will calculate a PoW hash that gets attached to the header of the message. Each node can verify that the hash is of sufficient difficulty, the new system is similar to bitmessage. PoW in the new system is only done for messages being stored offline.
In terms of how I workout where to send my message I can use a measure of mathematical closeness to map each public key to a swarm of nodes which will correspond with each nodes offline inbox. If I'm conducting online messaging their public key will map to their active leases from which I can work out their router endpoints and reach their open tunnel (see i2p for more info)
Ok, I'm interpreting that as:
What incentive does a node have to stay online or respect PoW-assigned TTL? Are they challenged by peers, and how are sybil attacks taken into account?
Yep you've got the general idea of the network.
So the nodes self police eachother, they all collect statistics on eachother throughout their interactions, (stuff like bandwidth provided). then every block we kick off Swarm tests were these some of these swarms (Partitioned nodes) are called to vote on other nodes in their swarm based on this historical data. if a node is performing standard deviations below the median of the network then the nodes in the swarm will come to a consensus and construct a de-registration transaction, which removes the dishonest node from the DHT.
Sybil isnt so much of an issue with routing since its a fairly low overhead task which reasonable limitations can be put on (ie each node blocks ip addresses that individually send 10000s of fake requests) , it only really starts to become an really bad issue when processing power or storage is required which is why for the higher end tasks we require a PoW to be done.
Nodes individually don't have to respect the TTL for a message however if they don't when they come into a Swarm test they are going to fail since they cant retrieve the message and produce a hash given the testers nonce.
Sorry if some of this is unclear reddit isn't the best tool for describing this stuff. V3 Paper goes into this in much more detail.
Excellent job, I assume all we need to do is have a Linux VPS to host the service node and just basic scripting like any other masternode config to get that puppy up and running at full steam!
Inboxes? I'm not sure what you mean. If you have someone's public key, that is enough to find their destination on the mixnet, allowing you to rout a message directly to their device.
As for the runechain, all messages are routed offchain. The runechain was just to regulate and enforce node behaviour. We now have found a way to do this without requiring the runechain. Our third WP revision will cover this
Thanks, looking forward to seeing the next revision. Any rough-estimates on when that V3 paper will be available?
Projected to be ready in the next couple of weeks.