gmane.network.ripple.devel

Re: reimagining the Ripple narrative — favours not dollars

Ryan Fugger — 2011-08-26T16:24:54

I've definitely been thinking about it more in terms of favours for
the last couple of years.  And that interview you sent was excellent
(still reading it).  My goal with this project has been to try to take
the violence out of money and return to the friendly neighbourly IOU
days.

I'd love to discuss this more, but this list is pretty dead.  There
are more people involved over at the Google group:

https://groups.google.com/forum/#!forum/rippleusers

Maybe Jiri you could repost the interview and your thoughts below to
start a discussion there?

Thanks,
Ryan

On Fri, Aug 26, 2011 at 5:46 AM, Jiri Baum <jiri-GQNJI/xCzH+6c6uEtOJ/EA< at >public.gmane.org> wrote:

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev

reimagining the Ripple narrative — favours not dollars

Jiri Baum — 2011-08-26T12:46:00

Hi,

I've been thinking that it might be an interesting excercise to rewrite the 
Ripple narrative with the standard example unit of account being "favours" 
rather than "dollars". I think I mentioned this in passing before, but never 
quite explicitly...

That is: Ripple keeps track of the fact that Alice owes Bob a favour, and when 
Bob needs a favour from Carol, etc. Standard Ripple narrative, just with the 
one word replaced by another.

Maybe it wouldn't be any use, but maybe it would provide quite interesting new 
insight into what Ripple really is or what it could become.


Jiri

Interesting article — What is Debt? – An Interview with Economic Anthropologist David Graeber

Jiri Baum — 2011-08-26T12:41:28

Came across an interesting article... I think it was a tweet that linked to a 
Bitcoin forum...

What is Debt? – An Interview with Economic Anthropologist David Graeber
http://www.nakedcapitalism.com/2011/08/what-is-debt-%E2%80%93-an-interview-
with-economic-anthropologist-david-graeber.html
(watch the line-break...)

Jiri

Re: New Bitcoin-inspired ideas

Ryan Fugger — 2011-05-25T19:09:59

2011/5/25 Jorge Timón <timon.elviejo-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>:

Registries will be identified by a key, but there's no reason for it
to be the same key as a node, even if the person who owns the node
operates the registry.  Most likely registry operators will also be
Ripple server operators, at least at the beginning.

Ryan

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1

Re: New Bitcoin-inspired ideas

Jorge Timón — 2011-05-25T09:48:30

Here are two proposals you may be interested in too:

Commit chain without "incentive problem" or without miners
https://groups.google.com/forum/#!topic/rippleusers/JFQ-zBqFjPI

I thought this as another possible decentralized registry, but it
can't be integrated with Ryan's design for registries. It is further
discussed in the registry thread.
Of course, any solution that doesn't involve any block chain would be
preferable.

F2F network to "handle atomicity"
https://groups.google.com/forum/#!topic/rippleusers/DqjnDmYiOWQ

Ryan, I have a proposal for changing the registries. To facilitate
regular nodes to be registrties. Fisrt some questions.

Can nodes (or try) send a message to another node just indicating its
public key?

If so, I think registries should be indicated by their public key too,
instead of an url.
This way, any node can act as a registry without further preparation
and intermediaries can just designate their friends as registries.

Different combinations of registries should be allowed.
For e

Re: New Bitcoin-inspired ideas

Jiri Baum — 2011-05-25T08:43:05

Hello,

Jiri:

Ryan:

I can picture two situations:

* The local Ripple Users' Group meeting-cum-market. If you hire or borrow the 
local community hall, it's easy enough to put down a wifi point, but Internet, 
well, maybe it's there and maybe it's not and maybe it's a bit dodgy or slow.

* Two-participant transactions between people who are directly connected.



Well, that's the trick, isn't it. If I put something together, I'll propose it 
and/or implement it.


Jiri

Re: New Bitcoin-inspired ideas

Ryan Fugger — 2011-05-24T18:29:28

On Tue, May 24, 2011 at 6:28 AM, Stephen Paul Weber
<singpolyma-BBL/675DSF9HD/0T1/Lv+A< at >public.gmane.org> wrote:

Broadcast search was my original idea years ago, but it definitely
won't scale.  The current draft uses link-state routing, like OSPF,
but it differs in that we're looking for the *cheapest* path, not the
shortest path, and also that the path must be reserved before passing
the IOUs, because best-effort isn't good enough here.

Ryan

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1

Re: New Bitcoin-inspired ideas

Ryan Fugger — 2011-05-24T18:22:38

I define "online" as "connected to each other", however that might be.
 Internet is the default.


Not likely at all.  You can't expect all the intermediaries to be in
the store with you while you make your purchase ;)


Definitely propose an idea if you have one.  I am quite content with
registries though.

Ryan

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1

Re: New Bitcoin-inspired ideas

Jorge Timón — 2011-05-24T16:02:47

Not sure, but it seems you're talking about path discovery. The issue
registers solve is transaction atomicity (and the possible attack of
locking intermediaries credit with fake transactions that never commit
?).

