I’m researching ILP together with my colleagues and we are trying to do some tests to better understand ILP. We setup several ILP connectors using Moneyd, locally and in the cloud - for our experimentation needs. There are several things that are unclear to us and we would like to clarify them to continue our work:
When we run our moneyd instance two payment channels are created. One payment channel talking from our test account, parent, to BTP layer (in DEBUG called channel) and second channel between parent and local on ILP layer (in DEBUG called clientChannel). Is this correct?
When running info command we can only see the channel initiate between BTP and our test account. Is this correct? Why after stopping the channel I have to configure new configuration file and my account gets blocked? Is there a way to see the clientChannel or this will be one of the future features?
When running info command could you explain what following fields mean: destination, amount (drops) and balance (drops)?
When we run the moneyd with a new account for the very first time our payment channel looks something like:
index channel id destination amount (drops) balance (drops) expiry
0 CE3963C6… rfES1negveYfX9TpV8tapBvye8a52pXBHG 10,000,000 0
After some time the balance (drops) will become 10,000.
Where does this come from (is this a claim)? I understand when we start moneyd the outgoing channel is created with an amount of 10. Does this 10 somehow translate to 10,000 and if that is the case - what’s the logic behind? And after some more time balance (drops) will jump to 20,000.
When transferring between two connectors using SPSP server the following happens - we don’t quite understand. Running moneyd-gui.
a) before sending the payment
Connector1 has balance parent 10000000; local 0
Connector2 has balance parent 10000000; local 0
b) I start SPSP server Connector1 and I acquire payment pointer
c) Initiate payment from Connector 2 to my payment pointer of the amount 1000000
d) Connector1 has balance parent 10000000 (slightly lower as I assume somekind of fee is applied?); local -1000000
Connector2 has balance parent 9000000; local 1000000
Why does one connector go to minus? And is there somekind of fee? Also running info or topup changes balance (drops) in the manner we don’t understand? Could someone clarify?
Yeah, the channel is from you to the parent connector. The clientChannel is created by the parent connector so they can send money to you.
Rippled lets you query for channels an account has opened (account_channels), but doesn’t have a simple command to query for channels that are opened to an account. After you’ve stopped your channel the parent connector can no longer receive settlements from you, so they will no longer forward packets for you. In the future it’d be nice to be able to delete and then recreate a channel without reconfiguring, but it makes the number of possible states much harder to manage.
destination is the account that the payment channel is opened to. When you sign a claim, that’s who the money is for. amount (drops) is the size of the channel. This is the largest claim you can sign before you need to add more funds. (drops) means it’s denominated in XRP drops (1 drop is 1 millionth of an XRP). balance (drops) is the value of the last claim that was submitted to the ledger. You can claim from a payment channel many times without closing, so this lets you track what was submitted last. If the balance is 1,000,000 drops and you sign a claim for 1,200,000 drops, then when it gets submitted 200,000 drops will be paid to destination. This article (https://developers.ripple.com/payment-channels.html) has more details on how Payment Channels work.
Moneyd uses 10,000 drops ~0.3 cents) to initially fund a small amount of bandwidth against its parent. So you’ll see that amount sent before you send any traffic. If you use the 10,000 drops or restart Moneyd it will fund 10,000 more, and so on. This amount is not correlated to the 10 XRP you put in your Payment Channel.
Depending on the parent connector you’re peered with, there may be a fee (likely <1%). When a connector sends packets to one of its peers, its balance to that peer goes down because it owes that peer money. When the balance to local goes negative, it basically means it sent money to something running on your machine (connected to that moneyd). On the sending connector it looks like your balance to the parent went down (because you sent money through the parent). On the connector that received the money the balance with the parent appears not to have changed, but that’s just because the parent sent a packet (raising your balance with the parent) but then immediately settled it by giving you a payment channel claim (bringing the balance back down to 10000000). The packet was forwarded by the receiving connector to an application connected to moneyd, bringing the local balance down to -1000000. Moneyd never settles the local peer because it’s just going to applications on your own machine.
I hope this makes things clearer, let me know if there’s any part I should elaborate on
Thank you very much for the answers. They were very helpful. May we ask a few more questions?
Why are claims being submitted to the ledger while the payment channel is still open? We noticed them in the logs. On the side of the receiver the on-ledger balance goes up, but no changes on the receiver channel. And who submits the claims (ultimate receiver of funds or connector)?
Can we set a different number of XRP for channel capacity or at the moment is only 10? It would be useful for our tests.
How do we initiate the trustline instead of a payment channel? Is it possible? We see great merit for our work in testing this.
And off the topic, when we run our SPSP servers to create payment pointers they crash almost instantly. When we started the experimentation this was not the case is something going on with SPSP service?
The claims are submitted so that you have access to funds as soon as possible. XRP ledger lets you claim out of a channel as many times as you want so it’s very cheap, even if you’re doing it every 10 seconds. The connector (i.e. your peer) is always the one who gets the claims. This is an important point: all settlement is always to your direct peer. settlement never occurs to a party who isn’t your direct peer. The Interledger layer just makes sure if I (the sender) get a fulfill and owe my peer more money, the receiver’s peer owes them more money too. The way that the receiver’s peer settles them that money isn’t ever my concern.
With Moneyd, your channel will automatically expand as you send more outgoing money, so there’s no need to have a larger channel. A smaller channel than 10 is not allowed to prevent a DoS attack (if your parent locks up more money than you, you could lock up all their liquidity easily).
If you’re talking about using a trustline on the XRP ledger to settle, then that currently hasn’t been implemented (of course if you wanted to implement it I would be happy to help; it would also be a great project for the upcoming ILP Summit if you can attend that). If you’re talking about a trustline in a more abstract sense, where two peers just trust each other, you could peer your connectors over ilp-plugin-btp. (this README https://github.com/interledgerjs/ilp-plugin-btp#use-as-a-data-channel-for-ilp describes the options to pass in to connect a btp client to a btp server).
Are your SPSP servers using localtunnel? Localtunnel is very spotty at times but it can be useful. If you run with --localtunnel false it should turn off localtunnel and then you can refer to your SPSP servers via their http://localhost:port urls.