Delivery-date: Mon, 01 Sep 2025 16:15:12 -0700
Sender: bitcoindev@googlegroups.com
Date: Mon, 1 Sep 2025 15:43:33 -0700 (PDT)
From: jeremy <jeremy.l.rubin@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <1c2539ba-d937-4a0f-b50a-5b16809322a8n@googlegroups.com>
In-Reply-To: <f118d974-8fd5-42b8-9105-57e215d8a14an@googlegroups.com>
References: <CAO3Pvs-Cwj=5vJgBfDqZGtvmoYPMrpKYFAYHRb_EqJ5i0PG0cA@mail.gmail.com>
 <f118d974-8fd5-42b8-9105-57e215d8a14an@googlegroups.com>
Subject: [bitcoindev] Re: [BIP Proposal] Elliptic Curve Operations for Bitcoin Script
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_19888_1831805090.1756766613602"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_19888_1831805090.1756766613602
Content-Type: multipart/alternative; 
	boundary="----=_Part_19889_521671807.1756766613602"

------=_Part_19889_521671807.1756766613602
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Noteworthy:

<zidx> PICK <G> OP_EC_POINT_MUL <yIDX> PICK <xidx> PICK <G> OP_EC_POINT_MUL=
=20
OP_EC_POINT_MUL OP_EQUALVERIFY gives the ability to do "naked" field=20
multiplication, in addition to the intended EC_MUL.

Same with addition, and divide by a constant (AFAIU, via mul by inv), and=
=20
any other prime field arithmetic tricks...

Therefore it may make sense to add to this proposal the raw field=20
arithmetic opcodes (and perhaps u256 arith generally), as they are there=20
somewhat implicitly otherwise.

As a distillable engineering principle/aphorism: what you enable, that=20
might be used commonly, should be enabled efficiently.

Cheers,

Jeremy

On Monday, August 25, 2025 at 10:13:35=E2=80=AFPM UTC-4 jeremy wrote:

> Interesting proposal and a great contrast of options v.s. OP_TWEAKADD. I=
=20
> have a few notes which might strengthen this proposal:
>
>
> I would suggest adding an operation *OP_EC_LIFT_X_EVEN* which "undos"=20
> OP_EC_POINT_X_COORD (not perfectly because of parity). This is helpful if=
=20
> OP_IKEY is used.
>
> I would also suggest adding *OP_EC_GENERATOR* which pushes G onto the=20
> stack, rather than taking a 0 to mean G. This is more composable, as=20
> presently you have:
>
>
> <x: [u8;32]> <y : Either<0, [u8;33]> OP_EC_POINT_MUL -> Either<0, [u8;33]=
>
>
> therefore scripts like:
>
> <blah> SHA256 <[0; 32]> <0> OP_EC_POINT_MUL OP_EC_POINT_MUL
>
> will return: h(blah) G
>
> rather than more straightforwardly carrying the point at infinity onwards=
.
>
> If you instead had OP_G:
>
> <blah> SHA256 <[0; 32]> OP_EC_GENERATOR OP_EC_POINT_MUL OP_EC_POINT_MUL
>
> will return: point at infinity
>
> then you'd get more correct multiplication chaining.
>
>
> This lets you implement OP_TWEAKADD as:
>
>
> <H> OP_EC_GENERATOR OP_EC_POINT_MUL OP_INTERNALKEY OP_EC_LIFT_X_EVEN=20
> OP_EC_POINT_ADD
> v.s.
> <H> OP_IKEY OP_TWEAKADD
>
>
>
> Note: The BIP incorrectly gives:
>
> <tweak> <empty_vector> OP_EC_POINT_MUL  # tweak*G (33-byte)
> <internal_key> OP_EC_POINT_ADD           # P + tweak*G (33-byte)
> OP_EC_POINT_X_COORD                      # Extract x-coordinate (32-byte)
>
> the internal key, as specified, must be lifted first before adding.
>
>
>
> On Sunday, August 24, 2025 at 8:52:36=E2=80=AFPM UTC-4 Olaoluwa Osuntokun=
 wrote:
>
>> Hi y'all,
>>
>> I've just published a draft of a BIP to add Elliptic Curve operation op=
=20
>> codes
>> as a soft fork utilizing the existing Taproot infrastructure and current=
=20
>> tap
>> leaf version.
>>
>> My primary motivation is enabling the commutation of the top level Tapro=
ot
>> output public key within Bitcoin Script. Alongside introspection enablin=
g=20
>> op
>> codes, this enables the creation of a new flavor of on-chain state machi=
ne
>> within Bitcoin Script. The set of op codes is also generic enough to=20
>> enable
>> several other use cases related to (optimized DLCs, partial musig2=20
>> signature
>> verification, EC based sigma protocols, etc).
>>
>> A total of 4 op codes are proposed (each allocated from the existing
>> OP_SUCCESS) range:
>>   * `OP_EC_POINT_ADD`
>>   * `OP_EC_POINT_MUL`
>>   * `OP_EC_POINT_NEGATE`
>>   * `OP_EC_POINT_X_COORD`
>>
>> The full BIP text can be found here:=20
>>  * https://github.com/bitcoin/bips/pull/1945
>>
>> A reference implementation in `btcd` can be found here:
>>   * https://github.com/btcsuite/btcd/pull/2413
>>
>> --Laolu
>>
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
1c2539ba-d937-4a0f-b50a-5b16809322a8n%40googlegroups.com.

------=_Part_19889_521671807.1756766613602
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Noteworthy:<div><br /></div><div>&lt;zidx&gt; PICK &lt;G&gt; OP_EC_POINT_MU=
L &lt;yIDX&gt; PICK &lt;xidx&gt; PICK &lt;G&gt; OP_EC_POINT_MUL OP_EC_POINT=
_MUL OP_EQUALVERIFY gives the ability to do "naked" field multiplication, i=
n addition to the intended EC_MUL.</div><div><br /></div><div>Same with add=
ition, and divide by a constant (AFAIU, via mul by inv), and any other prim=
e field arithmetic tricks...</div><div><br /></div><div>Therefore it may ma=
ke sense to add to this proposal the raw field arithmetic opcodes (and perh=
aps u256 arith generally), as they are there somewhat implicitly otherwise.=
</div><div><br /></div><div>As a distillable engineering principle/aphorism=
: what you enable, that might be used commonly, should be enabled efficient=
ly.</div><div><br /></div><div>Cheers,</div><div><br /></div><div>Jeremy<br=
 /><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_=
attr">On Monday, August 25, 2025 at 10:13:35=E2=80=AFPM UTC-4 jeremy wrote:=
<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Interesting =
proposal and a great contrast of options v.s. OP_TWEAKADD. I have a few not=
es which might strengthen this proposal:<div><br></div><div><br></div><div>=
I would suggest adding an operation <b>OP_EC_LIFT_X_EVEN</b> which &quot;un=
dos&quot; OP_EC_POINT_X_COORD (not perfectly because of parity). This is he=
lpful if OP_IKEY is used.</div><div><br></div><div>I would also suggest add=
ing <b>OP_EC_GENERATOR</b> which pushes G onto the stack, rather than takin=
g a 0 to mean G. This is more composable, as presently you have:</div><div>=
<br></div><br>&lt;x: [u8;32]&gt; &lt;y : Either&lt;0, [u8;33]&gt; OP_EC_POI=
NT_MUL -&gt; Either&lt;0, [u8;33]&gt;<div><br></div><div>therefore scripts =
like:</div><div><br></div><div>&lt;blah&gt; SHA256 &lt;[0; 32]&gt; &lt;0&gt=
; OP_EC_POINT_MUL OP_EC_POINT_MUL</div><div><br></div><div>will return: h(b=
lah) G</div><div><br></div><div>rather than more straightforwardly carrying=
 the point at infinity onwards.</div><div><br></div><div>If you instead had=
 OP_G:</div><div><br></div><div><div>&lt;blah&gt; SHA256 &lt;[0; 32]&gt; OP=
