11

When I was sending Ether using Mist I got the following message on Geth.

I0528 18:34:57.312997 core/blockchain.go:959] imported 1 block(s) (0 queued 0 ignored) including 3 txs in 19.344963ms. #1602638 [e4523f86 / e4523f86]
I0528 18:35:24.519128 eth/downloader/downloader.go:1091] Peer ############ [headers 0.00/s, blocks 0.00/s, receipts 0.00/s, states 0.00/s, lacking    0]: potential rewrite attack: #0 [########…] <= #1512638 limit

After that, the transaction didn't get sent. And I had to send it again.

What does the message mean? Is it dangerous? Is it Geth and the accounts currently being used on Mist compromised?

I tried Googling but nothing really relevant showed up.

0

4 Answers 4

6

the message appears 4 times here in the geth code of this function The comment explains it well :

// findAncestor61 tries to locate the common ancestor block of the local chain and
// a remote peers blockchain. In the general case when our node was in sync and
// on the correct chain, checking the top N blocks should already get us a match.
// In the rare scenario when we ended up on a long reorganisation (i.e. none of
// the head blocks match), we do a binary search to find the common ancestor.
func (d *Downloader) findAncestor61(p *peer, height uint64) (uint64, error) {
    glog.V(logger.Debug).Infof("%v: looking for common ancestor", p)

    // Figure out the valid ancestor range to prevent rewrite attacks

You're not compromised, it works as intended

2
  • It makes sense since the message only appeared once. So in short, was this a rare case where Geth did a binary search because the head blocks didn't match?
    – wacax
    Jun 2, 2016 at 2:14
  • honeslty I don't know, I don't keep logs so can't comment on that
    – euri10
    Jun 2, 2016 at 7:06
2

When the last block mined corresponds with the last block available (see https://testnet.etherscan.io/). If you execute your node with "console" at the end, then you could write "eth.syncing" in the console to see information about the syncing process, for example:

> eth.syncing

{
   startingBlock: 300,
   currentBlock: 312,
   highestBlock: 512
}

In you case, you last block mined when you wrote this post was #1805595 and the last block available according to etherscan is #1805643, so you are already synced.

About the potential rewrite attack, see: "potential rewrite attack" message on Geth

2

To check if the blocks are synced use eth.syncing(as indicated in the answer before) or eth.blockNumber

but for the rewrite attack : I think you are connected to a peer who is trying to give you blocks from the other chain (Forked one) so update your geth or just restart it.

2

Probably you have some blocks from Morden in your datadir.

the default datadir is:

Mac: ~/Library/Ethereum
Linux: ~/.ethereum
Windows: %APPDATA%/Ethereum

Delete the chaindata subdirectory that you find.

Then download Ropsten genesis block file from here

and run geth --datadir /path/to/testnet/data init genesis.json; geth --datadir /path/to/testnet/data --networkid 3 console

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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