# Emulating curve point scalar multiplication with OP\_CAT

**URL:** <https://delvingbitcoin.org/t/emulating-curve-point-scalar-multiplication-with-op-cat/370>\
**Category:** Protocol Design\
**Tags:** softfork\
**Created:** [January 6, 2024, 4:42pm UTC](https://delvingbitcoin.org/t/emulating-curve-point-scalar-multiplication-with-op-cat/370 "2024-01-06T16:42:13Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![RobinLinus](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/robinlinus/32/130_2.png) [@RobinLinus](https://delvingbitcoin.org/u/RobinLinus)\
**Post date:** [January 8, 2024, 3:14am UTC](https://delvingbitcoin.org/t/emulating-curve-point-scalar-multiplication-with-op-cat/370/3 "2024-01-08T03:14:02Z")

</div>

Not sure I understand you correctly. This procedure should enforce the message to be the

> [@ajtowns](#):
>
> tx msg hash used by the CHECKSIG operation.

- In step1 it is obviously the case.
- In step2 m=z is enforced with Andrew’s CAT trick. It can be used as a primitive to push the sighash digest onto the stack. (Of course, you have to check here that the signature is exactly 64 bytes, implicitly enforcing SIGHASH\_ALL.)

I don’t see how your attack breaks that.

* * *

> [@ajtowns](#):
>
> If you’re introducing a new secp256k1-specific 256 bit opcode `op_secp256k1_scalar_sub`

That’s a misunderstanding. I do not want to introduce any opcode.

My main point is that OP\_CAT can reduce scalar multiplication for _curve points_ to a single subtraction of _field elements_. That in itself is an interesting result.

Furthermore, I estimate that (given CAT) we probably can already implement subtraction of field elements in less than 250 opcodes. Definitely seems to be trivially possible when using kilobytes of Script. That’s why I thought it’s fair to assume `op_secp256k1_scalar_sub` as given, to then show the main point.

---

_[View the full topic](https://delvingbitcoin.org/t/emulating-curve-point-scalar-multiplication-with-op-cat/370)._