Cold storage….can be even colder!

My new wallet client(txtailor): A Twist on Cryptographic Key Tweaking Inspired by Bitcoin’s Advances using MAST

In my previous exploration, “Generating Cold Storage for Bitcoin” — ( Generating Cold Storage for Bitcoin | by ExperiMENTAL | Feb, 2024 | Medium), we looked into the foundational aspects of securing your bitcoin offline, ensuring that your private keys remain inaccessible to online threats. Today, I will take this concept a step further by introducing a new client I’ve created, using a technique that not only fortifies the security around private keys but also introduces a novel layer of privacy and functionality to blockchain transactions. This method can be applied to any blockchain networks that use the SECP256k1 Elliptic Curve(Bitcoin, Ethereum, Litecoin, and most others). Lets get into it!

The Genesis of My Method

The traditional cold storage methods serve their purpose by keeping your private key offline, away from the prying eyes of online hackers. However, the existence of a static private key, even in cold storage, poses a theoretical risk. If someone were to gain access to my private key, what stops them spending the funds? What if, instead of a static key, we could have a dynamic element that adds an extra layer of security?

This thought led me to develop a method that allows for the dynamic creation of a derived address through the application of a specific message or piece of data, directly into an existing public key(or private key — and you’ll see this below). This approach ensures that the corresponding private key to access funds sent to this derived address effectively remains non-existent until its creation using the same tweak.

The Core Concept: Dynamic Address Generation

At the heart of this method lies the concept of “tweaking” both public and private keys with specific messages or data, thus allowing me to generate new, derived addresses. This process can be used to either a) generate addresses for others with a condition, an auth code for example, or the transaction purpose b) generate addresses for yourself, either improved cold storage, or to embed data for indexing, enhancing security or other purposes.

Enriching Transactions with Purpose and Privacy

Imagine Alice wishes to send Bitcoin to Bob, not just as a simple transaction but with embedded details specifying the transaction’s purpose. Instead of sending to Bob’s standard address, Alice sends the Bitcoin to a derived address, which includes a unique message like “Payment to Bob: For the ASIC equipment, auth code:12345.” This message isn’t just a note; it’s a key. Without it, the funds remain locked away, accessible only when Bob, using the Txtailor wallet client, applies the same message to his private key to generate the corresponding derived address and access the funds.

1. First Alice will generate an address for Bob, and this address will have the following information embed into the address itself:
   “Payment to Bob: For the ASIC equipment, auth code:12345.”

First Alice creates an address on behalf of Bob, so she can embed a message directly into the address used by Bob to send the funds. This does 2 things, 1) allows Alice or Bob to prove the purpose of the TX(but only to those they disclose the message and other details to) 2) Lock the funds in an address, which Bob can access, but only when he receives the message from Alice.

2. Next Alice will send a small payment of bitcoin to Bob, using the newly created address above.

In the above, Alice is sending a payment to Bob, from her native address(associated directly with her Public Key) to an address she created for Bob, on his behalf. This allows her to embed the purpose of the transaction directly into the address. This address is accessible only by Bob, and upon being supplied by the message(as above in step 1). Anyone can verfiy the message, given the message and original public key, but only Bob can generate the private key for it.

3. Now Bob (using his own offline client) can generate the private key associated with the tx, once he is supplied with the message(now acting as a offchain Auth code)

Beyond Transactions: Embedding Identity and Proofs

This technique’s potential goes beyond securing transactions; it offers a novel approach to identity verification and authentication within the blockchain. By embedding identifiable information, such as an email address, directly into a Bitcoin address, individuals can prove ownership and verify their identity in a wholly new and secure manner.

Here I generate an address(owned by me) which embeds my email address directly. I can then sign from the key associated with this address, or send transactions, tying them together.

Anyone else running the txtailor client, and being supplied with the original public key, and the message, can verify this claim themselves, independently, and totally offline if required.

Colder Storage (My super secure method!)

By incorporating a dynamic element into the access mechanism for blockchain addresses, this method significantly reduces the risk posed by stolen or compromised private keys. The real power lies in the tweak — without knowledge of the specific message or data used to create the derived address, the original private key remains just a key to a lock that’s been changed.

If you followed my previous tutorial about Bitcoin Cold Storage( link at the top), then you can effectively add the following steps(below) onto it, to achieve an ever higher level of security.

In this example, I am going to first generate a fresh key pair on an offline machine. I will then take the public key only, and on another completely air gapped machine, generate my secret address. At this point, the counterpart private key doesn’t actually exist yet, and this is a good thing.

Humans are quite capable of remembering passwords( I still remember Admin passwords for sites I managed 15 years ago). So this( a password) is a natural choice for the tweak, when considering a Cold Storage for my own funds.

OK, how does it look.

1. First we generate a secp256k1 private key, and derive the public key:

Create a fresh private key on an offline machine

2. We will take only the public key, and this will be input into txtailor on another different machine.

Now, using only the public key, we have created a new address(our super Cold Storage), where the private key for the address technically doesn’t exist yet. It’s not until I want to spend the funds, that I will need to bring this key into existence, by tweaking the underlying original with the value(only I know, and isn’t written down anywhere typically, but can be)

And that’s it. The address above, can’t be accessed even if someone stole your original private key. You can obviously add further steps into this process( such as encrypting the private key and the tweak elsewhere).

What else?

The are many more things this client can do, and I’ll explore these in later tutorials. One of the other standout features is the introduction of Merkalized data structures. This allows me to prove a particular piece of information imbedded into an address, without exposing all of it. I can simply expose the branch, which contains the valid info I want to share, for example, my email, or some other piece of data, rather than the whole file, while still being able to prove ownership, timestamping provenance via the blockchain.

Another feature I want to talk about in more detail later, is the ability to generate addresses, both deterministically( as with a traditional HD wallet) and non-deterministically(as in using random 256bit nonces). The deterministic approach opens up possibilities for structuring of keys based on an indexing system(custom) tied to the user. The user can then choose to associate particular branches of transactions as part of a campaign(for example).

My initial POC was in creating a charity campaign system:
Within this system, the “Save the Planet” campaign(with it’s associated ID) acts as a root node from which all subsequent, more granular campaigns or sub-categories derive. For instance, under “Save the Planet,” there might be sub-categories like “Reforestation,” “Ocean Cleanup,” and “Wildlife Protection.” Each of these sub-categories, in turn, could have further subdivisions, such as specific projects or geographical locations for reforestation efforts, all the way down to specific elements or files.

Here’s how it works: The “Save the Planet” campaign is first assigned a unique address using the root private key, creating a secure and identifiable wallet for donations. Then, to create a sub-category like “Reforestation,” the system generates a tweak based on both the name “Reforestation” and its parent ID — linking it directly to “Save the Planet.” This tweak is applied to the private key associated with “Save the Planet” to generate a new, unique address for “Reforestation.” This process can be repeated at any level of the hierarchy, allowing each project or sub-campaign under “Reforestation” to have its own unique address, derived from tweaking the already tweaked key of its parent.

This method creates a robust indexing system, where each address is deterministically generated and securely linked to its parent, ensuring a traceable lineage of funds and making the management of campaign addresses efficient and organized. For example, donations received in the “Reforestation” address can be easily identified as intended for that specific cause, under the broader “Save the Planet” initiative. Furthermore, this system can extend beyond fund management to include file storage, where documents, reports, and other relevant data can be indexed and retrieved based on their association with specific campaigns or sub-campaigns, enhancing the transparency and accountability of charitable activities, while maintaining self-sovereignty of your data.

#txtailor #tweaking #security #blockchain #bitcoin #ExperiMENTAL