[Lightning-dev] Decker&Wattenhofer channels

Anthony Towns aj at erisian.com.au
Sat Sep 19 02:30:33 UTC 2015


On 19 September 2015 10:14:52 am AEST, Andrew Miller <amiller at cs.umd.edu> wrote:
>Are there any downsides of the alternative proposed in this paper?
>There
>was a discussion on Bitcoin subreddit but it got derailed
>https://m.reddit.com/r/compscipapers/comments/3at959/a_fast_and_scalable_payment_network_with_bitcoin/


The main difference between this and the lightning paper seems to be using timelocks to guarantee revocability rather than a key/hash scheme. To me Rusty's hash scheme seems fine, so I don't see the point.

Drawbacks to this scheme afaics are that it requires stronger malleability fixes than are likely anytime soon, and it sets a decreasing timelock on the channel, so the channel starts with a deadline then progressively reduces it. That time lock needs to be both large to give the channel as long a lifetime as possible, but also small because every HTLC on the channel has to have a larger timelock on the refund side. I think that greatly limits the lifetime of a channel compared to relative lock time lightning channels. (The refresh operation hits the block chain, so is effectively opening a new channel IMO)

If the chained revocation secrets turn out to be insecure or too heavyweight, this seems worth looking into further, but otherwise not afaics.

Setting Delta T to 1 hour seems bogus, but I don't think that had any effect on the rest of the proposal.

For reference, I think the reddit comment thread was 

https://www.reddit.com/r/Bitcoin/comments/3aohkv/olaoluwa_osuntokun_on_twitter_a_simpler/

Cheers,
aj
-- 
Sent from my phone.


More information about the Lightning-dev mailing list