2

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:

This is the problem ... https://github.com/ethereum/go-ethereum/issues/16691

Marcos Martínez
  • 545
  • 2
  • 9
  • 24
  • 1
    None of those transaction hashes appear to match the one submitted. My guess is you had a bunch of transactions pending and they were all picked up when you started mining. Stop mining and check if there are any pending transactions. Run your `eth.sendTransaction` again and check your pending submissions (without starting your miner). If you only see 1 pending transaction, turn your miner on and see how many processed transactions you get. – Adam Kipnis Aug 01 '18 at 02:40
  • Good idea, i will try it. But how that explain the abrupt decrease of coinbase balance? It started on 9.5 e74 and finish with less than 1 ether. I mean, on a PoA network, how can be possible to decrease the owner/coinbase account balance? i cant imagine one situation (i dont have a lot of experience with ethereum) – Marcos Martínez Aug 01 '18 at 02:44
  • The only thing I can think of is somehow you submitted transactions in a (possible infinite) loop. The pending transactions will help shine light. You can also check the `eth.getTransactionCount` – Adam Kipnis Aug 01 '18 at 03:40
  • Yes, thats possible too, i was sending only from metamask and the geth console, so it would be really difficult to do that.. but it might be kind of a bug of one of them. Also, see my edit, bots could be a reason too. – Marcos Martínez Aug 01 '18 at 03:43
  • I like his response. Try blocking the ports. Also, inspect the unknown transactions a see where the transfers are going. – Adam Kipnis Aug 01 '18 at 03:50
  • The transfers are going to two addresses that seems to be bots. Which ports?do you refeer to restrict rpc access? i cant, its a requirement for my project to make possible to hit the smart contract from any origin. What do you think about just dont unlock the account when running the node? – Marcos Martínez Aug 01 '18 at 03:54
  • I’m not sure why your node would need to be 100% open. If your contract needs to be public, deploying to the public blockchain will do that (you don’t even need to run a node to accomplish that). Instead of unlocking the account, sign the transaction and submit that. – Adam Kipnis Aug 01 '18 at 04:02
  • Same situation here https://github.com/ethereum/go-ethereum/issues/16691, bots... – Marcos Martínez Aug 01 '18 at 21:00

1 Answers1

3

[cross-posting here from Ethereum.SE for completeness]

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.

Raghav Sood
  • 81,899
  • 22
  • 187
  • 195
  • Indeed, there is an issue on github about this, https://github.com/ethereum/go-ethereum/issues/16691. Any ideas how i can expose my network to the internet, having my account unlocked without getting my private key vulnerable? – Marcos Martínez Aug 01 '18 at 21:25