Zcash had no reason to change this and they did not, and so this behavior is baked in deep to all Bitcoin and Zcash forks.
In light of the ITM/Metaverse attack, this determinism is considered dangerous by the author. The reason is that the
ITM/Metaverse attack utilizes the fact that wallet operations are predictable to extract more metadata than previously thought possible from z2z and t=>z xtns. The only way to prevent that is to break the assumption of predictable wallet behavior.
Code which uses purely raw transactions and broadcasts them to the network needs to do extra work to support Sietch.
This is why SDL has it's own implementation of Sietch, and any kind of hardware wallet support that uses raw transactions
in the future, would need to learn about Sietch.
### Metadata Attacks Against Sietch
Yes, Sietch can be metadata-attacked itself!
TLDR: Worst case is that an attacker steals wallet.dat files and does an immense amount of work to reduce privacy back to pre-Sietch levels, using the ITM attack.
At first there was a single Sietch implementation of 200 zaddrs that were fixed. If the wallet.dat owning those zaddrs were stolen, that could be used to delete all the Sietch "privacy dust" from the transaction graph, making the job of blockchain analysts and/or ITM attackers much easier. This theoretical attack is what prompted dynamic Sietch addresses and also a better way of generating zaddrs inside SDL: using [HIP39](https://git.hush.is/hush/hips/src/branch/master/hip-0039.md) seed-phrases to generate a single zaddr and then delete the seed phrase. This method leaves no wallet.dat on disk to steal and the private key material for the zaddr only existed in memory a short time.
Additionally, each zaddr is not linkable to each other since they were derived from different seedphrases. SDL uses this method in production currently.
Originally, `hushd` used 200 static zaddrs and SDL 10,000 static (HIP39-derived) zaddrs in `SDL`. hushd generates random public keys to derive each zaddr,
achieving unlinkability while avoiding the added cost of generating seedphrases.
There is no wallet.dat to steal to recover data for most Sietch zoutputs. This leaves a dead-end in blockchain analysis software, that prevents algorithms from being effective.
Dynamic Sietch zaddrs make the entire process much more secure by preventing analysts/attackers from even knowing the zaddrs that could potentially be a Sietch output. These dynamic Sietch zaddrs are generated at run-time and private keys never even written to disk, nor part of the `hdseed` of any wallet.dat in the case of `SDL`.
Sietch-enabled Hush Protocol can be thought of as using the ideas of combinatorial explosion and non-determinism to thwart brand-new
blockchain analysis techniques. Non-determinism is the stronger weapon, but it does not add enough privacy unless we add in the appropriate amount of combinatorial explosion to linkability analysis. Together they are a potent weapon which also give us a knob
to turn to increase future security, i.e. the minimum number of zaddr outputs allowed in a transaction.
This is why both techniques complement each other and have a greater privacy improvement when used together.
Dynamic Sietch addresses are in production in both hushd and SDL currently. More blockchain history uses the
new dynamic addresses, so any attacks against the first implementations have been mitigated.
Originally there were 4(!) implementations of Sietch in Hush world, 2 inside of `hushd` internals and 2 for `SilentDragonLite` which uses raw transactions and not the RPC interface of `z_sendmany`. Each of the 2 implementations has a static (drawing from a fixed pool of Sietch zaddrs) and a dynamic version (dynamically generating Sietch zaddrs at run-time). The static implementations went into production as of `Hush 3.3.0` and `SilentDragonLite 1.1.3`
### Why do some Sietch tx's have only 3 shielded outputs?
z_shieldcoinbase, which shields coinbase (mining) funds, uses 3 outputs instead of the normal sietch ~8 zouts because it's trivial to see that it's not a normal z2z, because it has taddr inputs. Trying to blend in with other z2z tx's just won't work. So instead, metadata leakage is reduced by creating 3 shielded outputs (zouts) which makes it harder for attackers to figure things out. 8 outputs could have been used for these transactions as well, but that doesn't hide the fact that they are shielding mining funds, takes up more bytes on the blockchain and makes the transactions slower to create. The reason ~8 was a good choice for z2z tx's is because sometimes you are sending to a few addresses, and ~8 zouts hides that metadata leakage. But when you shield coinbase funds, you are always sending to a single address, so 3 zouts is sufficient.
## Does Sietch protect transactions with more than 8 outputs?
Currently it does not. Originally this question was asked roughly as "If a shielded tx has M outputs where M>8, will Sietch create a transaction with M+8 outputs?" The answer is "No" because that wouldn't actually reduce metadata leakage. For example, if you make a ztx with 10 outputs, and Sietch always turned that into 18 outputs, then an attacker would know there was originally 10 outputs and 8 were added. Always adding a fixed number of outputs does not reduce metadata leakage.
## Is it possible for Sietch to reduce metadata leakage on transactions with more than 8 outputs?
Yes. This will be implemented as a future improvement to how Sietch works.
