Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

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

On 10/20/06, Jiri Baum <ji...@ba...> wrote:
> Hello,
>
> > > Ryan:
> > > > I'm thinking about account agreements that might specify a changing
> > > > interest rate, like the central bank prime rate...
>
> Jiri:
> > > No need to date and sign changes in that case; everyone can see what the
> > > central bank rate is.
>
> Ryan:
> > Yes, but what if one party decides they're going to read the central
> > bank rate at midnight, and the other at noon?
>
> Most central  banks publish rates once every few months; in any case, as
> Stanislav writes, that should be in the definition...

The central bank rate was only an example.  The published rate could
come from anywhere, at any interval, which may not be known ahead of
time.  We must be able to handle any arrangement, including one where
one party gets to dictate the interest rate whenever he wants.  We
must also be able to handle the case where various source for an
authoritative rate publish conflicting information.

>
> > What if the central bank server is unreachable by one party but not the
> > other?
>
> Then either they trust each other or they don't.
>
> If it's a question of exchanging one ripple unit for another, then you either
> take a guess or refuse the transaction.
>
> If it's at settlement, you can also use an approximate amount and figure out
> the rate retrospectively - the bank generally publishes historical rates, and
> at settlement it's two parties who have some trust between them anyway.
>
> > We must allow the two parties two explicitly agree on what rate they are
> > using at all times otherwise there will be balance discrepancies.
>
> Actually, they only need to agree at the time of a transaction, and then only
> if that transaction involves exchange.
>

Trust is a sticky thing.  Good communication is vital in maintaining
trust.  If for any reason, one party had presumed a certain interest
rate for any significant length of time, while the other party had
presumed a different rate of interest, that will be harmful to the
relationship.

Both parties to an account must be able to maintain a record of
messages, signed by the other party, that can be used to establish the
balance at any given time.  This leaves no room for disagreement.  The
interest rate is needed to calculate the balance.

Maybe there's a better approach to handling account changes than
having a separate set of messages and interactions for each piece of
data we can imagine ever being useful in an account (because
inevitably, people will want to add more).  A request to change any
account field goes into an "account-request" message, and a
confirmation or declaration of a changed field goes into an "account"
message.  (Maybe also some way to explicitly reject a request...?)  A
message attempting to declare a new field value that the receiving
node feels requires its assent can be countered with an error code:
"Must be addressed by account-request."  Then the sending node could
try account-request semantics if appropriate.

Together with something like a "must-understand/may-ignore" flag for
account fields (as previously suggested by Evgeni) and corresponding
error codes, this allows nodes to negotiate their own account
field-set and corresponding semantics.  But the important thing is
that there can be no authoritative third source for account
information -- that will only be a source of disagreements.  Any
change to any account field must be agreed to by the nodes themselves
and signed and dated messages to that effect made available to both.

Does that appeal to anyone?  Any problems with this scheme?  (I had
something like this in an early version of the protocol -- who knows
why I took it out...)

Ryan