IFEX and Ripple

[Ryan Fugger]

From the thread on multi-path support:

On Mon, Aug 6, 2012 at 6:03 AM, Jorge Timón <timon....@gmail.com> wrote:
> On 8/3/12, Walter <walter....@gmail.com> wrote:
>> Here's some specific feedback on the protocol proposal v0.6 @
>> http://ripple-project.org/Protocol/Protocol06
>> - SSL is not a great choice today for secure communications - see
>> http://www.youtube.com/watch?v=Z7Wl2FW2TcA for example.

There's no need to trust certificate authorities in order to use
TLS/SSL. It's perfectly viable to authenticate certificates in other
ways, such as trust-on-first-use, a web of trust, or using a
distributed system of certificate verification such as in
Perspectives:

http://perspectives-project.org/

All TLS does is present you with a certificate from the other side.
*You* (as a software developer) decide whether it's valid or not. I
don't feel there's any need to overspecify this before it's actually
in use.

>> - I have read that it is considered bad practice to mandate specific
>> cryptographic algorithms with protocols (Applied Cryptography?)

Where does the current draft mandate any specific algorithms? I've
tried to make it flexible, by specifying hash and signature algorithms
where they are used so they can be changed if warranted.

>> - It is not a good idea to have a flat error space (waiting_for....).
>> What you will wind up with is loads of crazy state-based logic. What
>> you need is grouping - general states, with more specific states as an
>> option.

These error states are only for debugging a failed payment in order to
determine alternate paths to try, and not part of the transactions
themselves. Again, I don't want to overspecify until we see how it's
actually used. Or, you can think of what I've specified as the
general states, with the more specific states awaiting later
specification :)

>
>> - HTTP is perhaps a limiting option for a financial networking
>> protocol as it limits people - just as TCP does - to point-to-point
>> communications. Many financial networks require broadcast/multicast
>> distribution of data, particularly when operating at scale. In
>> addition, there is a certain degree of overhead in SSL and HTTP that
>> introduces latencies that may not be desirable in certain financial
>> networking scenarios.

HTTP/JSON can be replaced with a custom binary transport and binary
message encoding such as protocol buffers if necessary for performance
in later versions. Right now HTTP is useful because people are
familiar with it and it encourages more implementations and easier
deployment, eg, using PHP.

If broadcast/multicast data is required, that can be specified to use
an appropriate transport. Currently that is not required. The goal
isn't to specify a monolithic meta-protocol that can support anything
a financial network would want, it's to do one thing (multihop value
transfers) and do it well. It could be a useful component in a larger
framework of protocols.

>
> I would prefer just JSON (or protocol Buffers, I don't care) and ZMQ.
> Anyway most of the design is based on JSON.
>

ZMQ doesn't do authentication and encryption well -- you basically
have to reimplement TLS on top of it (or whatever subset you need),
since it's not baked in.

Ryan

[Walter]

>>> Here's some specific feedback on the protocol proposal v0.6 @
>>> http://ripple-project.org/Protocol/Protocol06
>>> - SSL is not a great choice today for secure communications - see
>>> http://www.youtube.com/watch?v=Z7Wl2FW2TcA for example.
>
> There's no need to trust certificate authorities in order to use
> TLS/SSL. It's perfectly viable to authenticate certificates in other
> ways, such as trust-on-first-use, a web of trust, or using a
> distributed system of certificate verification such as in
> Perspectives:
>
> http://perspectives-project.org/
>
> All TLS does is present you with a certificate from the other side.
> *You* (as a software developer) decide whether it's valid or not. I
> don't feel there's any need to overspecify this before it's actually
> in use.

While I am sure that it's probably possible implement in better ways,
each of those does come with an overhead. My motivation in raising the
point was simply my own impression is that, practically speaking, the
vast majority of SSL use today is based on the public infrastructure
that is known to be widely compromised, and this is less widely
discussed than perhaps it should be.

>>> - I have read that it is considered bad practice to mandate specific
>>> cryptographic algorithms with protocols (Applied Cryptography?)
>
> Where does the current draft mandate any specific algorithms? I've
> tried to make it flexible, by specifying hash and signature algorithms
> where they are used so they can be changed if warranted.

I think I was referring to SSL here.

>>> - It is not a good idea to have a flat error space (waiting_for....).
>>> What you will wind up with is loads of crazy state-based logic. What
>>> you need is grouping - general states, with more specific states as an
>>> option.
>
> These error states are only for debugging a failed payment in order to
> determine alternate paths to try, and not part of the transactions
> themselves. Again, I don't want to overspecify until we see how it's
> actually used. Or, you can think of what I've specified as the
> general states, with the more specific states awaiting later
> specification :)

Haha, a veritable world of potential!!! *cue for slow, 16:9 camera pan
revealing vista of utopian bliss to euphoric electronica*

>>> - HTTP is perhaps a limiting option for a financial networking
>>> protocol as it limits people - just as TCP does - to point-to-point
>>> communications. Many financial networks require broadcast/multicast
>>> distribution of data, particularly when operating at scale. In
>>> addition, there is a certain degree of overhead in SSL and HTTP that
>>> introduces latencies that may not be desirable in certain financial
>>> networking scenarios.
>
> HTTP/JSON can be replaced with a custom binary transport and binary
> message encoding such as protocol buffers if necessary for performance
> in later versions. Right now HTTP is useful because people are
> familiar with it and it encourages more implementations and easier
> deployment, eg, using PHP.
>
> If broadcast/multicast data is required, that can be specified to use
> an appropriate transport. Currently that is not required. The goal
> isn't to specify a monolithic meta-protocol that can support anything
> a financial network would want, it's to do one thing (multihop value
> transfers) and do it well. It could be a useful component in a larger
> framework of protocols.

OK. So on the one hand you're limiting the scope, and on the other
hand you're saying it might get bigger later. This seems fair enough
but perhaps the practical challenges for interoperability may be
greater than expected. Probably at this point the most important
thing is an implementation.

>> I would prefer just JSON (or protocol Buffers, I don't care) and ZMQ.
>> Anyway most of the design is based on JSON.
>
> ZMQ doesn't do authentication and encryption well -- you basically
> have to reimplement TLS on top of it (or whatever subset you need),
> since it's not baked in.

On a somewhat connected note, my present thinking is that because in
some cases encryption may not be required or desirable (eg. (1)
scenarios with a trusted link layer and either (1A) low latency
requirements or (1B) low power consumption requirements, (2) signed
but not encrypted messages, (3) cases where oversight/transparency is
required, (4) unforeseen use cases, etc.) that it may be best to
exclude from protocol specification entirely.

An example of an unforeseen use case is something a research scientist
wrote to me after announcing some previous drafts (IIBAN, IMIC) on one
of the Internet Engineering Task Force mailing lists. He said that he
was interested in the application of such a generalized trading system
to the embedded systems arena, specifically the problem of controlling
the dynamic allocation of electric power to various subsystems. In a
similar way, perhaps such a system could be applied to national-scale
power grids or other unexpected areas. (ie. In this case, electrical
power becomes the commodity, the transport layer the internal
connections of the device, and perhaps some internal/external
connection for the negotiation of battery charge with external
devices)

- Walter

[Jorge Timón]

Just in case this link is useful...
http://www.zeromq.org/topics:encryption

"Use TLS/SSL as a transport (seems cleanest but is incompatible with
multicast and the notion of hops over devices)"

Maybe I'm too optimistic about the future development of ZMQ. It seems
compatible with anything, but many things seem to just not be
implemented yet.

Back to my main point, I don't see any financial transaction that
can't be modeled using the Ripple concept. That's why I think a
generic enough distributed ripple protocol can meet the requirements
of IFEX.

I like much the current design precisely because I think it is very
generic. Decisions like using HTTP have more to do with having an
implementation soon, but it's mostly JSON. I think it would be easy to
remove the HTTP and use only JSON.
We don't have any users now so we we don't need the perfect API with
the first prototype, later iterations (I know, you don't want many
iterations when publishing APIs) can be more ambitious, but the
current design is more than enough for a prototype.

What interests me most. Walter, do you have an example of a
transaction that can't be conducted with the protocol for some reason?
I would like to give it a try so you can understand my optimistic
point of view about the potential of this. I guess I think of Ripple
as you think of IFEX.
Maybe I'm too immersed in Ripple to see other things. I even use
Ripple as a way to understand and compare other monies, even cash
monies like gold, which initially may seem directly opposed to credit.

> --
> 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.
>
>


--
Jorge Timón

[Walter]

> What interests me most. Walter, do you have an example of a
> transaction that can't be conducted with the protocol for some reason?

It seems to me that any requirement for a reasonably low latency
multicast/broadcast/anycast message would fail on two levels due to
the use of HTTP and SSL. Such messages are needed for the free and
fair operation of currency and commodity markets so that participants
receive advice about market changes at as close to the same time as
possible. Also, with regards to the same goal, I am not sure how your
addressing works, or what authentication model you have, if any, to
validate the origin of multicast/broadcast/anycast messages
(classically sent via spoofable protocols such as UDP due to their
lack of state).

While you could hack some forwarding on top of point-to-point links
via HTTP and SSL and declare it equivalent, that type of solution
fails to scale with the same properties as the multi-point topology.

> I would like to give it a try so you can understand my optimistic
> point of view about the potential of this. I guess I think of Ripple
> as you think of IFEX.

Sure.

> Maybe I'm too immersed in Ripple to see other things. I even use
> Ripple as a way to understand and compare other monies, even cash
> monies like gold, which initially may seem directly opposed to credit.

Hehe, perhaps you are, and of course myself also. But it's often an
interesting and valid way to think through things... fixating on a
certain perspective for awhile. There remains a certain balance to be
had - being careful to try to see validity in differing concerns,
potential issues, and modifying things to suit cases unconsidered
(often hand-in-hand with the slow growth of complexity) - versus a
rigid table-thumping minimalism by which alternatives must be
addressed through layering. Good protocol design is supposed to be
hard, though I can't actually see anyone putting their hand up as an
expert - even at the IETF - which has a far better track record than,
say, the ITU in packet-based networking protocol design field.
Perhaps it's basically a question of user base and avoiding some
obvious pitfalls, hoping for the best, and phase of the moon. At
least, right now for financial networking and digital currencies, the
phase of the moon has never been better.

- Walter

[Ryan Fugger]

On Thu, Aug 9, 2012 at 12:14 PM, Walter <walter....@gmail.com> wrote:
>> What interests me most. Walter, do you have an example of a
>> transaction that can't be conducted with the protocol for some reason?
>
> It seems to me that any requirement for a reasonably low latency
> multicast/broadcast/anycast message would fail on two levels due to
> the use of HTTP and SSL. Such messages are needed for the free and
> fair operation of currency and commodity markets so that participants
> receive advice about market changes at as close to the same time as
> possible. Also, with regards to the same goal, I am not sure how your
> addressing works, or what authentication model you have, if any, to
> validate the origin of multicast/broadcast/anycast messages
> (classically sent via spoofable protocols such as UDP due to their
> lack of state).
>
> While you could hack some forwarding on top of point-to-point links
> via HTTP and SSL and declare it equivalent, that type of solution
> fails to scale with the same properties as the multi-point topology.
>

Low-latency near-simultaneous broadcast of all routing information to
all servers would be ideal, for sure... I wasn't aware that such
technology existed on an internet scale, though. Do you have any
examples you can point me to?

Ryan

[Walter]

That's just the thing, you asked for an example of financial
settlement that might not be possible to address with present ideas
about Ripple protocol design.

I gave it. Now you're implying that it's not valid because it doesn't
accord with your design assumptions.

My point was - as you requested - to highlight those are assumptions.

- Walter

[Ryan Fugger]

On Thu, Aug 9, 2012 at 1:35 PM, Walter <walter....@gmail.com> wrote:
>> Low-latency near-simultaneous broadcast of all routing information to
>> all servers would be ideal, for sure... I wasn't aware that such
>> technology existed on an internet scale, though. Do you have any
>> examples you can point me to?
>
> That's just the thing, you asked for an example of financial
> settlement that might not be possible to address with present ideas
> about Ripple protocol design.
>
> I gave it. Now you're implying that it's not valid because it doesn't
> accord with your design assumptions.
>
> My point was - as you requested - to highlight those are assumptions.
>

Sorry, I wasn't commenting on the validity of the example, I was
wondering if you knew a feasible way to actually build an
internet-scale system that can solve that problem. Because I would
like Ripple to be able to handle that example. If such a broadcast
mechanism were possible, you could specify it as a routing method,
just like the current routing is only specified as a routing method
that is defined separately from the core protocol:

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

As it stands, I've made the design assumption that we can't have
real-time broadcast routing updates, which means Ripple is of very
limited usefulness for high-frequency-trading-type activity. That is
fine with me because I see that kind of activity as potentially
destabilizing to the kind of network I want to build. I think that
the transfer fees in Ripple would be low enough to facilitate
real-world exchange, but too high for high-frequency speculative
trading, partly because if everyone's servers were getting hammered by
high-frequency traders, they'd increase their fees to keep it at bay.

I envision Ripple being an open, global system like the web, and I'm
trying to make design choices that reflect that. If certain groups
want to build private Ripple-type networks, that's fine, but they
don't need an open protocol to do it -- they can just design whatever
kind of system they want, based on as much of Ripple as is useful to
them.

Maybe this is a core difference between Ripple and IFEX -- IFEX wants
to be a protocol framework for building various exchange systems, and
Ripple wants to be a protocol, albeit an extensible one, for building
a single, unified global network...? Perhaps Ripple is an instance of
IFEX?

Ryan

[Walter]

On 10 August 2012 10:48, Ryan Fugger <a...@ryanfugger.com> wrote:
> On Thu, Aug 9, 2012 at 1:35 PM, Walter <walter....@gmail.com> wrote:
>>> Low-latency near-simultaneous broadcast of all routing information to
>>> all servers would be ideal, for sure... I wasn't aware that such
>>> technology existed on an internet scale, though. Do you have any
>>> examples you can point me to?
>>
>> That's just the thing, you asked for an example of financial
>> settlement that might not be possible to address with present ideas
>> about Ripple protocol design.
>>
>> I gave it. Now you're implying that it's not valid because it doesn't
>> accord with your design assumptions.
>>
>> My point was - as you requested - to highlight those are assumptions.
>>
>
> Sorry, I wasn't commenting on the validity of the example, I was
> wondering if you knew a feasible way to actually build an
> internet-scale system that can solve that problem.

In my opinion there are tradeoffs, for example it either has to have
high latency and remain "centralised" (eg. large-scale consensus
scheme, ala Bitcoin's blockchain), or it has to be decentralised.

I really do not know the answer. I am not and have never tried to
build a currency system. IFEX only wraps existing settlement systems
(of all kinds, for all commodities). Hopefully it can also provide a
useful basis for future systems.

The lack of unity in settlement system properties was the core reason
I started looking down the IFEX path - a perceived lack of clarity
regarding the objective properties of these systems, at least as
presented to machines for multi-system settlement pathfinding. (If
that makes sense...)

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

The hub concept sounds a little like a conventional market. What about
mischevious hubs? How is trust with a hub brokered?

> Maybe this is a core difference between Ripple and IFEX -- IFEX wants
> to be a protocol framework for building various exchange systems, and
> Ripple wants to be a protocol, albeit an extensible one, for building
> a single, unified global network...? Perhaps Ripple is an instance of
> IFEX?

The terminology in the existing IFEX draft at
http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft
would see Ripple as a "settlement system". Once Ripple is functional,
by objectively describing the properties of the Ripple network(s)
within an IFEX system, it should be possible to place Ripple on a
one-to-one footing with existing / conventional financial networks and
have IFEX settlements routed across it automatically in
computationally justifiable means (less fees, less time, greater
trust, accords better with user preferences like "avoid <x big bank>",
"avoid <y intermediate currency>", etc.)

- Walter

[Ryan Fugger]

On Thu, Aug 9, 2012 at 6:24 PM, Walter <walter....@gmail.com> wrote:
> On 10 August 2012 10:48, Ryan Fugger <a...@ryanfugger.com> wrote:
>> Sorry, I wasn't commenting on the validity of the example, I was
>> wondering if you knew a feasible way to actually build an
>> internet-scale system that can solve that problem.
>
> In my opinion there are tradeoffs, for example it either has to have
> high latency and remain "centralised" (eg. large-scale consensus
> scheme, ala Bitcoin's blockchain), or it has to be decentralised.
>
> I really do not know the answer. I am not and have never tried to
> build a currency system. IFEX only wraps existing settlement systems
> (of all kinds, for all commodities). Hopefully it can also provide a
> useful basis for future systems.
>

[...]

> The terminology in the existing IFEX draft at
> http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft
> would see Ripple as a "settlement system". Once Ripple is functional,
> by objectively describing the properties of the Ripple network(s)
> within an IFEX system, it should be possible to place Ripple on a
> one-to-one footing with existing / conventional financial networks and
> have IFEX settlements routed across it automatically in
> computationally justifiable means (less fees, less time, greater
> trust, accords better with user preferences like "avoid <x big bank>",
> "avoid <y intermediate currency>", etc.)

Hmmm... This is exactly the routing problem that Ripple intends to
solve: to have settlements routed across heterogeneous accounting
systems in order to optimize a certain set of characteristics (most
likely settlement cost). (In other words, just as a Ripple payment
could be one step in an IFEX transaction, an IFEX transaction could be
one step in a Ripple payment.)

My question, then, is: How does IFEX propose to accomplish routing
across heterogeneous accounting systems?

>> http://ripple-project.org/Protocol/ExchangePublishingRoutingMethod
>
> The hub concept sounds a little like a conventional market. What about
> mischevious hubs? How is trust with a hub brokered?
>

Brokering hub trust is outside the scope right now. Basically the
client software will tell the Ripple server what hubs to accept IOUs
from on its behalf. Where it gets this data is up to it. The most
obvious example is from direct user input: "What's X's credit limit?
$100? OK."

Previous versions of the protocol have had inter-hub messaging systems
for negotiating trust, but since they're not strictly necessary for
the protocol to operate, I've left them out of this version.

Ryan

[Ryan Fugger]

On Thu, Aug 9, 2012 at 7:03 PM, Ryan Fugger <a...@ryanfugger.com> wrote:
> My question, then, is: How does IFEX propose to accomplish routing
> across heterogeneous accounting systems?
>

Furthermore, how does IFEX propose to accomplish transaction atomicity
across multiple independent systems?

These have been the two major issues in developing the protocol draft
over time. How does IFEX address them?

Thanks,
Ryan

[Apostolis Xekoukoulotakis]

IFEX is an interoperability protocol between internet financial exchanges. It tries to define a common protocol , based on the knowledge of what transactions and guarantees the  current financial system requires.

That knowledge is valuable because it has been derived after many years of high volume transactions in the financial industry. In other words, we need to look at how the current system does things.

Ripple is a specific system that has specific problems to solve. It also has specific goals.
For example, the  latency requirement for ripple is something between 1sec to 20 sec. It doesnt need less because algorithmic trading is not part of its goals. But less is always better, it is simply not a requirement.

What in my opinion should be (are) the ripples goals? 

Generally :
1. achieve equality of oportunity between peers
2. "promote" solidarity between peers
 |
 |   specifically in importance order
\/

1. define the most generally possible iou "packet" and analyze at which conditions the network is stable and achieves the above goals.

my assumptions: the solution will require
a)the decentralization of investment, ie everyone being an investor of their own money.
b) equal opportunity in knowledge(skills, hardware)