2011/5/24, Stephen Paul Weber <singpolyma-BBL/675DSF9HD/0T1/Lv+A< at >public.gmane.org>:

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1

Re: New Bitcoin-inspired ideas

Stephen Paul Weber — 2011-05-24T13:28:29

I'm sure this has been discussed countless times: but what's wrong with just 
using OSPF or even simpler stuff?  Like, node A knows about some 
connections, builds them and broadcasts to nodes reachable from account A1, 
those nodes do the same (with broadcast path being kept to prevent flooding 
and such) and eventually after some TTL the request comes back with either a 
match or "no match withing that TTL" (where TTL is probably a number of 
hops).

Re: New Bitcoin-inspired ideas

Jiri Baum — 2011-05-24T12:25:02

Hello,

Ryan:


Why?

A transaction only involves the parties to it. As long as they're connected to 
each other, they can conclude a transaction among themselves. A transaction 
has no effect beyond its parties, so why would they need to be connected to 
the wider Internet?

Usage cases would probably all be in-person transactions where everyone is on 
the same wifi, LAN or even a near-field communication link.



I'm wondering whether there might be another algorithm that provides 
acceptable guarantees without registries...

In any case, registries don't really solve much, because they have the same 
problem, just one level removed. Thus they would seem to complicate the 
protocol for no real gain.




Hmm, I wonder if that would be a workable restriction. In any case, the ripple 
transaction completes either before or after the goods are handed over. Would 
it be possible to break down such a transaction into two, one involving only 
the two parties and the goods, the other a circular transaction? Depend

Re: New Bitcoin-inspired ideas

Ryan Fugger — 2011-05-24T10:23:11

No, the intermediaries and recipient can all be offline and the rest
of the network will process the transaction just fine.


No, it does actually require them to be online as I've designed it.  I
can't imagine a way to allow for offline nodes to participate in
transactions other than a block chain or centralized transaction
authority.


Unfortunately, it is necessary for transaction atomicity.  I've
discussed the dangers of registries abusing their powers here (near
the bottom of the message):

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

You can still perform transactions without registries -- registries
just enable more (and cheaper) transactions than would be possible
without them.


A consensus algorithm doesn't work among the participants:  the payer
can add an arbitrary number of dummy nodes at the beginning of the
chain and therefore control the commit/rollback to his own advantage
without being detected.  Only if the participants all know and trust
each other does this work

Re: New Bitcoin-inspired ideas

Jiri Baum — 2011-05-24T09:57:01

Hello,

Ryan:

No worries... I was catching up and skimming most of that rather quickly...


Actually, block-chain does require everyone to be on-line, otherwise they 
can't submit transactions to the cloud or retrieve the confirmations. 
Meanwhile, Ripple doesn't require everyone to be on-line, merely the parties 
to a transaction to be connected to each other.




Hmm, again I was skimming rather quickly, but my first impression is that the 
registries would become central points of trust... and Ripple design should 
probably avoid that. For instance, what happens when one or more of the 
registries goes off-line mid-transaction? You're back to the same problem, 
only among the registries rather than among the transaction participants.

If you do use some sort of Byzantine transaction commit consensus algorithm, 
as someone proposed on the thread, then you might as well use it among the 
transaction participants directly rather than among the registries, as you 
responded. It'll probably be easier to desig

Re: New Bitcoin-inspired ideas

Ryan Fugger — 2011-05-24T04:04:33

Hi Jiri.  Yes, I eventually came to those same conclusions in the
google group threads, and have posted an updated protocol draft that I
think is suitable for implementation:

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

The one advantage to a block-chain mechanism is that it doesn't
require all participating nodes to be online for the duration of the
transaction, and achieves full transaction atomicity, albeit only
probabilistically over time.  Have you read my proposed atomicity
extension for the current protocol?

https://groups.google.com/forum/#!topic/rippleusers/Ruy_QIb0AAY

I'd be interested in what you think.

Thanks,
Ryan

On Mon, May 23, 2011 at 6:26 PM, Jiri Baum <jiri-GQNJI/xCzH+6c6uEtOJ/EA< at >public.gmane.org> wrote:

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your

Re: New Bitcoin-inspired ideas

Jiri Baum — 2011-05-24T01:26:39

Hello,

Ryan:


Somewhat late to the party (and maybe in the wrong forum), but...

Personally, I think the Bitcoin proof-of-work block chain solves entirely the 
wrong problem for Ripple.

Bitcoin requires everyone to know the sequence of all transactions; in Ripple, 
only the parties to a transaction need to know about it.

Bitcoin requires transactions to be ordered; in Ripple, transaction order 
mostly doesn't matter, and with only minor redesign wouldn't matter at all.[1]

Bitcoin assumes nobody trusts anyone and everone is semi-anonymous; in Ripple, 
each transaction happens along a linear or circular path where adjacent 
participants know and trust each other in any case.


