* [bitcoindev] [BIP Proposal] Elliptic Curve Operations for Bitcoin Script @ 2025-08-25 0:50 Olaoluwa Osuntokun 2025-08-25 16:45 ` [bitcoindev] " jeremy 0 siblings, 1 reply; 3+ messages in thread From: Olaoluwa Osuntokun @ 2025-08-25 0:50 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 1379 bytes --] Hi y'all, I've just published a draft of a BIP to add Elliptic Curve operation op codes as a soft fork utilizing the existing Taproot infrastructure and current tap leaf version. My primary motivation is enabling the commutation of the top level Taproot output public key within Bitcoin Script. Alongside introspection enabling op codes, this enables the creation of a new flavor of on-chain state machine within Bitcoin Script. The set of op codes is also generic enough to enable several other use cases related to (optimized DLCs, partial musig2 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: * https://github.com/bitcoin/bips/pull/1945 A reference implementation in `btcd` can be found here: * https://github.com/btcsuite/btcd/pull/2413 --Laolu -- 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 email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs-Cwj%3D5vJgBfDqZGtvmoYPMrpKYFAYHRb_EqJ5i0PG0cA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 1887 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoindev] Re: [BIP Proposal] Elliptic Curve Operations for Bitcoin Script 2025-08-25 0:50 [bitcoindev] [BIP Proposal] Elliptic Curve Operations for Bitcoin Script Olaoluwa Osuntokun @ 2025-08-25 16:45 ` jeremy 2025-09-01 22:43 ` jeremy 0 siblings, 1 reply; 3+ messages in thread From: jeremy @ 2025-08-25 16:45 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 2966 bytes --] Interesting proposal and a great contrast of options v.s. OP_TWEAKADD. I have a few notes which might strengthen this proposal: I would suggest adding an operation *OP_EC_LIFT_X_EVEN* which "undos" OP_EC_POINT_X_COORD (not perfectly because of parity). This is helpful if OP_IKEY is used. I would also suggest adding *OP_EC_GENERATOR* which pushes G onto the stack, rather than taking a 0 to mean G. This is more composable, as 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 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 PM UTC-4 Olaoluwa Osuntokun wrote: > Hi y'all, > > I've just published a draft of a BIP to add Elliptic Curve operation op > codes > as a soft fork utilizing the existing Taproot infrastructure and current > tap > leaf version. > > My primary motivation is enabling the commutation of the top level Taproot > output public key within Bitcoin Script. Alongside introspection enabling > op > codes, this enables the creation of a new flavor of on-chain state machine > within Bitcoin Script. The set of op codes is also generic enough to enable > several other use cases related to (optimized DLCs, partial musig2 > 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: > * https://github.com/bitcoin/bips/pull/1945 > > A reference implementation in `btcd` can be found here: > * https://github.com/btcsuite/btcd/pull/2413 > > --Laolu > -- 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 email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f118d974-8fd5-42b8-9105-57e215d8a14an%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 4598 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoindev] Re: [BIP Proposal] Elliptic Curve Operations for Bitcoin Script 2025-08-25 16:45 ` [bitcoindev] " jeremy @ 2025-09-01 22:43 ` jeremy 0 siblings, 0 replies; 3+ messages in thread From: jeremy @ 2025-09-01 22:43 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 3825 bytes --] Noteworthy: <zidx> PICK <G> OP_EC_POINT_MUL <yIDX> PICK <xidx> PICK <G> OP_EC_POINT_MUL OP_EC_POINT_MUL OP_EQUALVERIFY gives the ability to do "naked" field multiplication, in addition to the intended EC_MUL. Same with addition, and divide by a constant (AFAIU, via mul by inv), and any other prime field arithmetic tricks... Therefore it may make sense to add to this proposal the raw field arithmetic opcodes (and perhaps u256 arith generally), as they are there somewhat implicitly otherwise. As a distillable engineering principle/aphorism: what you enable, that might be used commonly, should be enabled efficiently. Cheers, Jeremy On Monday, August 25, 2025 at 10:13:35 PM UTC-4 jeremy wrote: > Interesting proposal and a great contrast of options v.s. OP_TWEAKADD. I > have a few notes which might strengthen this proposal: > > > I would suggest adding an operation *OP_EC_LIFT_X_EVEN* which "undos" > OP_EC_POINT_X_COORD (not perfectly because of parity). This is helpful if > OP_IKEY is used. > > I would also suggest adding *OP_EC_GENERATOR* which pushes G onto the > stack, rather than taking a 0 to mean G. This is more composable, as > 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 > 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 PM UTC-4 Olaoluwa Osuntokun wrote: > >> Hi y'all, >> >> I've just published a draft of a BIP to add Elliptic Curve operation op >> codes >> as a soft fork utilizing the existing Taproot infrastructure and current >> tap >> leaf version. >> >> My primary motivation is enabling the commutation of the top level Taproot >> output public key within Bitcoin Script. Alongside introspection enabling >> op >> codes, this enables the creation of a new flavor of on-chain state machine >> within Bitcoin Script. The set of op codes is also generic enough to >> enable >> several other use cases related to (optimized DLCs, partial musig2 >> 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: >> * https://github.com/bitcoin/bips/pull/1945 >> >> A reference implementation in `btcd` can be found here: >> * https://github.com/btcsuite/btcd/pull/2413 >> >> --Laolu >> > -- 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 email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1c2539ba-d937-4a0f-b50a-5b16809322a8n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 5665 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-09-01 23:15 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-08-25 0:50 [bitcoindev] [BIP Proposal] Elliptic Curve Operations for Bitcoin Script Olaoluwa Osuntokun 2025-08-25 16:45 ` [bitcoindev] " jeremy 2025-09-01 22:43 ` jeremy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox