Re: [Lightning-dev] Witness asymmetric payment channels

2020-10-07 Thread Lloyd Fournier
For those interested I've recently integrated the above refinements and tried to coherently package the whole idea together here: https://github.com/LLFourn/witness-asymmetric-channel The main difference is that the protocol now uses what I am calling "revocable signatures" as the main primitive.

Re: [Lightning-dev] Witness asymmetric payment channels

2020-09-01 Thread Lloyd Fournier
> Unfortunately, while thinking about the above statement I realised > there is worse storage complexity. > In order to punish a revoked commitment transaction efficiently you > need to extract the publication secret. > But in order to do that you need to keep around the encrypted > signature

Re: [Lightning-dev] Witness asymmetric payment channels

2020-08-31 Thread Lloyd Fournier
Hi Z, Thanks as usual for your thoughtful comments I agree with you that there is no improvement in complexity in the formal sense. I do believe it is an improvement in conceptual complexity. At least, I am able to keep all the moving parts in my head at the same time whereas I struggle

Re: [Lightning-dev] Witness asymmetric payment channels

2020-08-26 Thread ZmnSCPxj via Lightning-dev
Good morning LL, and other LNers... Since we want to upgrade to Decker-Russell-Osuntokun in the future anyway, we still need to solve this "simultaneous HTLC" problem. So here is another cut at this, without the token-passing: * Perform a coin toss whenever simultaneous HTLC offers occur. *

Re: [Lightning-dev] Witness asymmetric payment channels

2020-08-25 Thread ZmnSCPxj via Lightning-dev
Good morning Lloyd, I think this is excellent work overall. With that said... > - It is more elegant as there are half the number of possible transactions. > I > expect this will follow through to reduced implementation complexity and > maybe > make it easier to explain as well. I