Minimal initial protocol

[Ryan Fugger]

Here are some thoughts about something relatively simple that we could
implement as a starting point:

A lot of the current protocol draft is concerned with broadcasting the
network state (available credit on links, exchange rates, etc.)
through the trust network. Let's just forget this to start and use
HTTP, the most ubiquitous information distribution protocol. Using
HTTP has been proposed by several people, and I actually started
developing the protocol years ago with HTTP. It's not the most
elegant thing, but it's so established and easy to develop on top of,
that it makes sense as a starting place for people with finite time
and energy. And there are promising optimizations to HTTP developing,
such as SPDY, that we would automatically benefit from as they evolve.

HTTPS gives easy secure connections. We can use the existing
certificate authorities (including free CAs like StartSSL), as well as
support self-signed certs using notary systems like Perspectives:

http://perspectives-project.org/

We can actually use the existing Perspectives notary system, since it
works with HTTPS.

Go back to using JSON text for data, rather than binary protocol
buffers. It's just easier to work with.

Every Ripple server simply publishes the network state for its nodes,
and asks for updates directly from other servers as it needs. Then
the information is out there, and people can innovate aggregation
schemes or routing services as needed.

The main thing you lose over the current draft is the ability to
obscure your server's domain/IP address from anyone but your
connections. We should be able to integrate with TOR easily enough to
support this though (using the .onion TLD, or similar).

Nodes are identified by email-style <node...@host.com> identifiers,
or maybe a URL. Servers communicate by HTTP POST (or other HTTP
verbs).

Let's forget about setting up the connections (mutual-credit accounts)
for now, and assume that users input them manually. Better methods
for doing this can develop over time.

So the payer will need to initialize the transaction with the
recipient, and then POST promises forward along a route it pre-selects
from the published routing data. The recipient can release the
promises by POSTing a release back along the promise path(s).

For commit, there are two options:

1. The commit gets POSTed back along the promise path(s). IOUs get
POSTed forward as acknowledgement.

2. The commit is timestamped and published by an agreeable authority
(commit registry).

The is no need for IOUs with commit registries, since the promise
combined with the timestamped commit constitute proof of IOU. (One
could say that IOUs are just voluntary timestamps on the commit by the
party who is least motivated to issue it...) Also, the transaction is
atomic. For those reasons, I favour option 2. To start with,
intermediaries can just poll the registry and get the commit once it's
ready.

A simple optimization is to allow intermediaries to subscribe to a
commit, and be notified once it is ready (or once the time has expired
and it has failed to appear). Then they might subscribe to several
different sources, including the promise holder, to maximize the
chances of being notified in a timely fashion. One can imagine commit
distribution networks arising to archive commits and make them
available in many places... Or maybe that won't be necessary. But it
would be fairly simple with HTTP.

To me this seems like a reasonable way to start simply and build a
good protocol that is easy for others to work with and develop
further.

Ryan

[Zecrets]

Ryan,

I know you programmed the original Ripple using Django (python)

and if you want to use HTTP (which could be a fast start)

.. then why not use www.web2py.com for the base platform.

It has power of python lots or dev libraries and comes with it's own webserver built in.

*** The best part is you can even create self contained executables for all platforms for easy cross platform usage and deployment

Faster and easier installation and better overall adoption/use I say.

I have even installed and ran web2py on an iphone.  (Django is not so easy to get working on all platforms)

The Ripple/web2py nodes, servers or instances can communicate over HTTP(S), json

and any interface can be done just using the web and HTML.  Use web-based interfaces for easy cross-platform/device usability.

Run the same code locally accessing the web-based interface or to use it as a server by 

just having it respond to remote addresses requests.

Design it in a way where any Ripple node run as a server can host multiple Ripple identities/persons for people that do not want to run a local node.. and a local node is just a server that hosts only one user identity.  Regardless of whether it is run locally with one ID or as a server with multiple, it all uses the SAME code base so this allows both flexibility in the way it is used while using only one code base.

Other thougts.  

I still say http://about.psyc.eu/ has potential along with 

http://secushare.org/  as  a good foundation for distributed Ripple.

I think I mentioned before that 

ZMQ/0MZ was forked by it's creators so I would not be so crazy about using it if they felt a reason to fork it.

Zen

Ryan

--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To post to this group, send email to rippl...@googlegroups.com.
To unsubscribe from this group, send email to rippleusers...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.

[Apostolis Xekoukoulotakis]

Ryan and Jorge and whoever else wants to help , they will decide for themselves what is better.

But the fact that zmq has been forked doesnt show in any way that zmq isnt good. It seems to me that it is misleading to suggest such a thing. It isnt difficult to check their new site where they explain the reasons of their fork.

2012/4/22 Zecrets <zec...@gmail.com>

--

Sincerely yours, 

     Apostolis Xekoukoulotakis

[Zecrets]

Apostolis and others,

Of course I agree on all your points Apostolis. :) 

I was just adding more food for thought to the discussion with my comments since I had not seen these aspects mentioned previously.

I like ZMQ myself, it makes some parts of development super easy. 

We're all looking for the same solution in the end  I think.

I could use a distributed Ripple system ready to go right now for my community.

How we get there is still being figured out. 

But I do agree with Ryan with something minimal and simple (http & json to start)  which is what inspired me to make my comments :)

Essentially build on whats available with basic widely used protocols and leverage other projects when possible

to create a usable proof of concept that can be adapted and extended as the project grows and as we learn from people using it.

Zen

[Walter]

> I still say http://about.psyc.eu/ has potential along with
> http://secushare.org/  as  a good foundation for distributed Ripple.

Both cool links.

Unfortunately Secushare seems to lack multicast capability:
http://secushare.org/comparison ... While this is not necessarily a
show-stopper for Ripple, I feel it is worth raising. (ZeroMQ and other
transports do provide this capability.)

Multicast is very important when you want highly available (HA)
systems built on commodity hardware using clustering - an effective
requirement for large scale financial systems, large scale being a
perceived requirement for any 'fiat'-interfacing systems with
sufficient community trust (eg. look at exchanges in the Bitcoin
world).

Psyced on the other hand seems to offer this, but is in a
self-described "phase of heavy renewal", "While the new project is
exciting, it is still only offering very basic service. The old stack
instead is loaded with features such as IRC and XMPP compatibility.
There is a possibility to teach psyced to act as a gateway for PSYC2,
thus combining the old with the new, but someone has to do it."

