[dlc-dev] Succinct order relations for DLCs

[Lloyd Fournier]

Hey Linus,

Thanks for putting that gist together.

I think your approach for "Greater than" is interesting. The performance
benefit is that you do less additions (although these are very fast).
It implies that the adaptor signatures must be produced asymmetrically
(Alice and Bob have different sets of adaptor signatures). This is already
the case with the current protocol so immediately applicable. But if we
were to use MuSig I think this would lead to extra multiplications (so a
performance decrease).

WIth your scheme that uses verifiable encryption -- that's indeed the
kicker. Verifiable encryption is computationally expensive especially when
you're doing thousands of them. There is another group of researchers
working on making it practical for DLCs.

If we assume we did have practical verifiable encryption, then there are a
number of ways of improving upon what you've suggested. For example, we
could use verifiable encryption to encrypt threshold secret shares to each
attestation point so that if any 3/5 oracles attests to an outcome that
signature can be reconstructed.

Your point about how NAND gates make it possible to map any boolean
function to a transaction is well taken and certainly an interesting point!

Cheers,

LL




On Sat, 5 Feb 2022 at 22:59, Robin Linus via dlc-dev <
dlc-dev at mailmanlists.org> wrote:

> Hi all,
>
> Here's a writeup on how to condense order relations into a single adaptor
> point. Key idea is to use verifiable encryption to express the logical
> disjunction of a set of points.
> https://gist.github.com/RobinLinus/7af908dafbed6319da251c90f0733a5b
>
> Best,
> Robin Linus
>
>
>
> dlc-dev mailing list
> dlc-dev at mailmanlists.org
> https://mailmanlists.org/mailman/listinfo/dlc-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20220218/371a4c29/attachment.htm>