Fee divergence between Zebra and Zakura: Questions

Technology
1

Hi all, I’d like to check my understanding on some fee-related stuffs between Zebra and Zakura implementations.

From what I can see, both nodes aren’t using the same `MARGINAL_FEE` value which seems to open the door for privacy leakages in the ecosystem (i’m not working on node stuffs, so please let me know if I miss smthg obvious :slight_smile:)

From my understanding, getstandardfee (feat(rpc)!: add `getstandardfee` RPC returning the ZIP-317 marginal fee by aphelionz · Pull Request #10717 · ZcashFoundation/zebra · GitHub) allows wallets to get their fee from the node.
The thing is:

Fees are public, including on fully shielded transactions, right?
So, if a wallet takes its fee from getstandardfee, as Zebra’s PR#10717 intends, the fee it pays reveals whether its backend runs Zebra or Zakura. ZIP 317 already notes that non-standard fees can reveal users, wallets or wallet versions (ZIP 317: Proportional Transfer Fee Mechanism), and ZIP 2009 coordinates its switch height for the same reason (ZIP 2009: Reduce Marginal Fee to 1000 Zatoshis and Raise the Weight Ratio Cap to 10).

TL;DR: AFAICT, having nodes returning different values on getstandardfee can be used to break indistinguishability and thus run some sort of fingerprinting attacks (because the value of the fee can leak the node the wallet is talking to).

Do I miss something?

3 Likes
2

I think it also risks dropping txs during relay if a zebra node connects to a zakura node.

2 Likes
3

Full nodes don’t control the fee’s wallets use! They only control minimum fee to enter a given node’s mempool, and that value itself should be per-node configurable. One day if there is a consensus fee market, that may change. I hope we add a consensus fee market soon after (or in) Tachyon, where it can be well designed without privacy compromise for multisigs / HW wallet signers.

Wallets have their own fee, which indeed is ideally consistent for privacy needs. At minimum consistent for all of the wallets users, and ideally across wallets as well. Shielded Labs is currently encouraging wallets to query full nodes for “getStandardFee” as an intermediate step. Adding an indirection makes sense, why that belongs on the full node versus the pre-existing RPC interface for wallets (“Lightwalletd”) isn’t clear to me.

If wallets are depending on this coming from the full node, it should be separately hard-coded from the mempool’s admission policy. However a generic full node query for versioning this doesn’t actually make sense imo, since then the fee can only update at fixed height boundaries beyond the slowest nodes EOS height - way too slow for an ad-hoc fee market’s ability.

I’d advocate:

  • The natural thing to use is LWD, even for IP privacy reasons.
  • It is never a safe assumption to assume every LWD / full node returns the consistent result. A wallet can only aim to ensure all of their default providers update in tandem. At the point where a wallet is reasoning about that, it seems easier for it to manage on its own, unless they are aiming to serve users who do not update soon after release.
  • Zakura’s “getStandardFee” can be updated to match Zebra today, though this isn’t the right assumption wallets should use. (Wallets choose their standard independently of any full node work)
1 Like
4

But in practice, zebrad will not even add a tx that pays lower than the zip 317 standard fee.

2 Likes
5

And if we remove this from the existing mechanisms, we remember what that could lead to.