Connector and Packet Questions

[Rawad_Rifai]

From documentation:

Payment channels are a way to use signed claims against funds held on a ledger

• Are there any assumptions about the type of account(s) that would exist between a participant and a connector? For example: multisig?

• Are there chances for cycles between connectors and are there any mechanisms in place to avoid them?

• Is there documentation on the executionCondition? I’m trying to find what’s the actual cryptographic function that runs to fulfill the condition. Is it just a hash digest of the secret?

• For the fulfill packet, how do connectors know the previous node to send the packet to?

• At the risk of asking a naive question, is there a mechanism to ensure the connector credits a receiver when receiving a fulfillment package?

• If connectors subtract X from the expiration date of the prepare packet, how do we know what’s the real expiration date? And do we need to know? By “we”, I mean connectors. IOW, on the way back, don’t connectors check for expiration? Are they checking the altered value, and against what? Unless it’s a function of the connector to increment the expiration in the fulfill.

From documentation:

If participants use payment channels, they may choose to sign an update to the payment channel to cover the value of each packet sent and thus minimize the amount the connector must trust the sender for

• What is meant by “sign an update”? If this means issue a blockchain transaction, then it might not be realistic for any of the existing blockchains. If it means balancing a bilateral database account, how does it reduce trust required in the sender?

• Can you point out wrong content in the following statements?
  Connectors may have multiple types of payment channels. Each payment channel type comes with an input asset type and an output asset type, for example BTC => ETH. Connectors apply exchange rates per channel type. Payment channel may input and output the same asset type. Connectors may pay each other fees depending on connectivity (for example, the less connected pays the more connected)

• When looking at the full stack, we have SPSP talking to ILP, while Pre-Shared Key V2 can be used for secret management. Is there an adopted db for bidirectional balance tracking?

[emschwartz]

Great questions!

@Rawad_Rifai

Are there any assumptions about the type of account(s) that would exist between a participant and a connector? For example: multisig?

The general assumption is that both parties independently track their view of the (net) balance between them and use some kind of external accounting system to settle. See this thread for the discussion on the main settlement options: Should the main Interledger UX use payment channels, on-ledger settlement, or hosted accounts?

@Rawad_Rifai

Are there chances for cycles between connectors and are there any mechanisms in place to avoid them?

Routing loops are possible if their routing tables are configured to point back to one another for a particular destination. Each time a packet is forwarded, some time is subtracted from the expiry, which at least makes it so that the packet won’t travel in a loop forever. For more details on how to avoid loops, you might want to ask in this thread: How does routing work in Interledger?

@Rawad_Rifai

Is there documentation on the executionCondition? I’m trying to find what’s the actual cryptographic function that runs to fulfill the condition. Is it just a hash digest of the secret?

The execution condition (also sometimes referred to as just the condition) is just the SHA 256 hash digest of the fulfillment. See the Interledger Protocol V4 spec for more details.

@Rawad_Rifai

For the fulfill packet, how do connectors know the previous node to send the packet to?

Connectors keep the previous hop in memory. Thus far, most implementations use a Promise or a Future (whatever async primitive the language uses) to map the incoming request to the outgoing request and response. A connector implementation could use a different design though.

@Rawad_Rifai

At the risk of asking a naive question, is there a mechanism to ensure the connector credits a receiver when receiving a fulfillment package?

If the receiver doesn’t trust the connector, they should use a payment channel for settlement and require payment channel updates for every packet. In this way, the payment would almost immediately be guaranteed by the underlying ledger/blockchain.

@Rawad_Rifai

If connectors subtract X from the expiration date of the prepare packet, how do we know what’s the real expiration date? And do we need to know? By “we”, I mean connectors. IOW, on the way back, don’t connectors check for expiration? Are they checking the altered value, and against what? Unless it’s a function of the connector to increment the expiration in the fulfill.

There is no single expiration date. Imagine that each time the packet is forwarded, it’s a completely separate packet with a different arrangement between the parties. If I send you a packet that expires in 20 seconds, what I’m saying is “I agree to pay you if and only if you give me a fulfillment that hashes to that condition within the next 20 seconds”. How you get that, including where you might send another packet or what that packet might look like, don’t matter at all to me. (A really important part of Interledger is how it localizes these relationships to the bilateral connections)

@Rawad_Rifai

What is meant by “sign an update”? If this means issue a blockchain transaction, then it might not be realistic for any of the existing blockchains. If it means balancing a bilateral database account, how does it reduce trust required in the sender?

A payment channel is like a temporary escrow account on a blockchain. The payment channel is created by at least one of the parties submitting a transaction on the blockchain to deposit funds into the shared account. Then, the two parties can instantaneously “pay” one another by sending signed transactions or updates to each other (not to the blockchain) that assign a greater portion of the escrowed funds to the other party. This can be repeated any number of times without touching the blockchain. When one or both of the parties wants to close the payment channel and withdraw their funds, they will then submit a second transaction to the blockchain to do so.

@Rawad_Rifai

Can you point out wrong content in the following statements?
Connectors may have multiple types of payment channels. Each payment channel type comes with an input asset type and an output asset type, for example BTC => ETH. Connectors apply exchange rates per channel type. Payment channel may input and output the same asset type. Connectors may pay each other fees depending on connectivity (for example, the less connected pays the more connected)

Sounds correct to me.

@Rawad_Rifai

When looking at the full stack, we have SPSP talking to ILP, while Pre-Shared Key V2 can be used for secret management.

Small correction: STREAM is now the recommended transport protocol to use, rather than PSK2. Implementations of SPSP SHOULD automatically use STREAM now.

@Rawad_Rifai

Is there an adopted db for bidirectional balance tracking?

That’s an implementation detail so not something that would necessarily be adopted across the board. Want to start a thread in the Implementations category about which database technologies to use?