projects:http://opensourceecology.org/wiki/Open_Source_Ecology_Paradigm

c)equal opportunity to capital.(the nullification of the effects of someone having more money than others to economic decisions )

d)possibly the reduction of personal economic freedoms so as to have stability.

2. provide a mechanism that will enforce the repayment of the ious.

assumptions:
a)this should be done in a decentralized way.
b) the mechanism should be able to handle all the possible economic activities that 1 allows.

projects: the currrent implementation at ripple is a good starting point. We need to increase the credit limits that peers have because currently they are not sufficient. That might require an entirely new decentralized mechanism based on other things than trust.

3.provide connections with the current financial system.

assumptions: bootstrapping an economy from zero is impossible( trading cycles will not be achieved or will be achieved at an increased cost.)


In conclusion, Ripples goals pose to us mathematical and engineering problems that need to be solved. The solution of those problems and our goals will define the protocol implementation. You cant define the protocol before hand.

If IFEX manages to become the leading internet financial protocol, then ripple will have to implement it so as to connect to the outside world.

2012/8/10 Ryan Fugger <a...@ryanfugger.com>

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.

--

Sincerely yours, 

     Apostolis Xekoukoulotakis

[Jorge Timón]

On 8/9/12, Walter <walter....@gmail.com> wrote:
>> What interests me most. Walter, do you have an example of a
>> transaction that can't be conducted with the protocol for some reason?
>
> It seems to me that any requirement for a reasonably low latency
> multicast/broadcast/anycast message would fail on two levels due to
> the use of HTTP and SSL. Such messages are needed for the free and
> fair operation of currency and commodity markets so that participants
> receive advice about market changes at as close to the same time as
> possible. Also, with regards to the same goal, I am not sure how your
> addressing works, or what authentication model you have, if any, to
> validate the origin of multicast/broadcast/anycast messages
> (classically sent via spoofable protocols such as UDP due to their
> lack of state).
>
> While you could hack some forwarding on top of point-to-point links
> via HTTP and SSL and declare it equivalent, that type of solution
> fails to scale with the same properties as the multi-point topology.

Ok, imagine the protocol is defined just as JSON over any network,
UDP, TCP, Tor...
Say we use zmq, so we have multicast.
Or better, let's forget those technical details for a little and focus
on the messages.
What I want to convince you about is that Ripple doesn't need to be a
"settlement system". What I want is Ripple to be the base of IFEX as
the accounting system that needs to be settled somehow. Regular ripple
users would settle their debts with products. Banking system users
would settle their debts with bank transfers, bitcoin users, with
bitcoin transfers, etc. LETS users can build their currencies on top
of the Ripple network, so no need for a separate settlement system
neither. Backed digital currencies can be directly represented as
"ripple IOUs", etc.
I'm more on the analysis phase when talking about Ripple and IFEX than
in the actual design.

>> I would like to give it a try so you can understand my optimistic
>> point of view about the potential of this. I guess I think of Ripple
>> as you think of IFEX.
>
> Sure.

So with the basic messages of the Ripple protocol (please, forget HTTP
and that stuff), what can't be done in IFEX?
I was expecting an example with several actors, different settlement
systems and so on. So that I can model it within a Ripple network.
I was thinking more about the "Ripple concept" in general than in any
instance of the decentralized protocol design.
Please, give me an ambitious example with "everything" that IFEX
should be able to do.
I'll try to model the whole example through an imaginary perfectly
scalable and working Ripple protocol. Through an imaginary IFEX
protocol build on top of Ripple through extensions.

[Walter]

>>> What interests me most. Walter, do you have an example of a
>>> transaction that can't be conducted with the protocol for some reason?
>>
>> It seems to me that any requirement for a reasonably low latency
>> multicast/broadcast/anycast message would fail on two levels due to
>> the use of HTTP and SSL. Such messages are needed for the free and
>> fair operation of currency and commodity markets so that participants
>> receive advice about market changes at as close to the same time as
>> possible. Also, with regards to the same goal, I am not sure how your
>> addressing works, or what authentication model you have, if any, to
>> validate the origin of multicast/broadcast/anycast messages
>> (classically sent via spoofable protocols such as UDP due to their
>> lack of state).
>>
>> While you could hack some forwarding on top of point-to-point links
>> via HTTP and SSL and declare it equivalent, that type of solution
>> fails to scale with the same properties as the multi-point topology.
>
> Ok, imagine the protocol is defined just as JSON over any network,
> UDP, TCP, Tor...
> Say we use zmq, so we have multicast.
> Or better, let's forget those technical details for a little and focus
> on the messages.


> What I want to convince you about is that Ripple doesn't need to be a
> "settlement system". What I want is Ripple to be the base of IFEX as
> the accounting system that needs to be settled somehow.

The IFEX notion at present includes aspects such as:
- descriptions of transactions in which a node was not involved at all
- identities of actors thus involved
- trust models on the former
- temporal computation
- potentially other "cost" computations (legal jurisdiction or risk
models, etc.)
- market-style auctioning of arbitrary commodities or currencies

Here the views of George Soros come to mind:
"I believe that the failure is more profound than generally
recognized. It goes back to the foundations of economic theory.
Economics tried to model itself on Newtonian physics. It sought to
establish universally and timelessly valid laws governing reality. But
economics is a social science and there is a fundamental difference
between the natural and social sciences. Social phenomena have
thinking participants who base their decisions on imperfect knowledge.
That is what economic theory has tried to ignore."
http://georgesorosblog.blogspot.ca/2012/07/george-soros-speech-on-eurozone-crisis.html

The points above, instead, seem to represent more than "an accounting
system that needs to be settled somehow", a phrase which to my mind
questionably implies a holistic understanding of state and a definable
end-goal, the sort of thing that's valid to discuss within closed
systems (economies as modeled in conventional economic theory) but
less so in unconsolidated markets such as cash, gold, reputation, etc.
which are shaky-but-functional cornerstones of the global economy, the
same economy with which any evolved economic system must integrate in
order to gain traction. I would argue that instead of an accounting
system seeking a solution, these aspects of IFEX instead represent the
expression of wants or needs, of past acts, of the relations between
actors, of specific routing requirements. They existing within a
potentially connected system, yes - but one in which there is no
solution. Instead, each actor, understanding what it does about the
system, seeks only to meet its own needs and minimise its own risks as
the ever-changing entirety evolves in state. Sometimes things break,
sometimes there are bad actors, shortages or oversupplies of
particular commodities in demand (including trust), but the beast
functions. Importantly, it functions with less artificial barriers to
innovation and efficiency than present models. Less covert
politicization or hidden control. Less assumptions, less legalese.
For there is no single center but many, and none of those may exist
more strongly than they may justify themselves economically or
functionally, and even that existence is rooted in the trust and
participation of others - not top-down regulation in a closed system
with old-world inertia.

>>> I would like to give it a try so you can understand my optimistic
>>> point of view about the potential of this. I guess I think of Ripple
>>> as you think of IFEX.
>>
>> Sure.
>
> So with the basic messages of the Ripple protocol (please, forget HTTP
> and that stuff), what can't be done in IFEX?
> I was expecting an example with several actors, different settlement
> systems and so on. So that I can model it within a Ripple network.
> I was thinking more about the "Ripple concept" in general than in any
> instance of the decentralized protocol design.
> Please, give me an ambitious example with "everything" that IFEX
> should be able to do.

I can't answer that, to be honest. It's aiming at generality - the
aforementioned, early example of a researcher expressing interest in
its use for power management in embedded devices being just one
potential example of unplanned but realistic use cases.

Since I don't know how to dream up an example with all potential uses,
would suggest having a look at the Settlement Paths section of the
proposal at http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Settlement-Paths
- in particular the two message sequence chart diagrams. If you do
that I would be very interested in your thoughts.

- Walter

[Walter]

>> My question, then, is: How does IFEX propose to accomplish routing
>> across heterogeneous accounting systems?

In short, by describing it accurately (and without the capacity for
repudiation) but at the same time keeping it entirely out of scope.

More verbosely, IFEX empowers nodes to execute the inter settlement
system or inter-currency/commodity transactions with increased clarity
via their own arbitrary, specific priorities... but these are - as
they have always been - based upon inherently subjective judgements.

> Furthermore, how does IFEX propose to accomplish transaction atomicity
> across multiple independent systems?

The present IFEX proposal suggests describing that state in a
simplified, unidirectional model adopted from an analysis of most of
the world's largest stock exchanges and their protocols, some of the
world's largest transaction processors, various personal experiences
and a touch of random. Those states and their relationship are
described here:
http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Financial-Transaction-State
(The proposal is certainly imperfect, but it is a reasonably well
considered starting point.)

- Walter

[Apostolis Xekoukoulotakis]

>> Furthermore, how does IFEX propose to accomplish transaction atomicity
>> across multiple independent systems?
>
>The present IFEX proposal suggests describing that state in a
>simplified, unidirectional model adopted from an analysis of most of
>the world's largest stock exchanges and their protocols, some of the
>world's largest transaction processors, various personal experiences
>and a touch of random.  Those states and their relationship are
>described here:
>http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Financial-Transaction-State
>(The proposal is certainly imperfect, but it is a reasonably well
>considered starting point.)

I dont think that any current system has the restrictions that are imposed to ripple.

Transactions cannot be guaranteed to be reversible. That is in fact the only reason why we need synchronization in the transactions to guarantee atomicity.

The same path cannot be guaranteed to be available again because new transactions could starve the credit limits of the path.

So things are more demanding in ripple.

2012/8/10 Walter <walter....@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.

--

Sincerely yours, 

     Apostolis Xekoukoulotakis

[Apostolis Xekoukoulotakis]

Which doesnt stop ripple from implementing the protocol. After all, all the important things are out of scope.

2012/8/10 Apostolis Xekoukoulotakis <xeko...@gmail.com>

[Walter]

>>> Furthermore, how does IFEX propose to accomplish transaction atomicity
>>> across multiple independent systems?
>>
>>The present IFEX proposal suggests describing that state in a
>>simplified, unidirectional model adopted from an analysis of most of
>>the world's largest stock exchanges and their protocols, some of the
>>world's largest transaction processors, various personal experiences
>>and a touch of random. Those states and their relationship are
>>described here:
>>http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Financial-Transaction-State
>>(The proposal is certainly imperfect, but it is a reasonably well
>>considered starting point.)
>

> Transactions cannot be guaranteed to be reversible. That is in fact the only
> reason why we need synchronization in the transactions to guarantee
> atomicity.
>
> The same path cannot be guaranteed to be available again because new
> transactions could starve the credit limits of the path.
>
> So things are more demanding in ripple.

The unidirectional notion does not mean irreversibility, it just means
simplified and predictable state flow with reduced complexity.

