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

[Evgeni P. <epa...@gm...>]

Ryan:
> * Account-change request:  The requesting node could encrypt the
> request data in the request message (along with a signed plaintext
> version) and the partner would echo it back (along with a signed
> plaintext version of its own) it the request was approved.  I'm not
> sure this would save any hassle because the requesting node will
> probably want to save pending requests in order to detect and
> gracefully handle any potentially conflicting requests from the user
> before the original request is approved.

I am not sure if I understood this well... anyway I agree it sound like a
bad idea.

> * Path-search:  We've covered this one.  Build an onion on
> path-search, and peel it during the promise phase.

A little generalization I consider important:
Build an onion using whatever method you like, and peel it during the
promise phase.

> * Promise phase:  The intermediaries could create an onion in the
> opposite direction as path-search, containing their promises and
> related information, to be peeled during receipt/commit-phase.  They
> would still need to store most of the state (amount of credit
> reserved, deadlines, penalties, as well as all payment/path IDs) in
> case the receipt or promise release never came and it needed to
> penalize its neighbour, though.  So all that could really be bundled
> in the onion would be the receipt authentication keys for the payment.
>  Not sure that would be worth the hassle.

I agree it does not worth the hassle.

> That's about it I think.  Can you make a better argument for storing
> state in messages for either account requests or promises?  Otherwise
> it doesn't seem worth it.

I will try to summarize how onion routing would change the promise-message:

In the current draft for the promise message we have:

   - payment ID
   - swarm ID
   - path ID
   - amount to be held for payment, in transaction units
   - ID of account to be made part of path by this promise being passed
   - amount to be held for payment, in account units, according to
   conversion rate defined by neighbour in path-query message
   - promise penalty deadline
   - daily penalty rate if receipt or path-cancel not received before the
   penalty deadline
   - promise final deadline, after which promise expires
   - the payer's receipt authentication key for this payment path
   - the recipient's receipt authentication key for this payment path
   - a timestamp to indicate the time the promise came into effect.

If we use onion routing we probably should have:

   - ID of account to be made part of path by this promise being passed
   (Can we use the URL of account units instead?)
   - amount to be held for payment, in account units
   - conversion rate between transaction units and account units
   - promise penalty deadline
   - daily penalty rate if receipt or path-cancel not received before the
   penalty deadline
   - promise final deadline, after which promise expires
   - the payer's receipt authentication key for this payment path
   - the recipient's receipt authentication key for this payment path
   (Can we make this field optional?)
   - a timestamp to indicate the time the promise came into effect.
   - onion routing blob (this is basically an advice for node accepting
   the message how to handle the payment further)

Does this message-structure make sense?




On 10/25/06, Ryan Fugger <rf...@gm...> wrote:
>
> On 10/25/06, Evgeni Pandurski <epa...@gm...> wrote:
> >
> > > This is equally hidden in the current design.  I think the reduce
> > > locally-stored state between path-search and payment is the main
> > > reason to use onion routing.  Although, this would be a stronger
> > > argument if there wasn't already so much stored state at each node...>
> ...
> > > I wonder if there are other places in the protocol where we can
> > > replace local stored state with encrypted protocol messages?  I can't
> > > think of any of the top of my head...
> >
> > This is a very interesting question. Where nodes are expected to hold
> state
> > according to the current draft? (I mean intermediary nodes of course)
> Why
> > don't
> > you open a discussion on that in the mail-list... saying "currently he
> hold
> > state
> > here, here and here... is this necessary... is there any way to avoid
> state
> > and
> > where". I would exclude from the discussion the state being hold during
> the
> > path-finding
> > phase or at lest to keep this separate from the other. I believe we
> could
> > perfectly do
> > things without any state-holding for promise/promise-redemption phase
> (of
> > course
> > accepting a promise do change state but this is OK). What we need to
> avoid
> > is
> > intermediaries to remember path IDs, payment IDs and other such things
> not
> > being
> > part of the promise semantics.
> >
> > Basically we can simplify relation between adjacent nodes *during the
> > commit-phase* to:
> > - I promise: to pay XXX if you supply the receipt.
> > - Advice: you have best chances to get the receipt if you follow the
> > onion-routed instructions.
> > - Do not torture your head/database with payment IDs and path IDs (I
> will
> > take care of this)
> >
> > Thus the only nodes that have to hold state would be buyer and seller.
> In
> > fact I am not
> > sure if seller needs to hold state either... if we have a temporary
> account
> > created it would
> > hold the whole state necessary for the seller (but I am not very sure
> about
> > this...)
>
> Any sort of request/confirm or reserve/commit dynamic exchange of
> messages might benefit from moving some of the stored state for one or
> more of the nodes involved into the messages using encryption:
>
> * Account-change request:  The requesting node could encrypt the
> request data in the request message (along with a signed plaintext
> version) and the partner would echo it back (along with a signed
> plaintext version of its own) it the request was approved.  I'm not
> sure this would save any hassle because the requesting node will
> probably want to save pending requests in order to detect and
> gracefully handle any potentially conflicting requests from the user
> before the original request is approved.
>
> * Path-search:  We've covered this one.  Build an onion on
> path-search, and peel it during the promise phase.
>
> * Promise phase:  The intermediaries could create an onion in the
> opposite direction as path-search, containing their promises and
> related information, to be peeled during receipt/commit-phase.  They
> would still need to store most of the state (amount of credit
> reserved, deadlines, penalties, as well as all payment/path IDs) in
> case the receipt or promise release never came and it needed to
> penalize its neighbour, though.  So all that could really be bundled
> in the onion would be the receipt authentication keys for the payment.
> Not sure that would be worth the hassle.
>
> That's about it I think.  Can you make a better argument for storing
> state in messages for either account requests or promises?  Otherwise
> it doesn't seem worth it.
>
> Ryan
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>