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>
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>
changing its type from `ShieldedProtocol` to `PoolType`.
Also fix compilation errors when the "orchard" feature is used without
the "transparent-inputs" feature.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
As part of this, we migrate to `secp256k1 0.27`. This version does not
bump `secp256k1-sys`, so remains compatible with the `libsecp256k1`
revision used in `zcashd`.
The `zcash_primitives::legacy::keys::AccountPrivKey` encoding also
changes to preserve the transparent extended key metadata. Previously
the type was documented as such, but only encoded the private key and
chain code; the new encoding now matches the documentation. As a side
effect, the unstable encoding of `zcash_keys::keys::UnifiedSpendingKey`
also changes.
Closeszcash/librustzcash#1407.
Closeszcash/librustzcash#1408.
Prior to this change, the recipient of a sent transaction would always
be shown as the protocol-level address, instead of any unified address
intended as the recipient. Now, instead of reencoding the recipient
address, we use the original `ZcashAddress` value from the payment
request.