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.

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)