An IFEX-based transaction may indeed result be reversed, however any
reversal must be created as a separate transaction for independent
processing (though this would generally reference the former
transaction's FTID or financial transaction identifier).

By decoupling the (sort of higher-level) notion of settlement
reversibility from IFEX's basic financial transaction concept, overall
complexity is reduced - not dissimilar to the way SMTP handles this
response to your email.

- Walter

[Ryan Fugger]

I think I might be starting to understand...

IFEX doesn't specify a routing mechanism or a distributed commit
mechanism, but it's more of a wrapper layer on top of systems like
Ripple that can perform these functions. Is that right?

So, for example, if someone was considering whether to pay by SWIFT or
by Ripple, they could use the IFEX metadata published by both systems
to determine which to use and how best to use it, according to the
criteria they decide.

But, if someone wanted to make a payment that traveled first over
SWIFT to an intermediary, who then make a Ripple payment to the final
destination, IFEX couldn't accomplish that, because it lacks the
routing mechanism to discover this settlement path, as well as the
distributed commit mechanism to perform the transaction across SWIFT
and Ripple in serial fashion. (If someone wanted to build a Ripple
layer to integrate their SWIFT transactions into the Ripple network,
then this could be done as a Ripple transaction.)

The purpose of IFEX is to provide a common interface to multiple
settlement systems for deciding which settlement system to use. The
purpose of Ripple is to make transactions using multiple settlement
systems in serial fashion. IFEX is like a logical OR; Ripple is like
a logical AND.

Am I understanding correctly?

Thanks,
Ryan

[Walter]

> I think I might be starting to understand...
>
> IFEX doesn't specify a routing mechanism or a distributed commit
> mechanism, but it's more of a wrapper layer on top of systems like
> Ripple that can perform these functions. Is that right?

Spot on.

> So, for example, if someone was considering whether to pay by SWIFT or
> by Ripple, they could use the IFEX metadata published by both systems
> to determine which to use and how best to use it, according to the
> criteria they decide.

Exactly.

> But, if someone wanted to make a payment that traveled first over
> SWIFT to an intermediary, who then make a Ripple payment to the final
> destination, IFEX couldn't accomplish that, because it lacks the
> routing mechanism to discover this settlement path, as well as the
> distributed commit mechanism to perform the transaction across SWIFT
> and Ripple in serial fashion. (If someone wanted to build a Ripple
> layer to integrate their SWIFT transactions into the Ripple network,
> then this could be done as a Ripple transaction.)

Wrong here. If you check out first message sequence chart at
http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Settlement-Paths
the initial step '1. Quotation request' (of type RFQ: request for
quotation) would be a sort of "can anyone (who I sent this to) deliver
to the following Ripple destination?" query.

The (subset of) positive responses to that query (messages of type QUO
- ie. quotations) would include various information regarding the
second-hop (and possibly further hop) settlement path, as well as
identity information upon which trust-related decisions could be based
by the initial node.

Based upon the originating node's own priorities, it could then select
a path and engage the transaction, referencing the quotation.

Throughout the life of the quotation, various updates might be sent
automatically or queried for, such as the intermediary SWIFT endpoint
receiving the funds, the intermediary SWIFT endpoint forwarding them
via ripple, and the ultimate ripple endpoint receiving the funds.

> The purpose of IFEX is to provide a common interface to multiple
> settlement systems for deciding which settlement system to use. The
> purpose of Ripple is to make transactions using multiple settlement
> systems in serial fashion. IFEX is like a logical OR; Ripple is like
> a logical AND.

I'm not sure that I follow this part entirely... I think that you
misunderstood that IFEX is not capable of serial transactions.

> Am I understanding correctly?

Mostly!

- Walter

[Ryan Fugger]

On Fri, Aug 10, 2012 at 7:38 PM, Walter <walter....@gmail.com> wrote:
>> But, if someone wanted to make a payment that traveled first over
>> SWIFT to an intermediary, who then make a Ripple payment to the final
>> destination, IFEX couldn't accomplish that, because it lacks the
>> routing mechanism to discover this settlement path, as well as the
>> distributed commit mechanism to perform the transaction across SWIFT
>> and Ripple in serial fashion. (If someone wanted to build a Ripple
>> layer to integrate their SWIFT transactions into the Ripple network,
>> then this could be done as a Ripple transaction.)
>
> Wrong here. If you check out first message sequence chart at
> http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Settlement-Paths
> the initial step '1. Quotation request' (of type RFQ: request for
> quotation) would be a sort of "can anyone (who I sent this to) deliver
> to the following Ripple destination?" query.
>

Ah, I hadn't seen this -- thanks for pointing it out! This was my
original understanding of what IFEX did, but when you said there was
no routing system or distributed commit mechanism, I assumed that IFEX
couldn't accomplish serial transactions. My understanding now is that
IFEX is analogous to Ripple's core protocol, at least in terms of
performing serial transactions.

IFEX's Quotation Request can be seen as a very simple routing system.
Your diagram says that the payer sends an RFQ to "World", but what
that means isn't defined. Presumably it means that you're just
broadcasting it out to everyone you know, and they are just relaying
it to everyone they know, and so on, which isn't a scalable approach,
but will certainly work for small network sizes. It seems clear that
this simple default routing system is interchangeable with other more
sophisticated routing systems.

The main difference with the way Ripple interacts with routing is that
Ripple prescribes an extra step between routing and initiating the
value transfer: Exchange Request.

http://ripple-project.org/Protocol/Protocol06#exchange-request

This step is basically to confirm the intermediaries' willingness to
participate in the transaction at the terms advertised by the routing
system, as well as to give them routing instructions for that
transaction. That functionality could probably be moved into the
routing extensions...

IFEX and Ripple core protocol are also similar in how they transfer
value in a serial transaction. IFEX has the payer send funds forward
down the settlement path, trusting that they will arrive, which is
called the "null" commit method in Ripple:

http://ripple-project.org/Protocol/Protocol06#commit-methods

Ripple core protocol, however, has explicit hooks to allow for more
sophisticated commit mechanisms that achieve better atomicity.
Presumably, IFEX would need something like this as well...?

How do IFEX payers know that their transfer has indeed been received
by the intended recipient? How does IFEX guard against intermediaries
cheating and keeping funds for themselves without passing them along?
There is a note in the draft about possibly requiring a cryptographic
proof to finalize the transaction. How would this work?

Thanks,
Ryan

> The (subset of) positive responses to that query (messages of type QUO
> - ie. quotations) would include various information regarding the
> second-hop (and possibly further hop) settlement path, as well as
> identity information upon which trust-related decisions could be based
> by the initial node.
>
> Based upon the originating node's own priorities, it could then select
> a path and engage the transaction, referencing the quotation.
>
> Throughout the life of the quotation, various updates might be sent
> automatically or queried for, such as the intermediary SWIFT endpoint
> receiving the funds, the intermediary SWIFT endpoint forwarding them
> via ripple, and the ultimate ripple endpoint receiving the funds.
>
>> The purpose of IFEX is to provide a common interface to multiple
>> settlement systems for deciding which settlement system to use. The
>> purpose of Ripple is to make transactions using multiple settlement
>> systems in serial fashion. IFEX is like a logical OR; Ripple is like
>> a logical AND.
>
> I'm not sure that I follow this part entirely... I think that you
> misunderstood that IFEX is not capable of serial transactions.
>
>> Am I understanding correctly?
>
> Mostly!
>
> - Walter
>

[Ryan Fugger]

On Sat, Aug 11, 2012 at 2:16 PM, Ryan Fugger <a...@ryanfugger.com> wrote:
> Ripple prescribes an extra step between routing and initiating the
> value transfer: Exchange Request.
>
> http://ripple-project.org/Protocol/Protocol06#exchange-request
>
> This step is basically to confirm the intermediaries' willingness to
> participate in the transaction at the terms advertised by the routing
> system, as well as to give them routing instructions for that
> transaction. That functionality could probably be moved into the
> routing extensions...
>

I have moved the exchange request specification into the routing extension:

http://ripple-project.org/Protocol/ExchangePublishingRoutingMethod#exchange-request

It fits better there, since it's possible that other routing methods,
like IFEX's RFQ, don't require it. I've also moved payment status
queries there, since they are coupled to the routing method in several
ways.

Ryan

[Walter]

>>> But, if someone wanted to make a payment that traveled first over
>>> SWIFT to an intermediary, who then make a Ripple payment to the final
>>> destination, IFEX couldn't accomplish that, because it lacks the
>>> routing mechanism to discover this settlement path, as well as the
>>> distributed commit mechanism to perform the transaction across SWIFT
>>> and Ripple in serial fashion. (If someone wanted to build a Ripple
>>> layer to integrate their SWIFT transactions into the Ripple network,
>>> then this could be done as a Ripple transaction.)
>>
>> Wrong here. If you check out first message sequence chart at
>> http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Settlement-Paths
>> the initial step '1. Quotation request' (of type RFQ: request for
>> quotation) would be a sort of "can anyone (who I sent this to) deliver
>> to the following Ripple destination?" query.
>
> Ah, I hadn't seen this -- thanks for pointing it out! This was my
> original understanding of what IFEX did, but when you said there was
> no routing system or distributed commit mechanism, I assumed that IFEX
> couldn't accomplish serial transactions. My understanding now is that
> IFEX is analogous to Ripple's core protocol, at least in terms of
> performing serial transactions.

OK. That's interesting. You are certainly better placed than me to
make such comparisons.

> IFEX's Quotation Request can be seen as a very simple routing system.
> Your diagram says that the payer sends an RFQ to "World", but what
> that means isn't defined. Presumably it means that you're just
> broadcasting it out to everyone you know, and they are just relaying

> it to everyone they know, and so on...

On the problem of routing.

Before drafting the IFEX proposal my employer Payward, Inc. submitted
the IIBAN proposal (http://tools.ietf.org/html/draft-iiban-01) to the
IETF which suggests normalizing non-conventional global financial
endpoints to an IBAN (International Bank Account Number)
machine-compatible standard that is based upon subsuming the position
of National Numbering Authority (NNA) for the nominal [ISO3166]
'nation' of AA, "the Internet". IBAN is the standard for bank account
numbering throughout Europe and a radidly growing number of additional
nations (such as Azerbaijan, Costa Rica, Guatemala, Israel, Pakistan,
Saudi Arabia, Switzerland, Tunisia, and Turkey: see
http://code.google.com/p/php-iban/source/browse/tags/1.3.1/registry.txt
for a full list). the IBAN standard and by extension IIBAN proposal
builds on the conventional European financial (and particularly
banking) world's experience dealing with billions of endpoints for
people and companies in the 20th century and hundreds of millions in
the electronic age [note: own rough guesstimate]. The IIBAN proposal
therefore features the following positive properties:
- Short and fixed length (13 characters, eg. AA-12-011-123Z56)
- IIBAN only allows single case letters. This reduces ambiguity by
discouraging the use of lower case presentation that may result in
ambiguity (the letter 'l' and the number '1'), and makes the standard
more accessible in parts of the world that do not normally make
extensive use of the Roman alphabet
- Democratic namespace allocation. (via IANA)
- Transcription error detection and correction (detects endpoint
specification errors before they cost money)
- Easy interoperability with existing banking systems in a growing
list of European and other countries
- Familiar to users

IIBAN proposes allocating 'institution codes' via the Internet
Assigned Numbers Authority (IANA). Nodes wishing to connect to
perform routing still need some mechanism for finding the network
location of the 'institution code' in question, and for clarification
in this area perhaps a subsequent version of the draft is needed - a
scheme that supports both strong cryptographic identification (this is
money, after all) and DNS might be preferable. The interplay between
IFEX and IIBAN is not yet completely clear. I had previously
considered that IIBAN-specified endpoints would probably form the bulk
of IFEX-based traffic, along with a small number of alternate network
connections (Bitcoin, Ripple, maybe some conventional payment
providers such as Paypal and Western Union, etc.), in which case the
number of peers broadcast to (getting back to the discussion around
'step 1' in the diagram) would be small, since the majority of routing
would be performed via a relatively efficient/low latency
(destinations can be cached, the global list of 'institution codes' is
not going to be large), semi-hierarchical, openly (ie. IANA)
administered protocol. This approach is not dissimilar to how the
global telephone system works, or how the SWIFT network apparently
operates. (Incidentally, lurkers may be interested in an inquiry I put
the the European Data Protection Supervisor of late, over here:
http://www.asktheeu.org/en/request/information_on_financial_informa).
In the end this is a tradeoff with good returns: you can scale a lot
more efficiently with a small dash of centralisation.

So in short - the set of recipients to be more likely a preset list of
peers (legacy gateways), and possibly some open hierarchical systems
such as that proposed by IIBAN as well. Actual money routing
obviously depends upon the financial endpoint type in question.
IFEX-wise, any node that is willing to talk to you could be a
potential relay, relays can promote services by proxy (and so on, and
so on0, and it is up to individual nodes to select with whom they peer
and ultimately execute transactions.

> The main difference with the way Ripple interacts with routing is that
> Ripple prescribes an extra step between routing and initiating the
> value transfer: Exchange Request.
>
> http://ripple-project.org/Protocol/Protocol06#exchange-request

I am not certain about the progression of message flow in a Ripple
exchange, but in IFEX the option is there to use cached willingness of
participation based upon prior information, or simply to assume it.
It has been an active goal of IFEX thus far to minimize any kind of
assumptions in the core proposal regarding desirable properties of the
transaction process, so as not to shackle its applicability to
specialist use cases such as internal financial routing, high
frequency trading or weird serial combinations of high-latency
decentralized bitcoin - USD - SWIFT - KRW - bubblegum - world of
warcraft magic swords on a particular subset of Korean servers.

> This step is basically to confirm the intermediaries' willingness to
> participate in the transaction at the terms advertised by the routing
> system, as well as to give them routing instructions for that
> transaction. That functionality could probably be moved into the
> routing extensions...

IFEX allows this to be cached in advance - for an example, compare the
two graphs at: http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Settlement-Paths

> IFEX and Ripple core protocol are also similar in how they transfer
> value in a serial transaction. IFEX has the payer send funds forward
> down the settlement path, trusting that they will arrive, which is
> called the "null" commit method in Ripple:
>
> http://ripple-project.org/Protocol/Protocol06#commit-methods

Actually, all systems trust that funds will arrive.

In IFEX, the difference is that the trust can be objectively modeled
and decisions made upon this basis - unlike conventional financial
networks, or similar system-specific functionality in specific
settlement systems (eg. Bitcoin).

> Ripple core protocol, however, has explicit hooks to allow for more
> sophisticated commit mechanisms that achieve better atomicity.
> Presumably, IFEX would need something like this as well...?

Sure. Intermediate nodes may issue reports (signed, with
non-repudation and relevant evidence) the ongoing flow of a
transaction that they are facilitating. This can be seen for example
in the same http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Settlement-Paths
diagram #1, in steps 4a, 4c, 4.3, 4.4b.

> How do IFEX payers know that their transfer has indeed been received
> by the intended recipient?

The appropriate evidence obviously depends upon the settlement system
in use - in particular at the last hop of the transaction.

Because in the present era, few settlement systems actually offer
third party, cryptographically verifiable evidence that a transaction
has taken place (as an aside, it would seem that this is one of the
great strengths of Bitcoin for the underground economy), it seems that
wrapping the settlement with a reputation layer built is the only
available solution. This is IFEX's approach - ie. if you claim to
deliver funds (a claim that is cryptographically signed), the
recipient claims they never arrived, and I hold this evidence up to
the community then either the ultimate receipient or you may have
issues receiving additional payments until such time as the weight of
evidence has placed the blame on one or other other or the matter is
resolved amicably. For computational purposes, both nodes would
likely be greylisted.

> How does IFEX guard against intermediaries
> cheating and keeping funds for themselves without passing them along?

As above.

> There is a note in the draft about possibly requiring a cryptographic
> proof to finalize the transaction. How would this work?

Firstly, I am not a cryptographer, so I do not deign to design and
hold up a cryptographic system to the world and proclaim it suitable
for the transportation of funds.

However, luckily certain systems that are well established seem to do
a reasonable job of providing exactly what is needed - ie.
non-repudiation, point to point encryption and a decentralized network
of cryptographic trust. In particular, the GPG ecosystem.

I propose that nodes adopt one (or more) GPG identities and use these
to facilitate message security, non-repudiation of message claims, and
trust management.

In practice, once such a system were to scale to any size, then - not
dissimilarly to existing financial networks - nodes would require some
degree of reputation in order for third parties to trust them handling
their funds. However, critically they would not require an
ISO-approved country to operate, or an ISO-approved-country-approved
formal banking license, which appears (no doubt along with hush-hush
regulatory ingress regarding anti money laundering legislation and
threats of asset seizure by one country in particular) to be a key
innovation barrier to the status quo of dominant international
financial networks today.

- Walter

[Apostolis Xekoukoulotakis]

Because IFEX has taken into account legacy financial systems to design its protocol, it cannot be used for ripple.

I am new to protocol designing but dont you need experience with existent implementations before you refine it to a protocol? This question goes to both Walter and Ryan.

 There have been some guys from the p2p f2f community that were willing to help in the design of such a protocol. We will certainly need help with that from people who have spent years in the subject(decentralized f2f routing). I am certainly not currently capable of doing it(due to it been decentralized).

I dont see the point in defining the protocol beforehand.

2012/8/12 Walter <walter....@gmail.com>

- Walter

--
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.

[Walter]

> I am new to protocol designing but dont you need experience with existent
> implementations before you refine it to a protocol? This question goes to
> both Walter and Ryan.

Of course, having some experience does make things easier to see sometimes!

> There have been some guys from the p2p f2f community that were willing to
> help in the design of such a protocol. We will certainly need help with that
> from people who have spent years in the subject(decentralized f2f routing).
> I am certainly not currently capable of doing it(due to it been
> decentralized).
>
> I dont see the point in defining the protocol beforehand.

My own impression is that in distributed application-level networking
protocols, even more so than in other types of protocols, a protocol
tends to truly define the overall system of which it is part.

- Walter

[Apostolis Xekoukoulotakis]

>My own impression is that in distributed application-level networking
>protocols, even more so than in other types of protocols, a protocol
>tends to truly define the overall system of which it is part.

Certainly, the protocol will define the system, but first we ll need to solve the real problems that will define the protocol.
After many implementations/cycles of a new protocol to a new over all system etc, we ll get a stable protocol.

And you did exactly that. You had a lot of experience in the financial industry, you took those experiences and you made IFEX.

2012/8/12 Walter <walter....@gmail.com>

- Walter

--
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 Sat, Aug 11, 2012 at 7:48 PM, Walter <walter....@gmail.com> wrote:
> So in short - the set of recipients to be more likely a preset list of
> peers (legacy gateways), and possibly some open hierarchical systems
> such as that proposed by IIBAN as well. Actual money routing
> obviously depends upon the financial endpoint type in question.
> IFEX-wise, any node that is willing to talk to you could be a
> potential relay, relays can promote services by proxy (and so on, and
> so on0, and it is up to individual nodes to select with whom they peer
> and ultimately execute transactions.
>

If you're not supporting non-hierarchical open networks, then this
seems feasible. Ripple's goal is to build a large, non-hierarchical
network that is open for anyone to participate in without requiring
registration. I think that the way IFEX is designed, it could support
more sophisticated routing systems as well, without needing to change
the transactions are processed.

> I am not certain about the progression of message flow in a Ripple
> exchange, but in IFEX the option is there to use cached willingness of
> participation based upon prior information, or simply to assume it.
> It has been an active goal of IFEX thus far to minimize any kind of
> assumptions in the core proposal regarding desirable properties of the
> transaction process, so as not to shackle its applicability to
> specialist use cases such as internal financial routing, high
> frequency trading or weird serial combinations of high-latency
> decentralized bitcoin - USD - SWIFT - KRW - bubblegum - world of
> warcraft magic swords on a particular subset of Korean servers.
>

Right. While that is exactly the kind of thing that Ripple wants to support :)

>> IFEX and Ripple core protocol are also similar in how they transfer
>> value in a serial transaction. IFEX has the payer send funds forward
>> down the settlement path, trusting that they will arrive, which is
>> called the "null" commit method in Ripple:
>>
>> http://ripple-project.org/Protocol/Protocol06#commit-methods
>
> Actually, all systems trust that funds will arrive.
>

There is a difference between trusting one's immediate peers and
having to trust intermediaries and payment recipients who are not
one's peers. There is also a difference between trusting in the value
of debt held with someone, and trusting that person to faithfully
carry out payment routing, especially if they can cheat on the routing
and not point the finger at someone else. There is also always the
possibility of technical glitches and miscommunications that lead to
lost funds.

In Ripple with the registry commit mechanism, you only need to trust
the value of debt held with your peers. You needn't trust anyone to
faithfully carry out payment routing -- if they cheat, or if there are
technical failures, they won't profit, and if they do, their peers
will know what they did.

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

IFEX could support such methods as well, albeit by adding some
explicit commit hooks into the transaction messages. The benefit is
that makes the system more flexible by requiring less administrative
overhead to manage trust, as detailed below.

> In IFEX, the difference is that the trust can be objectively modeled
> and decisions made upon this basis - unlike conventional financial
> networks, or similar system-specific functionality in specific
> settlement systems (eg. Bitcoin).
>

In Ripple, there's no need to worry about this, since trusting
intermediaries is not an issue.

>> Ripple core protocol, however, has explicit hooks to allow for more
>> sophisticated commit mechanisms that achieve better atomicity.
>> Presumably, IFEX would need something like this as well...?
>
> Sure. Intermediate nodes may issue reports (signed, with
> non-repudation and relevant evidence) the ongoing flow of a
> transaction that they are facilitating. This can be seen for example
> in the same http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Settlement-Paths
> diagram #1, in steps 4a, 4c, 4.3, 4.4b.
>

That works only if you have a trusted way of auditing that the actual
transfer occurred in each case. If there's a transaction A -> B -> C
-> D, you may not trust C, or the method of transferring funds to D.
In Ripple, this isn't a problem -- the fact of the existence of a
commit message means each intermediary has acknowledged the transfer
has occurred. In IFEX, you can't safely perform the transaction,
because C might report that the funds were transferred to D, but D
might say it never received them. You have no way of figuring out who
is lying.

>> How do IFEX payers know that their transfer has indeed been received
>> by the intended recipient?
>
> The appropriate evidence obviously depends upon the settlement system
> in use - in particular at the last hop of the transaction.
>

Spot on.

> Because in the present era, few settlement systems actually offer
> third party, cryptographically verifiable evidence that a transaction
> has taken place (as an aside, it would seem that this is one of the
> great strengths of Bitcoin for the underground economy), it seems that
> wrapping the settlement with a reputation layer built is the only
> available solution. This is IFEX's approach - ie. if you claim to
> deliver funds (a claim that is cryptographically signed), the
> recipient claims they never arrived, and I hold this evidence up to
> the community then either the ultimate receipient or you may have
> issues receiving additional payments until such time as the weight of
> evidence has placed the blame on one or other other or the matter is
> resolved amicably. For computational purposes, both nodes would
> likely be greylisted.
>

That could work, as long as each of the participants was registered
somewhere and there was a reliable way of preventing blacklisted
participants from adopting new identities.

> However, luckily certain systems that are well established seem to do
> a reasonable job of providing exactly what is needed - ie.
> non-repudiation, point to point encryption and a decentralized network
> of cryptographic trust. In particular, the GPG ecosystem.
>
> I propose that nodes adopt one (or more) GPG identities and use these
> to facilitate message security, non-repudiation of message claims, and
> trust management.
>
> In practice, once such a system were to scale to any size, then - not
> dissimilarly to existing financial networks - nodes would require some
> degree of reputation in order for third parties to trust them handling
> their funds. However, critically they would not require an
> ISO-approved country to operate, or an ISO-approved-country-approved
> formal banking license, which appears (no doubt along with hush-hush
> regulatory ingress regarding anti money laundering legislation and
> threats of asset seizure by one country in particular) to be a key
> innovation barrier to the status quo of dominant international
> financial networks today.
>

The main difference I see between Ripple and IFEX, then, is that
Ripple wants to be completely open and as anonymous as possible,
without needing to trust in the behaviour of all participants, and
IFEX wants to guard against bad behaviour by setting up its own
community-oriented reputation system, as an improvement over the
existing government-appointed gatekeepers.

The question I have for Walter, then, is whether IFEX would consider
Ripple-style commit hooks in its transaction messages in order to
avoid the need for any sort of gatekeeping at all...

Ryan

[Walter]

>> So in short - the set of recipients to be more likely a preset list of
>> peers (legacy gateways), and possibly some open hierarchical systems
>> such as that proposed by IIBAN as well. Actual money routing
>> obviously depends upon the financial endpoint type in question.
>> IFEX-wise, any node that is willing to talk to you could be a
>> potential relay, relays can promote services by proxy (and so on, and
>> so on0, and it is up to individual nodes to select with whom they peer
>> and ultimately execute transactions.
>
> If you're not supporting non-hierarchical open networks, then this
> seems feasible. Ripple's goal is to build a large, non-hierarchical
> network that is open for anyone to participate in without requiring
> registration. I think that the way IFEX is designed, it could support
> more sophisticated routing systems as well, without needing to change
> the transactions are processed.

This is now a discussion of IIBAN based addressing (one option for
specifying financial endpoints within IFEX) rather than a discussion
of IFEX per-se.

- IFEX certainly supports arbitrary settlement networks' native
addressing formats.
- IIBAN can easily support open membership without registration and
without sacrificing format compatibility with existing financial
systems if a registering party chooses to provide such a bridging
service. For more information about this specific design decision,
please see: http://tools.ietf.org/html/draft-iiban-01#section-4.4

>>> IFEX and Ripple core protocol are also similar in how they transfer
>>> value in a serial transaction. IFEX has the payer send funds forward
>>> down the settlement path, trusting that they will arrive, which is
>>> called the "null" commit method in Ripple:
>>>
>>> http://ripple-project.org/Protocol/Protocol06#commit-methods
>>
>> Actually, all systems trust that funds will arrive.
>
> There is a difference between trusting one's immediate peers and
> having to trust intermediaries and payment recipients who are not
> one's peers.

Can you give an example?

If the peer is an intermediate hop and you do not know the identity of
the further hops to be traversed, then it is in effect the same as
trusting the immediate peer... since no further information about the
further hops might be available. This is because it is probably safe
under most conditions to assume that, unless the peer is somehow
adding value (brokering trust, lowering fees, expediting delivery,
mitigating risk via insurance, or similar), then one would cut out the
peer and go direct to achieve improvements to these aspects of the
transaction.

> There is also a difference between trusting in the value
> of debt held with someone, and trusting that person to faithfully
> carry out payment routing, especially if they can cheat on the routing
> and not point the finger at someone else.

Taking the view that Bitcoin and similar distributed consensus systems
are centralised (or at least "consolidated"), a cryptographically
backed reputation system is the only mechanism I am aware of for
viable decentralised (or perhaps better to use the term
"non-consolidated") financial routing.

Please let me know if you can think of an improvement.

> There is also always the
> possibility of technical glitches and miscommunications that lead to
> lost funds.

Again, reputation systems and signed commitments to undertakings are
the only class of solution that I am aware of here. They are
certainly an improvement on current-era legalese and arbitrary legal
jurisdictions with evolving bodies of law and the need for costly,
time-consuming, specialist interpretation (often still resulting in a
distinct lack of clarity).

> In Ripple with the registry commit mechanism, you only need to trust
> the value of debt held with your peers. You needn't trust anyone to
> faithfully carry out payment routing -- if they cheat, or if there are
> technical failures, they won't profit, and if they do, their peers
> will know what they did.
>
> http://ripple-project.org/Protocol/RegistryCommitMethod

I believe I understand the concept, however this means that your peers
can spy on everything that you do and you can't cut them out without
somehow establishing a free line of credit with a stranger, right?

The pragmatic perspective may be that one can always leave a cash
deposit with someone to expedite the trust barrier. Of course, then
we end up with bodies approaching what banks are today. The
difference is that they will be competing based upon objective,
computationally available quality of service metrics (trust, speed,
cost, assets supported, etc.) and in an open and global market.

> IFEX could support such methods as well, albeit by adding some
> explicit commit hooks into the transaction messages. The benefit is
> that makes the system more flexible by requiring less administrative
> overhead to manage trust, as detailed below.

As above.

>> In IFEX, the difference is that the trust can be objectively modeled
>> and decisions made upon this basis - unlike conventional financial
>> networks, or similar system-specific functionality in specific
>> settlement systems (eg. Bitcoin).
>
> In Ripple, there's no need to worry about this, since trusting
> intermediaries is not an issue.

Hang on - how can it be a non-issue, but at the same time
intermediaries are aware of every transaction?

I wouldn't want just anyone to be aware of all of my transactions.

>>> Ripple core protocol, however, has explicit hooks to allow for more
>>> sophisticated commit mechanisms that achieve better atomicity.
>>> Presumably, IFEX would need something like this as well...?
>>
>> Sure. Intermediate nodes may issue reports (signed, with
>> non-repudation and relevant evidence) the ongoing flow of a
>> transaction that they are facilitating. This can be seen for example
>> in the same http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Settlement-Paths
>> diagram #1, in steps 4a, 4c, 4.3, 4.4b.
>
> That works only if you have a trusted way of auditing that the actual
> transfer occurred in each case.

Sure. You have the receiving party's cryptographic signature on a
report saying they received the funds.

> If there's a transaction A -> B -> C
> -> D, you may not trust C, or the method of transferring funds to D.

In some cases, you may not care. IFEX caters to these.
In others, you may. IFEX also caters to these.

> In Ripple, this isn't a problem -- the fact of the existence of a
> commit message means each intermediary has acknowledged the transfer
> has occurred. In IFEX, you can't safely perform the transaction,
> because C might report that the funds were transferred to D, but D
> might say it never received them. You have no way of figuring out who
> is lying.

This is just as in the conventional finance world. The only solution
is a reputation system, which effectively takes the place of the
global hodge-podge of government regulation.

>>> How do IFEX payers know that their transfer has indeed been received
>>> by the intended recipient?
>>
>> The appropriate evidence obviously depends upon the settlement system
>> in use - in particular at the last hop of the transaction.
>
> Spot on.

I should clarify. This is only relevant to the parties involved in a given hop.

Multi-hop IFEX wise, you still have the receiving party's
cryptographic signature on a report saying they received the funds.

>> Because in the present era, few settlement systems actually offer
>> third party, cryptographically verifiable evidence that a transaction
>> has taken place (as an aside, it would seem that this is one of the
>> great strengths of Bitcoin for the underground economy), it seems that
>> wrapping the settlement with a reputation layer built is the only
>> available solution. This is IFEX's approach - ie. if you claim to
>> deliver funds (a claim that is cryptographically signed), the
>> recipient claims they never arrived, and I hold this evidence up to
>> the community then either the ultimate receipient or you may have
>> issues receiving additional payments until such time as the weight of
>> evidence has placed the blame on one or other other or the matter is
>> resolved amicably. For computational purposes, both nodes would
>> likely be greylisted.
>
> That could work, as long as each of the participants was registered
> somewhere and there was a reliable way of preventing blacklisted
> participants from adopting new identities.

There is no way in an open system to prevent blacklisted participants
from adopting new identities.

However, new identities have zero reputation.

Obviously, don't choose zero-reputation nodes as intermediaries, or
don't send funds to them in ways that are deniable (like
cash-in-post).

The public key acts as the identity/registration.

IFEX's general design criteria is to integrate with any financial
system, with the latter being both vaguely and broadly defined.

Integration with Ripple is definitely desired.

However, in attempting to describe and model transactions on arbitrary
systems, it cannot impose a single transaction model. Therefore, I am
not quite sure what you mean here. Could you please go through the
commit hooks method and explain how it differs from other approaches
to transaction processing - specifically that proposed in the current
IFEX draft - and how it could be used to improve the current IFEX
draft?

- Walter

[Ryan Fugger]

On Sun, Aug 12, 2012 at 3:18 PM, Walter <walter....@gmail.com> wrote:
>> If you're not supporting non-hierarchical open networks, then this
>> seems feasible. Ripple's goal is to build a large, non-hierarchical
>> network that is open for anyone to participate in without requiring
>> registration. I think that the way IFEX is designed, it could support
>> more sophisticated routing systems as well, without needing to change
>> the transactions are processed.
>
> This is now a discussion of IIBAN based addressing (one option for
> specifying financial endpoints within IFEX) rather than a discussion
> of IFEX per-se.
>

I didn't intend to discuss IIBAN in particular, which I see as a
naming scheme, not a routing scheme, although naming schemes can aid
in routing, especially in hierachical systems. By routing, I mean how
someone discovers a path or paths over which to make a (potentially)
multi-hop payment. IIBAN naming does not help with this.

IFEX's routing model is simple broadcast search, and does not scale
well. I was pointing out how it would be simple enough to replace
broadcast search with something like link-state routing, which Ripple
uses, for greater scalability. Nothing needs to be changed in IFEX,
which I think is a good design.

> - IFEX certainly supports arbitrary settlement networks' native
> addressing formats.
> - IIBAN can easily support open membership without registration and
> without sacrificing format compatibility with existing financial
> systems if a registering party chooses to provide such a bridging
> service. For more information about this specific design decision,
> please see: http://tools.ietf.org/html/draft-iiban-01#section-4.4
>

It's not the registering for names that I want to discuss, it's the
need for a payer to trust all the intermediaries it uses, and have a
way to audit their transfers to ensure funds aren't lost in transit.
As you point out, this requires participation in some kind of global
reputation system. I think it ought to be possible for IFEX to avoid
that requirement with technical measures such as Ripple uses.

I'm going to skip over responding to a lot of points about trusting
intermediaries and having the recipient's signature, because I think
we both agree that IFEX in the current draft needs a global reputation
system to work, and that one should only transact with trustworthy
recipients, over paths of trustworthy intermediaries, lest they
misreport funds as not having arrived.

>> In Ripple with the registry commit mechanism, you only need to trust
>> the value of debt held with your peers. You needn't trust anyone to
>> faithfully carry out payment routing -- if they cheat, or if there are
>> technical failures, they won't profit, and if they do, their peers
>> will know what they did.
>>
>> http://ripple-project.org/Protocol/RegistryCommitMethod
>
> I believe I understand the concept, however this means that your peers
> can spy on everything that you do and you can't cut them out without
> somehow establishing a free line of credit with a stranger, right?
>

You can't send payment through someone without them finding out,
that's correct. The same is true in IFEX. (Peers are just those you
have accounts with.)

I should explain that only the payer and recipient know they are the
transaction endpoints. Intermediaries only know where the funds are
coming from, and where they are going to, not the original source or
final destination. (The current protocol prescribes the payer to
contact each intermediary, but could always do so anonymously, ie,
through a proxy.)

> The pragmatic perspective may be that one can always leave a cash
> deposit with someone to expedite the trust barrier. Of course, then
> we end up with bodies approaching what banks are today. The
> difference is that they will be competing based upon objective,
> computationally available quality of service metrics (trust, speed,
> cost, assets supported, etc.) and in an open and global market.
>

I agree. Ideally we can leverage trust that is not based in existing
centralized institutions, but it is always there to use if necessary.

> IFEX's general design criteria is to integrate with any financial
> system, with the latter being both vaguely and broadly defined.
>
> Integration with Ripple is definitely desired.
>

I don't think that's at issue. Integrating Ripple as a settlement
system into IFEX would be trivial on a technical level. Whether
financial incumbents would endorse it into the IFEX reputation system
is another story, however...

I'm more interested in improving IFEX, which to me, obviously, means
making it more like Ripple :)

> However, in attempting to describe and model transactions on arbitrary
> systems, it cannot impose a single transaction model. Therefore, I am
> not quite sure what you mean here. Could you please go through the
> commit hooks method and explain how it differs from other approaches
> to transaction processing - specifically that proposed in the current
> IFEX draft - and how it could be used to improve the current IFEX
> draft?
>

Ripple has a two-phase commit in which funds are frozen ("promised")
in the first phase, and then transferred in the second. The
first-phase promises specify the hash of a commit token known only to
the recipient, and only this token can actually trigger the transfers.
Once the recipient has been promised the correct amount, it publishes
the commit token, thereby triggering transfers for every promise
simultaneously. The different commit methods basically specify
different methods of publishing the commit token.

Between two peers who trust each other's creditworthiness (again,
different than trust them to route payments correctly), the promise
and the commit token together can be taken as an IOU from one to the
other, to be treated however they'd like. Between less trusting
peers, they'd need a 3rd-party settlement system that is integrated
with Ripple, or a legal agreement to honour Ripple IOUs between them
in whatever way suited them.

IFEX could implement similar transaction dynamics, I think, and then
it would not require a global reputation system to make sure there is
no cheating.

(You may still need a reputation system of some sort to impose a set
of criteria under which transactions must be reversed. Ripple treats
this as a higher-order issue out of scope -- a Ripple transaction may
or may not be directly reversible, and in any case what is needed is
collective pressure on the recipient to agree to repay the value
somehow, whether over the same path, a different path, or outside
Ripple altogether.)

What do you think?

Ryan

[Walter]

>>> If you're not supporting non-hierarchical open networks, then this
>>> seems feasible. Ripple's goal is to build a large, non-hierarchical
>>> network that is open for anyone to participate in without requiring
>>> registration. I think that the way IFEX is designed, it could support
>>> more sophisticated routing systems as well, without needing to change
>>> the transactions are processed.
>>
>> This is now a discussion of IIBAN based addressing (one option for
>> specifying financial endpoints within IFEX) rather than a discussion
>> of IFEX per-se.
>
> I didn't intend to discuss IIBAN in particular, which I see as a
> naming scheme, not a routing scheme, although naming schemes can aid
> in routing, especially in hierachical systems.

Right, though I think that's an understatement. It seems that most
successful global network addressing schemes today are based upon
various shades of transparently administered hierarchy... IP
addressing, DNS, the E.164 international telephone numbering scheme,
etc.

> By routing, I mean how
> someone discovers a path or paths over which to make a (potentially)
> multi-hop payment. IIBAN naming does not help with this.

Incorrect. Similar to the aforementioned schemes, typically a prefix
within the naming scheme identifies the namespace owner, which in turn
is used for routing (eg. IP -> AS -> route, but with the capacity for
edge-nodes to simply forward via a "default route" with optional QoS
or other specialist requirements specified). IIBAN proposes a very
similar scheme to the early (pre-CIDR) IPv4 address space routing, but
translated to the financial industry. If an IIBAN is like an IP, then
IFEX provides the transport-layer protocols on top of this addressing
layer.

> IFEX's routing model is simple broadcast search, and does not scale
> well.

Incorrect. I think you are looking at IFEX through too much of a
Ripple perspective. IFEX supports arbitrary routing schemes, the
priorities of which are ultimately decided by each node to suit their
own situation and financial transaction requirements. Ultimately IFEX
basically aims to provide a layer of information to each nodes' local
routing algorithms that allows them to make these decisions. Doing
so, it puts routing decisions out of scope in the algorithmic sense,
but remains critically focused on providing routing-related
information to enable those arbitrary local routing implementations.
This feels like the right thing to do, since deployments will
certainly have vastly differing priorities in areas such as latency,
centralization, anonymity, trust, wire-level security requirements,
location and nature of commodities being transferred, and acceptable
risk.

> I was pointing out how it would be simple enough to replace
> broadcast search with something like link-state routing, which Ripple
> uses, for greater scalability. Nothing needs to be changed in IFEX,
> which I think is a good design.

If I understand this roughly correctly as-per layer 2 networking
parlance as 'the link is up and free, let's use it', then yes ...
certainly IFEX could be used with link-state routing with no changes.
This is by design - as mentioned above, the basic idea of IFEX is to
enable arbitrary routing algorithms rather than mandating any. This
should also have the side effect of enabling the rapid implementation
of highly available, failover-capable settlement systems.... a
property missing at the financial settlement layer in the vast
majority of business and consumer-oriented conventional financial
settlement services today.

>> - IFEX certainly supports arbitrary settlement networks' native
>> addressing formats.
>> - IIBAN can easily support open membership without registration and
>> without sacrificing format compatibility with existing financial
>> systems if a registering party chooses to provide such a bridging
>> service. For more information about this specific design decision,
>> please see: http://tools.ietf.org/html/draft-iiban-01#section-4.4
>
> It's not the registering for names that I want to discuss, it's the
> need for a payer to trust all the intermediaries it uses, and have a
> way to audit their transfers to ensure funds aren't lost in transit.
> As you point out, this requires participation in some kind of global
> reputation system. I think it ought to be possible for IFEX to avoid
> that requirement with technical measures such as Ripple uses.

There are many ways to broker trust.

In conventional financial networks, walking in to a large business
labelled "bank" should assure you that the business is government
regulated, probably trustworthy enough to give you back any money that
you deposit, and capable of providing the various services you expect.
Most people would hand over money to such a bank, say, when opening
an account in a foreign country, even though they are unfamiliar with
the regulations.

Similarly, larger payment-facilitating or payment-taking businesses on
the internet have no trouble convincing people to hand over money,
bank or card details. This is often based similarly upon a certain
assurance of regulation.

However, the direction that the world seems to be moving today is one
of internationalism. With an increasing number of goods and services
being provided virtually and across borders and an ever-greater
percentage of their physical antecedents being ordered online through
multiple assets or currencies, and legal jurisdictions (often
involving corporates with careful structural planning for tax,
shipping, warehousing, etc.) everyone is facing increased trust
complexity.

Until now, a lot of that complexity has been faced with blind trust
(eg. "I trust my bank / payment processor / credit card company not to
rip me off on currency exchange", "I trust that the government will
not vindictively audit my innovative and probably-arguably-legal
tax-minimization structure as everyone's doing it", "I trust that the
state government of California will not get upset that I am routing my
payments through another US state to avoid taxation when selling to
local residents", "I trust that the credit card company will not
reverse this payment after I ship the goods to the customer", etc.),
and not always without remorse.

These aspects of trust are clearly far more far-reaching throughout a
the life of a settlement than simply a binary decision regarding an
entity's desirability as middleman within a settlement.

IFEX is perhaps more about is objectively describing trust-related
features of a transactions *that are already there* to provide a more
empowering platform for financial settlement in general than
specifying or enabling any one particular solution to areas such as
trust network development for alternate financial communities.

> I'm going to skip over responding to a lot of points about trusting
> intermediaries and having the recipient's signature, because I think
> we both agree that IFEX in the current draft needs a global reputation
> system to work, and that one should only transact with trustworthy
> recipients, over paths of trustworthy intermediaries, lest they
> misreport funds as not having arrived.

I must object to this as oversimplification, although I agree that a
cryptographically backed reputation system is the only decentralised
method I am aware of to either (A) deal with individual ones and twos
style transactions; or (B) democratically bootstrap intermediaries as
trust anchors within an emerging, multi-jurisdictional, potentially
self-regulating financial ecosystem.

Other trust metrics (as mentioned above) can come in to play. It's an
area for innovation. Anyone can potentially broker trust. One might
perceive intersections with, say, LETS and Unix keysigning-party style
communities.

>>> In Ripple with the registry commit mechanism, you only need to trust
>>> the value of debt held with your peers. You needn't trust anyone to
>>> faithfully carry out payment routing -- if they cheat, or if there are
>>> technical failures, they won't profit, and if they do, their peers
>>> will know what they did.
>>>
>>> http://ripple-project.org/Protocol/RegistryCommitMethod
>>
>> I believe I understand the concept, however this means that your peers
>> can spy on everything that you do and you can't cut them out without
>> somehow establishing a free line of credit with a stranger, right?
>
> You can't send payment through someone without them finding out,
> that's correct.

That's a pretty big drawback.

> The same is true in IFEX. (Peers are just those you
> have accounts with.)

I read this and thought "That's not necessarily true!", then realised
it hasn't been fleshed out even in my own mind.

In principle one could avoid this by encrypting each stage of a
multi-hop transaction separately, such that only next-hop destination
specificity was available to intermediaries.

I see no reason not to do this, other than message size and efficiency.

> I should explain that only the payer and recipient know they are the
> transaction endpoints. Intermediaries only know where the funds are
> coming from, and where they are going to, not the original source or
> final destination. (The current protocol prescribes the payer to
> contact each intermediary, but could always do so anonymously, ie,
> through a proxy.)

Oh, it seems Ripple does this already.

My thoughts for IFEX would be to simply encrypt the message for the
next hop in the message to the first hop, and so on, such that direct
contact is not required.

> I don't think that's at issue. Integrating Ripple as a settlement
> system into IFEX would be trivial on a technical level. Whether
> financial incumbents would endorse it into the IFEX reputation system
> is another story, however...

Reputation should never be allowed to be based explicitly or otherwise
upon central authorities - this has been the failure of the web's SSL
infrastructure.

> I'm more interested in improving IFEX, which to me, obviously, means
> making it more like Ripple :)

Haha. OK! But again, I think that for IFEX the scope reduction to
remove the notion of explicitly suggesting routing algorithms is very
important. IFEX is not a settlement network.

>> However, in attempting to describe and model transactions on arbitrary
>> systems, it cannot impose a single transaction model. Therefore, I am
>> not quite sure what you mean here. Could you please go through the
>> commit hooks method and explain how it differs from other approaches
>> to transaction processing - specifically that proposed in the current
>> IFEX draft - and how it could be used to improve the current IFEX
>> draft?
>
> Ripple has a two-phase commit in which funds are frozen ("promised")
> in the first phase, and then transferred in the second.

IFEX seems more sophisticated than Ripple in its view of transactions
in that it has still more 'phases' (with regards to the traditional
computer science use of the term), though not mandatory. See
http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft#TOC-Financial-Transaction-State
for the concrete states, which are divided in to three 'phases' (with
regards to the progression of the financial transaction - if the prior
sense it taken, then at least four [1][2][3][4]).

[ PRE phase ]
- Request for quotation [1]
- Quotation [1]
[ LIVE phase ]
- Execution [2]
- Settling... [2]
- Settled but reversible [3]
[ POST phase ]
- Done, failed, partial, reversed [4]

> IFEX could implement similar transaction dynamics, I think, and then
> it would not require a global reputation system to make sure there is
> no cheating.

I believe you are unclear or perhaps I am missing something.

IFEX describes and facilitates transactions occurring through external
settlement systems, and for this reason fundamentally *cannot prevent
cheating* in those external systems. In the event that trust issues
are likely to occur (eg. when exchanging with third parties over the
internet), then the best it can do is to provide for identification
and non-repudiation in order to facilitate a suitable reputation
system.

> (You may still need a reputation system of some sort to impose a set
> of criteria under which transactions must be reversed. Ripple treats
> this as a higher-order issue out of scope -- a Ripple transaction may
> or may not be directly reversible, and in any case what is needed is
> collective pressure on the recipient to agree to repay the value
> somehow, whether over the same path, a different path, or outside
> Ripple altogether.)
>
> What do you think?

I think you are looking at a finished IFEX implementation as an actual
financial settlement network. It's not. It's a system for facilitating
and describing financial-style transactions that occur over external
settlement systems in arbitrary currencies/commodities and over
arbitrary settlement paths that can operate over arbitrary topologies
and transport layers and makes minimal assumptions about the systems
it describes/facilitates. That's the current trajectory, anyway.

- Walter

[Ryan Fugger]

Yes, I realized yesterday that the fundamental difference between IFEX
and Ripple is that Ripple sees itself as a settlement system in and of
itself, and IFEX doesn't. I think the difference is semantic, in that
Ripple can model every transaction path that IFEX can. I also don't
think that the Ripple transaction model imposes any constraints on
external systems -- it is just a way of delivering the "execute"
message to all hops simultaneously, while giving the payer proof of
payment and the recipient and every intermediary proof they are owed
funds by their predecessor if there is any issue.

This mechanism can be used by IFEX to prevent cheating if it wants.
I'm happy to answer questions if you're interested in how exactly how
this mechanism could be implemented by IFEX.

Ryan

[Ryan Fugger]

I should add that I am also most interested in reasons you may think
that the two-phase commit model is unsuitable for IFEX, because if
Ripple wants to support the same kinds of transaction paths as IFEX,
then it should consider why it might not be able to with its current
model.

Thanks,
Ryan

[Walter]

> Yes, I realized yesterday that the fundamental difference between IFEX
> and Ripple is that Ripple sees itself as a settlement system in and of

> itself, and IFEX doesn't. I think the difference is semantic, ...

From my perspective the difference is clearly functional. This is
because any and all assumptions and limits regarding the settlement
process must, for a settlement system, be modeled either within the
state machine or the protocol itself, potentially including actual
algorithms defining their transition.

The weakness of IFEX's approach (leaving it out of scope) is perhaps
that it leaves open to implementators' interpretation the transition
criteria for any given settlement network being integrated. On the
other hand, it effectively limits scope, increases applicability and
extensibility to alternate models.

Without actually understanding the specifics, it seems to me that the
strength of Ripple's apparent approach is that it seeks to provide
guarantees to participants in and of itself. The weakness is that
this increases scope, reduces applicability and extensibility to
alternate models.

My own impression parallels that of the long held stratagem within
programming (particularly the Unix world: "This is the Unix
philosophy: Write programs that do one thing and do it well.",
http://en.wikipedia.org/wiki/Unix_philosophy) of seeking minimalism. I
am therefore less inclined to see the integration of additional
features (scope creep) within IFEX in a positive light. In fact, I
would prefer to remove features from IFEX and find ways to provide
them as optional extensions than to add them to the core proposal.
That said, a range of such features could prove an excellent resource
for defining and testing the extensibility of the base IFEX proposal.

> ... in that

> Ripple can model every transaction path that IFEX can.

I cannot comment on this part as I haven't yet had time to sit down
and attempt to properly understand Ripple.

> I also don't
> think that the Ripple transaction model imposes any constraints on

> external systems -- it is just a way of [1] delivering the "execute"
> message to all hops simultaneously, while [2] giving the payer proof of

> payment and the recipient and every intermediary proof they are owed
> funds by their predecessor if there is any issue.

IFEX's approach to the same is as follows.
[1] Outsource delivery concerns to the transport layer. (Note also
that 'simultaneously' is a very difficult thing to guarantee at the
best of times, and actually forms an exceedingly lucrative niche
within modern financial systems - high frequency trading)
[2] Recognise that "proof of payment" is both (A) a lost cause within
arbitrary external settlement systems, and (B) not necessarily
desirable for all deployments, for example due to overheads or the
potential use of IFEX to simply describe rather than execute
transactions

> This mechanism can be used by IFEX to prevent cheating if it wants.
> I'm happy to answer questions if you're interested in how exactly how
> this mechanism could be implemented by IFEX.
>

> I should add that I am also most interested in reasons you may think
> that the two-phase commit model is unsuitable for IFEX, because if
> Ripple wants to support the same kinds of transaction paths as IFEX,
> then it should consider why it might not be able to with its current
> mode

I remain unconvinced that integrating settlement guarantees is either
possible (given IFEX's goal to attempt to wrap arbitrary settlement
systems) or desirable (in that in IFEX's context this would increase
scope without, due the arbitrary nature of connected settlement
systems, apparently adding any effective guarantees). However, I am
not sure that I fully understand your proposal and would be extremely
interested if you can demonstrate how this is not the case.

- Walter

[Walter]

>> I also don't
>> think that the Ripple transaction model imposes any constraints on
>> external systems -- it is just a way of [1] delivering the "execute"
>> message to all hops simultaneously, while [2] giving the payer proof of
>> payment and the recipient and every intermediary proof they are owed
>> funds by their predecessor if there is any issue.
>
> IFEX's approach to the same is as follows.
> [1] Outsource delivery concerns to the transport layer. (Note also
> that 'simultaneously' is a very difficult thing to guarantee at the
> best of times, and actually forms an exceedingly lucrative niche
> within modern financial systems - high frequency trading)

Just for interest's sake and more generally as a good pondering
reference, see also point #2 @
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing

- Walter

[Ryan Fugger]

On Tue, Aug 14, 2012 at 5:06 PM, Walter <walter....@gmail.com> wrote:
>> Yes, I realized yesterday that the fundamental difference between IFEX
>> and Ripple is that Ripple sees itself as a settlement system in and of
>> itself, and IFEX doesn't. I think the difference is semantic, ...
>
> From my perspective the difference is clearly functional. This is
> because any and all assumptions and limits regarding the settlement
> process must, for a settlement system, be modeled either within the
> state machine or the protocol itself, potentially including actual
> algorithms defining their transition.
>

I don't see any limits that Ripple is putting on the settlement
process. It is simply delivering an "execute" message, just like
IFEX. It just avoids the possibility of half-completed transactions,
funds going missing partway to the destination, etc. These can be
sorted out manually in IFEX, sure, but why leave the possiblity open?

> The weakness of IFEX's approach (leaving it out of scope) is perhaps
> that it leaves open to implementators' interpretation the transition
> criteria for any given settlement network being integrated. On the
> other hand, it effectively limits scope, increases applicability and
> extensibility to alternate models.
>

Ripple also leaves it open. The two-phase commit is only an extension
to the core protocol. The core protocol itself has no commit dynamics
other than a voluntary forward passing of value, which is equivalent
to IFEX.

> Without actually understanding the specifics, it seems to me that the
> strength of Ripple's apparent approach is that it seeks to provide
> guarantees to participants in and of itself. The weakness is that
> this increases scope, reduces applicability and extensibility to
> alternate models.
>

On the contrary, Ripple can perform IFEX's simple forward commit, as
well as two-phase commit by many mechanisms because of its
extensibility. As it stands, there is no way to build a two-phase
commit extension for multi-hop IFEX transactions because it does not
support extensible commit mechanisms.

Adding support for more sophisticated commit mechanisms to IFEX could
look something like this:

* RFQ's and QUO's have a commit field that specifies the commit method
desired/offered, as well as other data relevant to that commit method
* EXE's have a commit field that specify the commit method in use, as
well as other relevant data

* The existing commit method could be called "basic", and nothing else
needs to be specified -- it works as currently designed

* A two-phase commit method could be called "two-phase", and would be
as follows:
* The recipient generates a secret commit token as well as its hash.
* The recipient sends the payer the commit token hash and a location
the commit token will be published, either directly if possible, or
via a relayed QUO message.
* The payer sends forward an EXE with the commit token hash and
commit token location, which means that the EXE is only valid when the
commit token is known. (There can also be a deadline for the commit
token to be known.)
* When the recipient received an EXE with the commit token hash, it
publishes the commit token to the location, which should be well-known
and non-repudiable (timestamped if deadline is used).
* Participants can (and probably should) wait until they receive
funds before forwarding funds on, but each one has a claim on its
predecessor -- an EXE combined with a valid commit token.

That way you don't lose anything the current design of IFEX can do,
but also gain the ability to add different commit mechanisms such as
the one I describe.

>> ... in that
>> Ripple can model every transaction path that IFEX can.
>
> I cannot comment on this part as I haven't yet had time to sit down
> and attempt to properly understand Ripple.
>

Oh, please do. I'll be happy to explain parts that don't make sense.

Two very short papers I wrote explaining the fundamental concepts of
the project:

http://ripple-project.org/decentralizedcurrency.pdf
http://ripple-project.org/paymentrouting.pdf

Then the latest protocol draft itself:

http://ripple-project.org/Protocol/Protocol06
http://ripple-project.org/Protocol/ExchangePublishingRoutingMethod
http://ripple-project.org/Protocol/RegistryCommitMethod
http://ripple-project.org/Protocol/BareCommitMethod

It's really not much reading -- probably less all told than the IFEX draft.

>> I also don't
>> think that the Ripple transaction model imposes any constraints on
>> external systems -- it is just a way of [1] delivering the "execute"
>> message to all hops simultaneously, while [2] giving the payer proof of
>> payment and the recipient and every intermediary proof they are owed
>> funds by their predecessor if there is any issue.
>
> IFEX's approach to the same is as follows.
> [1] Outsource delivery concerns to the transport layer. (Note also
> that 'simultaneously' is a very difficult thing to guarantee at the
> best of times, and actually forms an exceedingly lucrative niche
> within modern financial systems - high frequency trading)

By "simultaneously", I don't mean so much that every node receives the
execute message at the exact same moment (delivery = transport layer),
so much as a guarantee that either all nodes get an execute message or
none of them do (atomicity = commit mechanism).

> [2] Recognise that "proof of payment" is both (A) a lost cause within
> arbitrary external settlement systems, and (B) not necessarily
> desirable for all deployments, for example due to overheads or the
> potential use of IFEX to simply describe rather than execute
> transactions
>

Ripple doesn't give proof that the any particular settlement has
happened, but rather gives a claim on a settlement to those that must
receive one for the multi-hop transaction to succeed. It's proof that
all the participating settlement systems have received the execute
message, and cannot claim that they have not. They can do with it
what they will, but those owed have proof that they are owed. As
such, it's proof that something of value (a claim on settlement) has
been transferred to the final recipient.

In Ripple, I'm happy to call that "proof of payment", since part of
the project is to disrupt the common meaning of "payment". In IFEX,
you may wish to use different words, but I'm hoping you'll see what is
actually being accomplished and not let it become obscured by
differences in terminology.

Thanks,
Ryan

[Walter]

>>> Yes, I realized yesterday that the fundamental difference between IFEX
>>> and Ripple is that Ripple sees itself as a settlement system in and of
>>> itself, and IFEX doesn't. I think the difference is semantic, ...
>>
>> From my perspective the difference is clearly functional. This is
>> because any and all assumptions and limits regarding the settlement
>> process must, for a settlement system, be modeled either within the
>> state machine or the protocol itself, potentially including actual
>> algorithms defining their transition.
>
> I don't see any limits that Ripple is putting on the settlement
> process. It is simply delivering an "execute" message, just like
> IFEX. It just avoids the possibility of half-completed transactions,
> funds going missing partway to the destination, etc. These can be
> sorted out manually in IFEX, sure, but why leave the possiblity open?

Manually? Look, I think you have failed to see my point.

If the settlement process occurs external to any given system, then
the only thing that we can do is describe the process and allocate
blame. We cannot actually fully control that process. This is true
for Ripple, and it is true for IFEX.

I posit that your 'guarantee' is a logical fallacy. All that you are
doing is guaranteeing your own view, not reality.

And what of partially successful transfers, or those with incalculable
fees that wind up higher than assumed at the time of initiation? Those
that require additional inputs to complete?

How will they fail with your atomic commit? Sometimes? All the time?
Atomically? More or less descriptively or flexibly than under IFEX?

It's alright to call that feature optional and say it's not always
relevant, but actually it never adds value given external settlement
and signatures within messages.

PS. Just because a 'commit' token is not used (hey, I for one am good
with staying out of cryptography) doesn't mean that getting away with
bad behavior is functionally easier.

>> Without actually understanding the specifics, it seems to me that the
>> strength of Ripple's apparent approach is that it seeks to provide
>> guarantees to participants in and of itself. The weakness is that
>> this increases scope, reduces applicability and extensibility to
>> alternate models.
>
> On the contrary, Ripple can perform IFEX's simple forward commit, as

Again, IFEX leaves state change validation algorithms out of scope,
which in reality will almost certainly include gateways to settlement
services in order to validate third party claims, ie.
[1] IFEX: "I've sent you 500 USD"
[2] check bank account
[3] IFEX: perform local transaction state change
[4] IFEX: send acknowledgement of message #1.

In some cases under IFEX there may be no need at all to communicate
local transaction-related state change to other nodes. Think of the
situation wherein the deadline for initiation of a quoted transaction
has not been met and the transaction lapses. The other party may
later return to attempt the transaction, receiving an error due to the
transaction's expiry. Synchronization is relative, not absolute, with
a predictable state flow. The need for a clear notion of a
network-visible "commit" is therefore nominally avoided.

> well as two-phase commit by many mechanisms because of its
> extensibility. As it stands, there is no way to build a two-phase
> commit extension for multi-hop IFEX transactions because it does not
> support extensible commit mechanisms.

Actually the goal is that it's possible to add fields to any part of
any message, so extensibility is guaranteed. The extension you
suggest is entirely feasible under this mechanism, however I still see
it as a logical fallacy.

> Adding support for more sophisticated commit mechanisms to IFEX could
> look something like this:
>
> * RFQ's and QUO's have a commit field that specifies the commit method
> desired/offered, as well as other data relevant to that commit method

It seems to me that in reality the commit method is a property of the
settlement network and not of a description of the transaction's state
flow over time, which is what IFEX or, it seems, Ripple, is providing.

Layering a fantastic view of the transaction state atop an externally
executed settlement system and calling it atomic or somehow clearer is
to my mind a falsity.

> * EXE's have a commit field that specify the commit method in use, as
> well as other relevant data
>
> * The existing commit method could be called "basic", and nothing else
> needs to be specified -- it works as currently designed

A fair approach, though it may be the case that everyone has to wade
through this additional complexity when implementing or seeking to
understand the protocol.

> * A two-phase commit method could be called "two-phase", and would be
> as follows:
> * The recipient generates a secret commit token as well as its hash.
> * The recipient sends the payer the commit token hash and a location
> the commit token will be published, either directly if possible, or
> via a relayed QUO message.
> * The payer sends forward an EXE with the commit token hash and
> commit token location, which means that the EXE is only valid when the
> commit token is known. (There can also be a deadline for the commit
> token to be known.)
> * When the recipient received an EXE with the commit token hash, it
> publishes the commit token to the location, which should be well-known
> and non-repudiable (timestamped if deadline is used).
> * Participants can (and probably should) wait until they receive
> funds before forwarding funds on, but each one has a claim on its
> predecessor -- an EXE combined with a valid commit token.
>
> That way you don't lose anything the current design of IFEX can do,
> but also gain the ability to add different commit mechanisms such as
> the one I describe.

There is a mistake in your thinking.

Honestly, what does it *provide*?

The constructed view is only a fantasy with no relation to reality.
The 'guarantees' within that fantasy are meaningless.

You can play the blame game, sure, but you can do that with signed
messages under regular IFEX using the cryptographic primitive of
signatures, simultaneously guaranteeing entire message (and therefore
de-facto 'contract') integrity. These messages alone, when signed by
the appropriate party, are real and wholly descriptive claims upon
predecessor nodes. Your abstract token in and of itself is not.

I am sorry but your proposal, compared to that basic approach, just
doesn't seem to offer any additional value, while requiring some
ill-defined public publishing location and additional
latency/complexity.

>>> ... in that
>>> Ripple can model every transaction path that IFEX can.
>>
>> I cannot comment on this part as I haven't yet had time to sit down
>> and attempt to properly understand Ripple.
>
> Oh, please do. I'll be happy to explain parts that don't make sense.

The part where you claim to want to model the external settlement of
arbitrary currencies/commodities over arbitrary settlement networks
outside of your control but then specify a commit algorithm.

> Two very short papers I wrote explaining the fundamental concepts of
> the project:
>
> http://ripple-project.org/decentralizedcurrency.pdf
> http://ripple-project.org/paymentrouting.pdf

Inaccessible.

> Then the latest protocol draft itself:
>
> http://ripple-project.org/Protocol/Protocol06
> http://ripple-project.org/Protocol/ExchangePublishingRoutingMethod
> http://ripple-project.org/Protocol/RegistryCommitMethod
> http://ripple-project.org/Protocol/BareCommitMethod
>
> It's really not much reading -- probably less all told than the IFEX draft.

I don't want to read the commit method stuff because as explained I
consider it illogical. I've seen the others before.

> By "simultaneously", I don't mean so much that every node receives the
> execute message at the exact same moment (delivery = transport layer),
> so much as a guarantee that either all nodes get an execute message or
> none of them do (atomicity = commit mechanism).

It's false, because any meaningful change in transaction state
actually occurs within an external settlement system.

>> [2] Recognise that "proof of payment" is both (A) a lost cause within
>> arbitrary external settlement systems, and (B) not necessarily
>> desirable for all deployments, for example due to overheads or the
>> potential use of IFEX to simply describe rather than execute
>> transactions
>
> Ripple doesn't give proof that the any particular settlement has
> happened, but rather gives a claim on a settlement to those that must
> receive one for the multi-hop transaction to succeed. It's proof that
> all the participating settlement systems have received the execute
> message, and cannot claim that they have not. They can do with it
> what they will, but those owed have proof that they are owed. As
> such, it's proof that something of value (a claim on settlement) has
> been transferred to the final recipient.

It seems that more than this is accomplished (and far more flexibly)
by IFEX's idea of optionally signing (or encrypting and signing)
individual messages within the regular state flow.

For example:
1. You don't have to involve the entire path, and;
2. The whole message - ie. the nominal contract, including future
extensions to the protocol - has its integrity guaranteed along with
any such claim

- Walter

[Ryan Fugger]

OK, it's clear you don't see any value in two-phase atomic commit, and
I see no value in trying to convince you. But I am still interested
in why you don't see any value in it.

On Wed, Aug 15, 2012 at 12:24 PM, Walter <walter....@gmail.com> wrote:
> I posit that your 'guarantee' is a logical fallacy. All that you are
> doing is guaranteeing your own view, not reality.
>
> And what of partially successful transfers, or those with incalculable
> fees that wind up higher than assumed at the time of initiation? Those
> that require additional inputs to complete?
>
> How will they fail with your atomic commit? Sometimes? All the time?
> Atomically? More or less descriptively or flexibly than under IFEX?
>

Systems that can fail in those kind of ways after approving and
freezing funds for the transfer (all required before forwarding the
conditional atomic execute message) probably shouldn't commit
themselves to atomic multihop transfers.

Do there exist such systems? Can you give a specific example? That
would seem like poor design to me, but I'm sure you know more about it
than I do.

>> Two very short papers I wrote explaining the fundamental concepts of
>> the project:
>>
>> http://ripple-project.org/decentralizedcurrency.pdf
>> http://ripple-project.org/paymentrouting.pdf
>
> Inaccessible.
>

Thanks. Fixed.

Ryan

[Walter]

> OK, it's clear you don't see any value in two-phase atomic commit, and
> I see no value in trying to convince you. But I am still interested
> in why you don't see any value in it.

OK

>> I posit that your 'guarantee' is a logical fallacy. All that you are
>> doing is guaranteeing your own view, not reality.

^-- this.

>> And what of partially successful transfers, or those with incalculable
>> fees that wind up higher than assumed at the time of initiation? Those
>> that require additional inputs to complete?
>>
>> How will they fail with your atomic commit? Sometimes? All the time?
>> Atomically? More or less descriptively or flexibly than under IFEX?
>
> Systems that can fail in those kind of ways after approving and
> freezing funds for the transfer (all required before forwarding the
> conditional atomic execute message) probably shouldn't commit
> themselves to atomic multihop transfers.
>
> Do there exist such systems? Can you give a specific example?

A normal bank?

> That would seem like poor design to me,

We're dealing with reality here. Arbitrary systems. Unknown failures.
First-time failures. Clock skew. Earthquakes. Government intervention.
It's not 1s and 0s. Of course, if you are implementing the 999th
distributed commit mechanism under another name, then great. That can
survive earthquakes.

However, if you are implementing something that aims to provide
maximum descriptive power regarding the situation in real life to
levels that are indeterminable at design time on systems that aren't
even designed yet, then you have an issue - a false simplification of
reality that is only able to deal with 1s and 0s. And your algorithms
cannot, therefore, deal with the resulting shades of grey between the
1 and the 0. Lots of things are grey.

> but I'm sure you know more about it than I do.

Hey just because we don't see eye to eye on this please don't
interpret it as me being dismissive, I am very supportive of your
efforts and hope your approach works out.

I just can't see the value in it for IFEX, and think you've missed my point.

- Walter

[Ryan Fugger]

On Wed, Aug 15, 2012 at 9:51 PM, Walter <walter....@gmail.com> wrote:
>> Do there exist such systems? Can you give a specific example?
>
> A normal bank?
>

A normal bank can't atomically freeze an amount in an account? That
doesn't seem right to me. How can it issue a certified cheque then?
Certainly it's possible that some circumstance can arise where the
money backing the certified cheque is gone, but then the bank is on
the hook, no? That's all the 2-phase commit asks for, that the bank
freeze the funds pre-commit, and then release them once the commit is
issued. How can that be too much to ask? Banks do that all the time.

Any other systems that can't freeze funds atomically?

>> That would seem like poor design to me,
>
> We're dealing with reality here. Arbitrary systems. Unknown failures.
> First-time failures. Clock skew. Earthquakes. Government intervention.
> It's not 1s and 0s. Of course, if you are implementing the 999th
> distributed commit mechanism under another name, then great. That can
> survive earthquakes.
>

How does any of that prevent settlement systems from atomically freezing funds?

> However, if you are implementing something that aims to provide
> maximum descriptive power regarding the situation in real life to
> levels that are indeterminable at design time on systems that aren't
> even designed yet, then you have an issue - a false simplification of
> reality that is only able to deal with 1s and 0s. And your algorithms
> cannot, therefore, deal with the resulting shades of grey between the
> 1 and the 0. Lots of things are grey.
>

I don't see how atomically freezing funds is grey. It's the
definition of atomicity, and every financial system is capable of
atomic operations locally.

> I just can't see the value in it for IFEX, and think you've missed my point.
>

As I think you've missed mine, by a mile, but that's OK, IFEX is your
baby and it will be whatever you want. Now I'm trying to cover cases
in Ripple I hadn't considered. Thanks.

Ryan

[Ryan Fugger]

On Wed, Aug 15, 2012 at 9:51 PM, Walter <walter....@gmail.com> wrote:

> Hey just because we don't see eye to eye on this please don't
> interpret it as me being dismissive, I am very supportive of your
> efforts and hope your approach works out.

Thanks for the encouragement! I also hope IFEX works out. I'm sure a
much bigger issue than routing or commit mechanism is getting people
to actually, you know, use the protocol :)

Ryan

[Jorge Timón]

Wow, long discussion. I wasn't able to reply.
I still think that you, Walter, aren't understanding us.

You only see Ripple as a settlement network, I think that's the source
of your misunderstandings. Probably all due to semantics and we using
different definitions.
We Ripple people are so stupid that accept cryptographic IOUs as
payments, but actually they're debts that need to be settled with
later trades. But, please, let's forget that for a moment.
Let's try to make you understand the full potential of Ripple with an
example about how Ripple could do what I understand you want IFEX to
do without Ripple being itself a settlement method in any step of the
payment path:

A wants to pay D.
A will pay with euros and through IBAN.
B will get those euros in exchange of some bitcoins that will send to C
C will get the bitcoins in exchange of some dollars that will give to
D through a bank transfer that is not part of IBAN.

No one here wants Ripple IOUs.
Each user and currency is identified with the public key of a
cryptographic keypair.
You can do this within a Ripple transaction with no central authority
or GPG web of trust. At the end of the transaction B can prove that A
has promised to pay him X eur through IBAN, C can prove that B has
promised to pay him Y btc and D can prove that C has promises to pay
him Z dollars through a bank transfer.
All the debts must be settled outside Ripple.

The transaction (the exchange of signed IOUs) occurs atomically. All
the IOUs are valid or none of them. This is not a fallacy, it's true
in absolute terms.

Is a trust path from D to A necessary? Yes and no.
If there exists a trust path (D trusts C, C trusts B and B trusts A),
everything is fine.
But although Ripple does just one thing (in the unix sense), it can be
extended so you can use legal agreements to boost trust.

Every actor was identified by a keypair, right?
Imagine I'm A. B doesn't trust me but I happen to live in Spain where
we have electronic identification cards with digital signature.
I can use my eDNI to sign my Ripple keypair, with a legal contract
that says something like:

"I will settle any IOU from this Ripple keypair by paying with real euros".
Now, if B doesn't trust me and I don't settle my debt, B can sue me.

A clarification...the unit of account is not included in any Ripple
messages. Each keypair represents not only an actor but also a unit.
If one actor uses several units he needs several keypairs.

More data can be "attached" to a keypair from outside the protocol
just by using the keypair to sign that data. Since Ripple is
extensible, you can put a lot of messages on top of it to be as
descriptive as you want. I want Ripple to be the base of IFEX, not to
be equal to Ripple.

In this example, I'm not treating bitcoin as a special case, to avoid
complicating things and confuse you more but...in the special case of
chain currencies like bitcoin, you can extend the commit mechanism to
allow a chain to act as a registry. That way bitcoiners could, for
example, have their holy-grail "decentralized exchange". For example,
if mtgox issues uds IOUs, you could exchange those mtgoxUSD for real
btc atomically and in a decentralized fashion. Even without that
special commit mechanism, you can trade the same way mtgoxUSD fo
mtgoxBTC, tradehillBTC or whatever.

Why don't you want IFEX to have more capabilities? Why don't you want
IFEX to be more useful?

Feel free to ask any question about my example or anything I've said.
Feel free to make the example more complex so that I can "try" to
model it through Ripple. I'm very confident any financial example that
you present can modeled with the Ripple concept. Maybe not with the
protocol as it is, so such an example could be useful for us.

[Walter]

> Let's try to make you understand the full potential of Ripple with an
> example about how Ripple could do what I understand you want IFEX to
> do without Ripple being itself a settlement method in any step of the
> payment path:
>
> A wants to pay D.
> A will pay with euros and through IBAN.
> B will get those euros in exchange of some bitcoins that will send to C
> C will get the bitcoins in exchange of some dollars that will give to
> D through a bank transfer that is not part of IBAN.
>
> No one here wants Ripple IOUs.
> Each user and currency is identified with the public key of a
> cryptographic keypair.
> You can do this within a Ripple transaction with no central authority
> or GPG web of trust. At the end of the transaction B can prove that A
> has promised to pay him X eur through IBAN, C can prove that B has
> promised to pay him Y btc and D can prove that C has promises to pay
> him Z dollars through a bank transfer.
> All the debts must be settled outside Ripple.

Nothing here seems different to IFEX (if one chose to share the
specifics or generalities of certain hops of a transaction with nodes
involved in others) or any other system that would employ the
cryptographic primitive of signatures within its message passing for
the purpose of non-repudiation.

> The transaction (the exchange of signed IOUs) occurs atomically.

Again, I don't know what the preoccupation is with 'atomically', since
you're attempting to use arbitrary external settlement networks which
will each have their own range of potential states - not all of which
are 'atomic'. Even some of which might have funds arrive, but not
100% guaranteed (eg. Bitcoin blockchain, credit card or Paypal based
payments vulnerable to reversals, etc.) Leaving that rather
significant and fundamental issue aside for just one second, let's
look at some other possible states.

What happens when the bank goes bust, funds are seized or delayed
indefinitely, banks go on holiday, an exchange rate shifts markedly
during the course of the transaction, the Bitcoin network ceases to
function, bank fees increase suddenly and 80% of the value of the
original transaction is wiped out, an addressing error occurs and a
mid-party can't resolve who will pay for a re-attempted delivery,
nobody agreed in the first place who was paying some certain fee, a
new tax is introduced that nobody is aware of, etc.?

> All
> the IOUs are valid or none of them. This is not a fallacy, it's true
> in absolute terms.

Oh, perhaps I see something you meant earlier but had not realised
here - you're linking the various hops in to a single entity.

Fair play - that's an interesting take, and this may be what you meant
by 'atomic' that I had been missing.

Unfortunately, I am certain that approach is not always going to be a
desirable architecture. (More on this below.)

> Is a trust path from D to A necessary? Yes and no.
> If there exists a trust path (D trusts C, C trusts B and B trusts A),
> everything is fine.
> But although Ripple does just one thing (in the unix sense), it can be
> extended so you can use legal agreements to boost trust.

Ripple does more than one thing. By way of explanation, let me expand
on previous points. So far I have touched upon two apparent design
assumptions within Ripple that I claim aren't always valid given a
scope of 'arbitrary third party settlement networks'.

1. State of a transaction through arbitrary third party settlement
networks is not "complete or incomplete", but rather far more complex
(see many example scenarios above), with many possible paths to
resolution (manual or automated, we should aim for the latter but
support fallback to the former)
(SOLUTION: Reduce scope! Do one thing. Do describe the
transaction. Don't attempt to declare it in state X or Y to all
parties. Instead, allow them to make their own state transitions
independently with the information they have available, and share
claims regarding those state change with related nodes as they see fit
or previously agreed. Note that this appears to be a key difference
between the Ripple proposal - at least as I understand it - and IFEX.
IFEX is more minimal. It does one thing, and distributed commit
algorithms are *not* included.)

2. The constant want to link multiple hops together in to some
transaction-level shared-state meta-entity (which might easily be
undesirable for reasons of latency, privacy/anonymity, etc.)
(SOLUTION: Reduce scope! Don't mandate multi-party behaviours.
Provide identifiers to facilitate cross-node transaction
identification and thus allow people to build up optional explicit
behaviors from there ... sure. But don't mandate synchronous shared
views of a transaction. That's only one way to build a distributed
system, it's expensive in resource terms, it's a poor reflection of
reality in many cases, and it's often not required or desirable for
various reasons - latency, privacy/anonymity, etc.)

> More data can be "attached" to a keypair from outside the protocol
> just by using the keypair to sign that data. Since Ripple is
> extensible, you can put a lot of messages on top of it to be as
> descriptive as you want. I want Ripple to be the base of IFEX, not to
> be equal to Ripple.

Scope differs. This is illustrated by the two points above detailing
some assumptions within Ripple.

> In this example, I'm not treating bitcoin as a special case, to avoid
> complicating things and confuse you more but...in the special case of
> chain currencies like bitcoin, you can extend the commit mechanism to
> allow a chain to act as a registry. That way bitcoiners could, for
> example, have their holy-grail "decentralized exchange".

You claim this but in fact it is not so simple. You have to deal with
the fact that in such networks there is not one version of the truth
but in fact many perspectives current at any given time (See #8 @
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing).
From time to time, perspectives can even "roll back". To resolve this
necessary property of the network, each node is empowered to act upon
its own version of the truth and based upon its own assessment of
risk. This is what Bitcoin people are talking about when they talk
about '<x> blocks of confirmation', it roughly means "degrees of
certainty". Nobody actually waits for complete certainty, which IIRC
usually takes a really, really, really long time (like days?) relative
to expectations of reasonable financial settlement speed. Instead,
they pick a certainty they're happy with and then consider it settled.
This is an area of grey, just the sort of area I believe any
artificial 'atomic commit' notion in any external protocol (be it
Ripple or IFEX) fundamentally masks.

This is the logical fallacy I am trying to show you.

We simply can't naively apply notions of atomic transactions when
describing many arbitrary third party settlement networks, currencies
and commodities due to the differing properties of those systems.
Sure, we *can* do it ... but what we wind up is a simplified, delayed,
or in any case less immediate, less descriptive and therefore
relatively disempowered version of that arbitrary third party system's
reality.

Instead, I see the alternative of increased descriptiveness (eg. IFEX
adds but does not mandate additional generalised transaction states,
with optional extension) and a justified aversion to bringing any
commit-related algorithms within scope (assuming arbitrary settlement
systems as a design requirement, since, for the reasons outlined
above, they are poorly matched to many common settlement system
contexts).

> Why don't you want IFEX to have more capabilities? Why don't you want
> IFEX to be more useful?

"Do one thing and do it well."

I have explained why the atomicity idea as I understand it does not
provide any real benefit when scope is arbitrary settlement networks,
including specific examples such as those that you have provided.

IFEX's approach is simple - just (optionally!) sign messages. (Also,
this is great for extensibility as any additional information with
which the message was extended will be signed too.)

