> OP_MUL and OP_MOD are disabled opcodes - you can't use them in scripts because their evaluation by the interpreter will abort the script immediately and cause permanent fund loss.

Yes, I pointed that out in the post

> You are talking about Stealth addresses generated by C = (G*a)+B and C = (G*b) + A formulas, right? You don't need fancy scripts to spend to them - they are regular public keys which can be hashed into a Legacy, SegWit, or taproot address, or any other future address, and their respecive scripts can be used.

To be sincere, I didn't know about stealth addresses when I first came up with this scheme, only knew about them later. I don't know about those formulas you mentioned;
can you please suggest me some reading?

Also, as far as I know, the Legacy, SegWit and Taproot address formats do not provide the level of privacy suggested by the scheme. For example, if Alice publishes her Legacy/SegWit address on the internet to receive, i.e, donations, them everyone can see how much Alice has got by checking the public address on the timechain. On the other hand, in the scheme I suggested, the sender Bob does not use an address to send Bitcoin to, rather it generates a random nonce that nobody else knows, thus obfuscating the fact he sent the Bitcoin to Alice. Not only that, when Alice goes spend that Bitcoin, she does not reveal that it is she who is spending the Bitcoin. Please correct if I'm wrong, but from what I have studied it is not possible to achieve this level of privacy with legacy, segwit or taproot.

> Since adding OP_MUL and OP_MOD  OP codes anyway requires conducting a hardfork, it would be better to implement more sophisticated privacy-enhancing tools like ring signatures, confidential transactions, or anything else that hides senders and receivers and the amount transferred. But if it could be possible to hardfork bitcoin every time there is a "useful" update or interesting method to improve on-chain privacy, bitcoin would be no better than Ethereum, which is already almost taken over by large corporations and governments.

I agree with you. A hardfork is not an option. The immutability of the protocol is more desirable than rich features, even privacy features. However, if we can improve Bitcoin without causing hardforks, without introducing vulnerabilities, without compromising decentralization, then we should strive to do so.

> I see another problem with this scheme - the script size in bytes is too large. I'm counting two 64-byte pushes (n and k) along with some half-dozen opcodes - that's approximately 130 bytes of script size. This is multiple times larger than standard script types (P2[W]PKH is about 23 bytes, and P2[W]SH has an almost equal byte size). Inputs like these will fill up the block size limit very quickly, because you are basically reducing the number of transactions in a block by a factor of 6 if everyone goes on to use Stealth addresses which of course won't happen, so the reduction will be less but still significant - think a 2x or 3x reduction in transactions-per-block.

This is true, specially because in the draft I used RSA encryption, but there are nowadays encryption standards that allow shorter and more secure encryption and signatures schemes. My goals was to show a proof of concept; some real solution needs to be practical (i.e, fewer bytes, secure enough)

> Thanks for sharing. Maybe I'm missing something, but other than implementation challenges, I suspect this scheme is vulnerable to miner theft as once it goes to the mempool, miners can take it and replace the output with theirs. It is because the transaction is not signed, hence forgery is not prohibited.

That's true. Thanks for pointing that out. I didn't realize that... I thought the scheme was pretty useful because allowed one-time address to be generated by the sender on the fly, but now I see the scheme is useless since anybody monitoring the mempool can forge the script. I will see if I can come up with something to tackle that