Re: [Ripple-protocol] Ripple protocol design process - critical note

[Ryan F. <rf...@gm...>]

On 10/24/06, Evgeni Pandurski <epa...@gm...> wrote:
> > So it would give the payer the ability to
> > dictate what the payment chain is...  But how does the payer discover
> > what payment chains are even available?
>
> That's the whole point - payer discovers the path however it wants/can:
> 1) By asking (semi)centralized service
> 2) By off-line negotiations with intermediary-nodes
> 3) By re-using an old path. (do not underestimate this point!)
> 4) By issuing path-queries (at least :-) The routing schema we have in the
> current draft is perfectly compatible with onion-routing:
>
> path-query phase: N1 -----path-query------> N2 ----.....---->  N3 ---
> path-query-----> N4
> path-found phase: N1 <---onion-packing----- N2 <---.....-----  N3 <--
> onion-packing--- N4
>
>  At the end N1 holds perfectly valid "onion-routing-blob" without having any
> knowledge about
> the network structure. All exchange rates are chosen by the respective
> intermediary nodes.
> You see that you do not have to throw away the work you have done with
> routing-stuff. But
> you gain flexibility and this is very important.
>
> Ahhh, now I see what bothers you.... Onion routing might not allow both
> buyer and seller
> to emit queries and to rely on collision between queries. Actually I am sure
> this is not imposible
> to be done with onion-routing (in spite of my disbelief in the efficiency of
> this approach to routing).

Yeah, I'm not so sure anymore that collisions between searches in both
directions will occur that often.  The current path-search design is a
bit different from what we had last year.  It's more defined, more
targetted, and hopefully more scalable.  One thing that has changed,
however, is that credit is being frozen at the path-search phase.
This is feasible with more targetted searching, since it will not
result in large amounts of credit being needlessly frozen, and
desirable, since it means path-search is more reliable.

Unfortunately, this means there is state being stored between the
path-search and payment phases.  But this frozen credit is not
absolutely required by the payment phase -- payments could still be
attempted without it -- so this doesn't stop onion routing from
potentially being useful.  And after thinking about it I think I agree
that allowing payment to be independent of the path-search is good
design.  If nothing else, it reduces the need to interface with
persistent storage in node implementations.

My main concern would be the encryption overhead during the
path-search phase where the onion is built.  However, if the algorithm
used was chosen for encryption speed rather than decryption speed (I
think RSA fits the bill), then it might be a worthwhile tradeoff.  It
depends on the need for distinct routing strategies.  But, considering
that routing is the central core of Ripple, as well as the most
problematic bit, it makes sense to make it as independent as possible
from the rest.

Can we the same key pair for encrypting onion layers as for signing
messages?  Performance numbers for different algorithms/key types are
given here:

http://www.scramdisk.clara.net/pgpfaq.html#SubPerfAsymEnc

RSA would be preferable for both signing (more work for the signer)
and encryption (more work for the decrypter) in Ripple, I think, so a
single RSA key pair should do.  So all that's needed is to add a field
for the onion blob in the path-query messages emitted from the payment
recipient?  What should be in each onion layer?

* account ID of next hop (maybe also node ID?)
* the conversion rate between transaction and account units for the next hop
* time to penalty deadline
* late-receipt penalty rate
* time to final receipt deadline
* the expiry deadline for this path

Given that we wish to allow for minimal state carried over between
path-search and payment at each intermediary, we should include the
conversion rate in the path onion.  But that means we must allow
intermediaries to put a deadline on the use of that onion, to prevent
payers from attempting to use paths that will be refused by some
intermediary at the promise phase because of too-stale exchange rates.
 To a lesser extent, the other fields in the onion may grow stale as
well.

Also, the path-expiry deadline can be used as the credit-freeze expiry
deadline in the current routing scheme.

Things to add?

Ryan