ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-13 📝 Original message: Good morning Nadav, and ...

📅 Original date posted:2021-02-13
📝 Original message:
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 && B) || (A && !B)
>
> If we have any complicated Boolean logic, we can consider to always use some kind of product-of-sums form.
> So for the example case, escrow service is the logic:
>
> SELLER && (BUYER || ESCROW)
>
> The above is a standard product-of-sums form.
>
> Any sums (i.e. `||`) can be converted by De Morgan Theorem to product, and the payment can be a reversal instead.
>
> SELLER && !(!BUYER && !ESCROW)
>
> 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..
>
> For example, a simple DLC binary oracle can provide two points in such a way that it can only reveal one scalar of those two points (e.g. it has a persistent public key `P`, and two temporary points `H` and `T` such that `H = T + P`, and it can only safely reveal either `h` or `t`.).
> Based on the outcome of a coin flip (or other input from the mythical "real world"), it reveals either one or the other scalar.
> Then we can use either point as part of any `!Oracle` or `Oracle` Boolean logic we need.



Okay, so here is a worked example.

Suppose we have two oracles, 1 and 2.
At some point, they will flip coins in the future.
Based on their (independent) coin flip, oracle 1 will reveal either H1 or T1, and oracle 2 will reveal either H2 or T2.

Suppose some bettor wants to make some bet:

* Either both coins are heads (H1 && H2), or both coins are tails (T1 && T2).

So we have a Bettor, and a Bookie that facilitates this bet.

So the base logic is that the bettor wins (i.e. there is a payment Bookie->Bettor) if:

(H1 && H2) || (T1 && T2)

And the inverse of that logic (Better->Bookie) if the above is false.

We also know that `T1 = !H1` and `T2 = !H2` (i.e. the DLC oracles will only publish one scalar or the other), so:

(H1 && H2) || (!H1 && !H2)

Let us transform to product-of-sums (this can be done by computers by using a Karnaugh Map):

(H1 || !H2) && (!H1 || H2)

Let us check by Boolean table:

H1 H2 (H1 && H2) || (!H2 && !H2) (H1 || !H2) && (!H1 || H2)
0 0 1 1
0 1 0 0
1 0 0 0
1 1 1 1

So the above product-of-sums is correct.

We apply the De Morgan transform:

!(!H1 && H2) && !(H1 && !H2)

Then we return the `T`s:

!(T1 && H2) && !(H1 && T2)

Since the logic is inverted, what actually happens is that the Bettor makes two payments:

* Bettor->Bookie : (Bookie && T1 && H2)
* Bettor->Bookie : (Bookie && H1 && T2)

The Bookie would also need to pay out if the Bettor wins, so the Bookie makes two payments as well:

* Bookie->Bettor : (Bettor && T1 && T2)
* Bookie->Bettor : (Bettor && H1 && H2)

We can derive the above by inverting the initial `(H1 && H2) || (!H1 && !H2)` logic, then going through the same conversion to product-of-sums and De Morganizing it as for the Bettor case.

With the above, we now have a setup where either both oracles are heads, or both oracles are tails, and if so the Bettor wins, otherwise the Bookie wins.
This all probably needs to be set up with some kind of Barrier Escrow, but Nadav already has that covered.

Here is a cute magical trick.
What happens if for example oracle 1 has a failure where the CPU liquid cooler on its server fails, and oracle 1 is unable to find a replacement CPU cooler because the CPU socket has been obsoleted and nobody makes CPU coolers for that CPU socket anymore and the server cannot be brought up again?
In that case, it will be unable to publish either `H1` or `T1`.

And note that all the payments above involve `H1` or `T1`.
In that case, nobody pays out to anyone, as none of the payments are ever claimable.
Thus the case where "oracle disappears" is handled "gracefully" by simply not having any monetary transfers at all.
This seems to be a reasonable "fail safe" default to have when one of the oracles disappears without publishing the result of the coin toss.


Regards,
ZmnSCPxj