Hello, While reading this thread I realized that my colleagues and I have been working on a construction called “Bitcoin-compatible Virtual Channels” [1] that, at a first glance, highly resembles the use case and requirements that you put forward in this thread. In a nutshell, a Virtual Channel is built on top of two payment channels and use them to construct its own “funding transaction”. Imagine that Buyer and Seller do not have a payment channel between them, but they both have a payment channel with a common node (e.g., Escrow in your example). Alice and Bob can create a Virtual Channel between them using fundings from both: channel Alice-Escrow and channel Escrow-Bob. After created, the Virtual Channel offers the same functionality as a direct payment channel between Alice and Bob (i.e., Escrow is no longer involved for payments). Our construction makes sure that no party losses funds when the Virtual Channel needs to be closed (either when Alice and Bob collaborate or any of the 3 parties cheat).
This construction is compatible with the current Bitcoin script (e.g., taproot is not required although perhaps useful when available) and with the Lightning Network. In the paper, we describe our construction assuming that a payment-channel follows the design in “Generalized Bitcoin-Compatible Channels” [2], however the Virtual Channel construction can seamlessly work using the current Lightning payment channels. I would be glad to hear any feedback that you may have. Cheers, Pedro Moreno-Sanchez == [1] https://eprint.iacr.org/2020/554 [2] https://eprint.iacr.org/2020/476.pdf > On Feb 8, 2021, at 9:09 AM, Andrés G. Aragoneses <kno...@gmail.com> wrote: > > Hey ZmnSCPxj, > > Am I correct in understanding that this is a proposal to change the spec > (maybe add a new BOLT) so that all lightning implementations can try to > support this feature. > > If the above is true, then I'm wondering: could a Lightning-based escrow > system be implemented that doesn't require to modify the existing > implementations? Maybe if we simplify the requirements a bit? Like, removing > the "Escrow only learns of dispute cases, never learns non-dispute case" > aspect? That is, the third-party S always knows about an escrow between A and > B taking place. > > I understand that the above requirement is a good to have, but if removing it > allows a simpler version of escrow be implemented, then at least there could > be an interim solution for non-custodial exchanges to start adopting this > (otherwise they have to resort to custodial-based escrows, which is worse > than lacking the escrow privacy brought by the requirement above). > > Thanks > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