By contrast, Ripple apparently attempts to create some parallel system
of commit tokens (to the fundamental extensible messages), which to me
seems, once you acknowledge that commit algorithms are inappropriate
for a general financial protocol (for the above reasons), unnecessary
complexity that does not provide measurable value or - worse -
encourages naive and incorrect assumptions about the safe conclusion
of transactions that may later be reversed (eg. through bitcoin
blockchain rollback, card or settlement provider initiated transaction
reversal, etc.).

> Feel free to ask any question about my example or anything I've said.
> Feel free to make the example more complex so that I can "try" to
> model it through Ripple. I'm very confident any financial example that
> you present can modeled with the Ripple concept. Maybe not with the
> protocol as it is, so such an example could be useful for us.

I have done this earlier back in this rather long-running thread, I think.

Perhaps in this message you might see some further examples of
behavior apparently ill-matched to Ripple's commit notion - as I
understand it - to think through further.

With the sincere hope that you can understand my points above and in a
spirit of cooperation,
Walter

[Ryan Fugger]

I appreciate what you're saying Walter, and I understand that just
because a Ripple transaction goes through atomically, it doesn't mean
that the underlying systems magically lose all their inherent
restrictions and gain some new capabilities just because they now hold
a Ripple commit token. Please understand that I never thought
otherwise.

