Any projects which want to use Hush code from now on will need to be licensed as
GPLv3 or we will send the lawyers: https://www.softwarefreedom.org/
Notably, Komodo (KMD) is licensed as GPLv2 and is no longer compatible to receive
code changes, without causing legal issues. MIT projects, such as Zcash, also cannot pull
in changes from the Hush Full Node without permission from The Hush Developers,
which may in some circumstances grant an MIT license on a case-by-case basis.
This commit drastically improves the privacy of the HUSH anonymity set
under attacks which ingest wallet.dat's which have been obtained by
seizure, i.e. stealing someones HUSH wallet.dat and putting it into
chain analysis software. Ciphertrace is known to do this to ZEC and XMR
and we can assume all chain analysis companies are implementing new
ways to de-anonymize privacy coins with any data they can obtain.
Instead of randomly sending to a randomly chosen static address,
hushd Sietch zdust addresses are now randomly generated at run-time. These
addresses are not stored in wallet.dat in any way and their private keys
are not known except by the internal memory of hushd for a few milliseconds.
This data is not stored in long-lived data structures of hushd, only as long
as the RPC z_getnewaddress is running or the equivalent function for internals
code paths. The seeds or private keys of these addresses are never stored on disk.
This now brings hushd on par with SDL, which already does this via a
different but equivalent seed phrase technique.
With this technique, if a HUSH wallet.dat is seized, it's impossible to tell
if any of the shielded outputs are random Sietch zdust with random data payload
or a one-time-use zaddr with encrypted payload.
The sendmany RPC was broken in the 3.3.0 release due to a bad merge of upstream KMD code,
resulting in this kind of error:
./src/hush-cli sendmany "" "{\"$TADDR1\": 0.0001, \"$TADDR2\": 0.0002, \"$TADDR3\": 0.0004}"
error code: -3
error message:
Amount is not a number or string
No matter how many recipients you give, it will always "fall off the end" of the array, because it increments i twice per loop.
That means AmountFromValue(sendTo[i]) is given an invalid amount and the RPC errors out, with no loss of funds.
This is not a consensus bug and only nodes who want to use the sendmany RPC need to upgrade.
Since GUI wallets do not use this RPC, it's most likely pools and exchanges that would want this.
