From decker.christian at gmail.com  Sat Feb 27 10:02:29 2021
From: decker.christian at gmail.com (Christian Decker)
Date: Sat, 27 Feb 2021 11:02:29 +0100
Subject: [Lightning-dev] Escrow Over Lightning?
In-Reply-To: <gwQhus3cfLg3xavUQ22_64tZi0LTx_lXnIkXoJbz7C5zPO0Re4FZdEWJ6OUaCX_ZzSmocjc1knEmhIsCOPOCGo5qY6XXpNKCljNwOU62JZU=@protonmail.com>
References: <Pf4mKX21lqS2ZZz1ST7xlKSQ_Pt3E9HHqARQ-dqaBl9c_72u30v52tyZ4A62wq0XPtScXWIE-4J1d3aeh7umJKzeWze4lzB6CnSbiDupkkk=@protonmail.com>
 <825EEUgcuH2-nkbpWjxRIvqowD2W6moorCatcbnAIFKaXjOCRHHkFHcp3UaXt7aOlkF3WoZoMIfbbvJZgBkKvk263LasfXFJ345WRJywzZw=@protonmail.com>
 <CAGKT+VePO5XdZ=AQUtsGOqr8mBVNfQg7RkyBw19r4aT7mJ3w4Q@mail.gmail.com>
 <lh8LFefsrGsafnfNMdWCBeCj-0JDsbmE4Ce7Nt1EftdbGRfvuxvqTZ4HMbq6EPhONGatpRcq5sILb5TuKBUKewKYCWwDnDLjYF7-5qkrefA=@protonmail.com>
 <CAGKT+Vc+sjWd=f-JtS_CincnANkU=T=wR+bBTiWym+0kzkdKnQ@mail.gmail.com>
 <6d8QNfAwhsXdetXX64NXMD5Y-hjGaCtK40UIsJxoxb0CPjwJlSRZf6BfVDllCG9U70iJvxW2aBXyS6lMKztLffPXmcP5Xn7eMkpQiD2wtao=@protonmail.com>
 <CAGKT+VcP0jHnhL27umaAW9BSX8KMy8fd1m6vNotMhha+t-uyiw@mail.gmail.com>
 <FnNfuHwmpiJ52Q3hFbM32ADuQ4SCSnqXY5D5Dn-IzV_0nxz3n2hFtRp0UiUvzqxfKaBG2YiopqFS6wmMYyvtZ6hBjbA_aHcnsI7qwSMBWoc=@protonmail.com>
 <CALGTLwO3VMWDVrDbuoBZu7OKrtC-2U3jQZ-OhCdS62swj-WEag@mail.gmail.com>
 <gwQhus3cfLg3xavUQ22_64tZi0LTx_lXnIkXoJbz7C5zPO0Re4FZdEWJ6OUaCX_ZzSmocjc1knEmhIsCOPOCGo5qY6XXpNKCljNwOU62JZU=@protonmail.com>
Message-ID: <87lfb97rre.fsf@gmail.com>

> 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 products (i.e. `&&`) are trivially implemented in PTLCs as
> trivial scalar and point addition.
>
> So it may actually be possible to express *any* Boolean logic, by the
> use of reversal payments and "option not to release scalar", both of
> which implement the NOT gate needed for the above.  Boolean logic is a
> fairly powerful, non-Turing-complete, and consistent programming
> language, and if we can actually implement any kind of Boolean logic
> with a set of payments in various directions and Barrier Escrows we
> can enable some fairly complex use-cases..

This got me thinking about my first year logic course and functional
completeness [1], and it it trivial to prove that any boolean logic can
be expressed by this construction. We can trivially build a functionally
complete set by just constructing a NAND, a NOR, or {AND, NOT}, all of
which you've already done in your prior mails.

The resulting expressions may not be particularly nice, and result in a
multitude of payments going back and forth between the participants to
represent that logic, but it is possible. So the problem should now
simply be reduced to finding a minimal representation for a given
expression, which then minimizes the funds committed to a particular
instance of the expression.

Cheers,
Christian

[1] https://en.wikipedia.org/wiki/Functional_completeness