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

📅 Original date posted:2021-02-13
📝 Original message:
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 payment." This is actually very similar to something that is used in my PTLC DLC scheme where many payments are failed in most cases :) But nice to add it to the toolkit, especially as a way to not use ORs for the price of over-collateralization which is acceptable in many use cases.

Indeed, specifically this point of De Morgan Theorem transformation should probably be emphasized.

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.

>
> One comment to make though, is that this mechanism requires the atomic setup of multiple payments otherwise Seller -> Buyer will be set up after which Buyer may keep the free option and not set up the payment in return. Luckily with barrier escrows we can do atomic multi-payment setup to accomplish this!

For this particular use-case, I think it is safe to just use the order "Seller->Buyer, then Buyer->Seller" rather than add a barrier escrow.
Remember, the entire setup presumes that both Buyer and Seller can tr\*st the Escrow to resolve disputes, and the Seller->Buyer payment requires BUYER && ESCROW.
If the buyer never makes the Buyer->Seller payment presumably the Escrow will take that into consideration during dispute resolution and not release the ESCROW scalar to the Buyer.

And if the Buyer->Seller payment (which requires only SELLER scalar) is claimed "early" by the Seller before handing off the item, the Escrow is tr\*sted to consider this also (it is substantially the same as the Seller providing substandard goods) and release the ESCROW scalar.

Of course in the most general case above where we could potentially do any arbitrary logic it probably makes most sense to use a Barrier escrow as well to ensure atomicity of the setup.


Regards,
ZmnSCPxj