I'm wondering why public nodes are not changed to permanodes.

This way the light-wallet would not run the risk of address re-use after a snapshot. There can be many reasons that the light-wallet loses track of used addresses (reinstallation, cleanup, crash, different device, ...) and once a snapshot was done address re-use could happen, even when the user is aware that he should not re-use the address, but maybe not aware that a reinstallation or the usage on a different device puts him on risk.

  • My understanding is, that a permanode does know the full tangle history and is able to prevent any address reuse
  • My understanding is also, that a light-wallet will never be able to prevent double address use in a fool-proof way on its own
  • I also understand that the public nodes won't be necessary when the tangle goes live, but wouldn't it be worth to protect the light-wallet with perma public nodes as long as tangle beta is running ?
  • Furthermore, I understand that perma nodes need more disk space then ordinary full nodes. But still, in the recent days/weeks I saw tons of full nodes joining the tangle and many of them have lots of cpu power and disk space.

So the question is: Why don't we do this? (At least in the beta phase)

  • Why would a perma-node prevent address reuse?
    – Helmar
    Jan 4, 2018 at 10:22
  • 1
    They could maintain the "burnt" addresses and deny transactions from them. I think this is more secure than to rely on a stateful client. In my opinion there are too many scenarious where the state could get lost.
    – Malfi
    Jan 4, 2018 at 14:01
  • But at that point the stateless client has already done the pow for the re-use and sent it out to the node. Thus, the security breach has already happened.
    – Helmar
    Jan 4, 2018 at 14:10
  • I even think that a stateful client and public perma nodes could work well hand-in-hand. If for some reason the client loses track there is still the perma node preventing the client to upload the transaction to the tangle. The client could automatically react and recreate the transaction until it uses an unused address. Maybe there is some technical issue with this approach, but currently I don't see it.
    – Malfi
    Jan 4, 2018 at 14:13
  • Hmm, but if all public nodes are perma nodes they could deny the transaction. There is a security breach, but only the perma node knows about it and isn't this still much better than to allow the light wallet to re-use the address?
    – Malfi
    Jan 4, 2018 at 14:20

2 Answers 2


The issue is that a larger history will result in nodes being in need of more hard drive space and finally result in degraded performance as a larger database is slower than a smaller one.

There are a lot of smaller nodes running on VPS out there, which could not store the entire history. The database since the last snapshot is already almost 11 GB in size and is, of course, subject to grow when TPS increase!

A relatively simple solution would be to keep a list of spent addresses in addition to the snapshot.

We'll see how the Foundation plans to fix this in the future


1) It is a chicken and egg problem with wallet, at the moment the wallet is stateless, meaning it does not store any state on it (transactions and their balances). Everytime you reopen the wallet it reload the transaction from the tangle.

2) When a snapshot happens, all zero balance transaction (no value as well as zero balance address) are removed from it. The ones with value will be carried forward to the new DB of the node.

3) A partial solution is to have a wallet with state and store the value of all transaction that occurs in the wallet. This mean that opening a wallet on another PC with the same seed will incur the same problem of a stateless wallet (transaction is download from the tangle)

4) Public nodes will still be needed as always, otherwise where would your wallet connect to.

5) From what I can gather from the slack channel and reading the roadmap, the permanode is still in development.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.