Aug 27, 2020, 2:41:24 PM8/27/20
Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message as abuse
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Ripple Project
It seems to me like Ripple needs minimal infrastructure. Each person can keep track of their own balances, privately. Messages exchange (data transmission over data transmission layer, second layer in OSI model) only has to be between people who have trust lines. Queries for payment routing can hop from person to person, and be trusted only be pairs at each hop. Authentication can be with simple message authentication codes (they use a hash function and include the hash in the message), and privacy can be with symmetric encryption such as a one-time pad. Ripple is the ideal money system cryptographically. To prevent spam in payment routing, people can demand a fee to forward query requests, it solves the spam issue. Bidirectional query flooding involves sqrt(unidirectionalQueryFlooding) as many people as unidirectional, I think it can scale pretty good. Account identifiers can just be a random number between 0 and n where n is large enough to make collisions improbable. When people discover a collusion during their payment routing, they just change their ID. Needs no central coordination, the size of n can be decided on by indirect coordination. But does need to include checks for collision in the payment routing.
The part that is hardest for me is how to establish the data transmission connection between two people. This is very basic and was developed in the 1960s with the internet I think, but I'm not good at that. Once that exists, passing messages that activate the minimal number of functions needed to run Ripple, seems pretty straight forward.
During payment routing, establishing payment routes might need to include three pulses. Discovery, Collisions test, and agreement. The discovery is the bidirectional query flooding. Then, the collisions test is one directional between payment issuer and recipient, so they know they have not found a path to accounts with identical IDs. Which direction does not matter, the two are communicating already, they need to have a secure communication channel set up already to agree on a payment, and can notify the other if it worked. And then, agreement. Maybe this should be first from payment issuer to recipient, and each intermediary confirming that they have formed credit lines, and then back from recipient to payment issuer, notifying every intermediary closer to payment issuer that credit lines were formed by every intermediary further down in the payment chain at which point everyone knows a chain has formed and the payment has been issued.