1

Im working on a distributed application using Ethereum, the go-ethereum implementation (Geth).

On a Digital Ocean droplet (Ubuntu 16.04) i have installed geth.

I have created a structure like this:

devnet$ tree -L 2
.
├── accounts.txt
├── boot.key
├── genesis.json
├── node1
│   ├── geth
│   ├── keystore
│   └── password.txt

I have:

  • One bootnode/discovery node
  • One Seal/full node

The seal node is initialized this way:

geth --datadir node1/ init genesis.json

Then the bootnode:

devnet$ bootnode -nodekey boot.key -verbosity 9 -addr :30310
INFO [02-07|22:44:09] UDP listener up                          self=enode://3ec4fef2d726c2c01f16f0a0030f15dd5a81e274067af2b2157cafbf76aa79fa9c0be52c6664e80cc5b08162ede53279bd70ee10d024fe86613b0b09e1106c40@[::]:30310

And after the bootnode is listening, i run geth on the node1:

geth --datadir node1/ --syncmode 'full' --port 30311 --rpc --rpcaddr 'localhost' --rpcport 8501 --rpcapi 'personal,db,eth,net,web3,txpool,miner' --bootnodes 'enode://3ec4fef2d726c2c01f16f0a0030f15dd5a81e274067af2b2157cafbf76aa79fa9c0be52c6664e80cc5b08162ede53279bd70ee10d024fe86613b0b09e1106c40@127.0.0.1:30310' --networkid 1515 --gasprice '1' -unlock '0x87366ef81db496edd0ea2055ca605e8686eec1e6' --password node1/password.txt --mine

Note: this are examples, the real ip, bootnode "enode" value and account arent those.

On this private ethereum network i have deployed a ERC20 contract, with a basic Transfer function, so, i wanted to invoke that function from Metamask, using some random address.

For that, i needed to get some ETH in my account, so i have connected to the geth console and transfer some ether from the eth.coinbase to that addres:

eth.sendTransaction({from:eth.coinbase, to:"0xf17f52151ebef6c7334fad080c5704d77216b732", value: web3.toWei(10, "ether")})

After that, I discovered that some transactions that I had no way to identify, i mean, it was only a transaction to send ether from one account to another, why that result in multiple transactions submitted?

Here is a screenshot of the situation:

enter image description here

Also, every one of those transactions is decreasing the eth.coinbase balance (eth.coinbase == the address that deploys the contract), so i started with a huge amount of Ether on that account and after some of those "ghost" transactions the balance of eth.coinbase was like 0.0026 Ether..

So, i have 2 questions

  1. Is there any scenario that could decrease the contract owner address/coinbase balance?
  2. Any ideas of why those transactions appear?

EDIT:

Caused by bots:

1

Digital Ocean does not block any ports by default, to my knowledge.

In all probability, your node's RPC is publicly accessible, and when you unlock the account to send your transaction, a bot tries to sweep the rest to its own address (potentially more than one, since there seem to be multiple recipients).

Try blocking access to the RPC ports from outside the machine using ufw, or simply turn off RPC, since the console works over IPC.

Indeed, if you look at 0x6e4cc3e76765bdc711cc7b5cbfc5bbfe473b192e and 0x7097f41f1c1847d52407c629d0e0ae0fdd24fd58 on the mainnet, you can see that they have swept close to 15 ETH, and the pending transactions reflect a common tactic of such bots, which is to presign transactions of varying value with higher nonces while the rpc is unlocked.

  • Yes, D.O doesnt block the ports, but, if i want to access from outside the droplet via rpc or ws i cannot take that restriction, and thats a requirement for me. About the bot theory, which action is it doing? I mean, i dont know which operation can make the coinbase empty from the outside. Could you explain that more? its also curious that only when i execute the sendTransaction function this happen – Marcos Martínez Aug 1 '18 at 3:04
  • Also, there are 2 recipients, and one of them is the contract address – Marcos Martínez Aug 1 '18 at 3:08
  • See my edit, they are almost certainly bots, their mainnet accounts reflect the same – Raghav Sood Aug 1 '18 at 3:09
  • You can also use ufw to restrict RPC port access to just the IP you will use to call it. – Raghav Sood Aug 1 '18 at 3:10
  • 1
    Hmm, that is odd. I would suggest opening an issue on Github for geth, and detailing your network setup. They can likely help you better than I can – Raghav Sood Aug 2 '18 at 3:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.