We explained our proposal’s basic concept in the 2nd part of this series. We will now explain why IOTA was not designed like this in the first place, and why the proposed solution cannot fully replace the way transactions are handled right now.Spoiler Alert: At the end of this post we will hopefully see that we can still build a viable solution that combines the best of both worlds.We begin by looking at the advantages and disadvantages of this new approach.Arguments for the proposed approachReceiving funds now requires less resources on the receiving side, since recipients do not need to generate new addresses for every incoming payment, and the recipient has to monitor fewer addresses, in order to determine if funds were received.This in turn mitigates a possible DOS-like attack, whereby the recipient is bombarded with payment requests, forcing them to generate and monitor a quasi-unlimited number of addresses (assuming a working second-layer approach to deal with these requests).Fewer resources may also be needed on the sending side, as the sender would no longer have to constantly query for new receive addresses.Wallets can implement address books for saving contacts with predictable persistent addresses.Consequently, corporations and individuals could communicate their payment details in stationery. Recurring payments such as direct debits and standing orders to static addresses also become possible, making IOTA a viable solution for traditional businesses models.The approach would facilitate a decentralized DNS-like system, where complex IOTA addresses are mapped to human-memorable addresses. It would be possible to refer to contacts by using aliases (e.g. email addresses); immediately making IOTA as usable as existing payment systems (e.g. PayPal or traditional banking).Front-end validation of these address-aliases could prevent funds from being lost, if the user is warned that their mistyped alias is not mapped to a valid IOTA address.Received funds are always 100% secure, as the funds cannot end up on a used address.Replay attacks would be ineffective because of the changed public key.The wereAddressesSpentFrom API call can be deprecated — this temporary solution currently creates an ever-growing list of addresses that limits scalability.Bundles will get smaller because a full transaction (remainder transaction) can be omitted — reducing the required network traffic for spends.The common theme of these advantages is that the proposal makes IOTA more user-friendly for humans, and will ultimately drive wider adoption. They are therefore very valuable, and should not be readily dismissed.Predictable addresses would facilitate contacts management and easy transactions within message threads. Could this be a future version of Trinity?Arguments against the proposed approachAs mentioned at the start of this post, our proposed solution introduces some issues that would prevent it from completely replacing the current way that transactions are handled. We will discuss these issues one by one, along with possible mitigations.1. The order of transactions mattersOne issue with this new approach is that the order of transactions now matters. A succeeding transaction can only be confirmed if and when the previous transaction in the chain has been seen (and eventually confirmed) by the network.For example, if you rapidly send 10 consecutive payments from a reusable address, then the first transaction changes the public key of the address, and the new public key is required for the next transaction (and so on). If the first transaction does not get confirmed, and needs to be reattached, it would mean that the following transactions would be delayed until that reattachment confirms. They may then also need to be reattached (possibly multiple times) until they are accepted by the network in the desired order.It should be noted that this issue also exists with IOTA’s current approach. A consecutive spend can only be verified once the transaction funding the remainder address has been seen by the network (this address would otherwise appear empty). However with our new approach, it is harder to implement a mechanism that would allow for features such as temporary overdrafts (where a following transaction funds the spend of a previous one) — the change of keys means that we can not easily verify the signature of these transactions, when processing them in the wrong order.Even if we assume that the nodes would pay attention to the order and “sort” the transactions internally while determining their validity, it would at least make the task of verifying transactions slightly more complex and require more processing power. These CPU cycles could be spent processing other transactions which might decrease the ability to process a high number of transactions per second.Possible solution:Parts of this problem can be solved by directly or indirectly referencing a previous spend in a consecutive spend if the previous one is still pending. This way, we can ensure the validity of a subtangle without having to take parallel subtangles into account, when determining the validity of these pending transactions. Since the random walk happens from “past” to “present” we automatically see the transactions in their correct order and can omit sorting them internally, which eases these problems. This behaviour also increases the weight of the previous spend and therefore increases its chance of being accepted by the network. A consecutive spend would therefore act like a promotion of the previous transaction.We should bear in mind that this problem only manifests if we are trying to send a lot of spends from a reusable address at the same time, without waiting for the previous one to be confirmed (which will be addressed in the final proposal at the end of this post).2. Reduced privacyIf all the funds belonging to a user reside on a single reusable address, the exact balance of that address will be public knowledge. This would be further exacerbated by mapping services that could identify users via their alias. This reduction of privacy might encourage hackers and other criminals to access the funds through traditional attacks outside the IOTA network.Possible Solution:The current method of using addresses only once, and sending remaining funds to a new address will still work. We can regularly “sweep” funds from our public reusable address to a “non-reusable” address, which then functions the same way as it does currently.The privacy of these swept funds can then be further increased by applying services like “mixers”. These are open research topics and we will see additional efforts to increase privacy on the tangle. For now it is enough to assume that we can move the funds away from the reusable address to a traditional one.3. Increased storage requirements for the nodesSince nodes need to store an additional field in their ledger table, the storage requirements increase by 243 trits per address, which would lead to a bigger database size. In addition, emptied addresses cannot be removed from the database anymore since we need to keep track of the updated public key, in case the address receives additional funds in the future. An attacker could easily spam this ledger table and make the nodes run out of storage very quickly.Possible Solution:We propose to only keep a reusable address alive in the ledger table if it is not empty. This means that a user has to stake a certain amount of IOTA (eg 1 IOTA) that will always have to reside on that address if they want to be able to use it multiple times. Once the balance on the address falls beneath this amount, they effectively declare that this address is not used anymore, and it will be cleaned up by the nodes. In essence this means that the address is reset to its first public key, and any incoming funds will now be on a “used” address. Ideally the wallets would take care of managing the staked funds so that we cannot accidentally spend them, and drop beneath the threshold, when sending a payment.If implemented in this manner, we would most probably even see a reduced storage requirement because incoming funds would not need to be spread out over countless addresses anymore, but would be accumulated on fewer addresses.4. Problems in connection with economic clustersEven though the concept of economic clusters is still a research topic rather than an implementation concern, the basic idea is clear. This concept builds on the idea that some activity in a high throughput network, may only be seen by a certain part of the network rather than all existing nodes.For reusable addresses, nodes must see the original transaction which updates the public key, before they can validate any subsequent spends from that address. This original transaction may only be visible in some clusters but not others.Possible Solution:To be able to send inter-cluster payments, we must use non-reusable addresses for the payments. This would allow far-away nodes to verify the signature even without knowing about the updated public key. Since it is possible to move the funds from a reusable address to a traditional address prior to sending transactions, this is not a problem.In fact, we suggest the use of non-reusable addresses (whenever possible) to send funds, while preferring reusable addresses when receiving funds.ConclusionWe have shown that the proposed solution cannot completely replace the existing way of processing transactions, and that the design decisions made in the past were well-founded.It can however act as an opt-in addition for receiving funds in a secure way, without having to worry about address reuse and race conditions. It also has several usability enhancements that would promote current real world adoption of the protocol.Suggested Implementation:To balance the pros and cons, we propose the introduction of one reusable address per wallet, which can act as a single point of contact for incoming payments. This address can periodically be swept to a regular non-reusable one, which makes the funds available for easy spending. Spending from regular (non-reusable) addresses is not reliant on maintaining the order of transactions, which allows them to be efficiently processed in parallel, the same way as they are processed now.At the same time this new “public” address will not expose too much information about our funds because it is emptied regularly, distributing the funds to new addresses that cannot easily be associated to our reusable address anymore.A single reusable address for incoming transactions. Note, any of the normal (non-reusable) addresses could also receive direct transactions, as per current protocolBy making this new approach an opt-in feature, we do not give up any of the advantages of the base protocol that are required for scenarios like IoT and economic clusters, while at the same time opening up the technology to a more human-centric model of use. This will be an important step to achieving our goal of widespread adoption of the technology for humans and machines.We invite the community to discuss this proposal on this forum topic and on the IOTA Discord, particularly any advantages or potential problems that we may have overlooked.A Proposal for Reusable Addresses [Part 3] was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.