Protocol design considerations wiki page
Ryan Fugger
help people who are trying to figure out what's going on with the
protocol designs:
http://ripplep2p.com/wiki/Main/DesignConsiderations
Comments welcome. I'm sure there is a lot of stuff still to add.
Ryan
Ryan Fugger
> Been working through this. So far, the below conclusions about searching
> direction and about late commits.
>
> Is the search for credit part of the commit-ready (forwards) message?
>
> AFAICS a backwards search will be more effective. The payee doesn't need to
> specify exactly what his maximum fee is, so nodes won't be tempted to use it
> all up, and we don't have to make numerous searches with different fee caps.
> Further, as far as I can see it's the only realistic way to deal with
> interest in most cases: at each hop the interest rate must (usually)
> increase, therefore it is much easier to work backwards. The same argument
> can be made with any other currency with similar properties.
I agree that backwards search separate from the commit-ready is
usually best. There is also the use-case where the payment amount is
defined at the payer, not the recipient, for example, when someone
wants to transfer all their funds to a different account. In that
case, the search would be best carried out forwards, but it's probably
still best to keep it separate from the commit ready so it can be
lighter-weight.
>
> So perhaps we have some sort of a backwards search, several in parallel, which
> then result in the more concrete commit-ready. Assuming the commit-ready
> reaches the recipient (which it may not), we now have a chain of binding
> promises. If the commit is sent, everyone updates their respective balance
> and the transaction is completed. If a node goes down during the commit, it
> won't be relayed, so it is the node operator's responsibility to get back
> online before the downstream promises expire. For a major operator this means
> they need a reliable system. For an individual running their own Ripple
> server, this might mean taking it to a webcafe and flushing the pending
> commits. Either way some sort of emergency mode would be useful.
Your description is apt. I've often thought of having a
'promise-renew-request' sequence to renew expired commit-ready
messages. In general, if there's credit available on the path, the
payer's server should want to do this because the commit message is
the proof of payment. There might also be a mode where if the
promise-renew-request fails, the payer's server and the server stuck
with the commit message can negotiate for the payer to purchase the
commit message with a new Ripple payment.
If that fails though, there could be mechanisms to determine liability
for a loss in connectivity. A server stuck with a commit message and
unable to make a connection to the intended server ought to be able to
send the message to one or more reputable third parties for
timestamping and a relay attempt to the intended host. Servers could
then purchase insurance against these kinds of losses. I wouldn't
include these capabilities in the first versions of the protocol, but
they are potential solutions to these issues.
>
> The two have different requirements: how long can we realistically keep the
> promises for? It's a tradeoff between what you lose when your connection goes
> down (because you don't get the commit) versus what you lose when somebody
> else's connection goes down (because they don't get a commit and therefore
> you aren't able to spend their money). A major operator would likely have
> some "backbone" connections (reliable links with high capacity), i.e. to
> other banks, so I suppose the impact of the latter is minimised.
>
> But there is the DoS: Start a big transfer to another node you own through as
> much of the network as possible, don't let the second node commit it, wait
> for just before the deadline and then cancel it. Clearly this depends on
> having enough trust in the first place to make some mischief. So nodes that
> regularly do this can be punished (e.g. by reducing their credit limits).
> Obviously this is a problem for downstream nodes... but ultimately somebody
> chose badly, so this is the best way to deal with it. ???
Maybe if the promise-renew/repurchase scheme works well enough,
promise deadlines can be kept fairly tight to minimize the effect of
DoS. Also, like email spam, I see this as more of a server issue --
servers have to keep their clients in line. But detecting bad server
behaviour could be more problematic, since you never really know if
the server is originating the payment, or just passing it along.
If DoS is seen as a threat, I see two things that might happen: a
cartel of important Ripple servers forms where they all whitelist and
regulate each other, and control access to their club; or a
modification of the protocol where payment endpoints are identified
and authenticated in commit-ready messages. This last might not be so
bad, since it wouldn't be too hard to set up Ripple proxies to hide
the true payment endpoints. Banks might demand this as an
anti-money-laundering feature anyway, and the DoS aspect makes it hard
to argue against.
>
> How risky is it for an individual to get another entity to run their Ripple
> transaction server? Does it require trust greater than that they have now in
> a bank?
Well, a Ripple server would be obligated to provide signed client
messages for every originating payment and every exchange rate set, so
a Ripple server wouldn't be able to cheat you without getting caught
any more than a bank could. Probably it would be much easier for a
bank to cheat you, since it could easily fabricate a PIN authorization
record for a fraudulent transaction, whereas Ripple client
authorizations would be digital signatures and much harder to spoof.
The real trust would therefore have to be in your client software,
which would be much easier for you to run yourself than your own
server. The client API to the server I'm building now uses regular
HTTP, although an XMPP interface for realtime updates might also be
nice.
Ryan
Ryan Fugger
> > In general, if there's credit available on the path, the
> > payer's server should want to do this because the commit message is
> > the proof of payment.
>
>
> before it reaches it, the payer server times out, and sends a
> promise-renew-request along the commit-ready path to renew the commit-ready
> promises. When the node comes back up, it receives the commit (which is kept
> for a longer period, maybe forever), the original commit-ready has expired,
> but it queries the predecessor and finds that the commit-ready has been
> renewed so it can forward the commit anyway, perhaps at a slightly increased
> cost (within the original agreed bounds).
>
That's basically it. I would do it slightly differently: Since each
promise down the chain has a slightly shorter expiry time (to give
that node a safety buffer and time to process the commit and pass it
on), it's possible that the commit is stuck but the payer's original
promise is still valid. So the node stuck holding the commit could
send a promise-renew-request back towards the payer, and when it hit a
node happy to renew the promise to the new deadline requested, it
could do so, and it would propagate forward up to the stuck commit.
>
> > There might also be a mode where if the
> > promise-renew-request fails, the payer's server and the server stuck
> > with the commit message can negotiate for the payer to purchase the
> > commit message with a new Ripple payment.
>
>
> So here the interesting case is that the payer goes down. When it comes back
> up, it tries to renew the promise, but there isn't enough credit on the
> original path, so it is rejected.
>
> Is proof of purchase a sufficient incentive here? The recipient can talk
> directly to the sender to get proof of purchase, and the sender is happy as
> he has been paid by the adjacent node.
>
> What *is* an incentive is the potential liability. If the transfer reaches the
> commit stage, (which we can discover from the recipient), the currency has to
> stay locked, because the transaction has been made: node n-1 owes the
> recipient $N, therefore it expects to be able to use it from node n-2, and so
> on. If node m goes down, node m+1 is stuck with the transfer, and he will try
> to blame node m-1, won't he? Wouldn't you? It's not node m-1's fault, but it
> is his responsibility, at least in my country's legal system (the principle
> behind most employer's liability). Therefore, node m-1 has a strong incentive
> to find an alternative path to node m+1. If he doesn't, he may eventually be
> compelled to settle at least in part in hard currency.
Node m+1 does not know who node m-1 is, and even if he did, he has no
agreement with node m-1 and node m-1 has made no legal obligation to
node m+1. Node m-1's promise is to
redeem a valid commit message from node m in exchange for value on
their shared account. So liability is no incentive.
>
> IMHO until the commit has actually propagated back to the originator, we need
> to leave the door open for alternative routing in case of failure. This is
> what you mean by repurchasing?
Yes. What I was thinking was that the promise-renew-request sent back
towards the payer would contain the address of the server holding the
stuck commit, so if the promise-renew fails because of insufficient
credit, a new path could be negotiated.
> > If DoS is seen as a threat, I see two things that might happen: a
> > cartel of important Ripple servers forms where they all whitelist and
> > regulate each other, and control access to their club; or a
> > modification of the protocol where payment endpoints are identified
> > and authenticated in commit-ready messages. This last might not be so
> > bad, since it wouldn't be too hard to set up Ripple proxies to hide
> > the true payment endpoints. Banks might demand this as an
> > anti-money-laundering feature anyway, and the DoS aspect makes it hard
> > to argue against.
>
>
> This of course requires hard identity for the endpoints, so that a DoS'er
> cannot simply create a new identity behind an existing one.
I was thinking the endpoints would be identified by server only, since
any DoS behaviour would be the server's responsibility, and server's
are identified by X.509 certificates linked to their domain. I don't
imagine it's economical to buy a new certificate from a CA for each
DoS attempt...?
Ryan