As long as the amount is larger than the ZIP-317 per-input fee (0.00005), transactions can be built from faucet outputs with enough fees to not be considered spam, so you’re good.
I think the faucet is very useful! I would love if it supported testnet too.
Do you have a per-IP limit on claims? That might also help against people farming it.
Yes, actually ZecFaucet has various security mechanisms, to avoid this issue:
IP address
Browser fingerprint
Proxy / VPN detection
Claims are added to a wait list, any new claim with the same IP address, browser fingerprint or Unified address made in less than 120 minutes is rejected.
If a vpn is detected, the claim is rejected right away, using this free service to detect proxy/vpn: getipintel.net/
IP addresses protection can be bypassed with VPN, I believe browser fingerprint changes when opening a ingonito window, and VPN check isn’t perfect.
Requiring user registration can mitigate this problem, but I really don’t want to do this.
The faucet idea is to capture the old days of BTC faucets, direct transfers, no registration.
What really baffles me is the huge amount (using vpn, opening new browser windows, generating new UA for each claim*) of work this person is doing to collect few cents
* Just had an idea, maybe I’ll restrict addresses for a total of 10 claims (for example), that would force the attacker to generate and use large amounts of addresses, maybe this will make then give up.
Hi guys. Today we launched a new version of ZecFaucet.
This update brings a new layout. Much more modern and responsive than before. Now it actually looks professional!
Also changed a few things on the backend, trying to make the faucet more reliable.
One of the main new features is the addition of a new system for preventing fradulent claims: a Proof of Work algorithm! (as suggested by @Milton).
The faucet will present a challenge to the user, whose browser should find a specific hash. The difficulty of this challenge is dynamic, and will increase and decrease according to many factors, like faucet activity, user activity, and others. This system aims to be trivial for normal users, but computationally expensive (or at least annoying) for scammers.
We also decided only support unified addresses now on. Though I’m aware of the recent discussion regarding UA / t-addy leakage, we decided to only support UAs to make the faucet simpler to use.
Will the testnet be upgraded?
Yes. In the following week I’ll update the teestnet faucet as well.
It’s trickier than I imagined to run a testnet faucet. Testnet lightwalletd infrastructure isn’t optimal, blockchain reorgs also throws the faucet off. I’m planning to do a few things to avoid these problems. And hopefully make the testnet faucet a good experience.
Looking great! Good work! Love the idea of using PoW to mitigate drainers.
Using UAs to receive txs is fine - the issue is when wallets create transparent-including UAs and users not noticing that and posting the UA everywhere