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(maybe even for more trivial things like paid subscriptions with conditions, such as March2024+nonce or something) 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.

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 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 utility beyond what static multisig setups can achieve. ( i.e you can actually spend from an address tied to your email address for example if you chose to, or it was a requirement from a merchant)

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)

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, in the past people could do a hash > address and include this as an additional output in their tx too...or even burn some utxo as op_return with an encrypted message)  But this still doesn't allow them to spend from the address ofc(similar to multisig).



In traditional multisig setups, addresses are created based on a fixed set of conditions and keys at the time of setup, making changes to the address or its conditions a matter of creating a new multisig configuration. While you can change the message or recipient within a multisig transaction to create a new address. Txtailor allows for continuous, dynamic customization not just at the initial setup but through the entire lifecycle of an address, enabling a deeper level of privacy and flexibility.

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

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(other than their own ofc).

It can (in isolation) apply these manipulations to the Elliptic curve, to their a public key(can be done by anoyone) or the private key. Ofc, from a private key, you can generate a public key( but that isn't needed other than for generating private key(more aptly altering it, at use time). We can work exclusively with a public key to create the addresses... so think of it like an HD wallet, one where we work entirely on public keys, with no private keys at all.

In my setup, it's somewhat reversed from an HD wallet

User A has a private and public key

User B knows user A's public key only. They can generate a new address ( or literally any number) on behalf of user A.

They never needed to know user A's private key. This is where the confusion is, and how it works with a traditional HD wallet. What I am doing here, means the private key for this wouldn't actually exist yet.. becasue the public key( for which the base private key ofc does exist) would need manipulated too, by user A....

you do know that private is pre ECC and public is post ECC right

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. 

i know how things work with keypairs
just your title, description and explainer didnt match each other of where you put the message

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