zcash / librustzcash

Rust-language assets for Zcash
Other
337 stars 252 forks source link

Introduce ZIP 315 `TrustPolicy` struct or similar #873

Open str4d opened 1 year ago

str4d commented 1 year ago

We should implement the distinction of trusted and untrusted transactions outlined in ZIP 315, as a way of replacing the single "min confirmations" security level. This would then enable wallets to implement a "trust policy", whereby signals are used to determine whether an incoming payment can be trusted or not, and therefore what min-conf level to apply to the transaction to ensure security of funds.


Original OP:

We recently changed min_confirmations to be a NonZeroU32, but this exposed an issue where we still want to set it to zero for transparent coins. What we really need is a confirmation depth per pool (and for shielded pools, potentially different between own-wallet notes and externally-received notes).

str4d commented 1 year ago

We should also take into account the fact that when checking balances, we often do want to use min_confirmations = 0 for shielded pools (so that balance doesn't temporarily drop), while when creating transactions we want to enforce that it is non-zero.

nuttycom commented 1 year ago

@daira recently had a realization about the meaning of having different confirmation depths for change notes relative to confirmation depths for non-change notes related to the proposed scheme in ZIP 315 that I can't recall now, but that should be recorded here. IIRC ze was working on a commit to make a change related to this to ZIP 315, but I don't see that commit on https://github.com/zcash/zips/pull/607/commits yet.

nuttycom commented 1 year ago

We should also take into account the fact that when checking balances, we often do want to use min_confirmations = 0 for shielded pools (so that balance doesn't temporarily drop), while when creating transactions we want to enforce that it is non-zero.

Right. We do have the pending change notes in the wallet database, so we should be able to treat those as part of the balance so long as they have not expired.

str4d commented 1 year ago

(and for shielded pools, potentially different between own-wallet notes and externally-received notes).

To expand on / clarify what I meant here: we realised a while back that we don't need to have the same confirmation depth for all notes, as the decision about when to select a note for spending is entirely wallet-local. So we can e.g. use 10 confirmations for notes received from external transactions (as there is a risk of the inputs being double-spent), while using 3 confirmations for our own change notes (as we can assume we won't double-spend ourselves). Then the anchor height for a transaction can be set to the minimum of these (i.e. 3, vs. the 10 we currently set it to).

nuttycom commented 1 year ago

(and for shielded pools, potentially different between own-wallet notes and externally-received notes).

To expand on / clarify what I meant here: we realised a while back that we don't need to have the same confirmation depth for all notes, as the decision about when to select a note for spending is entirely wallet-local. So we can e.g. use 10 confirmations for notes received from external transactions (as there is a risk of the inputs being double-spent), while using 3 confirmations for our own change notes (as we can assume we won't double-spend ourselves). Then the anchor height for a transaction can be set to the minimum of these (i.e. 3, vs. the 10 we currently set it to).

Right, that's the idea that @daira realized was incorrect and I can't remember exactly the argument.

str4d commented 6 months ago

The comment that the above discussion was referring to was invalidated. So we're back in the position where we want to separate "confirmation depth" from "anchor depth" matching what we described in the current draft of ZIP 315, enabling both a much smaller anchor depth to be used, as well as to have confirmation depth set to that smaller anchor depth for trusted notes.

str4d commented 2 months ago

I'm currently attempting to work out the implementation for this.

There are several things that a wallet needs to select in order to produce a transaction proposal:

Anchor height selection has the following inputs:

Note selection has the following inputs:

nuttycom commented 4 weeks ago

Related to #1413