From rusty at rustcorp.com.au Sat Jul 25 05:04:46 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Sat, 25 Jul 2015 14:34:46 +0930 Subject: [Lightning-dev] Thoughts on HTLC Scripts In-Reply-To: References: Message-ID: <87zj2kq13l.fsf@rustcorp.com.au> Mats Jerratsch writes: > Hey everybody, > > I'm currently working on a Lightning Implementation Client/Server in > Java, building on bitcoinj (just as a basic framework, I wrote my own > classes to realize LN). Will push it into GitHub within a few weeks I > guess. Hi Mats! Awesome, I look forward to brushing up my Java skills :) > I had an implementation ready, that would not need any further changes > for bitcoin (works today already), but I just threw it all off the > ship, reading through your paper. It was based on some trust > dependencies and channel transactions were highly asynchronous, > meaning that a LN-Network would not be possible (since one party will > always be assumed lower trust and therefore has a disadvantage in > enforcing the ruleset). I can share further details if there is any > interest (it further needed to exchange 3 transactions for each > payment in the channel, building up huge amount of data within a few > hundred payments....) > > First I wanted to write up my solution for the anchor problem, but > then I realized, your solution makes it possible to have channels open > indefinitely, while mine doesn't. And while it really looks fishy, > indefinite channels are really worth it. However, it is important to > wait for the anchor tx of the other party. Otherwise the server has to > pay transaction fees for releasing his funds again and again (which > can really add up..). Yes, there's a delay waiting for the anchor(s) to be buried deep enough to be considered irrevocable. Also, if the anchors change, there's a while where commitment txs need to be maintained for both the old and new anchors. > While implementing the new redeemscripts, I noticed there is no delay > for the 'HTLC Receiver Redeemscript', when redeeming the contract > using R. Doesn't this mean that revoked or not, if the receiver has R, > he can instantly claim these outputs. Let's assume a channel with 4 > states: Which paper are you reading? The LN draft at lightning.network, or the implementation paper at https://github.com/ElementsProject/lightning/tree/master/doc? The rule is simple: any output condition which pays to "self" must be delayed (so A's HTLC output to A must be delayed, similarly B's HTLC output to B). I didn't spell out all the cases in Figure 9, nor even in the Appendix. I probably should, to make it clear... > Really good work though, although I just had to delete and rewrite a > good share of my work. ;) I know that feeling! I just rewrote my test-cli utils to support dual anchors... Cheers, Rusty.