Now please read carefully, because I am going to try again to explain
all that Ripple requires of a system to participate in atomic
transactions:

* It can freeze funds for a transaction, and guarantee that those
funds are available for that transaction if it commits within a
certain time frame

That's it.

I'm interested if you know of settlement systems that can't meet that
criterion. Banks can clearly meet it, because they participate in
point-of-sale debit transactions, which must guarantee funds in the
same way. (You can't say to the merchant the next day, sorry, that
transaction had to be reversed because it actually couldn't complete,
even though we said it was approved, sorry.)

Debit networks are actually a good analogue to what Ripple is trying
to accomplish. The ultimate transfer is guaranteed immediately, and
then whatever settlement mechanisms are necessary (if any) grind it
out afterwards behind the scenes. The difference is, where debit
networks rely on a closed system and global trust between participants
enforced by global authorities, Ripple is an open system that relies
on local trust/agreements between connected participants and two-phase
commit for value transfer without needing global trust or authorities.

Now, I would understand if some settlement systems would need to make
special arrangements to guarantee funds are available for Ripple
transactions in all circumstances, such as providing a contingency
fund to cover failed settlements. My understanding is that such
systems would already have such contingencies in place. But if not,
then perhaps they would see participating in Ripple transactions as
too risky, or the risk-mitigation required as too expensive. This is
obviously a subjective area, and I don't have the experience with
actual settlement systems to know the answer. If you can give
specific examples that would help me understand the issues here
better, I would appreciate it.

