[dlc-dev] Selling oracle signature via bitcoin on-chain payment

Nadav Kohen nadavk25 at gmail.com
Tue Mar 16 06:44:19 CET 2021


Hey Ichiro,

I think what you've laid out is generally right and was essentially what we
implemented on the April 2020 hackday here (though we weren't using
signature points, but this would only have been a couple extra steps to
compute them): https://youtu.be/w9o4v7Idjno

At a high level I would summarize as: PTLCs are first and foremost
*on-chain* constructs which just happen to be very useful when taken
off-chain (and you can always take on-chain contracts off-chain). One such
use is in either context to trustlessly sell Schnorr-like signatures.

I agree with most of your analysis of the trade-offs but would like to add
a few notes. First, I'd like to mention we can implement off-chain PTLCs
today just like we can on-chain ones, it is just more work (so still a
disadvantage just reworded). Second, I'd like to mention that although it
may be true that some amount of interaction between oracle and client is
required in either case, it is strictly much much worse for privacy
on-chain as you must reveal a UTXO you own whereas in LN no such thing must
happen, and all other communication in both cases can happen over TOR or
twitter or any other way in which the oracle does not learn anything about
the user. Furthermore, as such I think I would personally prefer using
HTLCs on the lightning network as is today to sell these signatures, using
something like LSAT or PAID APIs. I generally don't think the
truthfulness is a real issue because you already trust the oracle but if
users do want to mitigate this trust, simply ask the oracle to publish the
hash of the signature along with a relatively simple ZKP (such as a
bulletproof) showing that the hash corresponds to the signature (or more
likely the signature point). This amount of work to standardize this simple
ZKP is likely equivalent in magnitude to building a client and
bootstrapping networking for on-chain PTLC clients, and it has all the
advantages with essentially no disadvantages as far as I can tell.

All of that said, you can of course still do on-chain PTLCs and they likely
have many uses (such as in coin-swaps).

Best,
Nadav

On Mon, Mar 15, 2021 at 8:10 AM 桑原一郎 <kuwahara at cryptogarage.co.jp> wrote:

> Hi all,
>
>
> I was thinking about selling oracle's signature. Nadav’s article[1]
> explains oracle's signature can be sold on lightning payment based on PTLC,
> this idea is really cool.
>
> *I think we can also sell it on on-chain payment, so we don’t need to wait
> for PTLC on Lightning Network. *
>
> First I describe my understanding about selling signatures via Lightning
> payment, Please correct me if my understanding is wrong.
>
> Selling signatures via Lightning payment based on PTLC
>
>
> The following is the flow of transactions.
>
> -Contract preparation-
>
> 1. DLC users create CET and FundTx and broadcast FundTx
>
> -Contract maturity-
>
> 2. Oracle publishes a message *`m`* in public way (Note that oracle
> signature *`s`* is not published)
>
> 3. DLC users calculate valid signature point *`T`* from oracle message
> *`m`*
>
> 4. DLC users use *`T`* to execute Lightning payment (they lock their
> funds using *`T`*)
>
> 5. Payment is complete and DLC users get proof of payment (PoP). This PoP
> is the oracle signature *`s` **(Note that T=s*G)*
>
> I don’t describe PTLC protocol here but the point is oracle publishes the
> result(message *`m`*) in some public way and they sell the signature *`s`*
> via lightning payment, DLC users can calculate the valid signature point
> *`T`* from message *`m`* and they claim the oracle signature *`s`* via LN
> payment with signature point *T*.  *(Note that T=s*G)*
>
> *Selling signatures via bitcoin on-chain payment*
>
> I think we can do it on-chain by using Adaptor sig on ECDSA that Lloyd
> proposed[2].
>
> The transaction flow is as follows.
>
> -Contract preparation-
>
> 1. DLC user create CET and FundTx and broadcast FundTx
>
> -Contract maturity-
>
> 2. Oracle publishes a message *`m`* in some public way* (Note that oracle
> signature `**s` is not published)*
>
> 3. DLC user calculates valid signature point *`T`* from oracle message
>
> 4. DLC user ask oracle to get their public key and create 2 transaction
> and the adaptor signature as below* (please also check the attached image
> to get the overview of transactions)*
>
> Tx1:Input is user’s UTXO and outputs are multi-sig(oracle and user)
> address and user's change
>
> Tx2:Input is multi-sig(oracle and user) address and output is oracle's
> address
>
> Adaptor sig:User's adaptor sig on Tx2
>
> 5. The DLC user passes these transactions and the adaptor sig to oracle
> (then oracle verify those)
>
> 6. Oracle signs Tx1 and broadcasts it. After confirmation, oracle decrypts
> user's adaptor sig by using *`s`* and broadcasts Tx2 7. DLC user
> calculate oracle signatures *‘s’* from Tx2 (and then settle DLC)
>
>
> The analysis of selling signatures via on-chain payment
>
> This proposal basically has the following features, that is the same as
> PTLC payment.
>
> ・Getting signatures via on-chain payment is executed atomically
>
> ・Third party cannot get the signature from the blockchain information *(Note
> that user's adaptor signature is only known to oracle)*
>
> The inferior points compared to PTLC
>
> ・ On-chain fee (especially for numerical decomposition DLC)
>
>
> The advantages over PTLC
>
> ・We can implement it now
>
>
> And as a privacy aspect, this proposal is not good because users need to
> interact with oracle but I think via- LN PTLC payment also needs
> interaction between user and oracle. Please let me know your thoughts.
>
>
> Best,
>
> Ichiro
>
> [1] https://suredbits.com/payment-points-part-4-selling-signatures/
>
> [2]
> http://diyhpl.us/~bryan/papers2/bitcoin/One-time%20verifiably%20encrypted%20signatures%20AKA%20adaptor%20signatures%20-%202020.pdf
>
>
>
>
> 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/mailman/private/dlc-dev/attachments/20210316/70b958bc/attachment.htm>


More information about the dlc-dev mailing list