Here’s a more concrete sketch of my idea.
A poll response is a reduced form of a transaction:
- A poll ID (something unique to the poll, so that prior poll responses can’t be replayed against newer polls).
- The public poll response (message etc.)
- An anchor for the height at which the poll is being conducted.
- A SpendDescription (including nullifier) per note being used for polling.
- Dummy notes could potentially be used, but I don’t think they should be encouraged, because they are unlikely to contribute any privacy (the nullifiers for the real notes will eventually be revealed, whereas the nullifiers for the dummy notes would likely never be seen on-chain).
- An Output proof, plus necessary public commitments, to whatever change is not being used in the poll (respondents may wish to use some round amount, or an amount lower than their real input balance).
- A
valueBalancefield showing the total funds being used for the poll. -
bindingSig(bindingvalueBalanceto the spends and outputs).
Signatures would be over the above format instead of using the SignatureHash algorithm. The signatures themselves might be moved around to make this easier.
(A private version of this could be created where there is a near-standard OutputDescription containing the poll response encrypted to the poll operator’s Sapling address. In this case valueBalance would be zero and could be omitted, but bindingSig would need to remain.)
This poll response has the following properties:
- Smaller than the equivalent fully-shielded transaction, and can be explicitly specified as non-malleable.
- Poll response can be an arbitrary message (either publicly or privately).
- Poll response can be associated with an arbitrary amount of Zcash (up to the total amount controlled by the respondent). This includes zero (in both public and private schemes), enabling polls of coin-holders by number of notes rather than value, which is maybe useful?
- The poll respondent’s Sapling address (that controls or controlled the funds) does not need to be single-use, because it is never revealed.
- It is possible to verify both that the polling funds existed at the polling height (by the anchor), and that the funds were unspent as of that height (by checking that the revealed nullifiers did not exist in the nullifier set at the polling height).
- Double-spending in poll responses is prevented by the nullifiers.
- This has the explicit downside of linking the poll response to the on-chain transactions. If a single poll response uses several notes, and those notes were spent separately on-chain, this would link the on-chain transactions. I think this is unavoidable for any retroactive scheme (e.g. if one poll response were created per note, the linkability then just moves up one layer, to figuring out whether the same person submitted several poll responses).
- If the poll height is picked in advance, users can prevent this issue by merging their polling funds into a single note before the poll height, and then unmerging them after the poll height. This ensures that the on-chain transaction linked to the poll is only the unmerging (or first subsequent usage) transaction.