What I would expect generally though, is that Ripple counterparties
would make their own private agreements as to the meaning of an
unsettled Ripple obligation under extraordinary circumstances, like
bankruptcy of one of the parties. Obviously the assumption is that
the vast majority of transactions can be settled predictably.

Now maybe the difference between Ripple and IFEX is that IFEX would
never permit unsettled obligations to exist. But, as I understand it,
IFEX permits the case where one system in a multihop transaction rolls
back its transfer, leaving an implicit unsettled obligation, as funds
may have already been delivered further down the chain. And Ripple
can give the exact same degree of assurance that unsettled obligations
will not exist, if participating systems use the following integration
mechanism:

* Settle funds *before* agreeing to the Ripple transaction (ie,
accepting promises and passing them on), and then roll back the
settlement if the commit token does not appear.

This heuristic makes the Ripple transaction operate identically to the
IFEX transaction, except that Ripple still doesn't require global
trust between participants, because of the way all the settlements in
the chain are linked together by the single commit token.

In a sense, the commit token establishes sufficient trust between the
necessary participants *at transaction time*, rather than requiring a
more global notion of trust that is less integrated with the
transaction semantics. The trust between Ripple participants is
established by their agreement about which authority will be
responsible for certifying the existence or non-existence of the
commit token by the deadline.

