Send money before determining the exchange rate?

[emschwartz]

If the user sets the sendMax amount before knowing the exchange rate, should the packets sent to determine the exchange rate carry money (and be fulfillable)? This would potentially reduce the latency for the first bit of money to get through, because it wouldn't be waiting for multiple round-trips with test packets before sending real money.

On the one hand, this opens things up for connectors to take a larger share of that money, because the sender will set a minimum destination amount of 0. On the other hand, though, connectors that want to do that could just take the same amount of the test packet to influence the minimum exchange rate the sender will set, so it might not make much of a difference.

If a user doesn't want to send money with a minimum acceptable amount of 0, they could just wait until the exchange rate is known before setting the sendMax.

[traviscrist]

Seems reasonable and a simple way to improve the start time to transmission of funds. The risk outlined is there regardless of this being supported since as you mentioned the connectors that want to take a large share could do so anyways by influencing the test packets exchange rate initially.

[kincaidoneil]

Would the minimum exchange rate of 0 only apply to those first few test packets (i.e. until an exchange rate could be established, at which point it could be compared to decide whether to keep streaming or not), or would it apply to the entire amount being streamed (in sendMax)?

[emschwartz]

Would the minimum exchange rate of 0 only apply to those first few test packets

Yup! As soon as it figured out the exchange rate it would be able to set a more intelligent minimum.

[traviscrist]

@emschwartz have you given any more thought to this proposal, with web monetization we can really see this being beneficial.

If we did implement this do you have any more details on how it would work. Would the connection be created and then packets sent, as they are sent the exchange rate would become clearer and finally be set once a precision is reached?

Would we keep our packet volley. As is it seems we would see the following behavior:
Sent -> Received
1 -> 0
1,000 -> 2
1,000,000 -> F08
1,000,000,000 -> F08
1,000,000,000,000 -> F08
Max Packet size is communicated from F08's as 100,000

so if those were all valid packets 2 made it there on the 1,000. If we then follow the current logic we would try 100,000 which ends up failing.
Then we would try ~66,000 which may succeed but really the connection is already established since we are not holding it for the exchange rate so is it worth keeping the precision probe.

Maybe instead of the broken up logic we could take the first packet that makes it there and ramp up based on the max packet size. So the next packet would be like 1,000 + 10% of 100,000 = 11,000
11,000 -> 22 so we then ramp it up more to
21,000 -> 42
31,000 -> 62 until we hit a T04 and then back off by 1/3.

I'm curious what your take is on how to combine the exchange rate establishment and sending packets into one smooth flow.

[traviscrist]

@SolsticeLLC This issue is a discussion about how we can speed up the exchange rate establishment by sending fulfillable packets right away instead of test packets. What you have posted seems like a bug at the codiusd/ILP level which ends up throwing the STREAM 'Unable to determine exchange rate error'

To keep things clean can you repost it as a separate issue under codiusd so we can debug it there. As part of that posting can you also gather logs with ilp-protocol-stream* added to your DEBUG env so if you just have DEBUG=codiusd* it would not be DEBUG=codiusd*,ilp-protocol-stream* that will provide further insight into why the F99 is being triggered by g.aurora. If a STREAM bug is found then we can post it to the STREAM Project. Thanks!

[SolsticeLLC]

My apologies for the intrusion! Moving to the appropriate location for the issue. Thanks!