Endless loop emptying an account with Contact Creations

[bortzmeyer]

System information

Geth version:

Geth
Version: 1.4.8-stable
Protocol Versions: [63 62 61]
Network Id: 1
Go Version: go1.6.2
OS: linux
GOPATH=
GOROOT=/usr/lib/go-1.6

OS & Version: Ubuntu, kernel 3.14.32
Commit hash : Ubuntu most recent package

Not sure it is a bug, but I asked the question on StackExchange and there is no other explanation yet.

Expected behaviour

Actual behaviour

As soon as I add ether to the account 0x22e1472e3486dd72f4d65e1f6ca7b2f49205fc26 it is emptied automatically with Contact Creations (with an empty contract).

You can see it with any explorer. Here is my last attempt, as seen by Etherscan:

0x07b541ef53a5aa2d3e22cd8bc1a8cb4e2f982be0f76ed8f96dc7774de834cc84 1793620 22 secs ago 0x22e1472e3486dd72f4d65e1f6ca7b2f49205fc26 [Send] Contract Creation 0 Ether 0.04400132
0x797986800b4a66516f675387952eab5e87be051b38019b6ac55216b4dcb1c6a4 1793620 22 secs ago 0x22e1472e3486dd72f4d65e1f6ca7b2f49205fc26 [Send] Contract Creation 0 Ether 0.04400132
0xa63c1ce1d68c31e84f2107a5a5c6e936f0cfc45490e00676d675030ec931d5be 1793618 38 secs ago 0xc90cd1fa9940a4d4a07a37c53bb4f423fd286945 [Receive] 0x22e1472e3486dd72f4d65e1f6ca7b2f49205fc26 0.1 Ether 0.00042

When the account is empty, contract creation of course stops, and resumes a few seconds after I add ethers. I tried:

• restarting geth
• running geth with --cache "0"
• checking with ps that no program was running on my machine, sending requests
• it does not come from RPC, since it is not enabled

None of these changed anything.

The contract creations have stable characteristics: 2300000 gas units, empty contract, data 0x5b620186a05a131560135760016020526000565b600080601f600039601f565b6000f3 But I don't know how to use these to investigate.

So, I certainly made a stupid mistake but my question is which one? How to investigate such a problem? Where is the ghost?

Steps to reproduce the behaviour

If only I knew...

Backtrace

No crash, no backtrace

[bortzmeyer]

Also, the address I mentioned is an account, not a contract.

[karalabe]

You may have used a script to send hundreds of transaction/authorizations into the network which are cached by some nodes for later execution. They cannot be executed if you don't have enough balance but may become executable when you add Ether to your account.

Geth discards these transactions since about Christmas so no recent Geth node will retain such unexecutable transaction, but any other node flavor might indefinitely keep those transactions around and re-propagate when you have funds for them.

I have to run niw but will try to explore the network a bit to see where these are coming from.

[bortzmeyer]

I also tried to remove the database (geth removedb) in case the problem was local to my node, but it changed nothing (see http://etherscan.io/tx/0xf5f0bbbe6a0d9bf6c058f9c9ec9186275e5ea3c2225856a8b61e7c466d2cebfd )

Nothing appears in geth's log. Here, the transaction is the one moving funds to the problematic account, then we see only ordinary synch:

I0706 09:23:18.865998 eth/api.go:1193] Tx(0xa90e1c824ffa3432b4b531b8a2d19fa54ff03e53b05cf029c22c15a98527ec39) to: 0x22e1472e3486dd72f4d65e1f6ca7b2f49205fc26
I0706 09:23:19.670064 core/blockchain.go:964] imported 1 block(s) (0 queued 0 ignored) including 4 txs in 696.416995ms. #1833862 [afc9143c / afc9143c]
I0706 09:23:31.208743 core/blockchain.go:964] imported 1 block(s) (0 queued 0 ignored) including 6 txs in 126.614678ms. #1833863 [a95c5de6 / a95c5de6]
I0706 09:23:40.800766 core/blockchain.go:964] imported 1 block(s) (0 queued 0 ignored) including 2 txs in 35.849426ms. #1833864 [01bfa1c7 / 01bfa1c7]
I0706 09:23:58.698807 core/blockchain.go:964] imported 1 block(s) (0 queued 0 ignored) including 5 txs in 4.008110202s. #1833865 [f2677296 / f2677296]

[StevenBerryman]

Out of interest did you run the code that was being proposed by the Slock.It guys when the DAO was being attacked? In fact looking at your transaction I now know you did.

I have just hit actually the same issue with my account 0x81ea02f9f865d072cf75a123f83d25ac22d1dd8a and reading karalabe comment it suddenly dawned on me what happened. I had run that script on an account with a small amount of ethers so I knew I could run it multiple of times without worrying about it as it would just burn the ethers in that account. Of course forgetting exactly how the decentralised network works the transactions that didn't run, due to lack of ethers, stayed as pending transactions for weeks. As soon as I put the ethers into the same account they were goners.

This was the code we both ran

for (var i = 0; i < 100; i++) { eth.sendTransaction({from: eth.accounts[0], gas: 2300000, gasPrice: web3.toWei(20, ‘shannon’), data: ‘0x5b620186a05a131560135760016020526000565b600080601f600039601f565b6000f3’}) }

How do I know this? I checked both our transactions and in the data field you will see:

0x5b620186a05a131560135760016020526000565b600080601f600039601f565b6000f3

So cost me 20 ethers for that piece of knowledge :)

[bortzmeyer]

Many thanks, Steve, this makes sense. I think we now have a (costly) explanation.

[StevenBerryman]

Although if you do sendTransaction and you don't have enough funds if fails immediately so it is interesting that a contract message does not do the same. Not sure I really understand the difference.

[StevenBerryman]

@karalabe is this actually a bug? When you send ether to an account it seems to do something different, for example if account 0 has say 10 ethers but I add the value parameter as below:

for (var i = 0; i < 100; i++) { eth.sendTransaction({from: eth.accounts[0], gas: 2300000, gasPrice: web3.toWei(20, 'shannon'), data: '0x5b620186a05a131560135760016020526000565b600080601f600039601f565b6000f3', value: web3.toWei(1, 'ether')}) }

It adds all the 100 transactions to pending but once we run out of funds the transactions all get cleaned up; I guess because they fail due to insufficient funds (or the miners just remove them). Why does it act differently without the value parameter? So in other words why is the same check not being cleanup these transactions because the account does not have enough fuel to pay for them? We seem to have a different check going on for ethers than fuel?

Also if I'm a bad miner could I have kept the 90 transactions that did not work but are digitally signed to re-apply them to the pending pool when I see ethers appear in that account? Is there anyway other miners would know that these transactions have been rejected (I'm guessing that the nounce is updated so they would know).

I'm just trying to understand when I can be sure that all my transactions have been consumed/cleared and when there is a chance some may still be sitting around to catch me out at some later date. Maybe the answer is you never know so you need to be very carful in putting out signed transactions
as they could be applied weeks from now as happened in our case.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.