How to safely and quickly identify a privileged transaction within a smart contract?

Question

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).

Answer 1

The smart contract could look at the number of ETH a cat being added has already sent, and how much TKN they received for it. It can then credit them with an additional nine times that amount, as part of the process of adding that address to the list of cats.

Where you run into issues is with the cap, and you'd have to decide your policy on this. You can issue refunds so that everybody who gets tokens gets them at the promised rate, but you have to decide who gets tokens if there's a delay between when a cat buys them and a later time when you mark evidence that they're a cat, and the cap is reached during that gap. Do you refund the cat, or do you refund the buyer who scooped up those last remaining tokens, and got confirmation of it? As long as you're clear, you can choose based on your objectives for the crowdsale.

---

The more straightforward way is to have a pre-crowdsale period in which cats can register as such, and if there's a later delay in getting cats properly marked it's not likely to be seen as unfair: if you want the bonus, you have to wait until the approval process is complete. If a cat wanted assurance this would be done in time for them to take advantage of the benefit, they should have done that in what I would hope would be a generous time window before the sale. If the cat didn't find out about this opportunity until near the end, and there wasn't enough time to get approved before the cap was reached, then maybe they'll just miss out and have to pay more attention in the future. Be sure you're focusing your marketing well in advance, not pressuring people into last-minute quick decisions. It'll seem a lot less scammy.

---

Your proposed nonces solution is not great for multiple reasons, including that it requires the user to trust you to broadcast the transaction giving them the better rate (which is not in your narrow short-term self-interest) if they deserve it. Also, they could have other transactions to drain their account of all except what's needed for the lower-cost transaction, so you don't necessarily have the power or flexibility you think that solution is giving you.