bublina faucet amounts are really small

[ajtowns]

Hi,

https://signetfaucet.bublina.eu.org/ is sending really small amounts, eg 836 sats in https://mempool.space/signet/tx/9337037cad2c0f441e7802a356d9c794f962894cd89900dafb5228670d2acc48 despite having 6k sBTC in its wallet. Is there any reason for it to be so crazy low? The code here seems to imply a value between 5000 sats and 332670 sats, so presumably is not current anymore.

Doing something like:

 $ bitcoin-cli -signet getbalance > BALANCE.new; mv BALANCE.new BALANCE
 $ python3 -c 'import random; print("%.8f" % ((random.random()+1)/2e6*min(6000,float(open("BALANCE").read().strip()))))'

would let you have a random amount that scales with the faucet wallet's balance.

[jsarenik]

Hi!

Thank you for the feed-back!

Yes, the faucet service was being recently used as a honeypot for gathering addresses since the limits are shared between multiple different faucets.

See for example this:

https://mempool.space/signet/tx/70f7322888a545a157c4cc46b594e7aa39a107ac44c4b2a0d5a13946a67a0680

This bot seems to not be bothered by the low amount. And the IP(v4 in this case) addresses of these Goodline (around the world) clients will be denied service by this and befriended faucets on the next try.

Thanks for the code suggestion! To see the faucet's current GET.sh script head over to https://signetfaucet.bublina.eu.org/cgi-bin/GET.sh.txt and notice that many lines are commented-out. The amount is not being determined by this script anymore, nor by the client-supplied optional API parameter.

I was thinking more about adding a "captcha-like" parameter where the requestor will need to supply the current block's height and shortened code (last doublet of the block hash and doublets' "check" in one byte, doing three unpredictable and easily verifiable bytes together). Example: Signet block 213581 aa3b a1 (where a1 in the end stands for 10 (hex A) doublets which do not contain zero and 1 all-zero doublet)

       _|_|      _|  _|_|_|    
     _|    _|  _|_|        _|  
         _|      _|    _|_|    
       _|        _|        _|  
     _|_|_|_|    _|  _|_|_|    

     _|_|_|_|    _|_|      _|  
     _|        _|    _|  _|_|  
     _|_|_|      _|_|      _|  
           _|  _|    _|    _|  
     _|_|_|      _|_|      _|  

  ,---   .123 4567 89ab cdef   ---,
  | ..   .... .127 8f59 a752   .f |
  | 1.   f17. 9335 a5be 731f   1f |
  | 2.   257. 8cc4 a541 e3.7   2f |
  | 3.   1dd2 d71. cdc2 aa3b   3f |
  '===   ==== ==== ==== ====   ==='
   sk:   aa3b a1

Maybe some young blood, an apprentice, could help so if you know anyone interested, please send them my way.

The amount was changed now (see example) to send two-fold more sats which may resemble real stacking. See signetfaucet.sh, mktas.sh and most importantly awklist.sh. fee.sh just returns the vsize of the decoded Bitcoin transaction (using bch.sh inside any network directory so one does not need to add -datadir or -chain to bitcoin-cli, see cls for more).

[jsarenik]

@ajtowns and yes, the current faucet's balance is 6273.38730076, but was around 2500 few months ago. I am feeding it from fauCAT (one machine here running Signet in Inquisition).

[ajtowns]

@ajtowns and yes, the current faucet's balance is 6273.38730076, but was around 2500 few months ago. I am feeding it from fauCAT (one machine here running Signet in Inquisition).

Seems a little bit wasteful; if you want more, just ask? Or I could do the same thing I'm doing for my and kalle's faucet and just automatically feed a percentage of the coinbase reward your way?

I was thinking more about adding a "captcha-like" parameter where the requestor will need to supply the current block's height and shortened code

I feel like spammer folks will just automate that, and it'll only end up inconveniencing the newbs that we'd like to help... Hmm, random idea; how hard would it be to do auth via github, and then rate limit by github account (0.01 sbtc first time, 0.25 sbtc/week thereafter)? Maybe something like that could work...

[ajtowns]

FWIW, we tweaked up kalle's faucet code to (a) batch payments, (b) send the batches at regular intervals, (c) limit the maximum total funds sent in a batch; but that's all in python, and is probably annoying to translate to shell. Could be worth looking at; makes spam attacks a little self-limiting.

[ajtowns]

Or I could do the same thing I'm doing for my and kalle's faucet and just automatically feed a percentage of the coinbase reward your way?

You should start getting 100 sBTC every 50 blocks shortly.

[jsarenik]

Thanks for pointers! I have missed @kallewoof 's idea of batching that would silently ignore repeated requests from the same address. Let me think…

[jsarenik]

First, let me say I thought about batching some time ago but without the addition of silently ignoring retries from the same IP, which I like a lot, but still do not know how to handle this

The "misuser" in this case has access to huge number of IPv4 addresses never seen before by this faucet (or at least addresses seen long time ago, enough that they were forgotten).

And this all even without publicly sharing what is my exact time of when the cleanup happens (an any other unsuccessful try would extend the time IP is remembered and blocked).

I am wondering if and how it would be possible to allow very easy operation without a "captcha" and still ignore the "bots".

Here are some ideas:

• use Cloudflare Turnstile
• use batching
  • batching would be done in mod 9 of a blockheight, so that there is time to silently remove any retries — example: batch=($height+(9-$height%9), the current Signet block is 214015 and batch=214020 and the batched entries are stored in $network-$batch directory in a simple form of a file named by IP address (easy to remove on retry) containing the receiving address to get sats from the faucet at)

[ajtowns]

First, let me say I thought about batching some time ago but without the addition of silently ignoring retries from the same IP, which I like a lot, but still do not know how to handle this

At some point, it's probably better to just not worry about it? We can always do a signet reset of some sort and start redistributing coins from scratch if it becomes too big a deal; but as it stands the 20.1 sBTC that wallet has accumulated is less than a single block's reward currently, and given the current distribution, the bublina faucet will recover that amount within ~10 blocks.

• batching would be done in mod 9 of a blockheight,

A delay of ~4 blocks (on average) is expected to be about 40 minutes, which seems like a long time to wait. Just remembering the last 9, 144, 1008, 2016 blocks worth of requests and trimming duplicates would probably be friendlier?