Warning
We’ve all heard the stories about people losing or throwing away their Bitcoin. Let’s at least attempt to avoid this with Neptune!!
Neptune Core stores cryptographic data in two files: wallet.dat and incoming_randomness.dat.
The short version is that you need to back up your wallet.dat only once, and the incoming_randomness.dat each time you receive a transaction. Both these files are located in your data directory, which can be found in ~/.local/share/neptune/<network>/wallet/ if you use the default settings on a Linux machine. If you’re unsure what you data directory is, it’s value is in the 1st line that is printed when you start neptune-core.
The wallet.dat file never changes, but the incoming_randomness.dat gets a new line every time you receive or mine a transaction!
So to be safe, you need to back up wallet.dat and you need to back up incoming_randomness.dat with each transaction that you receive. Provided these two files are backed up correctly, you will not lose any funds. wallet.dat should be backed up to a media that’s not connected to the internet, and incoming_randomness.dat should be backed up with a solution that can sync the file over a secure network.
For each transaction you receive, you need to update your backup of incoming_randomness.dat.
To elaborate a bit on this, wallet.dat contains the secret key that is used to unlock the lock script that allows you to spend your UTXO. This secret key is provided as the “secret input” when executing the Triton VM whose STARK engine generates a cryptographic proof that you are allowed to spend this UTXO.
incoming_randomness.dat contains the sender_randomness which is a component that keeps your transactions private. The sender_randomness is a component of the canonical_commitment which constitute the leafs of the append-only commitment list that is a part of the “mutator set” data structure.
Rule of thumb for Neptune security
wallet.dat they take your coinsincoming_randomness.dat they can identify your transactionswallet.dat, you lose your coinsincoming_randomness.dat, you lose your coins.
hi, I’m new here so feel free to take with a grain of salt.
I am hoping that the situation with incoming_randomness.dat is temporary. If not, it strikes me as very problematic.
Simply put, people are terrible at making backups.
I remember the “bad old days” with bitcoin when all the private keys were stored in wallet.dat. It would pre-generate 100 keys, which more or less guaranteed 100 incoming tx before needing to backup the wallet again. Even still, people managed to lose funds pretty regularly. This is why the bip32/bip39 style wallets with a mnemonic one could write down became so popular.
So I am wondering if you see any path towards a solution that would not require incoming_randomness to be backed up each time?
Perhaps some kind of pre-generation of random data, or deriving from a known seed? Sorry if “dumb” q’s…
sword_smith 2023-09-19 👍 👎 [op]
Thank you for your feedback! And this is certainly not a dumb question, rather a prudent warning.
I agree that incoming_randomness.dat’s requirement of continuous backup is sub-optimal. There are ways to derive this entropy deterministacally, but that will be done by the initiator of the transaction, not of the receiver. So if the receiver should lose this randomness for an unspent UTXO, they might have to re-request if from the initiator of the transaction. That is currently our best solution, and I honestly doubt that anyone can come up with something better for this cryptographic protocol.
aszepieniec 2023-09-21 👍 👎
TLDR: Yes this situation is temporary.
Long version: The reason why the sender randomness is necessary is to break the link between output UTXO (addition record) and the input UTXO (removal record) of the transaction that spends it. Without sender randomness, or with sender randomness but with poor entropy, different input UTXOs originating from different expenditures to the same address can be linked.
Currently the only way to send coins around is to generation addresses. This format requires the sender to encrypt the sender randomness under the receiver’s public key. These ciphertexts are stored on the blockchain. As long as the user keeps his mnemonic seed phrase, all sender randomnesses can be recovered from the blockchain.
But there is a second way you can come into possession of UTXOs: by mining. Currently, the incoming randomness (not sender randomness because there is no sender) is generated at random but there is no reason why this can’t be deterministic. It should be and we will fix this in an upcoming update.
That said, we do plan to support other address formats as well, address formats with a smaller blockchain footprint. Users wanting to save costs can transmit sender randomnesses through an overlay protocol. If they want to use the blockchain as a backup they can always send the coins to themselves, resulting in a smaller ciphertext. Alternatively, they have to keep track of sender randomnesses in some other way, for instance in incoming_randomness.dat.