Hi Andrés,
> 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.
Yes, the proposal relies on the use of PTLCs in place of HTLCs which is a
popular change that will (hopefully) be bro
(I have replied without changing the subject line byte mistake so I will reply
again. sorry for spamming)
> But I see the advantage of your idea. If a malicious credential server is
> able to identify you somehow at the point of payment then they might want
> to selectively steal your money whil
(I have replied without changing the subject line so I will reply
again. sorry for spamming)
> But I see the advantage of your idea. If a malicious credential server is
> able to identify you somehow at the point of payment then they might want
> to selectively steal your money while being honest
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
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
