Joel, my scheme only needs a time horizon for the payer in the ripple
transaction, everyone else have pre-signed their orders. Forget about
time horizons for a moment. More important, forget about trust lines
for a moment because that's what is confusing you. Trust lines are
very complex in the shadow, they're like saying "I trade 1:1 with this
limits any of these assets: bitstampUSD, aliceUSD, bobUSD...".
That implies a lot.
Of course trust lines get nasty when you also involve time. In that
case, I agree with you, just don't do it. It would be too complex and
I don't think people would use it like that.
I must remind you that I would remove the trust-lines rippling completely
from the core. They can be simulated at the client level keeping the
core simpler with only regular trade orders. So forget for a moment
there are something else than multi-currrecy regular orders at all.
A Ripple invariant is that someone else's transaction can do something
to you so long as you have agreed that it is fair. There is no way to
tell if something is fair to you unless we know how you value assets,
and if those assets have interest rates associated with them, their
value cannot be determined without knowing the time horizon.
Trade orders are always fair for the user who submit them. Can we
agree on that?
Let's make an example of a ripple transaction involving interests:
1) Alice owns 100 bitstampUSD.
2) Bob wants to sell 20000 bitstampFRC for bitstampUSD at 0.02 usd per
frc. BitstampFRC have 5% demurrage like FRC.
3) Carol wants a FRC loan at 1% interest so she issues carolFRC1 at 1%
interest. She sets an order buying 20000 bitstampFRC for 20000
carolFRC1. She probably wants the order to execute all or nothing.
She wants to pay some hosting for her web project.
5) At the community time bank, Carol has earned 10 localHRS accounted
within Ripple. She also sets an offer to buy the 20000 carolFRC1
for the 10 localHRS she has.
5) David sells beers at his pub for 0.2 localHRS
6) Alice visits David and Carol's and asks David, "I want 50 beers, do
you accept bitstampUSD?"
David: No, but I accept Ripple, we can try. You probably don't have them,
but try to pay me 10 localHRS.
Alice: Great, it worked!
After the trade:
- Alice is drunk.
- Bob has the 100 bitstampUSD he wanted.
- Carol has the 20000 bitstampFRC she needed. She was lucky and didn't
had to pay any interest because she was able to sell the HRS for her
interest bearing debt in the same transaction, but if it would have
been in different transactions (maybe several of them) Carol would
have had to pay some interest.
- David received 10 localHRS.
- Nobody set a "time horizon" but it's all fair for everyone.
If Alice had several payment paths using bitstampUSD, bitstampFRC and
investmentFundUSD she would had needed a time horizon. That's why I
suggest the infinite as a sane default. That way Alice would try to
pay with bistampFRC first, then bistampUSD and only then
investmentFundUSD.
Interest bearing assets could be "custom currencies". Now let's put
the trust-line rippling back in. If "custom currencies" can only be
rippled within regular trade orders, everything is fine. Just no
"trust line rippling" for custom currencies.
Well the only question should be whether the demurrage from Bob's
offer is paid from the order itself or from Bob's bitstampFRC
outstanding reserves and automatically cancel the offer when there's
not enough reserves. You could allow both modes.
Does this make more sense to you?