For what it's worth, the IFEX protocol
(http://www.ifex-project.org/our-proposals/ifex and
http://schema.herokuapp.com/) is attempting to implement a lot of the
decentralized / trust-network services provided by SecuShare in an
open way - also text based, but keeping such services optional such
that if provided by a transport (SecuShare, VPN, physically secure
link layer, etc.) then they can be removed as an overhead, in order to
support lower latency deployment.

Regardless of what happens, surely one of these efforts or a similar
one will eventually succeed, gain some userbase, and likely become a
defacto most attractive deployment environment. Given this long-term
view, isn't it worth considering transport independence in a financial
messaging protocol? That's basically what the IFEX Project
(http://www.ifex-project.org/) is all about.

- Walter

[Ryan Fugger]

The cool thing about building on HTTP is that it should be easier for
others to develop their own implementations. I'm not a fan of PHP,
but it would be nice to have a PHP/MySQL implementation that would be
easy to deploy on any web host. Running python servers isn't so
simple...

Multicast only seems important for broadcasting routing information,
which is quite independent from the transaction mechanism itself, so
it should be easy enough to add in later using whatever technology
seems best at the time. It is entirely possible for the transaction
mechanism to be built from HTTP on standard TCP, while the routing
broadcast is done with 0MQ or whatever.

Ryan

[Miles Thompson]

Sounds like a good idea to me.

I thought that a helpful thing would be for me to ask questions about aspects of this proposal. Mostly things that confuse me or I don't understand so my apologies if some of these are stupid questions and I'm coming in late, so to speak.

So the idea as I understand it is to make a protocol that is HTTP (therefore REST?) based since this is easy for people to understand/implement and at the same time make it simpler by offloading as much as possible of the non-core problems (such as identity signing/broadcasting of state) onto lower/other parts of the stack.

Maybe the REST part is an invalid assumption but if it was REST we'd be looking for a list of resources aka nouns residing that people signed in to a given server would have the right to manipulate. 

Based on your Ripple requirements I guess the three most basic nouns are:

nodes - correspond to people, identified as joe...@host.com type identifiers.

offers of credit - edges between nodes (probably 'mutual credit' style), containing units, link to rates offered etc.. 

iou -as I understand it the edges between nodes after a commit has taken place

Other nouns might be things like 'authorization token' (for a given 'directive'), 'terms of credit' (for a given offer) etc.. right?

All these nouns would, be 'published' by a given server and it would be up to other servers to read data from that server (perhaps via a notification feed) and incorporate that data into its local state, right?

I guess verbs (aka services offered) would be things like 'register node', 'path finding', 'initiate payment', 'commit payment', 'release payment'

--

OK so assuming I'm basically on the right course? some really high level questions before I get too far into the weeds. 

1. Would you allow 'offers of credit' and 'iou' to be stated (and manipulated) separately or do you think its better/important  for their to be a single 'account' concept such that you could only ever see or manipulate the state of them both together. Both approaches would have difficulties when the data was potentially distributed across multiple servers of course. 

2. Do nodes 'belong' to and have a 'definitive source' at a particular server or is the whole idea that people, with appropriate key (assuming some sort of agreed notary service thing) can publish updates to info beloning to that node to/on any server and then have that propagate out. 

That is, the first/simple way is that only one server is able to make definitive statements about a given node and any data about that node or its immediate edges is just 'cached' elsewhere.. the more complex/more distributed? way is that any server can receive updates  appropriately signed and somehow all other servers when receiving data from those servers are able to check cryptographically for themselves that the statements on other servers (that they might be updating) are valid/signed information about nodes which they may already have. 

Maybe this is just my own way of restating your question about 'POST' ing back along the promise path vs a trusted 'commit registry'? The problem I have is I've not managed to keep up with all you've said previously on this list about commits and commit registries. The word 'commit' only appears once on the protocol requirements page ;-) 

3. Generally speaking do we aim for a system where every server has a complete copy of all the data on the network - but no server is 'definitive' for the whole network, or a situation where each server only has a copy of the data relevant to them locally, with caches of other data it may need for route calculation purposes. 

Well enough questions better stop here as not sure these questions even really make sense.

Thanks!

Miles

Ryan

--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To post to this group, send email to rippl...@googlegroups.com.
To unsubscribe from this group, send email to rippleusers...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.

--
Miles Thompson 
T: +64 49 023 023 | M: +64 2153 9843 | E: utu...@gmail.com

[Ryan Fugger]

On Sun, Apr 22, 2012 at 10:28 AM, Zecrets <zec...@gmail.com> wrote:
> I know you programmed the original Ripple using Django (python)
> and if you want to use HTTP (which could be a fast start)
> .. then why not use www.web2py.com for the base platform.
> It has power of python lots or dev libraries and comes with it's own
> webserver built in.
>
> *** The best part is you can even create self contained executables for all
> platforms for easy cross platform usage and deployment
> Faster and easier installation and better overall adoption/use I say.
> I have even installed and ran web2py on an iphone.  (Django is not so easy
> to get working on all platforms)
>

Thanks for the tip, Zen. The ability to deploy easily on local
machines does seem like an important feature to get people playing
with it right off the bat.

[Ryan Fugger]

On Tue, Apr 24, 2012 at 12:26 AM, Miles Thompson <utu...@gmail.com> wrote:
> So the idea as I understand it is to make a protocol that is HTTP (therefore
> REST?) based since this is easy for people to understand/implement and at
> the same time make it simpler by offloading as much as possible of the
> non-core problems (such as identity signing/broadcasting of state) onto
> lower/other parts of the stack.
>
"

Just trying to find a feasible way to get *something* implemented that
is "right enough" to drive further development. Worse is better.

http://dreamsongs.com/RiseOfWorseIsBetter.html

> Maybe the REST part is an invalid assumption but if it was REST we'd be
> looking for a list of resources aka nouns residing that people signed in to
> a given server would have the right to manipulate.
>

That's right. In my experience the exact list of resources will
develop as the implementation progresses, and it's not worth worrying
too much about them to start. You can go around in circles for a long
time trying to get the nouns right, only to have to discard them
immediately when you start coding because of a million things you
hadn't considered.

One thing that seems important is to make sure the protocol is
versioned, so that we can make changes to the design after it's
released and not have servers getting confused if they are speaking
different versions.

> 2. Do nodes 'belong' to and have a 'definitive source' at a particular
> server or is the whole idea that people, with appropriate key (assuming some
> sort of agreed notary service thing) can publish updates to info beloning to
> that node to/on any server and then have that propagate out.
>
> That is, the first/simple way is that only one server is able to make
> definitive statements about a given node and any data about that node or its
> immediate edges is just 'cached' elsewhere.. the more complex/more
> distributed? way is that any server can receive updates  appropriately
> signed and somehow all other servers when receiving data from those servers
> are able to check cryptographically for themselves that the statements on
> other servers (that they might be updating) are valid/signed information
> about nodes which they may already have.
>

Routing information should be signed with the node's key to avoid
spoofing, so it doesn't necessarily have to originate at the node's
transaction server.

> 3. Generally speaking do we aim for a system where every server has a
> complete copy of all the data on the network - but no server is 'definitive'
> for the whole network, or a situation where each server only has a copy of
> the data relevant to them locally, with caches of other data it may need for
> route calculation purposes.
>

I don't see much difference between the two. Routing data will always
potentially be stale for nodes on other servers, so it's all a big
cache, and no one knows whether they really have everything, or the
most up-to-date copy. It's all just hints in the end, and servers
will store as much as they think is useful. A simple initial
implementation will just store everything, and refresh it
periodically.

One thing I'm not sure about is whether servers, when asked, should
relay routing info they have about nodes they don't host. It's
probably a pretty simple optimization, but not strictly necessary at
first, so I'd probably leave it out to start for the sake of releasing
*something*...

Ryan

[Ryan Fugger]

I've started writing a bit of code implementing this minimal plan.
Notes so far:

I'm using python/django because that's what I'm most familiar with.
It's not as nice for distributing as web2py, but pyinstaller supports
compiling django projects in much the same way, so hopefully that will
be good enough.

I'm not worrying about any digital signatures to start with because
that involves python extension modules and a bit of mucking. I'm
focusing on the basic transaction messages first. The commit is just
a token that all participants know the hash of and can verify.

I've simplified the trust graph model. Nodes are now called "hubs".
Hubs issue obligations, accept obligations from other hubs, and
convert into their own obligations at specified rates. No more in/out
lines of credit and in_rate/out_rate etc. Hubs declare which other
hubs' obligations they will accept, what amount, and at what rate.
That's it. Hopefully this makes Timón happy, and works OK.

I'll put it up on github once it runs, or earlier if anyone's
interested in looking or helping.

Ryan

[Miles Thompson]

Rough consensus and working code etc.. Great stuff. Looking forward to seeing where this ends up. 

miles

Ryan

--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To post to this group, send email to rippl...@googlegroups.com.
To unsubscribe from this group, send email to rippleusers...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.

[Seth de l'Isle]

2012/4/25 Ryan Fugger:

> I've started writing a bit of code implementing this minimal plan.

That's awesome!

I got a wild hair and started implementing a toy distributed protocol.  My idea was that you should be able to leverage the trust to reduce interactions.  I've got some (non working) code that uses 0mq REQ/REP sockets.  I was also going for the minimal knowledge approach, mostly because that can be broken down into small pieces well. My goal is to be able to provide distributed Villages more than distributed Ripple. I, also wanted a friend-to-friend model  where my node would only connect to nodes I 1 Trust or 2 Want to pay.

The setting:

A trusts B for 5 hours.  B trusts C for 5 hours. C wants to pay A 5 hours for a bushel of peppers.  No one has promised any hours. Here's the golden path view of the protocol:

The interaction:

1.a C contacts A and says: "Please try to get 5 hours from me via the network for a bushel of peppers. Call this transaction: 12345."
1.b A says "OK."

2.a A contacts B and says: "Please try to get 5 hours from C for transaction 12345."
2.b B says "OK."
2.c A lowers their trust for B by 5 hours to 0.

3.a B contacts C and says: "Please fork over 5 hours for transaction 12345."
3.b C says "OK."
3.c B lowers their trust for C by 5 hours to 0.

4.a C promises B five hours for transaction 12345
4.b B says "Thanks!"
4.c B raises their trust for C 5 hours and notes a promise from C of 5 hours.

5.a B promises A five hours for transaction 12345
5.b A says "Thanks!"
5.c A raises their trust for B to 5 hours and notes a promise from B of 5 hours.

6.a A contacts C and says "I got your payment for transaction 12345, Thanks!"
6.b C says "Thank you!"
6.c A gives C the Peppers.

Thoughts:

1. Up front I was worried about performance.  Now I'm thinking that the friend-to-friend model mitigates that pretty well.  This would be pretty damn slow over TOR since RTT is critical here, lots of tiny transactions.

2. Note that any node doesn't need to know how many nodes were involved in the transaction.  Although it would probably be pretty obvious in most networks depending on how the routing was done.

3. Trust doesn't need to be communicated in this model. Promises are data that needs to be synchronized between two nodes at a time.

4. Obviously the above only shows the case where everyone answers yes, but you can probably see how rollback would work.

5. The right hand search rule probably has another name in networking, but that's my first approach.

6. The protocol is terse, do you think it needs emoticons to avoid misinterpretation?

Anyway, I would probably provide more value by hitting some of the low-hanging fruit in the villages.cc site, but I got distracted by my thoughts on distributed Ripple. Damn shiny things!

Thanks,
  Seth

[Ryan Fugger]

On Wed, Apr 25, 2012 at 7:08 PM, Seth de l'Isle
<seth.delisle...@gmail.com> wrote:
> I got a wild hair and started implementing a toy distributed protocol.  My
> idea was that you should be able to leverage the trust to reduce
> interactions.  I've got some (non working) code that uses 0mq REQ/REP
> sockets.  I was also going for the minimal knowledge approach, mostly
> because that can be broken down into small pieces well. My goal is to be
> able to provide distributed Villages more than distributed Ripple. I, also
> wanted a friend-to-friend model  where my node would only connect to nodes I
> 1 Trust or 2 Want to pay.
>

Cool. Implementing is good. Villages is just Ripple with no exchange
rates, and using other considerations for choosing paths.

> The interaction:
>
> 1.a C contacts A and says: "Please try to get 5 hours from me via the
> network for a bushel of peppers. Call this transaction: 12345."
> 1.b A says "OK."
>

Payment init, so far so good.

> 2.a A contacts B and says: "Please try to get 5 hours from C for transaction
> 12345."
> 2.b B says "OK."
> 2.c A lowers their trust for B by 5 hours to 0.
>
> 3.a B contacts C and says: "Please fork over 5 hours for transaction 12345."
> 3.b C says "OK."
> 3.c B lowers their trust for C by 5 hours to 0.
>

This is the kind of routing (broadcast search at payment time -- I'm
assuming nodes are just asking all their neighbours for a route) I
envisioned initially for Ripple. It maximizes privacy. Unfortunately
it won't scale well to a large network. But if there are only a few
thousand users, and not many payments, it would work fine I think, if
a tad slow.

You can double the speed by searching from both ends simultaneously...

I'm glad you wrote this because I can imagine a good hybrid routing
model where nodes/hubs have the option of publishing their
relationships so transactions can use them explicitly, or keeping them
private and building credit tunnels to the public backbone for use in
making and receiving payments. You could build these private tunnels
using broadcast search, since speed wouldn't really be a factor. Once
established, the tunnels could be used for multiple real-time payments
without compromising privacy.
The inconvenience would be the price to pay for better privacy.

I implemented broadcast search some years ago, and it can actually get
quite complicated once the network gets to be anything more than a
straight line. (Consider a diamond shape where the path diverges and
then reconverges later, and we have to make sure the same original
available credit before the divergence doesn't get counted twice; also
avoiding loops; etc.) So I think overall it would be simpler to
implement public link-state routing first and build on that, but I
could be wrong...

> 4.a C promises B five hours for transaction 12345
> 4.b B says "Thanks!"
> 4.c B raises their trust for C 5 hours and notes a promise from C of 5
> hours.
>
> 5.a B promises A five hours for transaction 12345
> 5.b A says "Thanks!"
> 5.c A raises their trust for B to 5 hours and notes a promise from B of 5
> hours.
>

The problem with this is that B can just keep the five hours from C
and not pass them on to A, and no one can prove he did it, since no
one knows who the intermediaries actually are. B can just say it was
someone else further on. That's why the commit signal either has to
propagate backwards from C, so that B sends obligations before
receiving any, or be issued by some agreed-upon commit-registry
authority.

> 5. The right hand search rule probably has another name in networking, but
> that's my first approach.
>

Ah, I see. Depth-first search. That would scale better in terms of
the number of messages per unit time in the network, but it would be
terribly slow to discover paths, especially if we were interested in
ones with better exchange rates...

> Anyway, I would probably provide more value by hitting some of the
> low-hanging fruit in the villages.cc site, but I got distracted by my
> thoughts on distributed Ripple. Damn shiny things!
>

Yeah, once you start thinking about it, it's hard to stop... :)

Ryan

[Ryan Fugger]

On Thu, Apr 26, 2012 at 1:02 AM, Ryan Fugger <a...@ryanfugger.com> wrote:
> On Wed, Apr 25, 2012 at 7:08 PM, Seth de l'Isle

>> 5. The right hand search rule probably has another name in networking, but
>> that's my first approach.
>>
>
> Ah, I see.  Depth-first search.  That would scale better in terms of
> the number of messages per unit time in the network, but it would be
> terribly slow to discover paths, especially if we were interested in
> ones with better exchange rates...
>

Hmmm.... Depth-first *is* much simpler to implement than
broadcast/parallel search. Maybe this would be a better way to
establish private tunnels, since speed isn't very important...

[Jorge Timón]

On 4/26/12, Ryan Fugger <a...@ryanfugger.com> wrote:
> I've simplified the trust graph model. Nodes are now called "hubs".
> Hubs issue obligations, accept obligations from other hubs, and
> convert into their own obligations at specified rates. No more in/out
> lines of credit and in_rate/out_rate etc. Hubs declare which other
> hubs' obligations they will accept, what amount, and at what rate.
> That's it. Hopefully this makes Timón happy, and works OK.

Yes, this makes me happy. Thanks Ryan. It seems to me that this is
more generic and will enable more use cases for the protocol with
minimal additional work. I hope I haven't underestimated the possible
drawbacks.

--
Jorge Timón

[Seth de l'Isle]

Hello,

Le jeudi 26 avril 2012 01:02:49 UTC-7, Ryan Fugger a écrit :

On Wed, Apr 25, 2012 at 7:08 PM, Seth de l'Isle  wrote:

The problem with this is that B can just keep the five hours from C
and not pass them on to A, and no one can prove he did it, since no
one knows who the intermediaries actually are.  B can just say it was
someone else further on.  That's why the commit signal either has to
propagate backwards from C, so that B sends obligations before
receiving any, or be issued by some agreed-upon commit-registry
authority.

 
So how about if A sends a secret to B along with the request for payment, and hands that secret to C, then C hands the secret to A as proof that the

trust relationship has been worked out?  A could deliver the goods upon receipt of that secret since A trusts B to be responsible for getting a promise back.

I have the narrative of this golden path scenerio in python code form; if this sounds at all promising to anyone I'll post it on github.  My next step will be to code show the case where B defaults as Ryan describes.  And after that I'll start working on connecting the nodes in a network with depth-first routing.

Thanks,
  Seth

[Ryan Fugger]

On Mon, Apr 30, 2012 at 8:36 AM, Seth de l'Isle
<seth.delisle...@gmail.com> wrote:
> Hello,
>
> Le jeudi 26 avril 2012 01:02:49 UTC-7, Ryan Fugger a écrit :
>>
>> On Wed, Apr 25, 2012 at 7:08 PM, Seth de l'Isle  wrote:
>>
>> The problem with this is that B can just keep the five hours from C
>> and not pass them on to A, and no one can prove he did it, since no
>> one knows who the intermediaries actually are.  B can just say it was
>> someone else further on.  That's why the commit signal either has to
>> propagate backwards from C, so that B sends obligations before
>> receiving any, or be issued by some agreed-upon commit-registry
>> authority.
>
>
> So how about if A sends a secret to B along with the request for payment,
> and hands that secret to C, then C hands the secret to A as proof that the
> trust relationship has been worked out?  A could deliver the goods upon
> receipt of that secret since A trusts B to be responsible for getting a
> promise back.
>

Unfortunately, that doesn't help. If I'm B, I can still keep all the
hours from C without passing them to A, and no one can prove what I
did.

This is a problem we solved long ago by making sure the payment
recipient is the one who triggers the commit in order to pull IOUs
from the chain of promises, rather than having the payer trigger
commit and pushing IOUs forward...

This document is somewhat dated, but might explain more:

http://ripple-project.org/Protocol/DesignConsiderations

Ryan

> I have the narrative of this golden path scenerio in python code form; if
> this sounds at all promising to anyone I'll post it on github.  My next step
> will be to code show the case where B defaults as Ryan describes.  And after
> that I'll start working on connecting the nodes in a network with
> depth-first routing.
>
> Thanks,
>   Seth
>

> --
> You received this message because you are subscribed to the Google Groups
> "Ripple Project" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/rippleusers/-/hEzGWTVC7mUJ.

[Apostolis Xekoukoulotakis]

I just read the last email so i might be saying nonsense but doesnt ryans solution have the dual problem of what he describes.

someone could pretend that he has obligations to a previous person of the route and ask the next person of the route to have obligations to him. Since noone knows if he indeed gave 'obligations' to the previous person, he cannot be accounted responsible.





 

2012/4/30 Ryan Fugger <a...@ryanfugger.com>

[Jorge Timón]

Maybe having registries from the beginning is simpler than allowing
Bare two-phase commits.
The simpler thing would be to not support fees for them from the start.
I'm not really sure, but at the very the rollback cases seem harder to
test and code.
Just a thought.
Last time we talked about registries not everybody seemed to like them.

Jorge Timón

[Ryan Fugger]

On Mon, Apr 30, 2012 at 12:10 PM, Apostolis Xekoukoulotakis
<xeko...@gmail.com> wrote:
> I just read the last email so i might be saying nonsense but doesnt ryans
> solution have the dual problem of what he describes.
>
> someone could pretend that he has obligations to a previous person of the
> route and ask the next person of the route to have obligations to him. Since
> noone knows if he indeed gave 'obligations' to the previous person, he
> cannot be accounted responsible.
>

You set it up so he can only get the token that he needs to collect on
the promises he holds by fulfilling the promises he has issued.

The problem then is that an intermediary in league with the payer
might pretend to ignore this token until his promises time out,
leaving someone stuck with the commit token, having fulfilled his
promises, but unable to collect on the ones he holds. The cheater can
then say that there was a network outage and it's not his fault. He
can say that he would love to fulfill his promises, but that the
person before him in the chain has left the network and so it is
impossible to collect all the way back to the payer. He can say that
his server was online the whole time and that it must have been the
fault of the person holding the commit token that he didn't receive
it. It's not clean.

That's why I prefer to require all intermediaries to trust a
third-party commit registry, and have the recipient send it the commit
token for timestamping and be done with it. We discussed this at
length last year -- there should be lots of relevant posts in the
archive.

Ryan

[Seth de l'Isle]

Hello,

Le lundi 30 avril 2012 10:10:59 UTC-7, Ryan Fugger a écrit :

> So how about if A sends a secret to B along with the request for payment,
> and hands that secret to C, then C hands the secret to A as proof that the
> trust relationship has been worked out?  A could deliver the goods upon
> receipt of that secret since A trusts B to be responsible for getting a
> promise back.
>

 

Unfortunately, that doesn't help.  If I'm B, I can still keep all the
hours from C without passing them to A, and no one can prove what I
did.

In the abstract, I don't see the problem. A trusts B, and B betrays A's trust.  A will no longer trust B, in exchange for that loss of trust B now gets to spend A's trust worth of C's hours.

If it is C who betrays B's trust, then B is still trustworthy and upon deciding that C has done a runner, B will still make good on the debt to A.

What do you think?

[Ryan Fugger]

On Mon, Apr 30, 2012 at 6:46 PM, Seth de l'Isle
<seth.delisle...@gmail.com> wrote:
> In the abstract, I don't see the problem. A trusts B, and B betrays A's
> trust.  A will no longer trust B, in exchange for that loss of trust B now
> gets to spend A's trust worth of C's hours.
>

There's no requirement for A to trust B. A might just have issued
IOUs to B. Or A might only trust that he can sue B if he can prove he
failed to live up to some legal agreement. But he needs to be able to
prove B has cheated.

B might be gambling on the odds that the payment isn't destined for A
at all, but for some other person further down the line, and so A is
unaffected. Or maybe B is generally honest, but not above skimming a
bit when he knows the chances of getting caught are small. Or maybe
B's server operator is redirecting the stolen value into their own
accounts, leaving B unaware that anything's amiss, since they haven't
lost anything.

Or maybe someone's server has a network or memory glitch or poorly
written software and loses a message, and the value is lost halfway
without anyone realizing, despite everyone's best intentions.

This isn't fundamentally about trust, it's about transaction
atomicity. A payment system can't really work without good atomicity
at a technical level.

Ryan

> If it is C who betrays B's trust, then B is still trustworthy and upon
> deciding that C has done a runner, B will still make good on the debt to A.
>
> What do you think?
>

> --
> You received this message because you are subscribed to the Google Groups
> "Ripple Project" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/rippleusers/-/QfBL9zhEE1YJ.

[Apostolis Xekoukoulotakis]

Let me try something.

A transfer of credits from C to A.

C -> A.

We assume that a route has been found. (That route can even be a multi-route.)

C->B->D->A

C signs he will give N credits to B if he gives him back a receipt, a signed document by A that "A received N credits by C"

B signs he will give N credits to D if he gets the same document.

etc...

In this method, noone can cheat.

There is one drawback. Any intermediary will not be able to use the trust he has from the previous node, his friend, to its maximum, he would only be able to only use Remaining Trust - N. That way someone could initiate fake transactions that will block the network.

Transactions with expiration date.

Each node in the chain gives the same promise with an expiration date.

C says it expires in 10 min.
B in 8 min.
D in 6.

Now, lets consider the fact that inside trust, one also also takes into account the reliability of someones server and the predictability of the in between network latency.

Each one of the servers has a clock. Their clocks dont have to be synchronized.
Each node will send the document to the previous node at a specific time. Each node can prove to itself that
he sent the document on time and that the only reason for not getting the credit from the previous node is either fraudulent behavior or an unreliable connection.


Ok this is a first draft. Tell me what you think. One problem that might arise would be a ddos attack on a node, increasing the latency of the network. Maybe implement some kind of friendly reconciliation after the attack.

2012/5/1 Ryan Fugger <a...@ryanfugger.com>

[Jorge Timón]

On 5/1/12, Apostolis Xekoukoulotakis <xeko...@gmail.com> wrote:
> Each one of the servers has a clock. Their clocks dont have to be
> synchronized.

And the clocks can also be deliberately changed. That's the main
reason for having registries as atomicity providers.
IMO is the simplest solution. I want the protocol to be able to
support block chains as registries in the future, but that's not
urgent at all. Any of the participant in the transaction could act as
the registry without giving him much opportunity for fraud (please
correct me if there's something I don't see here) so I don't see much
problem with registries being "centralized".
In fact, I think the bare transaction is equivalent to letting the
last signer be the registry. That's why I don't think bare
transactions are worth to be implemented at all. Just registries by
default. Only transactions with registries.

Timón

[Ryan Fugger]

Apostolis, you've described quite well the basic transaction mechanism
in the current draft :) It is still possible for the transaction to
be in a partially-committed state, which leaves the door open for all
sorts of problems, but it is an improvement in that it is much easier
to point to who failed/cheated.

The problem is that transactions must be allowed to time out,
otherwise it is easy to attack the network by reserving credit and
never releasing it. But once there is a timeout on promises, there is
a distributed race condition where the commit message must be
communicated to everyone before all the promises time out. To get rid
of this race condition, we can't eliminate communication latency, so
we must eliminate the timeout.

Like Timón, I see commit registries as the best solution: Every
participant agrees that a certain third-party registry will be the
commit authority for the transaction and gives up their unilateral
timeout power. (They can still specify a timeout, they just need a
certified rollback from the commit registry for it to come into
effect.)

https://groups.google.com/d/msg/rippleusers/Ruy_QIb0AAY/fUF5bGNJWXkJ

Registries centralize the timeout function of a transaction, and so
the network is vulnerable to getting clogged with unresolved
transactions if and when registries go down. The cool thing is, there
are lots of ways to imagine registries that are very reliable, such as
a distributed registry consisting of multiple independent servers
around the world built on a resilient consensus algorithm like Paxos
or the Bitcoin block chain. Publishing on Freenet might work, and
there might be a clever hack involving tweeting. The possibilities
are endless, so it seems like a safe avenue to pursue...

Ryan

On Tue, May 1, 2012 at 4:17 AM, Jorge Timón <timon....@gmail.com> wrote:
> And the clocks can also be deliberately changed. That's the main
> reason for having registries as atomicity providers.
> IMO is the simplest solution. I want the protocol to be able to
> support block chains as registries in the future, but that's not
> urgent at all. Any of the participant in the transaction could act as
> the registry without giving him much opportunity for fraud (please
> correct me if there's something I don't see here) so I don't see much
> problem with registries being "centralized".
> In fact, I think the bare transaction is equivalent to letting the
> last signer be the registry. That's why I don't think bare
> transactions are worth to be implemented at all. Just registries by
> default. Only transactions with registries.
>
> Timón
>

[Apostolis Xekoukoulotakis]

The clocks are only there for self reference. They prove to you if someone cheats.
Example:

C->B->D->A

1.C sends a message to B telling him he will give N credits if he receives this document in 8 min.
2. message arrives at B at time k.
3. the document arrives at B at time l.

B checks if l+2*latency-k<8min. If it is the case, then he expects from C to fulfill his promise.


Let me add now the friendly reconciliation part. I call it 'friendly' because someone can cheat and it is not possible to prove he cheats.

example ddos attack, increased unexpected latency in part of the chain.

C->B->D->Incr. latency->S->A

S has paid A what he promised but D didnt receive the message on time and so he doesnt want to pay in fear that the previous nodes will not pay him.
The expired promise from D to pay S becomes a best effort promise.

D finds a new route from D to S.
B from B to D.
C from C to B.

T->J K->L H->Y
|     ||      ||      |
C->B->  D -> S

A new common route (T->J->B->K->L->D->H->Y->S) is then created with new promises and new expiration dates.

In the first route of them, the promise will be like this.
Cs promise.  I sign to give N credit to T if he provides me the old document plus a new document signed by B saying that he was given N credits.

etc...

Conclusion: The problem with friendly reconciliation is that it cannot be proved that a route from C to S exists, thus providing plausible deniability to the fraudulent person.

Anyway, I think this is a difficult problem and thus another solution might be better. The difficult part is that exogenous factors affect it. I wonder how others have solved the latency problem and whether atomicity is possible in a decentralized way.
 

2012/5/1 Jorge Timón <timon....@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To post to this group, send email to rippl...@googlegroups.com.
To unsubscribe from this group, send email to rippleusers...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.

[Apostolis Xekoukoulotakis]

It is funny when someone reinvents what already exists... lol

2012/5/1 Apostolis Xekoukoulotakis <xeko...@gmail.com>

[Apostolis Xekoukoulotakis]

Ok, next time I will read those registry solutions(when I have some free time). Have you and Timon decided yet  which registry solution you will implement?

2012/5/1 Apostolis Xekoukoulotakis <xeko...@gmail.com>

[Ryan Fugger]

On Tue, May 1, 2012 at 6:47 AM, Apostolis Xekoukoulotakis
<xeko...@gmail.com> wrote:
> Ok, next time I will read those registry solutions(when I have some free
> time). Have you and Timon decided yet  which registry solution you will
> implement?
>

To start with, I would implement a simple web host registry that makes
commit tokens available at suitable URLs.

Ryan

[Seth de l'Isle]

Hello,

On Monday, April 30, 2012 8:45:10 PM UTC-7, Ryan Fugger wrote:

There's no requirement for A to trust B.  A might just have issued
IOUs to B.  Or A might only trust that he can sue B if he can prove he
failed to live up to some legal agreement.  But he needs to be able to
prove B has cheated.

I pursued this quite a bit further. I have a command line tools that implements the basics of what I had described.

If anyone wants to see, I uploaded my code to github here: https://github.com/szoth/Rivulet

I put together an example shell session that might make my thinking a little more concrete to some: https://github.com/szoth/Rivulet/blob/master/walkthrough.txt

I haven't begun integrating with TOR, but I'm very optimistic about that after playing with TOR hidden services recently.

Thanks,
  Seth

[Ryan Fugger]

Awesome. My own implementation has been sidetracked, so it's great
that you're doing this :)

Might I suggest a different name, since Rivulet is already being used:

https://github.com/jplewicke/rivulet

On your payment C -> B -> A in the walkthrough, it appears that IOUs
are passed in this order:

1. C -> B
2. B -> A

For all the reasons I gave earlier (and more), I believe this is a
much more stable IOU-passing order:

1. B -> A
2. C -> B

Any plans to implement it that way? What's next?

Ryan

> --
> You received this message because you are subscribed to the Google Groups
> "Ripple Project" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/rippleusers/-/0HsIPGQ-ugwJ.

[Seth de l'Isle]

Hello,

Le dimanche 27 mai 2012 11:01:41 UTC-7, Ryan Fugger a écrit :

Might I suggest a different name, since Rivulet is already being used:

Thanks for pointing that out!
 
I have changed the name to something less friendly, catchy, and name-conflict-prone.

https://github.com/szoth/semosancus 

 

For all the reasons I gave earlier (and more), I believe this is a
much more stable IOU-passing order:

1. B -> A
2. C -> B

Any plans to implement it that way?  What's next?

I'll get back to you on that first (essential) question.  I've entered 7 items in github's issue tracker https://github.com/szoth/semosancus.

Thanks!

[Apostolis Xekoukoulotakis]

I really like the simplicity of things without paxos.

Without timeouts, We have guaranteed consistency.

The only reason we have timeouts is so as to protect the network from someone locking credit, resources.

What would really happen if we didnt have timeouts? There is a boundary on the amount of credit that someone can lock for himself, that is the sum of the trust he has, multiplied by the average length of a chain.

One thing we should take into account if we witness a credit lock, is that acountability is a local concept in ripple. Even if someone else started the fake transaction, it is your friend that provided him the credit that locked your credit. This way, we can reason as to whether we should keep someone as friend or not without really caring as to what really happened.

In essence we have some sort of transitivity of trust, I trust that someone will not lock my resources, because i trust my friend.

After many unnecessary locks, the graph would simply change to protect itself.

..just some random thoughts. I think they have merit, we just have to facilitate the change of the graph when something happens.

2012/5/27 Seth de l'Isle <seth.delisle...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "Ripple Project" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rippleusers/-/7Ty-kO4-umwJ.

To post to this group, send email to rippl...@googlegroups.com.
To unsubscribe from this group, send email to rippleusers...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.

[Alessio Stalla]

On Sun, May 27, 2012 at 10:29 PM, Apostolis Xekoukoulotakis
<xeko...@gmail.com> wrote:
>
> I really like the simplicity of things without paxos.
>
> Without timeouts, We have guaranteed consistency.
>
> The only reason we have timeouts is so as to protect the network from
> someone locking credit, resources.
>
> What would really happen if we didnt have timeouts? There is a boundary on
> the amount of credit that someone can lock for himself, that is the sum of
> the trust he has, multiplied by the average length of a chain.
>
> One thing we should take into account if we witness a credit lock, is that
> acountability is a local concept in ripple. Even if someone else started the
> fake transaction, it is your friend that provided him the credit that locked
> your credit. This way, we can reason as to whether we should keep someone as
> friend or not without really caring as to what really happened.
>
> In essence we have some sort of transitivity of trust, I trust that someone
> will not lock my resources, because i trust my friend.
>
> After many unnecessary locks, the graph would simply change to protect
> itself.
>
> ..just some random thoughts. I think they have merit, we just have to
> facilitate the change of the graph when something happens.

I wholeheartedly agree. The nature of the Ripple graph is such that
you can assume that immediate neighbours of a node are trusted, and
that extends transitively. If one finds one of her "friends" isn't
that trustworthy after all, she can reduce or even eliminate the
amount of credit she allows to that "friend". This is a great property
that imho makes certain technical solutions much less necessary - just
keep it simple and the network will adjust itself.

Alessio

--
Some gratuitous spam:

http://ripple-project.org Ripple, social credit system
http://villages.cc Villages.cc, Ripple-powered community economy
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my current open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source
model-driven Java web application framework

[Ryan Fugger]

On Sun, May 27, 2012 at 1:29 PM, Apostolis Xekoukoulotakis
<xeko...@gmail.com> wrote:
>
> I really like the simplicity of things without paxos.
>

Paxos (or something like it) is only proposed to allow multiple
independent commit registries to arbitrate a transaction. The basic
protocol using only a single registry per transaction does not require
paxos. And it ought to be possible to build single registries that
are arbitrarily reliable, so this may not ever come up.

> Without timeouts, We have guaranteed consistency.
>

Guaranteed *eventual* consistency. The network may be made
inconsistent for arbitrarily long lengths of time, which doesn't seem
tolerable to me.

> The only reason we have timeouts is so as to protect the network from
> someone locking credit, resources.
>
> What would really happen if we didnt have timeouts? There is a boundary on
> the amount of credit that someone can lock for himself, that is the sum of
> the trust he has, multiplied by the average length of a chain.
>
> One thing we should take into account if we witness a credit lock, is that
> acountability is a local concept in ripple. Even if someone else started the
> fake transaction, it is your friend that provided him the credit that locked
> your credit. This way, we can reason as to whether we should keep someone as
> friend or not without really caring as to what really happened.
>

This reasoning is only reliable if users are not permitted to send
IOUs directly to untrusted parties, meaning we would need something
like a whitelist of trusted Ripple servers, and users could transact
with servers not on the whitelist.

Timeouts with registries means you only have to trust the registry --
much less restrictive. That way there's much less risk of having
friends pitted against one another should a transaction go wrong in a
far-off part of the network. (Remember, this might be the result of a
technical glitch, not attempted fraud, although there's generally no
way to tell the difference.)

Not to discourage these kinds of discussions, but this has been
covered at length in the past on the old sourceforge mailing list:

http://sourceforge.net/mailarchive/forum.php?forum_name=ripple-protocol

I initially took a similar position to you, feeling that we could rely
on the social trust inherent in the network to ignore technical
issues, and let them be sorted out socially. I now believe it is much
better to sort problems out technically, and leave the social trust to
just backing the value of obligations where possible.

Put it this way: Ripple users that are connected should have to trust
each other to provide value in exchange for IOUs; Ripple servers that
are communicating should not have to trust each other to behave in
particular ways. Server operators are not the same as users in
general, and the protocol should be resilient against misbehaving
and/or glitchy servers.

Ryan

[Apostolis Xekoukoulotakis]

I agree to all your remarks.

If we ask ourselves as to what to develop right now, I would say, develop the simplest thing that works. The solution with a registry achieves those goals. It is the right choice for now.

I am mostly thinking of using paxos on the chain of the transaction, not on servers.



The discussion is about the bigger problem of having a fully p2p solution. Having servers that delegate on your behalf create problems indeed. Lets forget that for the time being and lets evaluate the cost of the non-existence of timeouts. Can an attacker stop the network from functioning? I doubt that.

Advogato and pagerank also put boundaries on the cost of attacks. (reference)

Just some random thoughts again..

2012/5/28 Ryan Fugger <a...@ryanfugger.com>

[Seth de l'Isle]

Hello,

Just want to report that I've got semosancus working over TOR, with a dependency on connect-proxy.  Depth first routing is also complete.  I'm sure its all buggy as hell.

https://github.com/szoth/semosancus/issues/2

As a side note I have to say that programming with 0mq is a blast!

[Seth de l'Isle]

Hi Ryan,

Le jeudi 26 avril 2012 01:02:49 UTC-7, Ryan Fugger a écrit :

The problem with this is that B can just keep the five hours from C
and not pass them on to A, and no one can prove he did it, since no
one knows who the intermediaries actually are.  B can just say it was
someone else further on.  That's why the commit signal either has to
propagate backwards from C, so that B sends obligations before
receiving any, or be issued by some agreed-upon commit-registry
authority.

In my current implementation, A and C share a secret.  A gives the secret to B and B to C.  Then C gives B an IOU knowing that it came from a party trusted by A.  The problem, as you point out, is that B can double spend A's trust by accepting payment from C and then pretending that he couldn't find a route to C. 

How about this?  When A sends the token to B he also appends a secret to allow C to authenticate B.  When C receives that additional secret he uses it to prove to A that he got the payment through a node A trusts.  At this point C can pay B.  If B doesn't pay A, A holds B accountable.  I think I can envision this being applied to longer chains. The payer would finally receive a list of secrets at least as long as the chain of nodes that could be used to hold each hop accountable by the hop before it.

Thanks,
  Seth

[Ryan Fugger]

On Mon, May 28, 2012 at 1:11 PM, Seth de l'Isle
<seth.delisle...@gmail.com> wrote:
> In my current implementation, A and C share a secret.  A gives the secret to
> B and B to C.  Then C gives B an IOU knowing that it came from a party
> trusted by A.  The problem, as you point out, is that B can double spend A's
> trust by accepting payment from C and then pretending that he couldn't find
> a route to C.
>
> How about this?  When A sends the token to B he also appends a secret to
> allow C to authenticate B.  When C receives that additional secret he uses
> it to prove to A that he got the payment through a node A trusts.  At this
> point C can pay B.  If B doesn't pay A, A holds B accountable.  I think I
> can envision this being applied to longer chains. The payer would finally
> receive a list of secrets at least as long as the chain of nodes that could
> be used to hold each hop accountable by the hop before it.
>

Right, yes, that's the basic idea of how the protocol works. I'd
point out, though, that the token that travels A -> B -> C is what
commits the transaction, since it binds the parties to issuing an IOU,
and is what any timeouts would hinge on. The IOU is a social
formality at that point.

See my draft:

http://ripple-project.org/Protocol/Protocol05

Ryan

[Seth de l'Isle]

OK, implemented!  Stayed up later than I should have been I was able to wrap up a couple evenings of work. Any other suggestions for prioritization?

Le lundi 28 mai 2012 17:02:14 UTC-7, Ryan Fugger a écrit :

On Mon, May 28, 2012 at 1:11 PM, Seth de l'Isle

[Ryan Fugger]

I've drafted a short basic protocol based on HTTP, meant to be extended:

http://ripple-project.org/Protocol/Protocol06

I've defined basic routing and transaction mechanisms, but no commit
mechanism. There is a hook for using various commit methods to be
defined elsewhere. I'm writing up commit method extensions for basic
non-atomic commit passing and for registries. A block chain commit
mechanism, or more sophisticated commit scripts could also be defined
as extensions in the same way.

It should also be possible to define other routing mechanisms like
decentralized path-finding. I left the basic routing in the core
protocol for now, but it could also be factored out as an extension.

Ryan

[Ryan Fugger]

I've added the registry commit extension:

http://ripple-project.org/Protocol/RegistryCommitMethod

Working on defining the non-registry pass-the-commit method...

Ryan

[Ryan Fugger]

Bare commit method:

http://ripple-project.org/Protocol/BareCommitMethod

All the latest docs are at the top of the protocol summary page:

http://ripple-project.org/Protocol/Protocol

Ryan

[Apostolis Xekoukoulotakis]

Keep up the good work. When and if I finish my wiki project, I ll probably need ripple ,with bitcoin as currency, to implement some form of a microtransaction system. Of course ,in order to do this I ll have to automatically close the loops by requiring people to transfer money from one end of the circle to the other. I cant see how this can be avoided.

2012/6/12 Ryan Fugger <a...@ryanfugger.com>

--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To post to this group, send email to rippl...@googlegroups.com.
To unsubscribe from this group, send email to rippleusers...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.

[Ryan Fugger]

On Wed, Jun 13, 2012 at 2:34 PM, Apostolis Xekoukoulotakis
<xeko...@gmail.com> wrote:
> Keep up the good work. When and if I finish my wiki project, I ll probably
> need ripple ,with bitcoin as currency, to implement some form of a
> microtransaction system. Of course ,in order to do this I ll have to
> automatically close the loops by requiring people to transfer money from one
> end of the circle to the other. I cant see how this can be avoided.
>

Can you expand on this? What do you need it to do exactly?

Ryan

[Apostolis Xekoukoulotakis]

First of all, there is flattr or bitcoin alone that could somehow do the job. I will use ripple because I want to promote it and because in the future, I want to create a decentralized economic system based somehow on ripple. Also, pages in my wiki will be forkable and filtered through trust so ripple and my wiki have similar requirements: you will get nothing from my wiki if you dont appoint someone as trustworthy. In fact since all versions of a page are considered equal, unlike wikipedia, you would be bombarded with the same pages.

Now, one imminent goal  is the decentralization of flow of information and that will require that readers be able to pay articles they like either a posteriori or a priori.

The number of payed journalists will be a small percentage of the total number of people. Since,at first, the other people will not be able to pay with their own work, there must be a way to balance this flow by creating an opposite flow of money. I think the existence for loops as a requirement for ripple to work has already been well documented.

The advantages of ripple are many when ripple reaches a certain mass size.

2012/6/14 Ryan Fugger <a...@ryanfugger.com>