So, for Ripple, the block chain mechanism would give no clear advantage, and 
would bring all its disadvantages (computational load, storage footprint, 
susceptibility to better-resourced opponents, requirement for global 
connectivity, long delay in confirmation).

If you want a peer-to-peer Ripple, then just write a peer-to-peer R

Re: Next protocol draft messages

Ryan Fugger — 2011-03-02T23:02:12

Hi Stephen.  Yes, relationships are not secret.  Encoding would be
JSON.  More here:

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

(I'll be updating it a bit soon, but I don't think there will be any
drastic changes.)

There are loads of examples on the v0.4 pages here:

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

The new protocol will be somewhat different, but the messages are similar.

Ryan

On Wed, Mar 2, 2011 at 2:08 PM, Stephen Paul Weber
<singpolyma-BBL/675DSF9HD/0T1/Lv+A< at >public.gmane.org> wrote:

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev

Re: Next protocol draft messages

Stephen Paul Weber — 2011-03-02T22:08:56

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Somebody claiming to be Ryan Fugger wrote:

This seems like a start.  It seems like this is based on using routing where 
relationships are not secret?  What is the idea on encoding for these 
messages?  MIME-style seems like it could work, but I'd need to better sense 
of what the different messages look like.  Examples maybe?

- -- 
Stephen Paul Weber, < at >singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJNbr/3AAoJENEcKRHOUZzeW5oP/2LKoMg3vug5ZHUN7Gcd+ckp
4NAETtPhjgyTGHnaXShq6/ez9AYRTrX4TGyefTpplR2IdxCQwMisy0ZqPOvEo2cA
vp5wpgWwTuji6BADF5rrk/qAGPTJ8GI9Q91Zxe+aX1ElsQbU4dbS2Vd3d3Hw5OGZ
+w+ex123wH9hLhc0G2gM8qHlg+aP/4Mi558XIZwXg1YdmEPXWMbyv52cCQpS1N3P
6MA90emghKYu59jKQgRvHuqyHnoG6mzvU0VxkVuGiHEVE5MTZ7KPz5P9cHws4sEC
sXmvbsh8Ddx5flHN+neOBRVMcu6KG4N4Fy5XZm7haHjPfjK1gA6PVLeFrj4AJwEm
Ahwlu20Am0fAPgS9EL6ryrYqB+8c/05gTxiYMN2Uy8sUH/nt8w5E4B0tP9hkKjsn
s+

Next protocol draft messages

Ryan Fugger — 2011-03-02T09:03:26

I put up a brief summary of the messages for the next draft of the
Ripple protocol:

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

Comments welcome, if there's anyone still reading this list...

Ryan

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev

New Bitcoin-inspired ideas

Ryan Fugger — 2011-02-18T23:07:29

Not sure who's still listening on this old list, but there's a new
thread on the Ripple Project group (formerly Ripple Users) that has
some new ideas for a distributed Ripple protocol:

https://groups.google.com/forum/#!topic/rippleusers/6sBQXKTluDk

I've summarized these on the wiki, and added a few new formulations of
old ideas (under "Ideas for v0.5"):

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

Any thoughts are welcome.  Thanks.

Ryan

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

Re: "Circular Multilateral Barter 1.0" ReleaseAnnouncement

Ryan Fugger — 2010-11-25T23:19:13

What I want to do with Ripplepay is to allow users to look at other
users' profile information and account histories, as well as
marketplace history once there is a marketplace.  (User's could make
some or all of their data private by default, and there could be a way
to request to view another's data, or propose to both expose their
private data simultaneously, etc.)  The way you summarize the
histories is important.

More details on Ripplepay plans here: http://ripple-project.org/Main/Roadmap

Maybe a good thing would be to only let me see details of the other
user's dealings with people who are in my network, or at least
highlight that data as most likely to be genuine and relevant.

Fundamentally though, the ability to connect with strangers is most
important at the start, when there is little of value in the system to
steal.  So connecting to strangers should be relatively safe early on.
 Later, the ability to look at other users' profiles will be used more
to find people you already know and trust, be

Re: "Circular Multilateral Barter 1.0" ReleaseAnnouncement

Evgeni Pandurski — 2010-11-25T22:46:43

You are both right! But the problem, in my view, is much harder than it looks
(and this probably applies to ripplepay too). I believe that creating
a reliable
reputation system is a very, very hard thing to do, so I rule it out right away
(But I might be wrong, so I am open to suggestions)!

Therefore, users should always verify that the ID they've found is the
genuine ID
of the person they know (or otherwise they lose money, so to  speak).
So users will probaby prefer to go to person's website directly (or to make a
phone call) and discover the real user ID instantly (assuming that most local
traders already *do* have IDs!).

But there are 2 problems with my reasoning: 1) In the beginning most traders
*will not* have IDs, so users will probably want to search only for
traders that
are already in the system. 2) It is extremely unusual not to have an
user-search
in such kind of a website.

An analogy that comes to my mind: you "google" some trader's site and there
they say "Our bank account is 1234567890 --