Bootstrapping Interledger

85 views
Skip to first unread message

Ryan Fugger

unread,
Nov 8, 2016, 1:18:11 PM11/8/16
to Ripple Project
Adrian Hope-Bailie from Ripple, just posted over at the Interledger list about bootstrapping Interledger:

https://lists.w3.org/Archives/Public/public-interledger/2016Nov/0032.html

What he proposes is very much in line with my original vision of a decentralized person-to-person Ripple network.  If you're interested, check out the new wiki page for bootstrapping this network:

https://github.com/interledgerjs/ilp-kit/wiki

Giovanni P

unread,
Nov 8, 2016, 2:20:51 PM11/8/16
to rippleusers

it's strange and interesting how they're reinventing the old Ripple protocol from backwards.

Daniel

unread,
Nov 8, 2016, 7:53:51 PM11/8/16
to Ripple Project
Great! I'll let you know when I get a node up.

David Watson

unread,
Jan 11, 2017, 6:13:08 PM1/11/17
to Ripple Project
Ryan, 

I agree with Giovanni.  People keep coming back to this.  Especially me!   

I think the magic of the ripple concept is in the fact that it's currency agnostic (with respect to peer 2 peer clearing, not necessarily with respect to "price" as everyone thinks in the local currency) and the network can collapse and reform with little problem.

I'm just now getting back into this.  I have abandoned my own project many times over the last 8 years.  Even after I had a good algorithmic concept for how to ignore pathfinding and instead simply determine which nodes are on the same graph.  There is no specific "granting of credit" in my idea either.  A person simply declares how much money they have and this is allotted to them as a balance.  You "grant them credit" simply by connecting to them.  This is for simplicity obviously, and you could emulate simply by having a different account.  I saw a lot of benefit in simply having everyone in the system, or perhaps a subset of the system to have the same-what I call-"reserves".  

Say for instance I say I have $10 in cash.  You connect to me validating that you "trust" I have that cash, then you can trade the balance on the network.  If I think you are a liar I simply disconnect.  Binary.  No "I trust you this much" stuff.  Then how to simplify when to clear?  None of that either.  If the whole network has $10 and 2 participants everyone holds $5 (the average).  "But what if everyone doesn't want to use cash?"  Clearing is only between nodes.  The "price" is universal, but you can settle with neighboring node however you want.  Bitcoin, real estate, tacos, whatever.

And that's actually where I left the system last time.  What algorithm will tell me every X time what the optimal settlement is with your neighboring nodes in order to bring everyone in the network closer to the average considering you can only pass to nearest neighbor?  

Today, I worked it out in my head.  So looks like I'm back in the game.

David  

Jorge Timón

