You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 7, 2019. It is now read-only.
In #17, a fulfillment packet was introduced, which can be used as a standard representation of the arbitrary transport-layer or application-layer data, that may be passed back from the receiver, along the payment path, to the sender.
However, in other contexts, the term 'fulfillment' is already used to refer to the preimage which unlocks the hashlock of a conditional transfer.
@justmoon Wouldn't 'serializeIlpFulfillmentData' be a better name than 'serializeIlpFulfillment'?
The text was updated successfully, but these errors were encountered:
... to keep it consistent. (Read as: IlpPaymentData travels with a payment, IlpFulfillmentData travels with a fulfillment and IlpRejectionData travels with a rejection.)
We'd keep the old method names around for backwards compatibility, of course, but perhaps mark with util.deprecate. And I'd make a PR for the spec to use the same new terminology.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In #17, a fulfillment packet was introduced, which can be used as a standard representation of the arbitrary transport-layer or application-layer data, that may be passed back from the receiver, along the payment path, to the sender.
However, in other contexts, the term 'fulfillment' is already used to refer to the preimage which unlocks the hashlock of a conditional transfer.
@justmoon Wouldn't 'serializeIlpFulfillmentData' be a better name than 'serializeIlpFulfillment'?
The text was updated successfully, but these errors were encountered: