(if available) collides with an existing imported or derived FVK.
This does not check for collisions on IVK for `Incoming` accounts.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
This moves the tracking of whether or not a spending key is expected to
be available for an imported account into the `AccountSource::Imported`
variant.
This adds a mechanism that can be used by the backend to request
additional transaction data or status information from the client,
for the purpose of being to explore transparent transaction history
that is otherwise currently unavailable.
In the case that `decrypt_and_store_transaction` is being used to add
data for fully-transparent transactions to the database, it may be the
case that there is no existing relationship between a transaction and
the block height at which it was mined (unlike for transactions being
enhanced after discovery via block scanning.) This change makes it
possible to set the mined height for transactions that do not have any
shielded components that involve the wallet.
The test was previously shielding a 10,000 zatoshi transparent input,
which was precisely enough to pay the ZIP 317 fee, and resulted in a
"shielding" transaction that had one transparent input, and no outputs
of any kind. Under our new `is_shielding` definition in `v_transactions`
this would not be a shielding transaction (it is effectively a "donate
coin to miners" transaction).
This fixes an issue wherein transparent outputs of transactions added to
the wallet via `decrypt_and_store_transaction` would not be properly
recorded as UTXOs belonging to the wallet.
Part of #1434
zcash/librustzcash@72d8df8e68 altered the
`v_received_notes` view to include transparent coins (renaming it to
`v_received_outputs`), and updated `v_transactions` to not separately
query transparent coins. The latter queried `v_received_notes` twice,
once to fetch notes received in a transaction, and again to fetch notes
spent in a transaction. The spent notes were obtained by joining on
the junction table `v_received_note_spends` to get the spent-in
transaction's ID. The commit retained the junction table join, but
didn't use it due to a typo, leading to notes being "spent-in" the
transaction they were received in. This bug had several effects:
- `account_balance_delta` showed `+change` for transactions in which a
change note was received that had not yet been spent.
- `account_balance_delta` showed `0` for transactions in which all
received notes had been subsequently spent.
- Transactions that spent funds with no change were omitted.
This also provides additional documentation for why it's necessary
to store ephemeral_addresses table entries at indicies that do not
correspond to valid addresses.
table, or to run an sqlite3 command. The latter is marked `unsafe`.
The name of the table must be a static string containing only `[a-ZA-Z_]`
characters. These are only usable if both `#[cfg(test)]` and the
"unstable" feature are enabled.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
when another wallet creates a transaction with an output to one of our
ephemeral addresses, and repair the implementation to pass this test.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Also change the return type of `find_index_for_ephemeral_address_str` to
`Result<Option<NonHardenedChildIndex>, SqliteClientError>` so that the
`expect` is in the right place.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
`find_account_for_transparent_address`) to take a `TransparentAddress`
rather than a `WalletTransparentOutput`.
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
within the gap. Also support paging for `get_known_ephemeral_addresses`.
Co-authored-by: Jack Grigg <jack@electriccoin.co>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
`addresses` table to a `NonHardenedChildIndex`.
(This moves where a `diversifier_index_be` field of the wrong length would
be detected and so is not quite a no-op, but that shouldn't matter.)
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
addresses within the gap limit. This should make recording TXOs found at
these addresses via `WalletWrite::put_received_transparent_utxo` work
correctly.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
`zcash_client_sqlite::wallet::transparent::ephemeral`. Also report the
account id and index for `SqliteClientError::ReachedGapLimit`.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
the transaction mined at an earlier height, out of the newly observed
transaction and any already referenced one. This slightly reduces the
chance of unnecessarily reaching the gap limit too early in some corner
cases.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
is ephemeral.
This also fixes `try_into_standard_proposal` to allow decoding from the
protobuf representation into a proposal that uses references to prior
ephemeral transparent outputs, provided that the "transparent-inputs"
feature is enabled.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
The `foreign_keys` pragma has no effect when used within a transaction,
so it should only be set at the top level. The `legacy_alter_table`
pragma should only be used in cases where its effect is explicitly
intended.
now implement a different strategy for choosing whether there will be any
change, and its value. The aims are:
* Ensure that it is possible to create fully transparent transactions with
no change (this will be needed for ZIP 320). The `InsufficientFunds`
error in this case should have a `required` field that reflects the
additional amount needed, according to the fee calculated without an
extra change output.
* Avoid leaking information about note amounts in some cases: an adversary
that knew the number of external recipients and the sum of their outputs
was able to learn the sum of the inputs if no change output was present.
* Defend against losing money by using `DustAction::AddDustToFee` with a
too-high dust threshold.
* Ensure that if a "change memo" is requested, there will always be a
shielded change output in which to put it. Previously, this would not
be the case when using `DustAction::AddDustToFee`.
Co-authored-by: Jack Grigg <jack@electriccoin.co>
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Daira-Emma Hopwood
Kris Nuttycombe
Jack Grigg
Kris Nuttycombe
Alfredo Garcia
Andrew Arnott
hattizai