unread,
Jan 11, 2017, 7:57:08 PM1/11/17
to rippleusers
The ripple concept is currency agnostic, maybe you're confusing
currencies with units. For convenience some mutual credit networks may
adopt 1:1 as the conversion rate between two different assets (the
same unit issued by 2 different participants). You don't need
"granting of credit" for pathfinding. You can treat mutual credit
trust declarations as open orders between 2 assets. Don't confuse
aliceUSD with bobUSD or bobBTC, even with the same issuer, pathfinding
should treat different assets as different nodes in a graph to
navigate the network of trust relationships or market orders (because
they're the same thing IMO).

Mutual credit users don't usually need cash "reserves", they need to
produce things people on their network want and consume things people
on their network produce, one could even think it's not that hard
sometimes.

I haven't studied interledger much myself, but I'm very skeptic
transactions are reasonably irreversible, which I believe is
fundamental for removing proportional fees on arbitrary value
transfers.
Let me put an example transitive transaction:

AliceUSD (ripple.com chain token) -> BobEUR (federated chain multisig)
-> BobBTC (btc in the Bitcoin chain) -> CharlieHRS (on ETC)

I should just read the paper already, but I think trying to be
compatible with everything may be impractical if possible and it's
probably not what I was looking for (but is on my toread dir).
> --
> You received this message because you are subscribed to the Google Groups
> "Ripple Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rippleusers...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Zecrets

unread,
Jan 12, 2017, 5:46:41 PM1/12/17
to rippl...@googlegroups.com
>I think the magic of the ripple concept is in the fact that it's currency agnostic 
>(with respect to peer 2 peer clearing, not necessarily with respect to "price" as everyone 
>thinks in the local currency) and the network can collapse and reform with little problem.

I have spend a lot of time thinking of how various similar algorithms would for my project as well.
I conceptually separate this stuff into Consolidating Balances and Rippling Credit.

> You "grant them credit" simply by connecting to them.  This is for simplicity obviously, and you could emulate simply by having a different account. 

I try to simplify it even more using the concept if IOUs.   Why waste time granting credit.  Simply send an IOU or request an IOU for a quantity of x currency.
The receiver either accepts or declines.  If the person accepts than credit is created.  Since it runs on all mobile devices now and people always carry mobile phones
they can usually quickly respond to such a message. It is not as passive as previous Ripple implementations but I don't think it has to be.  I really  like the idea of approving each deal as it comes up.
Don't people usually respond pretty quickly to text messages?  faster to texts than to emails IMO.


Loads of features, reports and credit ratings.  It does not yet allow rippling between users but that is the part I have spent the most time thinking about. I have one solution designed out on paper.  Just not implemented yet.
I have also separated the concept of settling/consolidating any open IOUs (credits/debits) to try and zero out large outstanding IOUs and the concept of rippling through other connections/credit_lines in the network. 
I also think it would be a good idea to limit the ripple hops to at most 2 or  3.  More than that in most cases is not necessary and over-complicates "my liking" of interactive approval of credit & ripples.
For me they are 2 different processes and algorithms.  Consolidating Balances and Rippling Credit.

Xen


--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rippleusers+unsubscribe@googlegroups.com.

Ryan Fugger

unread,
Jan 13, 2017, 5:51:31 PM1/13/17
to Ripple Project
Those are all interesting approaches, and I think a good protocol would accommodate all of them and let them interoperate to the extent it's actually possible.  I think the ILP protocol that Ripple has designed actually does a good job of that, and so would make a good building block for all of these kinds of systems.  Do any of you think that your particular approach wouldn't work on ILP?

(Here's the current documentation: https://interledger.org/overview.html)

David Watson

unread,
Jan 25, 2017, 5:48:44 PM1/25/17
to Ripple Project
Ryan,

I'm not really impressed by it at all, and honestly it doesn't look like it aims to do anything that Ripple didn't already do except move the concept to a different architectural layer, and also make the middle man's "debt switching" explicit instead of like Ripple, where the pathfinding algo would decide for you.

I think Bitcoin has shown us that "money" has semantic issues as well as technical.  On top of semantic problems inherent in economic talk about money in general, we have different people trying to solve different problems in the same space and disagreeing about what problems are relevant.  Some are trying to solve open payment problem.  Bitcoin creator thinks he's solving inflation problem, partly anyway, what Bitcoin really solves in my opinion is a trust problem related to an open ledger.  But people have "faith" or trust anyway, in what Bitcoin represents.  To many who have looked at the problem, it "seems" like a sounder money than what's the standard.  Because no one fully understands the problem, there's no implementation of a solution TO the problem.  Bitcoin doesn't actually solve THE problem imo, not even close.  But my solution, just like Ripple, isn't really a competitor to Bitcoin.  And Bitcoin would actually augment and enhance, imo, my solution, though I think moreso if it actually was used in conjuction with real assets.  But getting to deep now...

My semantic explanation of what my system is, is probably as complex as the technical explanation.  But neither is really all that complex.  It's basically classic Ripple with some minor semantic and technical modification.  But I believe when people understand it, they will easily see how to build and use it and even trust it, though many may disagree with my conclusions on why it's economically better and in fact helpful to use it.

I'm kind of lost right now where to begin, or when to begin talking about it in detail anyway.  Kind of busy in life right now, so trying to focus on getting the prototype built.  Been shying away from long-winded posts

I already know I'm going to build it on Google App Engine stack because I want anyone to be able to get an instance going for themselves.

Language: Python
DB:  Datastore
Templating: Jinja2
Client: JQuery Mobile

I have a public Github already setup for it (though old skeleton code so far, nothing worth looking at, haven't gotten too far beyond GSD level development, but just started couple weeks ago)

Basically, the idea was I wanted anybody with a web browser to be able to run the thing.  And that is still the plan.  Completely develop, test, deploy from a web browser.

What I think people have ignored in classic Ripple all these years, which is really central in my opinion to the solution to this money problem, is the "clearing" of Ripple debt.  Even this interledger concept of "escrow" is really a small semantic jump to "pre-clearing".  My solution is really nothing but "flowing escrow" if you want to think of it that way.  It accomplishes the same thing.  

The "gimmick" of my solution is how I have solved the path-finding problem.  I basically just determine that all are connected (some path exists between all nodes) and have devised an algorithm to distribute the "escrow" which I call "reserves" evenly.

Anyway, I got to go for now.  But I'm willing to answer questions, problem maybe I should start a thread on it, if anyone's interested.  I don't mind talking about it, Developing prototype is going to take a couple months.  If someone wants to take a stab at helping, I'm all for sharing.  There's only about less than 20 objects, and maybe 10 functions that will be in the prototype.  It's very basic demonstration of principle oriented.

But I do feel that ultimately if you understand Ripple, and Interledger, then my solution could be thought of as something that simplifies path-finding with a "network of path exists" algorithm, together with a "escrow distribution" algorithm.  Other than that its still just a Ripple graph of nodes connected to other nodes.

David
To unsubscribe from this group and stop receiving emails from it, send an email to rippleusers...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rippleusers...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages