Thank you, Franky. I do appreciate the feedback and hopefully I can make it clearer in the title and in the body of the post what I'm doing.

Let me try to clarify these points more accurately:

The title was intended to highlight the aspect of embedding transactional information or conditions directly within the cryptographic process, without adding extra metadata on the blockchain.(I just couldn't come up with a title which wasn't overly wordy). This is achieved through what I've termed the KeyShift process, which indeed tweaks the public key based on a condition or message. As you rightly point out, the data isn't stored on the blockchain in the conventional sense. However, it can be proved to have been part of the address where the funds are sent. This is by design ofc, because I specifically wanted to avoid storing arbitrary data on chain.

Relation to ECC and secp256k1: The process I am using is deeply rooted in the principles of ECC, particularly with keys derived from the secp256k1 curve. The idea here is in the application on said keys(either public or private in any order) - performing a tweak on the public key derived from ECC operations. This allows for the creation of a new, unique address (public key) that incorporates the intended condition or message without altering the fundamental ECC process of generating keys. So while conventionally, the public key might not undergo further ECC operations, I do carry out further calculations within the ECC framework.

Clarification on Public vs. Private Keys: The confusion might stem from my attempt to explain the technical process in layman's terms( but I'm having a hard time to gauge how to get people to engage with content in general, and so this is my bad). To clarify, the KeyShift process involves tweaking the public key in a manner that is cryptographically linked to a specific message or condition. This tweak does not require any manipulation of the private key itself by external parties. Instead, it's the derivation of the new, tweaked public key that's influenced. The owner of the original private key(for which the original public key is tied to) can then generate a corresponding private key to access the funds or data, maintaining the integrity and security of the ECC framework. The above can obviously be reversed, as would be the case if you started with an existing private key. In that scenario, you can tweak the private key directly, and derive the tweaked public key. However the order doesn't have to be so. Any public key can be tweaked first, and it only later required( when looking to spend) that the private key(for the tweaked public key) would need to be created by manipulating the original private key counterpart to the earlier tweaked public key.


In any case, although the data isn't stored on chain in the conventional sense, it does act as a proof and/or mechanism to have this condition directly embedded into the transactional process.


I'm totally open to how to reword/rephrase the title on initial description. I'd appreciate any ideas you have on that.