On Sat, Aug 11, 2012 at 7:48 PM, Walter <walter.stan...@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:
> 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.
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-dra... > 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...
> --
> You received this message because you are subscribed to the Google Groups "Ripple Project" group.
> To post to this group, send email to rippleusers@googlegroups.com.
> To unsubscribe from this group, send email to rippleusers+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.
>> 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:
>> 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.
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-dra... >> 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).
>> 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
On Sun, Aug 12, 2012 at 3:18 PM, Walter <walter.stan...@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.
> 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.)
>>> 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.
>> 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...
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.
On Mon, Aug 13, 2012 at 12:09 PM, Walter <walter.stan...@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.
> 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.
>>> 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
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.
On Tue, Aug 14, 2012 at 2:40 PM, Ryan Fugger <a...@ryanfugger.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, 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
> On Mon, Aug 13, 2012 at 12:09 PM, Walter <walter.stan...@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.
>> 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.
> 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.
>> 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)
On Tue, Aug 14, 2012 at 5:06 PM, Walter <walter.stan...@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:
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.
>>> 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:
> 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
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.stan...@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:
> 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.
On Wed, Aug 15, 2012 at 9:51 PM, Walter <walter.stan...@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.
On Wed, Aug 15, 2012 at 9:51 PM, Walter <walter.stan...@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 :)
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.
> 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
On Fri, Aug 17, 2012 at 5:03 AM, Walter <walter.stan...@gmail.com> wrote:
> 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.
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.
>> 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.
> I appreciate what you're saying 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
...
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?
> >> 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.
> > I appreciate what you're saying 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
> 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.
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.
> > 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
> --
> You received this message because you are subscribed to the Google Groups
> "Ripple Project" group.
> To post to this group, send email to rippleusers@googlegroups.com.
> To unsubscribe from this group, send email to
> rippleusers+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rippleusers?hl=en.
On Fri, Aug 17, 2012 at 8:30 PM, Walter <walter.stan...@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.
> --
> You received this message because you are subscribed to the Google Groups "Ripple Project" group.
> To post to this group, send email to rippleusers@googlegroups.com.
> To unsubscribe from this group, send email to rippleusers+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.
> > 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.
