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 Joost,
> > Not quite up-to-speed back into this, but, I believe an issue with using
> > feerates rather than fixed fees is "what happens if a channel is forced
> > onchain"?
> >
> > Suppose after C offers the HTLC to D, the C-D channel, for any reason, is
> > forced onchain, and
Hi Antoine,
That said, routing nodes might still include the risk of hitting the chain
> in the computation of their `hodl_fee_rate` and the corresponding cost of
> having onchain timelocked funds.
>
Yes, that could be another reason to define `hodl_fee_rate` as a base fee
rate plus a component
Hi Joost,
Thanks for working on this and keeping raising awareness about channel
jamming.
> In this post I'd like to present a variation of bidirectional upfront
payments that uses a time-proportional hold fee rate to address the
limitation above. I also tried to come up with a system that aims
