Topic: Off-chain proof of commitment for Bob to pay Charlie before Alice pays Bob..? (Read 776 times)

Fantastic, thank you for all your help!

It doesn't have to be on-chain. The blockchain is only used in case of a dispute between the parties involved. In that example they say dave claims his payment by broadcasting a transaction on-chain and in doing so reveals the secret allowing bob to get paid too. But in practice dave would simply reveal the secret to bob off-chain and keep the payment channel open for future transactions.

Also you should read the official lightning docs section for HTLCs because it's a little more complicated than that in practice:

https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf

Thank you for that extremely helpful post!  Now my next question is, how do you do that off-chain.  The whole point of going from A to B to C to D is that they are all connected to each other via previously opened payment channels.  If you have to make a new address and thus a new payment channel which incorporates the hashed secret, then you have to make an on-chain transaction, and Alice might as well just open the channel directly with Dave, rather than going through Bob and Charlie.

The assumption here is that on-chain transactions are costly, and thus Alice greatly prefers to go through existing payment channels without needing to open another one.

So is there a way to use segwit to accomplish this with already opened channels?

I can require some information by having it be the solution to a separate input, and my own input is signed with SIGHASH_ALL locking that input requirement in... except that lightning channels require SIGHASH_NOINPUT.

What kind of payment channels are available where I can add a hash lock condition on an update to a pre-existing channel?

lightning wouldn't be very useful if this wasn't possible:

https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts

Now that segwit is locked in, I'm thinking about designing some topology on top of the current lnd software.

I imagine a wallet software where the wallet software company is a hub that has an arbitrarily large amount of funds to dedicate to being locked up in payment channels. So the user downloads a wallet, and whenever the user requests one of his addresses to be displayed for deposit or payment, he's actually shown a payment channel multisig.  He doesn't know or care about this, it's just how the wallet operates.

So the wallet is a spoke that connects to the hub run by the wallet software company, which also maintains very large (in value) payment channels to various other hubs run by exchanges and large merchants and such.

Now, our user wants to make a payment to some other user who is connected some hub somewhere else.  For example, Alice and Bob have a channel, Bob and Charlie have a channel, and Charlie and Dave have a channel.  So when Alice wants to pay Dave, Alice pays Bob who pays Charlie who pays Dave.  Bob and Charlie are hubs in this example, and Alice and Dave are users -- although it really doesn't matter.

My question is -- is there a way for Alice to be sure that Bob will pay Charlie and Charlie will pay Dave?  Alice only has a channel with Bob, so if she pays Bob, Bob can just keep the money.  How can Alice be assured that Bob will pay Charlie (and Charlie will pay Dave), and be sure those transactions are committed to before Alice makes the payment to Bob?

(All of this is presumably off-chain since every player is involved in a current open payment channel with each of his neighbors.)

Are there current solutions to this that I'm just not aware of, or is this a problem I need to figure out how to solve?