public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream.com>
To: Jeremy <jlrubin@mit.edu>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
Date: Tue, 6 Jul 2021 14:21:33 -0400	[thread overview]
Message-ID: <CAMZUoKnhUoQGgpx_+keb_vpobKkaT2cbdZWib4oA+VytFwOsDA@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhhft7sKUS++LnS7-Fw37ovCioQWX3pV57JtTdDZ1MfzHg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

If the main outstanding issue is whether to split R or S, I think as far as
Elements goes, I am inclined to go with the CAT option regardless of
whether Bitcoin chooses to split R/S or not (not that I'm necessarily a
decision maker here).

The issue here is that (a) Elements already has CAT, and (b) updating
CHECKSIGFROMSTACK is effectively a blocking issue for deploying Taproot on
Elements.  I don't think we will be holding up CHECKSIGFROMSTACK for this
issue even if it risks being incompatible with an eventual Bitcoin
CHECKSIGFROMSTACK.

To be clear, I don't mean to prejudice this discussion by this statement.
This just happens to be what makes sense for the Elements project at this
time, and what makes sense for Elements may not necessarily make sense for
Bitcoin.

Of course, I think we should just go for CAT compatibility.  Otherwise we
are just going to have a proliferation of trusted CAT oracles paid for with
lightning by people wanting to perform CAT operations.

On Tue, Jul 6, 2021 at 1:55 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Re-threading Sanket's comment on split R value:
>
> I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We
>> would need to update the suggestion to BIP340, and add it to sigops budget.
>> I have no strong preference for splitting R and s values or variable-length
>> messages.
>>
>
> Back to my comment:
>
>
> I see a few options:
>
> 1) Making a new 64 byte PK standard which is (R, PK)
> 2) Splitting (R,S)
> 3) Different opcodes
> 4) CAT
>
> The drawback of option 1 is that it's designed to support only very
> specific use cases. The main drawback of splitting via option 2 is that you
> entail an extra push byte for every use. Option 3 wastes opcodes. CAT has
> the general drawbacks of CAT, but worth noting that CAT will likely
> eventually land making the splitting feature redundant.
>
>
> Before getting too in the weeds, it might be worth listing out interesting
> script fragments that people are aware of with split R/S so we can see how
> useful it might be?
>
> Use a specific R Value
> - <S> <M> || <R> SWAP <PK> CSFS
>
> Reuse arbitrary R for a specific M (pay to leak key)
> -  <R> <S1> <S2>  ||  DUP2 EQUAL NOT VERIFY 2 PICK SWAP <M> DUP TOALTSTACK
> CSFSV FROMALTSTACK CSFS
>
> Verify 2 different messages reuse the same R.
> - <S1> <R> <M1> <S2> <M2> ||  2 PICK EQUAL NOT VERIFY 3 PICK <PK> DUP
> TOALTSTACK CSFSV FROMALTSTACK CSFS
>
> Use a R Value signed by an oracle:
> - <S> <M> <S_oracle> <R_oracle> <R> || DUP TOALTSTACK <PK_oracle> CSFSV
> FROMALTSTACK SWAP <PK> CSFS
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6172 bytes --]

  reply	other threads:[~2021-07-06 18:21 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-03 16:31 [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin Jeremy
2021-07-03 17:50 ` Russell O'Connor
2021-07-03 18:30   ` Jeremy
2021-07-03 20:12     ` Russell O'Connor
2021-07-04 17:30       ` Jeremy
2021-07-04 19:03         ` Russell O'Connor
2021-07-06 17:54           ` Jeremy
2021-07-06 18:21             ` Russell O'Connor [this message]
2021-07-06 18:53               ` Jeremy
2021-07-04  1:13 ` David A. Harding
2021-07-04 18:39   ` Jeremy
2021-07-04 20:32     ` [bitcoin-dev] Unlimited covenants, was " David A. Harding
2021-07-04 20:50       ` Billy Tetrud
2021-07-05  0:50       ` ZmnSCPxj
2021-07-05  1:02         ` Russell O'Connor
2021-07-05  2:10           ` Russell O'Connor
2021-07-05  2:39             ` ZmnSCPxj
2021-07-05  5:04           ` Anthony Towns
2021-07-05 13:46             ` Matt Corallo
2021-07-05 13:51               ` Greg Sanders
2022-02-03  6:17               ` Anthony Towns
2021-07-05 17:20         ` Russell O'Connor
2021-07-06  6:25           ` Billy Tetrud
2021-07-06 10:20             ` Sanket Kanjalkar
2021-07-06 11:26             ` Russell O'Connor
2021-07-06 18:36               ` Jeremy
2021-07-07  4:26           ` ZmnSCPxj
2021-07-07  6:12             ` Billy Tetrud
2021-07-07 13:12             ` Russell O'Connor
2021-07-07 14:24               ` Russell O'Connor
2021-07-07 17:26                 ` Jeremy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMZUoKnhUoQGgpx_+keb_vpobKkaT2cbdZWib4oA+VytFwOsDA@mail.gmail.com \
    --to=roconnor@blockstream.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jlrubin@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox