Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
feat: introduce best-effort payments (with no amount specified) #323
@emschwartz from the other ticket:
That's not an argument against this proposal. Do you see any downsides in using two different call types? Are you afraid we'll use up our 256 possible call types too soon if we use type 9 for this? Even if that's the concern, I don't think multiplexing/overloading different behaviors onto the same call types would be the solution, we should then just make the call type an Int16 instead of an Int8.
I'm not worried about using up call types. I'm having a hard time getting behind having two versions of Interledger before anyone is really using any version of it.
That said, I do think it's better not to have the amount in the packet as cleartext in basically all cases: delivering at least a certain fixed amount, chunked payments, streaming payments, end-to-end quoting, or building any other type of protocol on top of ILP.
Agree. I think this change may happen but is premature.
As I said to @michielbdejong privately our decision process should go as follows:
IMO these are our options:
The ILP protocol doesn't specify how a node calculates the amount and expiry on the outgoing transfer so I think it's as simple as that.
I believe that the majority of implementations will behave according to 2 so we should standardize on that.
If we decide that we prefer to standardize on 1 THEN we should consider this proposed change.
left a comment
After talking about this more individually with @michielbdejong and @justmoon I was more convinced that it would make sense to make the no-amount packet a separate type. I'm now in favor of defining a separate type as the Interledger V2 Packet, with roughly the structure suggested here, and then at some point in the not too distant future deprecating packet type 1. @michielbdejong made a fair point that making a change to the meaning of packet 1 means you need to know whether you're in a network that uses the old behavior or the new one, so it's better to be more explicit and just use a new type. Even so it'll need to be a breaking change because we are going to expect everyone to upgrade to start supporting packet 9 at some point, and then I think we're going to start removing support for packet 1.
Whether or not we deprecate ILQP is a separate question. I would also be in favor of that but we should discuss that in a different issue.
referenced this pull request
Nov 17, 2017
2 times, most recently
Dec 1, 2017
Hmm, I was thinking we would experiment using the existing method for best-effort payments for a while and then decide what we want the new packet to look like.
Right now I'm not aware of any other changes we would make, so this looks good to me. But I think it's possible that we would come up with changes while experimenting with the new transport layer protocols.
@emschwartz as explained on Slack, overloading type 1 would be a dirty hack and a breaking change, and both those things are undesirable, and also avoidable thanks to the fact that the ilp packet has an envelope. That is why I implemented the type 10 forwarded payments in several PRs to the reference stack, sorry if that wasn't clear.
I'm interested to hear what benefit anyone feels having these packet definitions is providing at this point?
It seems to me that having a standard packet format is only mildly useful in that it provides a standard binary encoding which you can adopt in a ledger protocol but that's it.