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.

And this is how the tool works:

Hopefully, by including cryptographic process, it is clearer what I am doing:

If we say:
Original public key: PB
User B's private key: kB
Tweak (SHA-256 of message): t = SHA-256(M)
Tweaked public key: PB' = PB + T
Tweaked private key: kB' = kB + t


1: User B's Original Key pair ( which is created in the normal way on their own machine)
User B's public key, PB, comes from multiplying their private key, kB, with the elliptic curve's generator point, G: PB = kB * G.

2: User A Generates a new Address for User B
User A takes User B's public key(which is known to them), PB, and selects a message, M, for the tweak (like "Payment for something" or a nonce of some kind).
User A generates a tweak value, t, by hashing the message M using SHA-256, for example: t = SHA-256(M).
This tweak, t, is converted into a point on the curve by multiplying it with the generator point, G, to get T: T = t * G.
User A adds this point, T, to User B's original public key, PB, to get a new tweaked public key, PB': PB' = PB + T.
The tweaked public key, PB', now serves as User B's new address for receiving funds. User A, only ever came in contact with User B’s Public key.

3: User B Accesses the Funds
To spend the funds, User B needs the corresponding private key for PB', called kB'.( this is the one they generated or already had in step 1)
Since PB' is the result of adding PB and T (PB' = PB + T = kB * G + t * G = (kB + t) * G), User B can find kB' by adding the original private key, kB, to the tweak value, t: kB' = kB + t.
User B uses this tweaked private key, kB', to sign transactions from the new address.

At no point was there a shared private key, and therefore there would be no urgency for User B to move the funds from the generated address, because only User B has both the original private key, and the message(the tweak) required to to generate the private key for the tweaked public key in the first place.




Would love to get some advice, feedback or if anyone wants to try it out, let me know. I designed this to be a free tool, so I'm not trying to promote a business or anything like that.

Hey Franky

I wasn't explaining Keypairs, but how my system works. Your previous comment implied that I didn't know how ECC works, and I'm sure you can tell that's not true. It makes sense for me to include the full context to the post


I am not trying to be argumentative, but I believe I have included all the information, answered everyone's questions, and did so completely, and politely.


As I said, the tweaking doesn't need to take place on private keys initially, so I was simply clearing up that fact. I can start with a public key, and this would be the process if you were creating an address for someone else, rather than yourself. Therefore your comment above "you do know private key is pre ECC and Public key post"... in order to clarify.


"just your title, description and explainer didn't match each other of where you put the message"  - How so? A public key is used to derive an address, and therefor the message is part of the address, and can be validated against it?

Explaining complex subjects isn't a strong point of mine, but I think I've done an OK job of it, considering the article wasn't for a technical audience, and my follow up comments clear things up. Happy to take on any constructive criticisms or otherwise

Hopefully, by including cryptographic process, it is clearer what I am doing:

If we say:
Original public key: PB
User B's private key: kB
Tweak (SHA-256 of message): t = SHA-256(M)
Tweaked public key: PB' = PB + T
Tweaked private key: kB' = kB + t


1: User B's Original Key pair ( which is created in the normal way on their own machine)
User B's public key, PB, comes from multiplying their private key, kB, with the elliptic curve's generator point, G: PB = kB * G.

2: User A Generates a new Address for User B
User A takes User B's public key(which is known to them), PB, and selects a message, M, for the tweak (like "Payment for something" or a nonce of some kind).
User A generates a tweak value, t, by hashing the message M using SHA-256, for example: t = SHA-256(M).
This tweak, t, is converted into a point on the curve by multiplying it with the generator point, G, to get T: T = t * G.
User A adds this point, T, to User B's original public key, PB, to get a new tweaked public key, PB': PB' = PB + T.
The tweaked public key, PB', now serves as User B's new address for receiving funds. User A, only ever came in contact with User B’s Public key.

3: User B Accesses the Funds
To spend the funds, User B needs the corresponding private key for PB', called kB'.( this is the one they generated or already had in step 1)
Since PB' is the result of adding PB and T (PB' = PB + T = kB * G + t * G = (kB + t) * G), User B can find kB' by adding the original private key, kB, to the tweak value, t: kB' = kB + t.
User B uses this tweaked private key, kB', to sign transactions from the new address.

At no point was there a shared private key, and therefore there would be no urgency for User B to move the funds from the generated address, because only User B has both the original private key, and the message(the tweak) required to to generate the private key for the tweaked public key in the first place.

However as above, my wallet can then retrospectively match the private key with the newly generated public key. So the fact any user with my public key, can then create valid addresses for me, which I(and only I) can then generate the private key for, is the basis of most of what I am trying to explain. 

Yes, you're right about the sequence in ECC: we start with the private key and then generate the public key through ECC. Txtailor builds on this process by adding tweaks to enhance the system's privacy and security while adhering to ECC's core principles. This can be done on a public key in isolation( where the private key can be hidden.. unknown.. not shared... And thus creating a new address, which is accessible by only the user who's public key we tweaked... because only they have the corresponding original private key

There are absolutely no shared private keys in this process. I am sure my poor ability to explain myself isn't helping

No this is not correct. It does this with the public key... and therefore the other party most certainly does not need to have the private key!

I get you.  I guess, what I mean is that the core feature of the client I have here is applicable across any blockchain using compatible cryptographic methods (like secp256k1), not just Bitcoin(and this is a standout property, rather than the fact people embedded messages previously or not). Me defending it being different from Multi-sig doesn't make any sense.. because it does so completely differently. It doesn't require 2 addresses for one. I guess similarly, people could do a hash > address and include this as output in their tx too... But this still doesn't allow them to spend from the address ofc(similar to multisig).

Not discounting there were methods of achieving this before, nor that (when using native Taproot) features it wouldn't be better for a more seasoned user to provide tapscripts or similar conditions for this purpose too.

Thanks. On traditional multisig setups, it's important to note that Txtailor significantly diverges from these methods though.

Unlike multisig, which operates on the scripting or wallet level, Txtailor works directly with the cryptographic layer (layer 0) of blockchain protocols. This allows for a seamless application across any blockchain that uses the secp256k1 curve, not limited by the blockchain's scripting capabilities.

Dynamic Address Generation: The approach approach I've used isn't about static address combinations but dynamically generating addresses through key tweaking. This means the address for each transaction can be unique and created on-the-fly, enhancing privacy beyond what static multisig setups can achieve.

Efficiency and Broad Applicability: By not relying on the multisig structure, Txtailor avoids the added transaction complexity and costs associated with it. This efficiency is inherent and applicable across Bitcoin and other blockchains too( which may not use space saving techniques available via segwit)

Hey dzungmobile

Thanks for the feedback.. I would like to clarify several aspects of the Txtailor wallet client that may not have been fully apparent from the article.( note this is a project I've developed solo, not a company, and intended as a free tool for use by anyone)


1. Privacy is not compromised:

The core functionality of Txtailor involves embedding transaction purposes or authentication codes directly within transactions in a secure and private manner. Importantly, this information is not publicly available on the blockchain or visible to all in the way you might think. Instead, it is accessible only to the intended recipient who possesses the correct cryptographic key or information to decode it. In order to validate the message, you must know the message & original public key(and this would assume it was unencrypted). Other people would simply see an address, which ofc is a hashed public key with encoding. In that scenario I describe( where the tweak or message is unencrypted) the anyone supplied with the message and the public key can verify( deliberately so).. However, not if it is also encrypted.

2. Security and Encryption:

The transaction details are securely handled, leveraging cryptographic techniques to prevent unauthorized access. For instance, the tweak (message) can be communicated over secure channels, decided upon in person, or encrypted using the recipient's public key through schemes like ECIES (Elliptic Curve Integrated Encryption Scheme) and send via  encrypted email or such. Furthermore, I've implemented homomorphic encryption, allowing certain operations to be performed on encrypted data for more niche use cases I have been working on. This means that even while the data is encrypted, it retains its utility without compromising privacy.

3. Utility of Added Information in Transactions:

Adding specific information to transactions, such as a purpose or auth code, is not about sacrificing privacy. Instead, it's about enhancing the utility and security of standard transactions, especially in contexts where additional verification or context is necessary. This could be particularly beneficial in scenarios like legal contracts, detailed financial transactions, or any situation where added clarity and authentication are crucial. The funds are not spendable by the recipient until they are also in possession of this message/auth code(the tweak). Anyone who gained access to the tweak, would have no ability to sign from the address, without also having the recipients private key.

4. Cold Addresses and Enhanced Security:

The concept of cold addresses (or storage) is elevated through Txtailor by allowing the dynamic creation of addresses that are secure until the moment they are needed. By using a tweak to generate these addresses, the corresponding private key does not exist until its intended use. This greatly reduces the risk of key compromise, as there's no static key to steal or lose. It combines the security benefits of cold storage with the flexibility of dynamic access, tailored to the user's needs. If the original private key( akin to the root in a standard HD wallet, which does not using tweaking) is compromised, this alone is not able to spend the funds.

5. Flexible IRT Secure Communication of Tweaks:

I absolutely recognize the importance of flexibility in how transaction-related information is communicated(and this is something totally open at the moment). Whether the tweak is sent over encrypted messaging services, decided in person, or through cryptographic encryption methods like ECIES, the priority is always on maintaining the utmost level of security and privacy. The advanced implementation of homomorphic encryption further ensures that the utility of this data is not lost, even when it is encrypted, allowing for secure operations that respect user privacy.

The ability to create any number of new address on behalf of a user( i.e with only the public key, from a known spent tx or other), where the recipient can only access the funds when also supplied with an offchain message can be pretty powerful. Normally, doing this wouldn't be possible, because any alteration to the public key or the hashed version, would invalidate it. Using this method, the private key which corresponds to the public key, can similarly be altered, and access this valid address. Traditional HD wallets, first start with a private key seed, and you'd need to know the private key to create an address on behalf of another user.

If we focus on this from your own perspective(i.e generating addresses for yourself).... if the addresses are generated using nonces, rather than hashes of known messages, timestamps,  or other, then you would effectively be creating random addresses similar to an HD wallet. However unlike an HD wallet, you can do this with just a public key, which means it can be done on a machine which has no access to the private key.


Worth mentioning that this can also be used for encryption, rather than signing ofc. In that, the properties are the same, albeit the message is required( as well as  the recipients private key) before the content can be decrypted. It's like a  type of cryptographic MFA.

This is a solo project, which is fully intended to become a free opensource tool. I am simply trying to validate the usefulness and get feedback on it, so I can make improvements, and (hopefully) share with people interested to try  it out or work on it with me.

Gotcha! In effect then, this offchain protocol is really the one which will check a utxo back to it's coinbase tx. For in doing so, it can determine the ordinal range of the utxo(which is the part considered static)

The data is actually stored in the witness data, but when the utxo is move, like crafting a normal raw tx, there is no need for the data... so in effect the size of the tx becomes standard in regards to the inputs/outputs as normal( rather than the hijacked data in the original)

I wrote a wallet client which takes some of the stuff I'd learned while looking at Merkalized Abstract Syntax Tree's and Schnorr signatures, and applied this concept more generally to secp256k1 Elliptic Curve:

https://medium.com/@jamie.brian.gilchrist/my-new-wallet-client-txtailor-a-twist-on-cryptographic-key-tweaking-inspired-by-bitcoins-83233795feb1


I'd be interested to see what people make of the tool. It is quite flexible, and works across any chain using the secp256k1 EC.

coinfaucet.eu is a decent one.

I also have some Bitcoin Testnet coins, if you give me an address I can send you some.

The aspect of Ordinals I find most contentious is the application of Ordinal theory.  The concept that individual satoshis have a unique identifier based on their issuance order on the network (i.e., the first coinbase transaction being 0-50 billion sats) is intriguing to me. However, my main issue lies in the method used by Ordinals to store data. This method involves making the data appear like it is valid signature data and exploits a feature intended for multiple parties. As it stands, using this to store arbitrary data is similar to having an unlimited op_return—except for the overall blocksize/weight limit.

While op_returns, which are technically spent outputs, are a network-acknowledged method for storing arbitrary data, the debate continues over whether Bitcoin should be used for this purpose at all. However, between the two methods (op_return or hijacking the witness data), the one based on op_return is more widely accepted.

Currently, transferring ownership of an Ordinal is highly inefficient. Every time you want to send it to someone else, the entire weight of the data must be included in the transaction.

If the data which is actually stored in an Ordinal was nothing more than a pointer,  including a signature (witness) and a hash, CID, url or whatever of the actual full-fat data, the misuse of the blockchain could have been mitigated. As it stands it's like just a total cramming in of data, with 0 regard on how that looks being moved around full-fat each time.

By requiring all data to be included directly in the input and UTXO for each transaction, the data transfer, fees, and network overhead remain high every time. Moreover, there's a lack of delta-encoding in Ordinals, exacerbating these issues.

Moving to a layer 2 solution could represent a step in the right direction, in my opinion.

I concur with others who view the capacity to store unlimited amounts of arbitrary data within the witness (limited only by the block size) as a potential attack vector.

No, it should be < the target ( not equal to it).

When mining Bitcoin , the goal is to find a hash that is not equal to the target(near impossible), but less than the target value(probalistic).  The target is a 256-bit number that the network adjusts every 2016 blocks to ensure that the time between blocks remains approximately 10 minutes on average.  A lower target means a higher difficulty in finding a valid block.

The hashing process is essentially a race to find a nonce value that, when combined with the block's header data(which itself contains the Merkle root of the previous blocks tx) and passed through the SHA-256 hashing algorithm twice, produces a hash value that is less than the network-defined target, which everyone can easily verify for themselves too.

Therefore the condition, in the educational example,  if hash < target: is correct because you are looking for a hash that is numerically less than the target.

No, it should be < the target ( not equal to it).

When mining Bitcoin , the goal is to find a hash that is not equal to the target(near impossible), but less than the target value(probalistic).  The target is a 256-bit number that the network adjusts every 2016 blocks to ensure that the time between blocks remains approximately 10 minutes on average. A lower target means a higher difficulty in finding a valid block.

The hashing process is essentially a race to find a nonce value that, when combined with the block's header data(which itself contains the Merkle root of the previous blocks tx) and passed through the SHA-256 hashing algorithm twice, produces a hash value that is less than the network-defined target.

Therefore the condition, in the educational example,  if hash < target: is correct because you are looking for a hash that is numerically less than the target.

True. There has been some momentum around moving the kernel over to Rust, in time.

https://www.zdnet.com/article/rust-in-linux-where-we-are-and-where-were-going-next/

True. There has been some momentum around moving the kernel over to Rust, in time.

https://www.zdnet.com/article/rust-in-linux-where-we-are-and-where-were-going-next/

100%. I probably wasn't very clear in my answer, but what I was meaning is C and C++ are very much related( so much so that if certain OO features are not used, the performance is exactly the same. However you are most certainly right, and actually writing something(complex) without using OO = pain!