Hi,
Is it technically feasible / possible to airdrop ZSA token to every Zcash holder? cc @LeCryptoMath @str4d
I’m interested in airdropping tokens to ZEC holders.For example:
Thanks
Such as the ECC Agoric BLD tokens?
Nope. It will be a new token inspired by successful airdrops like SOS. I’m super interested in this!!
There seems to be a fundamental misunderstanding of shielded transactions and addresses in this question. So maybe someone smarter than me can clarify.
For #1, you can get the balance of every transparent address, but for #2, you can’t even get the set of all shielded addresses… and even if you could do that, you wouldn’t have the fvk to calculate the balance for every single shielded address.
I thought this was the beauty of sapling/shielded? We don’t get spam to our shielded addresses. On ETH and BSC spam coin from drops are out of control.
For your #1 it also seems a little odd that the transparent hodler use case is somehow more valuable than the shielded hodler or even folks who actually transact in zcash. Kinda moot at this point but just giving my opinion.
Unless I’m misunderstanding something, either 1) folks would have to opt-in somehow to reveal the portion of their stake that they wanted to apply toward a drop OR 2) there’d have to be some proof of position ownership mechanism at a certain point in time. I think this was discussed in other threads regarding shielded stake-weighted voting.
I might be missing something though
Great points. I’m not proposing solutions. I’m poking intellectual minds to come up with a general privacy-preserving solution, that might lead to architectural changes to the way Zcash works.
What about dropping to notes? You couldn’t weight it by amount yet each note spend could specify a specific block checkpoint, instead of a recent one with its full privacy offerings, to prove historic existence and add an additional OP_RETURN output specifying a transparent address to redeem coins to. Since this operation only costs the TX fee, no privacy is leaked since a new note is immediately created and usable with the full privacy set.
This works for colored coins as described, where OP_RETURN outputs are used as an additional TX DAG. For ZSAs specifically, you could specify a shielded address and then have a central server execute the airdrop. This would place a shielded address on chain though, which has relevance to the recently posted quantum computing thread.
You kinda lost me at this part. So, someone with 1000 ZEC distributed on 1000 notes is better off than someone with one 1000 ZEC note? The former would get a bigger airdrop? That seems gameable.
Also, tbh I didn’t understand your ZSA specific suggestion (it seemed to me like you were crossing wires with what can be done with shielded notes vs transparent eg p2sh)… maybe it’s just me though.
I guess if your suggestion makes more sense than what I got, then others might be able to comment too. 
I think its possible. I could probably make a really cheesy demo on top of something like BabyZoE if it helps. Basically the way i would think of it is, you would be defining a new kind of nullifier associated with each note. You can think of the nullifier as like hash(tag, noteSecret). Then to claim the airdrop, it would be similar to an unshielding transaction, just with the new nullifier instead, hash(tag2, noteSecret). This way the airdrop claims are completely separated from other uses of the note, but the value can be used to weight the airdrop claim
I like cheesy ELI5 demos 
I also would advocate for these kinds of minting strategies but I’m doubtful either of these would be included in ZSA v1. My understanding is v1 will only allow for minting on transparent addresses only. We are also yet to verify if we can airdrop based asset allocation of another asset (E.g. zcash).
There may also be a few complications that may need to be addressed with regards to shielded minting like auditablity of tokens etc. For example once asset has a shielded “mint” the total number of assets may be unknowable. While freedom to do these kinds of asset allocations would be awesome we also need to have a pretty in-depth discussion about what we want the ZSA ecosystem to look like.
This isn’t completely true because presently we do know how many ZEC exist in each pool. So if we were to airdrop to all ZEC holder in a pool we know the total assets required.
My personal view is we may want to keep the minting actions simple and only to transparent addresses and allow for more complex transactions.
For example:
I didn’t read the OP very carefully, reading again I see it’s about future ZSAs in Zcash proper (which will have a different design space), whereas I’ve been trying to answer the related question: could an entirely separate project (a friendly fork?) create an airdrop to ZEC shielded pool holders?
So anyway, yolo, this is work-in-progress but I won’t be able to take it any further for a week or so
There’s not a whole lot to it, it’s a clone of the TornadoCash circuit, except that the nullifierHash function is replaced with a different function airdropifierHash that just uses different generators.
tornado-core/claimairdrop.circom at snarky-airdrop · amiller/tornado-core · GitHub
It should be possible to demo this by minting an airdrop to the TornadoCash shielded pool on testnet or something
This is a correct analysis and why this idea is flawed. You could also force revealing the amount of the note while you’re at it, also via OP_RETURN to include the keys, but…
Very interested in amiller’s work though.
Yes.
[It’s quite possible new zkp L1s that are popping up might want to airdrop their token to ZEC holders in shielded pool. It’s a neat way to acquire users! I’m glad you figured high-level design for the problem you originally thought of]
I’m more interested in native ZSA airdrop to a shielded pool. Claiming process could reveal some information but based on what you said, my gut feeling says this can be done in privacy-preserving manner!
Is it possible to build a demo with str4d code for ZSA to create airdrop on Zcash Testnet?
Just found your previous tweets:
This is for known to the distributor accounts where they set balances. For airdropping shielded assets to shielded ZEC, you’d have to have users doxx themselves to you under this model, yet they could use a distinct address to claim the funds, therefore not doxxing themselves to the public.
If ZSAs use the same value commitment basepoint, this would be trivial so long as you apply a fixed multiplier to all accounts and have the ability to post new commitments into the tree as part of the mint function without doxxing them (which breaks supply auditability). For a Pedersen commitment aG + bH, where a is amount, b is blinding factor (easier to explain, I know another project uses b for amount and I’d have to check Zcash’s preferred ordering stylization), any multiplier x can be applied to create axG + bxH. Since the user knows the randomness and amount of their output, they’ll know the new randomness and amount as well, enabling spendability.
I believe ZSAs are using DIFFERENT basepoints though. While I’d expect the randomness basepoint to be the same (different amount basepoint, distinct randomness basepoint should enable transfers without revealing the sent asset, even allowing for TXs sending multiple assets in the same TX), this creates the issue where we’re now doing axG on one side and a2G2 which… is gibberish. These commitments are verified by proving you know the blinding factor behind sum(inputs) - sum(outputs). If the amounts are the same, they’ll cancel out, making that all that’s left. axG - a2G2 though? Those aren’t the same. It’s not even a known value. It’s some value, sure. No one knows what it is though because the relationship between G and G2 is unknown.
You can trivially convert this to work, albeit with an insufficient 2^64 searchable space. If you require the blinding factors to be the same, and reveal them, you need a DLEq proof for axG and a2G2 (where a DLEq proof says ax == a2 given their representations against G/G2). This is just brute forceable as it’s not 2^256.
There probably is some blindable DLEq proof available, and I spent the past hour drafting one for the hell of it. I think it works, yet I don’t care to post it at this time until I check in with a couple people. This means for the existing commitment set, if you can insert new commitments without revealing their amounts, you can do 100 AIR to 1 ZEC, so long as you can actually create a full Zcash output out of this (and not just the value commitment, which… almost certainly won’t be feasible without at least getting a proof a certain address owns a certain output commitment).
Then there’s always going to be circuits available, with the distinction they’d have to be in Zcash consensus somehow, and temporary/selective de-anons. The latter is how this will practically be accomplished.
Then the final comment is ZSAs are not a full featured DeFi platform and even actions as simple as airdrops likely are not feasible without reverting to transparency.
Sorry for having poor notation, to any fellow devs who read this. I meant to do a very basic explanation non-devs may have a chance at understanding, not submit a paper 
EDIT: This is a really late addition, sorry. I never saw the previous post, just saw it now, and assumed it was new (not seeing it’s dated March). Sorry about that…