Wouldn’t it be easier and more consistent with ILP’s intent to go directly over to the ledger?
2 Likes
Hi Rawad, ILP uses lightning for Bitcoin transactions due to the slow settlement time and high cost of on ledger transactions for the Bitcoin network. Lightning enables connectors to more rapidly settle their balances and at a lower overall cost, making them better able to manage their credit risk.
2 Likes
That said, if someone built an integration using standard Bitcoin payment channels, that would work too. Alternatively, we could use a Lightning implementation to manage the payment channel state (no easy matter on Bitcoin because of fees, transaction times, and UTXO format) and only use it directly between peers (instead of leveraging Lightning’s own multi-hop capability).
3 Likes
Unfortunately, Bitcoin’s longer block time is not suitable for streaming payments. The settlement time would be dependent on multiple confirmations (roughly an hour), which might still be useful in some rare custodial cases.
The Lightning Network uses multi-hop routing which might not be desirable for connectors on ILP, but payment channels are required for faster settlement. It is possible to construct uni-directional payment channels on Bitcoin, and I suspect ILP connectors will use them over Lightning-style channels in some cases.
Some folks have discussed stripping Lightning-style channels to only handle the single-hop case.
2 Likes
I disagree with this (the way it’s phrased at least). The speed of an Interledger payment isn’t dependent on the speed of the settlement mechanism.
Even though Bitcoin takes an hour for 6 confirmations you can allow a credit limit with your peer equal to about an hours worth of traffic. That way by the time you’re reaching the limit of the counterparty risk your peer will accept, your settlement goes through and you can fire off another one.
Of course, high counterparty risk is less than ideal in many scenarios. And Bitcoin’s large fees make it expensive to settle very often. But between two parties with a business relationship, this might be the most practical way to transact Bitcoin using Interledger, even if they’re doing streaming payments.
4 Likes
Agreed with this. Just settle less often. I think adding another layer between ILP and the ledger (such as lightning) is redundant. ILP does what Lightning does. I have not done a full deep dive in lightning but I assume it requires some kind of deposit/credit between peers…
how are you measuring this in terms of time? (an hour worth of…)
I think that is fair, but Bitcoin is not being streamed, credit is. Settlement times can be adjusted with credit, but should not be done with untrusted entities. I think there is a lot of flexibility between raw transactions, credit, and Bitcoin Script that streaming payments can be achieved.
I was simply pointing out that settlement times without credit OR additional scripting seems impractical. I also didn’t see the other replies before I posted. 
That is false. Perhaps there is some overlap in their respective goals, but the structure of the two systems are fundamentally different. The main goal of Lightning is scalability, whereas Interledger is about value interoperability.
I don’t mean that lightning is a bad way to go about this, because it does allow us to abstract a lot of the really complicated payment channel stuff that we would otherwise do. I just don’t think that Bitcoin transactions on their own are totally unworkable for all cases.
Sorry, I should have explained that better. Here’s the hypothetical scenario I’m laying out:
- I’m processing 1 BTC/hour (let’s say I know this based on past history or based on the max throughput I’ll accept)
- My settlement mechanism (i.e. Bitcoin ledger) takes 1 hour to settle.
So with those parameters I need to choose how much to trust my peer for. Let’s say our balance starts at 0.
If I have <1 BTC of trust, then even if I start a settlement pre-emptively, by the time it goes through I’ll have hit the trust limit with my peer. If I hit the trust limit then I’ll have to stop sending more packets until my settlement goes through. Basically I’ll have downtime.
If I choose >1 BTC of trust, then I won’t hit my trust limit at the end of the hour (because I only process 1 BTC/hour), and my settlement will go through and the balance will be reset to 0.
Of course, in practice you don’t know these values so precisely (transaction time is variable and Interledger traffic is variable). But you can determine some sensible limits and configure your trust limit accordingly.
I did not mean it in the literal form. But I think you got the point. There is no need for lightning if you want to operate at scale.
I would agree that working with bitcoin, specifically bitcoinjs-lib, is a pain in the butt. utxo’s are what keep bitcoin stateless. I love the concept. We’ve developed libraries to do almost all the things you need from Bitcoin without having to worry about implementation, i.e. sign, verify, send, get status … abstracting the tx work underneath. I even put together this for funs: http://txproxy.io.
That said - so far I’m on the camp of NOT using lightning. I really think it’s redundant. I think developers and users would appreciate being closer to the ledger to minimize discrepancies between the actual state and the ledger state.
Furthermore, I don’t know how relevant bitcoin is to the overall usage of ILP. While I absolutely appreciate everything Bitcoin did, their core team is interested in maintaining the values of bitcoin as a constitution. I don’t think it will necessarily be part of the main usage for ILP. I’m thinking more of non-fungible assets down the road. like buying/selling a house using ILP and doing so within an atomic swap of money and the house.
There is a need for Lightning or similar payment channel implementation if you want to operate at scale without credit risk. There are other benefits and counter-party risks associated with different payment channel designs, but defaulting (pun unintended) to credit is not always feasible.
As I briefly mentioned earlier, payment channel designs that pipe into ILP can take many forms that predates the works of Lightning. If you want to see some examples of other smart contracts that can be implemented on Bitcoin, and possibly piped into ILP, check out some of the example Ivy contracts here.
In an attempt to minimize development overhead and maximize asset coverage, the Lightning plug-in serves its purpose quite well.
That is fair. I do not think the success of ILP is contingent upon the usage of Bitcoin on the network either, but it is a huge source of liquidity if we only consider the existing cryptocurrencies and their respective market capitalization. In the same way, I don’t care about the success of USD, but people will almost certainly see success when supporting USDT, USDC, TUSD, Dai, or what have you.
That’s not really the point though, right? It doesn’t matter if you don’t like X Currency, because ILP abstracts that away, and you receive Y Currency. That being said, I think there is a tremendous opportunity to be had for those who choose to support the most liquid assets early on.
I think this is still an area of open discussion, and if you deem it desirable, I would recommend reaching out to others working in this area to see how this goal can be achieved. It’s still early days for NFT maturity. Consider opening a separate topic for discussion on the forum (if there isn’t one) or submitting a PR to support NFTs.
1 Like