Right now, according to the wallet app threat model a malicious or compromised lightwalletd can omit transactions, concealing them from the wallet user.
This is undesirable because it means that a wallet app provides significantly less guarantees to the user than a full node, and it increases how much trust the wallet app user must put in their choice of lightwalletd, increasing centralization.
In Zbay's use case, where memos on Sapling transactions are used to register usernames, it means that a malicious lightwalletd could spoof usernames, and potentially send or receive messages or funds on behalf of a user. TryQuiet/zbay#517
In the light wallet working group, str4d explained that addressing this vulnerability is possible for Sapling transactions, but requires implementing FlyClient support:
It is possible to verify that lightwalletd is not omitting transactions containing Sapling outputs. Light clients can check that the root of the Sapling commitment tree they are building locally matches the hashFinalSaplingRoot field in:
- Before Heartwood, the block header (now renamed to hashLightClientRoot).
- After Heartwood, the FlyClient history tree leaf for that block. Light clients would then use a FlyClient proof to confirm that the history tree leaf is correctly part of the chain via the hashLightClientRoot.
This requires implementing FlyClient support in light clients and lightwalletd, which has not yet been done.
I don't know how much work this is, or how to prioritize it, but it seemed best to create this issue to track it.
Right now, according to the wallet app threat model a malicious or compromised lightwalletd can omit transactions, concealing them from the wallet user.
This is undesirable because it means that a wallet app provides significantly less guarantees to the user than a full node, and it increases how much trust the wallet app user must put in their choice of lightwalletd, increasing centralization.
In Zbay's use case, where memos on Sapling transactions are used to register usernames, it means that a malicious lightwalletd could spoof usernames, and potentially send or receive messages or funds on behalf of a user. TryQuiet/zbay#517
In the light wallet working group, str4d explained that addressing this vulnerability is possible for Sapling transactions, but requires implementing FlyClient support:
I don't know how much work this is, or how to prioritize it, but it seemed best to create this issue to track it.