2
votes

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

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
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
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
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
I like his response. Try blocking the ports. Also, inspect the unknown transactions a see where the transfers are going. - Adam Kipnis

1 Answers

3
votes

[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.