_EC_GENERATOR OP_EC_POINT_MUL OP_EC_POINT_MUL</div><div><br></div><div>will=
 return: point at infinity</div><div><br></div></div><div>then you&#39;d ge=
t more correct multiplication chaining.</div><div><br></div><div><br></div>=
<div>This lets you implement OP_TWEAKADD as:</div><br><br>&lt;H&gt; OP_EC_G=
ENERATOR OP_EC_POINT_MUL OP_INTERNALKEY OP_EC_LIFT_X_EVEN OP_EC_POINT_ADD<d=
iv>v.s.</div><div>&lt;H&gt; OP_IKEY OP_TWEAKADD</div><div><br></div><div><b=
r></div><div><br></div><div>Note: The BIP incorrectly gives:</div><div><br>=
</div><div>&lt;tweak&gt; &lt;empty_vector&gt; OP_EC_POINT_MUL =C2=A0# tweak=
*G (33-byte)<br>&lt;internal_key&gt; OP_EC_POINT_ADD =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 # P + tweak*G (33-byte)<br>OP_EC_POINT_X_COORD =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# Extract x-c=
oordinate (32-byte)</div><div><br></div><div>the internal key, as specified=
, must be lifted first before adding.</div><div><br></div><div><br></div><d=
iv><br></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_at=
tr">On Sunday, August 24, 2025 at 8:52:36=E2=80=AFPM UTC-4 Olaoluwa Osuntok=
un wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr">Hi y&#39;all,<br><br>I&#39;ve just published a draft of a BIP to add E=
lliptic Curve operation op codes<br>as a soft fork utilizing the existing T=
aproot infrastructure and current tap<br>leaf version.<br><br>My primary mo=
tivation is enabling the commutation of the top level Taproot<br>output pub=
lic key within Bitcoin Script. Alongside introspection enabling op<br>codes=
, this enables the creation of a new flavor of on-chain state machine<br>wi=
thin Bitcoin Script. The set of op codes is also generic enough to enable<b=
r>several other use cases related to (optimized DLCs, partial musig2 signat=
ure<br>verification, EC based sigma protocols, etc).<br><br>A total of 4 op=
 codes are proposed (each allocated from the existing<br>OP_SUCCESS) range:=
<br>=C2=A0 * `OP_EC_POINT_ADD`<br>=C2=A0 * `OP_EC_POINT_MUL`<br>=C2=A0 * `O=
P_EC_POINT_NEGATE`<br>=C2=A0 * `OP_EC_POINT_X_COORD`<br><br>The full BIP te=
xt can be found here: <br>=C2=A0* <a href=3D"https://github.com/bitcoin/bip=
s/pull/1945" rel=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"htt=
ps://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin/bips/pul=
l/1945&amp;source=3Dgmail&amp;ust=3D1756852606279000&amp;usg=3DAOvVaw0A6vaH=
Nfzq1qr7fAcCSTWt">https://github.com/bitcoin/bips/pull/1945</a><br><br>A re=
ference implementation in `btcd` can be found here:<br>=C2=A0 * <a href=3D"=
https://github.com/btcsuite/btcd/pull/2413" rel=3D"nofollow" target=3D"_bla=
nk" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttp=
s://github.com/btcsuite/btcd/pull/2413&amp;source=3Dgmail&amp;ust=3D1756852=
606279000&amp;usg=3DAOvVaw0NLD3Tr_dyrqK6WMK37_TW">https://github.com/btcsui=
te/btcd/pull/2413</a><br><br>--Laolu<br></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/1c2539ba-d937-4a0f-b50a-5b16809322a8n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/1c2539ba-d937-4a0f-b50a-5b16809322a8n%40googlegroups.com</a>.<br />

------=_Part_19889_521671807.1756766613602--

------=_Part_19888_1831805090.1756766613602--