In the first part of this blog post, we discussed our motivation for introducing reusable addresses. Moreover, we suggested why this would work best at the protocol level, rather than as a second-layer approach. In this part of the blog post, we outline our basic proposal.Before you read this article, we suggest that you first understand how an IOTA seed is used to generate and validate addresses, by reading these in-depth posts by Koen Maris and Eric Hop. For this article, we will assume that we can generate a quasi-infinite number of public/private key pairs.Current approach (a recap)Whenever we issue a payment from one of our addresses, we sign the message using the private key belonging to that address. The nodes can verify that the spend was issued by the owner of the address by verifying the transaction signature against the address itself. Since IOTA uses a quantum-resistant signature scheme, we reveal a certain part of the private key whenever we sign a transaction. This means that we cannot use the same private key more than once without compromising the security of funds on that address.To overcome this problem, users are advised to:Never spend from an address more than once.When spending a subtotal of funds at an address, all remaining unspent funds should be sent to a new address (called a remainder address) at the same time. Thereby allowing those remaining funds to be safely spent in the future from the new (remainder) address.The IOTA wallet software takes care of this automatically in the background, so that users’ funds remain safe.When Alice sends funds from an address, her IOTA wallet automatically moves any remaining funds on that address to a new safe “remainder” address in her wallet, from which she can spend safely in the future.After the spend is confirmed, the remaining funds reside on a new unused address.This mechanism secures the funds of the spending party in a very efficient manner. However, the receiving party may still have issues, if somebody sends funds to an address that has already been spent from (either through a mistake by the sender, or due to race conditions, as discussed in the previous post).In this example Alice has already sent money from one address to Bob. Unfortunately, Dave then sent funds to this used address.Funds on this used address are unsafe as the private key from this address has already been partially revealed. Note that Alice (the receiver) could not stop Dave from sending tokens to an unsafe address.New approach (our proposal)Since the signature scheme cannot be changed without breaking a very fundamental feature of IOTA (ie quantum-resistance), we must devise another method to use a new private key for consecutive spends from the same address.Considering that a new private key is always associated with a new public key, this effectively means that we must:Logically separate the address from the public key that is used to verify the signature of transactions.Introduce a way to change the public key that is associated with an address, for every spend.To achieve this, we propose:The introduction of a new field in the transaction metadata, that allows us to update the public key of an address and inform the network about this change.The next spend from this address will have to be verified against this different public key instead of the address itself.For every spend we will generate a new public/private key pair that will be used to authorize the next spend from that address, with the public key for the next transaction being set by the metadata of the current transaction. The algorithm for sending a transaction can be summarized as follows:Spend Funds (nth time from an address)Construct the transaction.Generate a new public/private key pair for the next spend (pubkey_n, privkey_n).Include the public key of the newly generated key pair in the transaction metadata by setting the corresponding field: nextpubkey = pubkey_n.Sign the transaction with the private key belonging to the public key that was set by the previous transaction: privkey_n-1 (Note: The very first spend will use the private key belonging to the address itself)Broadcast the transaction.The steps involved involved in sending from a reusable address.All residual funds remain at the same address, rather than being moved to a remainder address. It is still safe to send funds to this address in the future.To be able to process transactions this way, the nodes will simply have to store an additional field per address in their ledger state, and change the updated public key whenever a new spend gets confirmed.The ledger state will change from:to:Note:The public key is the address itself, if we did not spend from the address yet (see AddressA in the example).KeyB7 implies the 7th public key for address B.KeyX9 implies the 9th public key for address X.A (made up) “real world” comparisonIOTA’s current approach to signing payments can be compared to having diamond doors on your house. They are extremely secure but sadly they are also transparent. So whenever you use your key to leave the house to walk to the bank, somebody waiting outside can “see” a little part of the key that you used to unlock the door. And at some point, they might see enough to be able to forge a key and access the contents of your address.To prevent this from happening, we currently take all of our belongings with us to a new (remainder) address (with a new lock and a new key) and never return to our old address.In comparison, this new approach can be compared to “changing the lock” after you leave the house but staying at the same address. So even if somebody sees your old key, they will not be able to access your house/funds. Plus you have the added bonus of a stable address where people can send you mail (or money!).Cool, let’s do this! Wait a minute! Not so fast …While the proposed solution does indeed solve the problem of address reuse, it also introduces a few new issues of its own.The final part of this blog post will examine these problems and discuss their solutions. Check back here tomorrow!A Proposal for Reusable Addresses [Part 2] was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.