I'm running a crowdsale for dogs and cats. If you're a dog, you can earn my token (TKN) at 1 ETH per TKN. But, if you prove you're a cat, you can earn TKN at a rate of 0.1 ETH per TKN (meaning you get a better rate) in the crowdsale.
As the owner of the crowsdale's smart contract, I'll dynamically add to a list of who is a cat and who isn't a cat using a smart contract. Each time a user proves to me they are a cat, I'll post encrypted evidence (think zero-knowledge proof) that they are a cat. Using an address they give me, I'll add them to a list of cats within the smart contract. When a user sends ETH from that address, they should be identified as a cat. But, this only works if my transaction adding them to the list of cats has already been executed by the time they send it.
Is the best solution to ask a cat to wait for 5-10 confirmations to ensure the privileged address is added to the smart contract? I.e. is this how long to wait to be sure the smart contract knows the address they are sending from belongs to a cat not a dog. What number of confirmations is considered secure in Ethereum?
It would be great to not make the cats wait like this -- you could do it if Ethereum were capable of verifying signed messages on its platform. But the fees associated with verifying a signed message would be too high.
Something like child-pays-for-parent could work? If the cat sent me their donation transaction, or if I sent them a privilege-enabling transaction to send first, the donation transaction could be conditionally executed upon the accurate execution of the privilege-enabling transaction. But I'm not sure I've seen anything like this in Ethereum, only in bitcoin.
Another option would be to have the user to send a donation in ETH, and not issue tokens until they are confirmed to be or not to be a cat. This would require locking their tokens indefinitely. It would make it risky to run a capped crowdsale, as you'd have to assume that every donation had the better conversion rate, even if it were later proven not to have had one. Asking users to suggest a conversion rate for themselves might temporarily alleviate the cap problems.
A last thing to use might be nonces? I could ask the user to provide me with two signed transactions, each with the same nonce, with a different amount of Ether depending on the conversion rate. Depending on whether they are a cat or not, I will broadcast one of the transactions. While technically possible, this would probably scare the user into thinking I am somehow robbing them twice, and also is a very inconvenient user experience (especially if there are more than two possible conversion rates).