Quote from: franky1 on March 10, 2024, 03:56:23 PM

your title suggests adding message to a transaction
.. yet its hidden in the key thus never appears in the blockchain as extra meta data..

you then said its related to any keypair that use ECC of secp256k1 type,
..yet then you tell me its done after the ECC, to the public key not private

so it was about clarifying your description,
i dont doubt your knowledge it was more of a poke at your description

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.