Couldn't it just be broken up into a bunch of small transactions instead? In the lightning network it would still get through pretty fast, and with arguably less risk (only the currently "active" small transaction is at risk of failing). When faced with a narrow data bus, up the frequency.
That would require closing the contract and paying mining fees. If mining fees go up substantially, then you end up paying a lot more. The point of Lightning is to rarely pay mining fees.
No it wouldn't. The whole point of a payment channel is that multiple payments can be made on it without submitting to the block chain. The only reason to do so would be if a party is uncooperative.
I was under the impression that payments could be made with credit already nLockTimed into the system so you wouldn't need to commit more money into it than is owed to you.
I get the feeling we're not on the same page here. Let me know if this scenario helps to answer your original question:
A has a channel with B and B has a channel with C, but A and C do not have a channel with each other. A wants to send 10 BTC to C through B but B only has a 1 BTC balance in his/her channel with C (his balance with A doesn't matter, since he will be pulling funds from him/her). For simplicity, we'll assume there are no fees between any of these parties. A creates a 1 BTC Hashed Timelock Contract (HTLC1) and passes it to B. B then creates a HTLC for 1 BTC (HTLC2) and passes it to C. C unlocks HTLC2 and pulls 1 BTC from B. This allows B to unlock HTLC1 and pull 1 BTC from A. The transfer of 1 BTC is now complete. Notice that B never has to commit more funds from outside his channels. His balance fluctuates between 0 and 1 BTC, finalizing back to its original 1 BTC. A, B and C now repeat the same procedure 9 more times. In the lightning network this can all happen in a matter of milliseconds.
Edited for clarity.
