Skip to content

Commit eaa43b4

Browse files
authored
Merge pull request #1257 from daira/implement-transparent-source-only
Add support for transparent-source-only (TEX) addresses
2 parents 909c015 + f8bedd8 commit eaa43b4

38 files changed

+3056
-805
lines changed

Cargo.lock

+1
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

Cargo.toml

+2-1
Original file line numberDiff line numberDiff line change
@@ -104,8 +104,9 @@ tonic-build = { version = "0.12", default-features = false }
104104
secrecy = "0.8"
105105
subtle = "2.2.3"
106106

107-
# Static constants
107+
# Static constants and assertions
108108
lazy_static = "1"
109+
static_assertions = "1"
109110

110111
# Tests and benchmarks
111112
assert_matches = "1.5"

zcash_client_backend/CHANGELOG.md

+56-17
Original file line numberDiff line numberDiff line change
@@ -6,18 +6,39 @@ and this library adheres to Rust's notion of
66
[Semantic Versioning](https://semver.org/spec/v2.0.0.html).
77

88
## [Unreleased]
9+
### Notable changes
10+
`zcash_client_backend` now supports TEX (transparent-source-only) addresses as specified
11+
in ZIP 320. Sending to one or more TEX addresses will automatically create a multi-step
12+
proposal that uses two transactions.
13+
14+
In order to take advantage of this support, client wallets will need to be able to send
15+
multiple transactions created from `zcash_client_backend::data_api::wallet::create_proposed_transactions`.
16+
This API was added in `zcash_client_backend` 0.11.0 but previously could only return a
17+
single transaction.
18+
19+
**Note:** This feature changes the use of transparent addresses in ways that are relevant
20+
to security and access to funds, and that may interact with other wallet behaviour. In
21+
particular it exposes new ephemeral transparent addresses belonging to the wallet, which
22+
need to be scanned in order to recover funds if the first transaction of the proposal is
23+
mined but the second is not, or if someone (e.g. the TEX-address recipient) sends back
24+
funds to those addresses. See [ZIP 320](https://zips.z.cash/zip-0320) for details.
925

1026
### Added
1127
- `zcash_client_backend::data_api`:
1228
- `chain::BlockCache` trait, behind the `sync` feature flag.
1329
- `WalletRead::get_spendable_transparent_outputs`.
1430
- `zcash_client_backend::fees`:
15-
- `ChangeValue::{transparent, shielded}`
31+
- `EphemeralBalance`
32+
- `ChangeValue::shielded, is_ephemeral`
33+
- `ChangeValue::ephemeral_transparent` (when "transparent-inputs" is enabled)
1634
- `sapling::EmptyBundleView`
1735
- `orchard::EmptyBundleView`
36+
- `zcash_client_backend::proposal`:
37+
- `impl Hash for {StepOutput, StepOutputIndex}`
1838
- `zcash_client_backend::scanning`:
1939
- `testing` module
20-
- `zcash_client_backend::sync` module, behind the `sync` feature flag
40+
- `zcash_client_backend::sync` module, behind the `sync` feature flag.
41+
- `zcash_client_backend::wallet::Recipient::map_ephemeral_transparent_outpoint`
2142

2243
### Changed
2344
- MSRV is now 1.70.0.
@@ -31,36 +52,54 @@ and this library adheres to Rust's notion of
3152
`change_memo` is given, and defends against losing money by using
3253
`DustAction::AddDustToFee` with a too-high dust threshold.
3354
See [#1430](https://github.com/zcash/librustzcash/pull/1430) for details.
34-
- `zcash_client_backend::zip321` has been extracted to, and is now a reexport
55+
- `zcash_client_backend::zip321` has been extracted to, and is now a reexport
3556
of the root module of the `zip321` crate. Several of the APIs of this module
3657
have changed as a consequence of this extraction; please see the `zip321`
3758
CHANGELOG for details.
3859
- `zcash_client_backend::data_api`:
39-
- `error::Error` has a new `Address` variant.
60+
- `WalletRead` has new `get_known_ephemeral_addresses`,
61+
`find_account_for_ephemeral_address`, and `get_transparent_address_metadata`
62+
methods when the "transparent-inputs" feature is enabled.
63+
- `WalletWrite` has a new `reserve_next_n_ephemeral_addresses` method when
64+
the "transparent-inputs" feature is enabled.
65+
- `error::Error` has new `Address` and (when the "transparent-inputs" feature
66+
is enabled) `PaysEphemeralTransparentAddress` variants.
4067
- `wallet::input_selection::InputSelectorError` has a new `Address` variant.
41-
- `zcash_client_backend::proto::proposal::Proposal::{from_standard_proposal,
42-
try_into_standard_proposal}` each no longer require a `consensus::Parameters`
43-
argument.
4468
- `zcash_client_backend::data_api::fees`
45-
- The return type of `ChangeValue::output_pool`, and the type of the
46-
`output_pool` argument to `ChangeValue::new`, have changed from
47-
`ShieldedProtocol` to `zcash_protocol::PoolType`.
48-
- The return type of `ChangeValue::new` is now optional; it returns `None`
49-
if a memo is given for the transparent pool. Use `ChangeValue::shielded`
50-
to avoid this error case when creating a `ChangeValue` known to be for a
51-
shielded pool.
69+
- When the "transparent-inputs" feature is enabled, `ChangeValue` can also
70+
represent an ephemeral transparent output in a proposal. Accordingly, the
71+
return type of `ChangeValue::output_pool` has (unconditionally) changed
72+
from `ShieldedProtocol` to `zcash_protocol::PoolType`.
73+
- `ChangeStrategy::compute_balance`: this trait method has an additional
74+
`Option<&EphemeralBalance>` parameter. If the "transparent-inputs" feature is
75+
enabled, this can be used to specify whether the change memo should be
76+
ignored, and the amounts of additional transparent P2PKH inputs and
77+
outputs. Passing `None` will retain the previous
78+
behaviour (and is necessary when the "transparent-inputs" feature is
79+
not enabled).
5280
- `zcash_client_backend::input_selection::GreedyInputSelectorError` has a
5381
new variant `UnsupportedTexAddress`.
82+
- `zcash_client_backend::proposal::ProposalError` has new variants
83+
`SpendsChange`, `EphemeralOutputLeftUnspent`, and `PaysTexFromShielded`.
84+
(the last two are conditional on the "transparent-inputs" feature).
85+
- `zcash_client_backend::proto`:
86+
- `ProposalDecodingError` has a new variant `InvalidEphemeralRecipient`.
87+
- `proposal::Proposal::{from_standard_proposal, try_into_standard_proposal}`
88+
each no longer require a `consensus::Parameters` argument.
5489
- `zcash_client_backend::wallet::Recipient` variants have changed. Instead of
55-
wrapping protocol-address types, the `Recipient` type now wraps a
56-
`zcash_address::ZcashAddress`. This simplifies the process of tracking the
57-
original address to which value was sent.
90+
wrapping protocol-address types, the `External` and `InternalAccount` variants
91+
now wrap a `zcash_address::ZcashAddress`. This simplifies the process of
92+
tracking the original address to which value was sent. There is also a new
93+
`EphemeralTransparent` variant, and an additional generic parameter for the
94+
type of metadata associated with an ephemeral transparent outpoint.
5895

5996
### Removed
6097
- `zcash_client_backend::data_api`:
6198
- `WalletRead::get_unspent_transparent_outputs` has been removed because its
6299
semantics were unclear and could not be clarified. Use
63100
`WalletRead::get_spendable_transparent_outputs` instead.
101+
- `zcash_client_backend::fees::ChangeValue::new`. Use `ChangeValue::shielded`
102+
or `ChangeValue::ephemeral_transparent` instead.
64103

65104
## [0.12.1] - 2024-03-27
66105

zcash_client_backend/proto/proposal.proto

+16-9
Original file line numberDiff line numberDiff line change
@@ -73,14 +73,14 @@ message ReceivedOutput {
7373
uint64 value = 4;
7474
}
7575

76-
// A reference a payment in a prior step of the proposal. This payment must
76+
// A reference to a payment in a prior step of the proposal. This payment must
7777
// belong to the wallet.
7878
message PriorStepOutput {
7979
uint32 stepIndex = 1;
8080
uint32 paymentIndex = 2;
8181
}
8282

83-
// A reference a change output from a prior step of the proposal.
83+
// A reference to a change or ephemeral output from a prior step of the proposal.
8484
message PriorStepChange {
8585
uint32 stepIndex = 1;
8686
uint32 changeIndex = 2;
@@ -112,22 +112,29 @@ enum FeeRule {
112112

113113
// The proposed change outputs and fee value.
114114
message TransactionBalance {
115-
// A list of change output values.
115+
// A list of change or ephemeral output values.
116116
repeated ChangeValue proposedChange = 1;
117117
// The fee to be paid by the proposed transaction, in zatoshis.
118118
uint64 feeRequired = 2;
119119
}
120120

121-
// A proposed change output. If the transparent value pool is selected,
122-
// the `memo` field must be null.
121+
// A proposed change or ephemeral output. If the transparent value pool is
122+
// selected, the `memo` field must be null.
123+
//
124+
// When the `isEphemeral` field of a `ChangeValue` is set, it represents
125+
// an ephemeral output, which must be spent by a subsequent step. This is
126+
// only supported for transparent outputs. Each ephemeral output will be
127+
// given a unique t-address.
123128
message ChangeValue {
124-
// The value of a change output to be created, in zatoshis.
129+
// The value of a change or ephemeral output to be created, in zatoshis.
125130
uint64 value = 1;
126-
// The value pool in which the change output should be created.
131+
// The value pool in which the change or ephemeral output should be created.
127132
ValuePool valuePool = 2;
128-
// The optional memo that should be associated with the newly created change output.
129-
// Memos must not be present for transparent change outputs.
133+
// The optional memo that should be associated with the newly created output.
134+
// Memos must not be present for transparent outputs.
130135
MemoBytes memo = 3;
136+
// Whether this is to be an ephemeral output.
137+
bool isEphemeral = 4;
131138
}
132139

133140
// An object wrapper for memo bytes, to facilitate representing the

0 commit comments

Comments
 (0)