Quote

I don't think consensus is an issue.

It was, and it still is. Read about issues with DER encoding, that happened in the past, when it was needed to create stricter rules specifically for Bitcoin, to avoid signature malleability. Do you remember BIP-66? Better read it before touching OpenSSL, to not reintroduce the same bugs in your own code.

Quote

All the cryptographic functions used by Bitcoin are standardized, and if any implementation deviates from the standard, including Bitcoin's, I assume it will be fixed.

Every software has some bugs. There is always "one more not-yet-fixed bug" in any software you use.

Quote from: satoshi on June 17, 2010, 06:46:08 PM

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

In general, I think you can modify the original software, or use your own settings for your node, but you should be aware that every change can potentially harm you, if you will be the only user that introduced it. Long time ago I also thought about using only my own implementation, but the reality is that currently I send everything through two sources: my own implementation, because I like it, and Bitcoin Core, to double-check that everything works correctly. There are more bugs you can introduce than you can probably imagine before writing code. For example, even huge mining pools lost a lot of coins, because of miscounting sigops.

Quote

It would be a mistake for me to implement my own cryptographic functionality, so I must rely on others.

The easiest way to start is to clone the whole Bitcoin Core implementation, and modify only the part you want to change. In this way, you don't have to think about everything you don't care about. For example, if you want to grab all public keys, it is easier to attach to the place in code, where signatures are validated, than reinvent the wheel, and parse everything from scratch. Then, instead of checking "is it witness?", "is it taproot?", "is it unexecuted branch?", "is it compressed?", you can simply tell the computer "I want to dump all public keys", and you can reuse existing code, to not implement every single case from scratch in your own client.

Quote

I considered using bitcoin's secp256k1 library and I may still, but right now I am looking for a comprehensive solution.

If you want to cover everything, then use Bitcoin Core. In other case, you can for example be distracted by thinking "how to improve it" during implementing things from scratch, and then your implementation will no longer be "bugward-compatible". And this case is important, because if we wouldn't be forced to think about backward compatibility, then we could have P2PK as the only address type, enable Schnorr signatures there, attach MAST into that, and we could have one pubkey-based address type to rule everything. Or we could simply replace uint32 with uint64 for time, and no longer worry about crashing clients after 2038 (but of course, in practice maybe we will have rolling time modulo 2^32, or even modulo 2^31, because of "bugward-compatible-code", we will probably see those changes in 2035 or later, when someone will invent, how to deal with that).