In that light, I think my design for two-phase commit could fall
within your notion of a cryptographic proof-of-transfer from the
recipient, and as we've already established, could be integrated
within the existing extensible IFEX framework. I'm sure other such
designs are possible, and since both frameworks are extensible, both
could accommodate such designs.

I suppose then, the real difference between IFEX and Ripple is a
matter of taste about what a more elegant approach to where the
boundaries lie between different components of a multihop transaction
system. And the root of that might be that IFEX's goal is
primarily to allow fresh approaches to settlement to integrate with
existing financial systems, and Ripple's is primarily to allow fresh
approaches to settlement to integrate with *each other*, assuming
existing systems will only integrate when forced to by the market. As
such, Ripple can afford to be more unconventional in its approach, as
well as more opinionated about the kinds of trust-brokering protocol
extensions that participants ought to implement. But I'm content that
functionally they are (or can be made to be, by extending the existing
designs) fairly equivalent.

It might be interesting to talk more about the degree to which
existing financial systems are actually interested in implementing
multihop settlement protocols that facilitate integration of
potentially disruptive new entrants, but that could be a new thread...

Ryan

PS: If you're like me, and begin rebutting point-by-point before
you've read the whole email, I'd appreciate if you'd go back and omit
argumentative sections that don't really address the central thrust of
our discussion. That's what I've been trying to do on the last few
emails, and I don't think we've really lost anything for not sorting
out a few minor technicalities that are in all likelihood meaningless
once we come to a better understanding generally.

[Walter]

Respectfully, perhaps you believe you do, but from your writing it
seems otherwise.

> and I understand that just
> because a Ripple transaction goes through atomically, it doesn't mean
> that the underlying systems magically lose all their inherent
> restrictions and gain some new capabilities just because they now hold
> a Ripple commit token. Please understand that I never thought
> otherwise.

What's the point of them then? Define, concretely and succinctly, what
they provide.

To me it seems that you have been claiming that they provide a view to
all nodes that the transaction has succeeded or failed.

Leaving aside the question of "what for?" - most natural exchange both
within the conventional world and emerging networks seems to occur
more organically without explicitly declaring intent to all
participants within a multi-hop flow ahead of time - I'll tell you why
that makes no sense to me.

It makes no sense because they are a simplification of external
systems - often invalid - that encourage incorrect thinking regarding
financial realities. They engender a naive risk model, reduced
responsiveness to complex transactions' intra-settlement developments,
and a forced architecture that is demonstrably expensive and
unsuitable to many situations.

If you can't see this, given the number of examples I've raised
already, I really don't know how to explain it any better without
getting in to drawing pictures. Perhaps another email ... but I don't
have time for that now.

> Now please read carefully, because I am going to try again to explain
> all that Ripple requires of a system to participate in atomic
> transactions:
>
> * It can freeze funds for a transaction, and guarantee that those
> funds are available for that transaction if it commits within a
> certain time frame

OK, Ripple's scope as you describe it has apparently further expanded.
When you say "freeze funds for a transaction" - this is basically
local resource management. From my perspective it's incorrect to
argue that's really being provided by a protocol (either IFEX or
Ripple). Regardless of what kind of transaction system is in use, a
node has to do that anyway. In reality, the freezing of funds is
handing them to someone, whether it's your internal "frozen for
imminent third-party transfer" department accountant, or a third
party.

It seems to me that the risk model for local resource liquidity is
perhaps not something that a protocol should get in to. I can
understand the need if one is writing a settlement system (ie. prevent
double-spending), but that is not what IFEX seeks to be. If that's
what Ripple seeks to be, then so be it.

> That's it.
>
> I'm interested if you know of settlement systems that can't meet that
> criterion. Banks can clearly meet it, because they participate in
> point-of-sale debit transactions, which must guarantee funds in the
> same way.

Many people think so, because it does sound like common sense, but in
fact, like many things in economics when viewed through the lens of
popular perception, that is actually the naive perspective and
demonstrably wrong.

(Before going further it's worth noting that putting 'banks' in one
lump and combining them with point of sale networks is a mistake.
There is much variation within either one of those categories, the use
of 'debit' is also a loaded qualifier that "does not always do what it
says on the tin". This must be pointed out because you re-use the term
similarly naively later.)

> (You can't say to the merchant the next day, sorry, that
> transaction had to be reversed because it actually couldn't complete,
> even though we said it was approved, sorry.)

Sorry but it is very clear from your words that you don't have much
experience with this sort of thing.

It happens many thousands of times per day, every day.

It happens on Paypal, it happens on Mastercard/Visa card networks, it
happens on Bitcoin, and it certainly happens on other networks.

> Debit networks are actually a good analogue to what Ripple is trying
> to accomplish.

It's very much unclear here what you mean by 'debit networks'.

> The ultimate transfer is guaranteed immediately, and
> then whatever settlement mechanisms are necessary (if any) grind it
> out afterwards behind the scenes. The difference is, where debit
> networks rely on a closed system and global trust between participants
> enforced by global authorities, Ripple is an open system that relies
> on local trust/agreements between connected participants and two-phase
> commit for value transfer without needing global trust or authorities.

This is far too inspecific to comment on, but basically this suggests
that Ripple is trying to be a settlement network rather than describe
external settlement networks (ala IFEX).

> Now, I would understand if some settlement systems would need to make
> special arrangements to guarantee funds are available for Ripple
> transactions in all circumstances, such as providing a contingency
> fund to cover failed settlements. My understanding is that such
> systems would already have such contingencies in place. But if not,
> then perhaps they would see participating in Ripple transactions as
> too risky, or the risk-mitigation required as too expensive. This is
> obviously a subjective area, and I don't have the experience with
> actual settlement systems to know the answer. If you can give
> specific examples that would help me understand the issues here
> better, I would appreciate it.

Again asking for examples of my concerns, you have them. They are
concrete. You have not responded to them. (I believe you dismissed
them as baseless argumentative verbiage, but they were not.)

> What I would expect generally though, is that Ripple counterparties
> would make their own private agreements as to the meaning of an
> unsettled Ripple obligation under extraordinary circumstances, like
> bankruptcy of one of the parties. Obviously the assumption is that
> the vast majority of transactions can be settled predictably.

The following combination in Ripple as described on this thread does
not sit well for me.
- unspoken "obvious" "assumptions" that affect all parties to a
multi-hop transaction in ill-defined ways ... with no clear means for
resolution.
- claims of "Atomicity"
- claimed of planned scope including being able to wrap or describe
arbitrary settlements on arbitrary networks in arbitrary
currencies/commodities with arbitrary properties

> Now maybe the difference between Ripple and IFEX is that IFEX would
> never permit unsettled obligations to exist.

I repeat again, IFEX's view is that it (and, if the arbitrary
settlement system thing is in scope, then also I believe Ripple)
cannot control the state of external obligations. Sure, it can
declare "that should not be!", but in fact it cannot prevent this from
occurring. Attempting to do so would be imperfectly representing the
reality outside of the system, which is a recipe for costly
miscalculations and reduced efficacy in accounting related processes.

> But, as I understand it,
> IFEX permits the case where one system in a multihop transaction rolls
> back its transfer, leaving an implicit unsettled obligation, as funds
> may have already been delivered further down the chain.

One can't prevent this if one wants to describe transactions occurring
over popular settlement networks. All that one can do is model it
accurately and then make various node-local decisions based upon a
more informed risk model. This is IFEX's approach.

> And Ripple
> can give the exact same degree of assurance that unsettled obligations
> will not exist, if participating systems use the following integration
> mechanism:
>
> * Settle funds *before* agreeing to the Ripple transaction (ie,
> accepting promises and passing them on), and then roll back the
> settlement if the commit token does not appear.

Oh, sure. We all want perfect knowledge that things have gone without
a hitch. But how does it happen?

It seems to me that you're now defining a magical parallel reality
where the internet settlement ponies have mystically shared the pot of
gold at the end of the rainbow "before" the transaction occurs
(without breaking down in to bitter factionalised pony-warfare in
which vast numbers of innocent bystanders and their transactions are
trampled without remorse.)

In short, that's a cop-out because it's just pushing all the juicy
problems and details out of scope to the pre-trasactional pony
pasture. It doesn't actually address them.

> This heuristic makes the Ripple transaction operate identically to the
> IFEX transaction, except that Ripple still doesn't require global
> trust between participants, because of the way all the settlements in
> the chain are linked together by the single commit token.

Hrrm... "and one token to bind them! ... the pony-token!"

*cue ambient feel-good music; slow pan across New Zealand landscape,
with bushwalking 180 kilo German Megahobbit in foreground, Joe Bidden
and the MPAA SWAT team approaching in helicopter in midground,
spectacular middle-earth mountains in background*

Voiceover: "It is said that when engaging in a multi-hop settlement
over arbitrary networks, he who possesses the pony-token has knowledge
that all of his single hop component settlements have already gone off
without a hitch, and that all of his relations in trust, business and
communications with intermediate ponies have also gone off without a
hitch. The common people fear him, the great ponies come to pay
homage, and he rules over the greatest of the exchanges. For his
reputation is known far and away throughout all of Middle Earth and
the outer realms, and in every part of all of the lands, no child of a
hundred moons has gone without hearing his name. They call him...
*extended drumroll* ... SETT-LOR!"

*fade to reality*

"Err, man ... so like... what happens if a pony gets shot?"

> In a sense, the commit token establishes sufficient trust between the
> necessary participants *at transaction time*,

Sorry, but again, it seems to me that's a logical fallacy.

The commit token pushes the problem of doing this back to things that
happen "before the transaction". Functionally, at least in terms of
99% of potential issues, it basically represents the *end* of the
transaction.

> In that light, I think my design for two-phase commit could fall
> within your notion of a cryptographic proof-of-transfer from the
> recipient, and as we've already established, could be integrated
> within the existing extensible IFEX framework. I'm sure other such
> designs are possible, and since both frameworks are extensible, both
> could accommodate such designs.

Err, let's get this straight. Neither of us are cryptographers.

Let's not try to design new cryptographic systems, but rather
implement well known cryptographic primitives.

The primitive in question is the signature.

"I, <x*>, attest that, <y>".
(Realistically we often attempt to extend this to)
..." under penalty of <z**>"

* Where <x> is potentially a throwaway identity.
** Where <z> is often a fairly weak threat to the effect that "I'm
not playing with you anymore".

You see, we haven't designed anything at all, we're just
re-implementing the 99999th instantiation of 'Applied Cryptography',
albeit the 'Pony playground (sponsored by KimDotCom) limited edition'.

> I suppose then, the real difference between IFEX and Ripple is a
> matter of taste about what a more elegant approach to where the
> boundaries lie between different components of a multihop transaction
> system.

But, think of the ponies!

> And the root of that might be that IFEX's goal is
> primarily to allow fresh approaches to settlement to integrate with
> existing financial systems,

I would write 'arbitrary', rather than 'existing'. (Though it is
certain that any financial system that cannot integrate with existing
systems stands very little chance of widespread deployment.)

> and Ripple's is primarily to allow fresh
> approaches to settlement to integrate with *each other*, assuming
> existing systems will only integrate when forced to by the market.

Forgive me for being frank: that sounds a little like a really poorly
defined scope.

> As
> such, Ripple can afford to be more unconventional in its approach, as
> well as more opinionated about the kinds of trust-brokering protocol
> extensions that participants ought to implement. But I'm content that
> functionally they are (or can be made to be, by extending the existing
> designs) fairly equivalent.

I'm glad that you're content, but ask yourself this - is there value
in describing the areas where equivalence is not absolute between
arbitrary trust relationships? Does a lack of equivalence potentially
represent a vulnerability within the distributed trust model, of which
no particular node has complete knowledge? How do the settlement
ponies preceding the pony-token in Ripple actually handle this issue
.. or is there complete trust between all ponies in the
pre-transaction pony pasture?

Perhaps, as it seems you have simultaneously claimed that the pony
token is issued before the transaction, and that the pony token is
issued after the transaction's real-world money transfer is complete
(ie. for all intents and purposes, "the transaction"), that perhaps it
follows that time does not exist in the pre-transaction pony pasture.
And as we know, when time does not apply, then trust is a non-issue,
right?

Honestly, I'm having problems following your logic.

> It might be interesting to talk more about the degree to which
> existing financial systems are actually interested in implementing
> multihop settlement protocols that facilitate integration of
> potentially disruptive new entrants, but that could be a new thread...

Perhaps, but in short they can't prevent it.

> PS: If you're like me, and begin rebutting point-by-point before
> you've read the whole email, I'd appreciate if you'd go back and omit
> argumentative sections that don't really address the central thrust of
> our discussion. That's what I've been trying to do on the last few
> emails, and I don't think we've really lost anything for not sorting
> out a few minor technicalities that are in all likelihood meaningless
> once we come to a better understanding generally.

I do usually re-read, but believe the contrary - what you apparently
see as argumentative bits included concrete examples of problems that
you fail to address.

You're still missing my point, and I am at a loss as to how to explain
it more clearly than the numerous examples already rendered*.

- Walter

* Now with added ponies.

[Apostolis Xekoukoulotakis]

This discussion is certain to fail because there are no concrete examples. As I said before, in order to find how to  design a protocol, you must have experience with some implementations. Ryan just ignored my question all together.

Let me say before hand that I cant follow any of you. 99% of what you say doesnt make sense to me.

The general idea, i think is this:

Walter says that there can be no guarantees on atomicity or anything in general.

Ryan believes that ripples model provides atomicity.

We need to check how both ideas apply to the current ripple decentralized model that is based on a single registry that is used as a time authority. or a ripple system that is based on the byzantium paxos algorithm.

On the first case, failure of the registry server(hacking/malevolence/error) leads to the colapse of the ripple network.(noone wants to aknowledge new transactions).

Someone might also pretend to believe that the server failed so as not to pay the transactions.

On the second case, paxos guarantees atomicity. The only way to break this system is to find  a cryptographic weakness(ex.quantom computer) or a weakness in the algorithm.

