Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat: introduce best-effort payments (with no amount specified) #323

Merged
merged 1 commit into from
Dec 5, 2017
Merged

feat: introduce best-effort payments (with no amount specified) #323

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 28 additions & 3 deletions 0003-interledger-protocol/0003-interledger-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: The Interledger Protocol (ILP)
draft: 6
draft: 7
---
# Interledger Protocol (ILP)

Expand Down Expand Up @@ -152,7 +152,12 @@ See below for the [ILP Error Format](#ilp-error-format) and [ILP Error Codes](#i

### ILP Payment Packet Format

Here is a summary of the fields in the ILP payment packet format:
There are two types of payment packets: delivered and forwarded. A delivered payment specifies the amount that should arrive at the destination, a forwarded payment doesn't.
Note that forwarded payments are still experimental, and their definition may change or get deprecated at any time.

Here is a summary of the fields in the delivered and forwarded ILP payment packet formats:

#### Delivered Payment Packet

| Field | Type | Short Description |
|:--|:--|:--|
Expand All @@ -163,7 +168,7 @@ Here is a summary of the fields in the ILP payment packet format:
| data | OCTET STRING | Transport layer data attached to the payment |
| extensions | Length Determinant | Always `0`

#### Example
Here's an example:

| Type | Length, 8+(1+14)+(1+3)+1=28 | Amount (123,000,000) ... |
|:--|:--|:--|
Expand All @@ -182,6 +187,26 @@ Here is a summary of the fields in the ILP payment packet format:
|:--|:--|:--|:--|
| 98 | 3 | 4 16 65 | 0 |

### Forwarded Payment Packet (experimental)

| Field | Type | Short Description |
|:--|:--|:--|
| type | UInt8 | Always `10`, indicates that this ILP packet is an ILP Forwarded Payment Packet (type 10) |
| length | Length Determinant | Indicates how many bytes the rest of the packet has |
| account | Address | Address corresponding to the destination account |
| data | OCTET STRING | Transport layer data attached to the payment |
| extensions | Length Determinant | Always `0`

Example:

| Type | Length, (1+14)+(1+3)+1=20 | Length | Address ... ('g.us.nexus.bo')
|:--|:--|:--|:--|
| 10 | 20 | 14 | 103 46 117 115 46 110 101 120 117 115 46 98 111 |

| ... Address ('b') | length | data | extensions |
|:--|:--|:--|:--|
| 98 | 3 | 4 16 65 | 0 |


Let's look more closely at the three important fields: `amount`, `address`, and `data`.

Expand Down
8 changes: 6 additions & 2 deletions asn1/InterledgerPacket.asn
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,9 @@ IMPORTS
FROM GenericTypes

InterledgerProtocolPaymentData,
InterledgerProtocolErrorData
ForwardedPaymentData, -- experimental
InterledgerProtocolErrorData,
InterledgerProtocolFulfillmentData
FROM InterledgerProtocol

QuoteLiquidityRequestData,
Expand All @@ -34,7 +36,9 @@ PacketSet PACKET ::= {
{5 QuoteBySourceAmountResponseData} |
{6 QuoteByDestinationAmountRequestData} |
{7 QuoteByDestinationAmountResponseData} |
{8 InterledgerProtocolErrorData}
{8 InterledgerProtocolErrorData} |
{9 InterledgerProtocolFulfillmentData } |
{10 ForwardedPaymentData} -- experimental
}

InterledgerPacket ::= SEQUENCE {
Expand Down
12 changes: 12 additions & 0 deletions asn1/InterledgerProtocol.asn
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,18 @@ IMPORTS
FROM InterledgerTypes
;

-- the following packet type is experimental and may still change
ForwardedPaymentData ::= SEQUENCE {
-- Destination ILP Address
account Address,
-- Information for recipient (transport layer information)
data OCTET STRING (SIZE (0..32767)),
-- Enable ASN.1 Extensibility
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@justmoon mentioned the idea that this might be a good time to add a Time to Live value. I don't feel too strongly about it either way, but adding a new packet type is a decent "speak now (for new features/fields) or forever hold your peace" moment. So...thoughts on TTL (or other new fields)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if signed data is expected to come back from the receiver, the payment packet could contain the pubkey of the receiver. Even if the ledgers don't enforce a crypto-condition (just like there might be ledgers in the chain that don't enforce the hashlock), it would be correct to define the pubkey and the signature scheme as an expectation of the payment as a whole

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be correct to define the pubkey and the signature scheme as an expectation of the payment as a whole

That doesn't sound like a good idea to me. If some parties enforce it but not all, that would be easily exploitable by sending payments you know one party will accept that the other won't. I think whether or not we have fulfillment data is orthogonal to this change.

Copy link
Contributor Author

@michielbdejong michielbdejong Oct 28, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If some parties enforce it but not all

A ledger sits between two connectors. The sending connector should make sure they know if the next ledger enforces it or not. If they know it doesn't, then they need to trust the next connector for the in-flight amount (because the next connector could claim the in-flight amount without producing correctly signed fulfillment data). But that's just a basic HTLA trade-off. You cannot exploit a remote connector, you can only get into disputes with your direct neighbors.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds like a jankier way of doing Crypto Conditions that would run into similar problems. Unless you can rely on the whole network supporting a feature (that needs the whole path to support it in order for it to work), it either can't really be used or it becomes a point of incompatibility between different parts of the network.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused about what you're arguing for here and how this is related to this discussion (as opposed to #314). Are you proposing that a public key would go in the Interledger packet and that a signature by the corresponding private key would be an additional condition for executing transfers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, i agree it would be too much work to add such enforcement. i just feel that it should be clear, if Alice sends Bob a conditional transfer, and Bob produces the fulfillment but nothing else, will Bob have done his job? Or does his job also include delivering the attached data? Or is this something neither Alice nor Bob can know by just looking at the packet? If Alice includes the final receiver's pubkey in her ask to Bob, and Bob comes back with only a fulfillment, then it will be clear that Bob didn't do all the things Alice hoped he would do.

But none of this is necessary anyway if we decide against adding data along with the fulfillment as part of Interledger, and decide that that data will just have to travel out-of-band (even if it piggybacks over side-protocols)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@emschwartz @justmoon what would be the purpose of the TTL and how would it be implemented by senders/connectors/receivers?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if Alice sends Bob a conditional transfer, and Bob produces the fulfillment but nothing else, will Bob have done his job?

I think that's the question under discussion in #314. I think it should either be an expectation of the ILP protocol that connectors send response data back, or not. I don't think there needs to be an indication on the forward path whether it's expected. The transport protocols will know when it's expected or not.

what would be the purpose of the TTL and how would it be implemented by senders/connectors/receivers?

There would be a field in the packet that the sender would set (to a number less than 256 and probably closer to 10). Each connector would decrease that value by 1 before passing on the packet. The purpose, like in IP, is to mitigate the damage caused by routing loops. When the value gets to 0, connectors would not forward the packet any more and would reject the incoming transfer with a specific error.

Previously we've thought that we didn't need a TTL or max number of hops because the routing loops would be implicitly handled by the amount and/or transfer timeout. For packets with no amount in them, it's less clear to connectors when there is not enough money to deliver the destination amount -- unless the transfer amount is 0. @justmoon made the point that relying on the amount or transfer timeout may take too long for packets to get dropped for them to mitigate the damage of routing loops.

I'm on the fence about whether it's worth adding a max number of hops. Leaning towards no right now but could be convinced otherwise.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. What if we add and make FF or something a flag to ignore so it can be optional.

extensions SEQUENCE {
...
}
}

InterledgerProtocolPaymentData ::= SEQUENCE {
-- Amount which must be received at the destination
amount UInt64,
Expand Down