In the old builder code in zcash_primitives, we would never pad spends. The new logic extends this with a bundle_required case, where the caller can force a 1-spend 2-output bundle to be created even if no spends or outputs are added to the builder.
There is an edge case here that is perhaps non-intuitive: if the caller sets bundle_required = false and then only adds outputs, the resulting bundle will not have any spends (whereas if they instead add spends but no outputs, padding outputs are added). This technically follows the prior logic, but now that we have a separate coinbase mode for the "no spends, no output padding" use case, we might want to reconsider whether we should always pad to at least one spend if we have any outputs.
This is distinct from #121; that PR fixes a regression relative to previous behaviour, whereas this would be a change to it.
https://github.com/zcash/sapling-crypto/blob/ab3aea55c0813c760e74d248bd3f16825b577514/src/builder.rs#L65-L71
In the old builder code in
zcash_primitives, we would never pad spends. The new logic extends this with abundle_requiredcase, where the caller can force a 1-spend 2-output bundle to be created even if no spends or outputs are added to the builder.There is an edge case here that is perhaps non-intuitive: if the caller sets
bundle_required = falseand then only adds outputs, the resulting bundle will not have any spends (whereas if they instead add spends but no outputs, padding outputs are added). This technically follows the prior logic, but now that we have a separate coinbase mode for the "no spends, no output padding" use case, we might want to reconsider whether we should always pad to at least one spend if we have any outputs.This is distinct from #121; that PR fixes a regression relative to previous behaviour, whereas this would be a change to it.