Eriq

Created a script to get the connections every time a new node connected. Everything looked normal in the peer list until I saw many nodes from:

100.42.27.* (around 200 peers)

193.142.59.* (around 200 peers)

199.116.84.* (around 100 peers)

209.222.252.* (around 150 peers)

91.198.115.* (around 150 peers)

The 100.42.27., 199.116.84., 209.222.252., and 91.198.115. all belong to "Lionlink Networks".

These are around 600 nodes that are under that ISP and account for 20-30% of all nodes seen from a 3 day survey span.

This looks suspicious to me and the massive amounts of nodes raises many red flags and does not look natural at all.

~~If these were malicious, in concept, with the 13 default IN/OUT peers, if all connected are malicious, the innocent one would have no other data to compare it to~~.

(Edit: Updated Theory: having many nodes has the ability trace transactions and block miners easier based on timing attack)

Created a simple sample jackpot website for educational purposes, especially educational when you look at the rigged version of this even thought it looks legit https://github.com/ErikASD/simpyle-xmr-arcade-rigged with all the bs provability fair.

I was interested on which the best way to accept XMR programmatically and made this concept payment processor that credits PGP based accounts with the XMR amount deposited like an exchange would have with sub addresses assigned to each account.

When withdrawing, It is a lot more difficult to implement as transfer RPC call cannot auto-calculate the fee.

Workaround:

Estimate transfer is sent with no relay

transfer2 with no relay is sent after deducting fee manually.

Checks for proper deduction and then uses relay_tx for the final step.

If you have any suggestions on how to improve this, especially if you have a better architecture in mind for the withdraw/deposit functionalities.