Warning
This post was published 411 days ago. The infomation described in this article may have changed.
Receiving paper wallet funds.
⚓ Neptune 📅 2023-10-06 👤 danda 👁️ 1319
I was just reading about Paper Wallets in Neptune. It states:
There is no privacy from the sender; he can tell if the receiver spent the coins. After all, the sender possesses knows the UTXO and can derive the decommitment information. However, since the sender does not have the secret key (a,b) he cannot satisfy the lock_script and therefore he cannot spend the UTXO himself.
If I understand correctly, this can easily be mitigated by first receiving funds from 3rd party into a regular software wallet and then sending to your paper wallet. Since you are both sender and receiver of the 2nd tx, privacy is maintained.
Perhaps it might be worth adding this caveat to the post, since in practice the issue can be easily worked around, and custodial wallet software could facilitate it.
<rant> Additionally, in my view, paper wallets have been the abandoned step-child in the bitcoin world. Ever since bip32 support was added into bitcoin-core it would have been so easy to add a “generate paper wallet” feature that is easy and basically foolproof for users with the seed never stored on disk and memory wiped after use. I even offered to work on said feature, but was told it wasn’t wanted. Instead it seems they prefer to recommend hardware wallet honeypots like Ledger that collect customer’s home addresses and then manage to get hacked. </rant>
So yeah, I’d love to see Neptune do better and offer a simple paper wallet generator in the official client(s). The UI would warn users only to fund their paper wallet from your own neptune software wallet, and might offer a “create and fund” single step feature/wizard.
I’d be happy to work on such a feature at some point, if its agreed to be a good idea.
🏷️ paperwallet
aszepieniec 2023-10-08 👍 👎
There is no privacy from the sender; he can tell if the receiver spent the coins.
While your understanding and the proposed mitigation are correct, we actually solved this issue in between writing the article and implementing mutator sets. The paper describes the solution under section 5.7 heading “Sender and Receiver Randomness”. In the code, relevant fields are called sender_randomness and receiver_preimage. The point is that the sender knows the receiver_digest but you need the receiver_preimage to produce the removal record. When it is spent, the original sender has no indication that the observed removal record came from the transaction he initiated.
I’ll update the article to reflect this shortly.
Having support for paper wallets front and center in the official client is definitely necessary. However, right now I would caution against such a feature because the address formats are still in flux and we don’t want to risk limiting flexibility. The right time is
- after having a satisfying answer to Issue 40 (which poses the question whether we need public scripts to compute anything, or whether public announcements suffice);
- after implementing
TraceableChangeor whatever we end up renaming it to.