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.

wacax
  • 1,388
  • 2
  • 13
  • 29

4 Answers4

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

euri10
  • 4,640
  • 5
  • 24
  • 55
  • 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 02 '16 at 02:14
  • honeslty I don't know, I don't keep logs so can't comment on that – euri10 Jun 02 '16 at 07:06
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

Shayan
  • 895
  • 2
  • 8
  • 24
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

AdrianClv
  • 1,269
  • 10
  • 14
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.

Badr Bellaj
  • 18,780
  • 4
  • 58
  • 75