Hey Christian,
Love this chain of thought! Back before I'd realized as ZmnSCPxj did that
we have a nice general NOT operation for a given point, I had a similar
thought on this thread
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002213.html
where we eventually figured
> The `!(a && b && ...)` can be converted to a reversal of the payment.
> The individual `!BUYER` is just the buyer choosing not to claim the
> seller->buyer direction, and the individual `!ESCROW` is just the
> escrow choosing not to reveal its temporary scalar for this payment.
> And any
Good morning Nadav, and list,
>
> More generally, all Boolean logic can be converted to one of two standard
> forms.
>
> - sum-of-products i.e. `||` over `&&`
> - product-of-sums i.e. `&&` over `||`
>
> For example an XOR can be converted to the sum-of-products form:
>
> A ^ B = (!A
Good morning Nadav, and list,
>
> More generally, all Boolean logic can be converted to one of two standard
> forms.
>
> - sum-of-products i.e. `||` over `&&`
> - product-of-sums i.e. `&&` over `||`
>
> For example an XOR can be converted to the sum-of-products form:
>
> A ^ B = (!A
Good morning Nadav,
> Hey ZmnSCPxj,
>
> Your earlier post about how to accomplish ORing points without verifiable
> encryption was super interesting.
>
> I think this contains a clever general NOT operation where you double the
> payment and use the point as a condition for the "cancellation
Hey ZmnSCPxj,
Your earlier post about how to accomplish ORing points without verifiable
encryption was super interesting.
I think this contains a clever general NOT operation where you double the
payment and use the point as a condition for the "cancellation payment."
This is actually very
Good morning Andres,
> > > Is there any disadvantage about using dual-hash HTLCs?
> > > Is it supported by the current LN spec?
> >
> > It is no supported by current LN spec, and PTLCs are overall superior (they
> > are equivalent to having any number of hashes, not just 2 that dual-hash
> >
Hey ZmnSCPxj,
On Fri, 12 Feb 2021 at 08:52, ZmnSCPxj wrote:
> Good morning Andres,
>
> > Hey ZmnSCPxj,
> >
> > On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj wrote:
> >
> > > Good morning Andres,
> > >
> > > > This looks cool but would hinder UX too much for certain scenarios:
> e.g. if the escrow in
Good morning Andres,
> Hey ZmnSCPxj,
>
> On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj wrote:
>
> > Good morning Andres,
> >
> > > This looks cool but would hinder UX too much for certain scenarios: e.g.
> > > if the escrow in place is part of a bitcoin exchange, then you require
> > > the bitcoin
> On Feb 11, 2021, at 6:31 AM, ZmnSCPxj wrote:
>
> Good morning Pedro,
>
>> Hi Nadav,
>>
>> You are right that the intermediary (i.e., Ingrid) needs to hold a certain
>> amount of coins to allow the virtual channel between Alice and Bob. Some
>> comments here:
>> - The protocol makes
Hey ZmnSCPxj,
On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj wrote:
> Good morning Andres,
>
> > This looks cool but would hinder UX too much for certain scenarios: e.g.
> if the escrow in place is part of a bitcoin exchange, then you require the
> bitcoin buyer to have bitcoin already, which makes it
Good morning Andres,
> This looks cool but would hinder UX too much for certain scenarios: e.g. if
> the escrow in place is part of a bitcoin exchange, then you require the
> bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new
> users (which could maybe only have fiat).
This looks cool but would hinder UX too much for certain scenarios: e.g. if
the escrow in place is part of a bitcoin exchange, then you require the
bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new
users (which could maybe only have fiat). Am I right?
So are you saying
Good morning Nadav and Andres,
Thank you for bringing up this topic again.
Let me provide a new twist to this old idea.
This is the entire logic of the contract to the seller:
SELLER && (BUYER || ESCROW)
Now, a big issue is that simple `&&` is trivial for PTLCs, it is the `||` which
is
Good morning Pedro,
> Hi Nadav,
>
> You are right that the intermediary (i.e., Ingrid) needs to hold a certain
> amount of coins to allow the virtual channel between Alice and Bob. Some
> comments here:
> - The protocol makes sure that Ingrid will get paid whatever fee she decides
> to charge
Hi Nadav,
You are right that the intermediary (i.e., Ingrid) needs to hold a certain
amount of coins to allow the virtual channel between Alice and Bob. Some
comments here:
- The protocol makes sure that Ingrid will get paid whatever fee she decides
to charge for the service of creating a
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
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
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
Good morning list,
One thing I am attempting to think through is some implementation of escrow
over Lightning.
A non-custodial onchain escrow protocol simply uses a 2-of-3 multisig amongst
the two participants and the escrow.
Such a contract (like any onchain-enforceable contract) can be
20 matches
Mail list logo
