Arguments against the proposed approach

As 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 matters

One 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 privacy

If 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 nodes

Since 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 clusters

Even 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.