Even in this case someone might find excuses and not pay back what he owes.

In the existence of such a failure(last case), ripple has been designed to fail locally to ones friend. In other words, ripple has been designed from the start with the possibility of failure. That is why I call ripple an insurance system that is based on trust. Ones friends guarantee ones transactions and will pay the price when their friend is an ash%le.

So the protocol in case of failure is not inside the computer but outside between people(giving a call/ talking).

So that leaves us with describing a failure state when the cryptography fails(for the paxos system).

What is the best way to handle such a failure in a protocol?

How did the financial institutions/e-commerce handled the failure of ssl? Did they revoke any transactions?

2012/8/18 Walter <walter....@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.

[Walter]

> This discussion is certain to fail because there are no concrete examples.

Concrete examples:
1 - A transaction considered 'settled' is rolled back (eg. bitcoin
blockchain rollback, Paypal transaction reversal, credit card
transaction reversal).
2 - Exchange rate and fee fluctuations after the terms of a
transaction have been agreed (for example when utilising
floating/free-market currency or commodity exchanges within a
multi-hop transaction).
3 - Participants do not wish to publish their own trust relationships
to the network (eg. currency/commodity exchange providers who do not
wish to reveal the source of their liquidity to competitors).
4 - Participants do not wish to advertise the endpoints of their
multi-hop transaction to all middle-parties (eg. personal bank account
information, including name, address, email, transaction description,
etc.)
5 - Large quotations that exceed liquid funds for any intermediate
node (eg. single, large transactions such as buying a car), or many
simultaneous quotations to the same effect.

How does the Ripple proposal deal with these scenarios? My
understanding is as follows:
1 - A ripple node is out-of-pocket yet all nodes within the network
view the transaction as successful and complete.
2 - Ripple would only include these transactions as a fixed rate of
exchange. Ripple nodes providing exchange services on
floating/free-market currencies/commodities would therefore be forced
to include over-compensating risk-margins within all quotations. This
has the net effect of discouraging the use of Ripple for such exchange
by introducing inefficiencies.
3 - Ripple shares too much information for these participants, making
it unattractive.
4 - As per 3.
5 - Ripple requires both that a maximum transaction size between
nodes is defined, and that nodes 'freeze' funds when issuing
quotations. These two issues both have the effect of reducing
liquidity and capacity within the Ripple network, as well as
potentially exposing it to Denial of Service (DoS) attacks through
resource exhaustion.

IFEX resolution:
1 - IFEX can describe this kind of failure, and can describe
arbitrary strategies for how to recover from them. Recovery strategies
are a matter for the two nodes in question (yet complete and
non-repudiatable evidence of transaction discourse can be provided to
a wider community as part of trust/reliability perspective-evolution
where appropriate).
2 - Potential to describe either no, explicit *or* acceptable ranges
of exchange rates or fees as part of the quotation process. Recovery
strategies will normally also be defined (eg. 'immediate refund it if
no longer executable within this rate range')
3 - There is no requirement for a complete record of the multi-hop
transaction at every node (nor for the complete set of
trust/settlement peers of each node to be visible to the greater
network).
4 - As per 3.
5 - IFEX does not require (but can support) 'freezing' of funds
(liquid capital) for a quotation request at intermediate nodes within
a multi-hop settlement. However, in most cases funds will be provided
by the originator, removing this issue. Also, IFEX does not impose a
maximum transaction size limit between hops.

Following on from the above, some of my concerns with Ripple are:
- Whilst atomicity might be claimed regarding the Ripple-network's
view of a transaction (paxos, two-phase-commit, etc.), these describe
the computational transaction as viewed by the Ripple network and not
the real world financial transaction itself. In common real-world
financial settlement-processes (see example 1 above) failures will
occur that Ripple seems unable to describe and recover from.
- Ripple's network-wide view of transactions causes numerous issues
such as undue overhead, latency, problems of failure recovery, denial
of service/resource exhaustion and undue information sharing.
- Ripple's description of pre-transaction quoting processes and the
transaction process is not broad enough to elegantly integrate with a
range of real-world processes such as free-market/floating rate
currency/commodity exchange.
- Ripple disempowers individual nodes from providing backup routes
and/or transaction failure recovery strategies that may be desirable
or required by a given node's individual and transaction-level
context.
- Ripple's trust model is network enforced, inflexible, and poorly
models many real-world scenarios.

I doubt that I will be able to put any more time in to this discussion
for awhile, so I hope that the above is useful for you and provides
some clarity. I do however look forward to reading, in due course, a
response to the concerns raised.

- Walter

[Apostolis Xekoukoulotakis]

Ok, whenever you have time look at it.

First of all, we should stop assuming that ripple and IFEX were made for the same purpose. By understanding each sides limits, we ll stop fighting unnecessarily on things that are out of scope for one or the other.

Ripple main features are:

1) the creation of credit out of nowhere. In other words, funds are not tranfered. Inside ripple, they are just credits.

2)each transaction is considered by each person to be a transaction between his friends.

Even if someone bought something from a person far away, the local(friend) peer is liable for the failure of payment.

3) provides atomicity in the transaction without caring whether the transaction happened in real or not.

Responsible for the failure would be the people/institutions that trusted each other. 

The most important reason why ripple people insists on atomicity is because things are more difficult in ripple than in the financial industry.

Ripple has to deal with dynamically changing paths. It has to deal with very small credit limits. If atomicity is not guaranteed, most transactions will be in an irreversible state and the failure rate will be huge.

That is the most important thing for you to understand. IFEX doesnt solve the same problem, ripple cant afford not to have atomicity. Maybe that will increase latency but that is ok for ripple.

So here is an interesting question. What would be the failure rate on the p2p graph that ripple works under normal transaction activities without having atomicity. That is what I call concrete. If you can provide me with numbers that show that the failure rate is small and that with your mechanism we have reduced latency at the same failure rate, then that would be proof enough to drop atomicity as a requirement.

I cant provide evidence either. I only make the assumption that ripple deals with different things than IFEX.

Apart from that, ripple could describe a failure mechanism. Ripple should describe a refund mechanism. Most of what you say are valid and they could be done.

2012/8/18 Walter <walter....@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.

[Ryan Fugger]

On Fri, Aug 17, 2012 at 8:30 PM, Walter <walter....@gmail.com> wrote:
> Concrete examples:
> 1 - A transaction considered 'settled' is rolled back (eg. bitcoin
> blockchain rollback, Paypal transaction reversal, credit card
> transaction reversal).
>

> 1 - A ripple node is out-of-pocket yet all nodes within the network
> view the transaction as successful and complete.

The Ripple obligation is still outstanding, and would be settled by
whatever means the counterparties have agreed to or can agree upon.
As I explained earlier, Ripple can avoid this situation to the same
degree as IFEX by settling the underlying funds transfer *before*
issuing the Ripple obligation, and then rolling the underlying funds
transfer back if the Ripple commit does not happen. The drawback is
slower transactions.

> 2 - Exchange rate and fee fluctuations after the terms of a
> transaction have been agreed (for example when utilising
> floating/free-market currency or commodity exchanges within a
> multi-hop transaction).
>

> 2 - Ripple would only include these transactions as a fixed rate of
> exchange. Ripple nodes providing exchange services on
> floating/free-market currencies/commodities would therefore be forced
> to include over-compensating risk-margins within all quotations. This
> has the net effect of discouraging the use of Ripple for such exchange
> by introducing inefficiencies.

Your solution is correct: safety margins. Also short transaction
windows. These could make currency/commodity exchanges less
attractive choices for use in Ripple paths.

> 3 - Participants do not wish to publish their own trust relationships
> to the network (eg. currency/commodity exchange providers who do not
> wish to reveal the source of their liquidity to competitors).
>

> 3 - Ripple shares too much information for these participants, making
> it unattractive.

These participants would have to use a different routing method than
exchange-publishing. For example, it would be simple to extend Ripple
to include IFEX's RFQ/QUO mechanism, and use that for finding paths.

> 4 - Participants do not wish to advertise the endpoints of their
> multi-hop transaction to all middle-parties (eg. personal bank account
> information, including name, address, email, transaction description,
> etc.)
>

> 4 - As per 3.

Middle parties in Ripple never know the endpoints of the transactions.

> 5 - Large quotations that exceed liquid funds for any intermediate
> node (eg. single, large transactions such as buying a car), or many
> simultaneous quotations to the same effect.
>

> 5 - Ripple requires both that a maximum transaction size between
> nodes is defined, and that nodes 'freeze' funds when issuing
> quotations. These two issues both have the effect of reducing
> liquidity and capacity within the Ripple network, as well as
> potentially exposing it to Denial of Service (DoS) attacks through
> resource exhaustion.

If there is insufficient credit available through the network, then
you can't do a Ripple transaction. This is the same as not receiving
QUO's for a high enough amount in IFEX.

Nodes do not freeze funds when issuing quotations. They freeze funds
in the following phase, which is the promise phase, or commit-ready
phase in traditional two-phase commit-speak.

DoS attacks based on freezing credit are a real concern in two-phase
commit mode. This would be addressed by implementations rate-limiting
neighbours that too often freeze credit and hold it for the maximum
amount before letting it expire, and eventually severing relations if
that behaviour continues.

Ripple does also have a one-phase commit mode (called "null" commit
method) which functions similarly to IFEX, without credit DoS
concerns.

>
> IFEX resolution:

> 2 - Potential to describe either no, explicit *or* acceptable ranges
> of exchange rates or fees as part of the quotation process. Recovery
> strategies will normally also be defined (eg. 'immediate refund it if
> no longer executable within this rate range')

This flexibility in quotations will be useful for Ripple to implement
eventually. An earlier draft had this functionality, but I've left it
out of the latest draft in order to make it easier to implement a
first version.

> Following on from the above, some of my concerns with Ripple are:
> - Whilst atomicity might be claimed regarding the Ripple-network's
> view of a transaction (paxos, two-phase-commit, etc.), these describe
> the computational transaction as viewed by the Ripple network and not
> the real world financial transaction itself. In common real-world
> financial settlement-processes (see example 1 above) failures will
> occur that Ripple seems unable to describe and recover from.

True. Ripple does not prescribe how obligations incurred during
Ripple transactions are to be ultimately settled, it simply creates
the obligations. Ultimate settlement can be done after the Ripple
obligation is created, before the obligation is created (and rolled
back if it is never created), or just ignored completely and given its
own meaning as an outstanding Ripple obligation going forward, to be
cleared by future Ripple transactions.

> 1 - IFEX can describe this kind of failure, and can describe
> arbitrary strategies for how to recover from them. Recovery strategies
> are a matter for the two nodes in question (yet complete and
> non-repudiatable evidence of transaction discourse can be provided to
> a wider community as part of trust/reliability perspective-evolution
> where appropriate).

Since, as in IFEX, recovery strategies are a matter for the two nodes
in question, Ripple's core protocol leaves their description out of
scope. Protocol extensions may describe recovery strategies
explicitly, as in IFEX.

> I doubt that I will be able to put any more time in to this discussion
> for awhile, so I hope that the above is useful for you and provides
> some clarity. I do however look forward to reading, in due course, a
> response to the concerns raised.
>

Yes, thank you. It definitely clarifies some present weaknesses in
Ripple, and points to some future directions.

Ryan

> - Walter

[Jorge Timón]

> > and I understand that just
> > because a Ripple transaction goes through atomically, it doesn't mean
> > that the underlying systems magically lose all their inherent
> > restrictions and gain some new capabilities just because they now hold
> > a Ripple commit token. Please understand that I never thought
> > otherwise.
>
> What's the point of them then? Define, concretely and succinctly, what
> they provide.

Although the ripple transaction has been executed atomically and
successfully, only IOUs have been traded. The agents that directly
accept the ripple IOUs as settlements are done but the rest of
sub-transactions aren't settled yet, they would be (from IFEX
perspective) in the Live Phase, Pending State (PENDING).
But during the transaction, different exchange rates may have been
negotiated. In my example we go from euros to usd through bitcoin. The
importance of the atomicity is clear here.
More generally, B doesn't want to give his signed IOUs to C without
receiving the signed IOUs from A. This atomicity is not the panacea
and doesn't involve settlements, but it is very think is very valuable
and is certainly critical for Ripple.
This atomicity is all I want you to include in IFEX, what a pity that
you don't see any value in it. I don't think any financial protocol
can be "the protocol of the future" without this.
I don't see many people willing to make an atomic trade crossing 5
different currencies today, but the number of complementary currencies
grows exponentially and they need to be inter-operable.

> 1. State of a transaction through arbitrary third party settlement
> networks is not "complete or incomplete", but rather far more complex
> (see many example scenarios above), with many possible paths to
> resolution (manual or automated, we should aim for the latter but
> support fallback to the former)
> (SOLUTION: Reduce scope! Do one thing. Do describe the
> transaction. Don't attempt to declare it in state X or Y to all
> parties. Instead, allow them to make their own state transitions
> independently with the information they have available, and share
> claims regarding those state change with related nodes as they see fit
> or previously agreed. Note that this appears to be a key difference
> between the Ripple proposal - at least as I understand it - and IFEX.
> IFEX is more minimal. It does one thing, and distributed commit
> algorithms are *not* included.)

Trades are atomic but settlements are out of the scope in Ripple,
problem solved.
I think it has value to describe states for different settlements and
I thought that was the main purpose of IFEX.

> 2. The constant want to link multiple hops together in to some
> transaction-level shared-state meta-entity (which might easily be
> undesirable for reasons of latency, privacy/anonymity, etc.)

> (SOLUTION: Reduce scope! Don't mandate multi-party behaviors.

> Provide identifiers to facilitate cross-node transaction
> identification and thus allow people to build up optional explicit
> behaviors from there ... sure. But don't mandate synchronous shared
> views of a transaction. That's only one way to build a distributed
> system, it's expensive in resource terms, it's a poor reflection of
> reality in many cases, and it's often not required or desirable for
> various reasons - latency, privacy/anonymity, etc.)

No. Ripple allows different commit mechanisms but transaction "must"
(there's the bare option) be atomic.
An example where this is not desirable or harmful would be useful.

> > More data can be "attached" to a keypair from outside the protocol
> > just by using the keypair to sign that data. Since Ripple is
> > extensible, you can put a lot of messages on top of it to be as
> > descriptive as you want. I want Ripple to be the base of IFEX, not to
> > be equal to Ripple.
>
> Scope differs. This is illustrated by the two points above detailing
> some assumptions within Ripple.

I mean outside of the Ripple protocol but taking advantage of its
public cryptography infrastructure.

> You claim this but in fact it is not so simple. You have to deal with
> the fact that in such networks there is not one version of the truth
> but in fact many perspectives current at any given time (See #8 @
> http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing).
> From time to time, perspectives can even "roll back". To resolve this
> necessary property of the network, each node is empowered to act upon
> its own version of the truth and based upon its own assessment of
> risk. This is what Bitcoin people are talking about when they talk
> about '<x> blocks of confirmation', it roughly means "degrees of
> certainty". Nobody actually waits for complete certainty, which IIRC
> usually takes a really, really, really long time (like days?) relative
> to expectations of reasonable financial settlement speed. Instead,
> they pick a certainty they're happy with and then consider it settled.
> This is an area of grey, just the sort of area I believe any
> artificial 'atomic commit' notion in any external protocol (be it
> Ripple or IFEX) fundamentally masks.

I'm familiarized with how bitcoin works. In fact I came here from the
bitcoin forum.

Whatever is on top of the current longest chain is the truth, even if
the truth can be rolled back and changed. In fact, there's never
complete certainty, only a ridiculously low probability of a chain
reorganization. But it is always remotely possible that I mine the
longest chain with in a few seconds with an old pentium MMX. That's an
issue with chain based commits, not with the Ripple protocol itself.
Anyway, this is a very special case that no one but me cares about,
let's discuss this later, when we have a clearer view of the
differences between IFEX and Ripple. I shouldn't had to even mentioned
it, sorry.

> Instead, I see the alternative of increased descriptiveness...

This is a great goal for IFEX, but not useful for Ripple. As said,
Ripple doesn't even describe the currency each hub issues. It only
describes what is completely necessary, that is, exchange rates, fees
and limits.

> With the sincere hope that you can understand my points above and in a
> spirit of cooperation,

I think I've done it. But since you're still calling our approaches
naive, I don't think you've understood Ripple yet.

> The most important reason why ripple people insists on atomicity is because things are
> more difficult in ripple than in the financial industry.
> Ripple has to deal with dynamically changing paths. It has to deal with very small credit
> limits. If atomicity is not guaranteed, most transactions will
> be in an irreversible state and the failure rate will be huge.
>
> That is the most important thing for you to understand. IFEX doesnt solve the same
> problem, ripple cant afford not to have atomicity. Maybe that will
> increase latency but that is ok for ripple.

I think atomicity of trades is desirable for IFEX too. Consider my
example A (eur, IBAN) -> B (btc) -> C (usd, bank transfer) -> D using
IFEX isntead of Ripple. Don't they want to agree the exchange rates
atomically before settlements?

> > 2 - Exchange rate and fee fluctuations after the terms of a
> > transaction have been agreed (for example when utilising
> > floating/free-market currency or commodity exchanges within a
> > multi-hop transaction).
> >
> > 2 - Ripple would only include these transactions as a fixed rate of
> > exchange. Ripple nodes providing exchange services on
> > floating/free-market currencies/commodities would therefore be forced
> > to include over-compensating risk-margins within all quotations. This
> > has the net effect of discouraging the use of Ripple for such exchange
> > by introducing inefficiencies.
>
> Your solution is correct: safety margins. Also short transaction
> windows. These could make currency/commodity exchanges less
> attractive choices for use in Ripple paths.

I don't understand this part. Exchanges with float prices can be made
within Ripple.
Let's put mtgoxUSD/mtgoxBTC as an example. If mtgox issues both
currencies as Ripple IOUs, they don't need to run the exchange
anymore. The trades can be made directly within Ripple using the
exchange publishing routing method.

> - Ripple's trust model is network enforced, inflexible, and poorly
> models many real-world scenarios.

No, no, no. The trust is completely voluntary, completely flexible and
I claim it can model ANY financial relationship, be it from the real
world or from the theory world. Please try to find a simple
counter-example so that I can try to invalidate it as a prove that I'm
wrong by successfully modeling the example.