ref: 68ed9c34b0d4a2eaa0e49def372deabe4eb55daf jmp-pay/lib/electrum.rb -rw-r--r-- 1.7 KiB
Merge branch 'rubocop'

* rubocop:
  Update rubocop
Update rubocop

And use settings from sgx-jmp
Various Electrum Checks and Fixes

There were some issues with Electrum, and we lost a bit of confidence,
so I built these to help with that.

- This one is meant to be run in cron. It checks for addresses we've
  given a user that Electrum doesn't know we have. It just prints out,
  so we get an email and can go look.
  The purpose of this is to know before our users that we're missing

- This one is meant to be run in cron. It looks through the addresses
  that users has have been given to make sure the same address hasn't
  been given out to more than one person.
  It just prints out the issues, so we'll be notified and can take a

- This is one potential solution that can be run in response to
  duplicate addresses.
  Since I'm expecting an email from bin/detect_duplicate_addrs, this
  takes as input the text that was sent to us.
  It goes through each address and re-assigns it away from all users,
  parking the addresses on the support account so we still get notified
  when people send money, etc
  Because it takes output as input, they could be piped together in
  theory, but I never tested that because I assume some investigation
  would be warranted

- This script goes through every bitcoin address that's been given to a
  customer and makes sure that electrum knows to tell us about changes
  to that address
Cronjob to check pending BTC transactions

When they become confirmed, insert them into the transactions table.
We can never double-insert because of the PRIMARY KEY on transaction_id, so the
script is always safe to run even if something ends up in redis twice.
Endpoint that pushes all unknown transactions into Redis

The intent is to use `electrum notify <address> <app>/electrum_noify?address=&customer_id=`

The app asks electrum for all transactions on that address, and then checks
which ones we *don't* already have recorded in the transactions table.  These
are pushed into Redis to be picked up by a to-be-written job that will write
them to the transactions table after 3 confirmations.