mensaje de "ataque de reescritura potencial" en Geth

Cuando estaba enviando Ether usando Mist, recibí el siguiente mensaje en 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

Después de eso, la transacción no se envió. Y tuve que enviarlo de nuevo.

¿Qué significa el mensaje? ¿Es peligroso? ¿Están comprometidos Geth y las cuentas que se utilizan actualmente en Mist?

Intenté buscar en Google pero no apareció nada realmente relevante.

Respuestas (4)

el mensaje aparece 4 veces aquí en el código geth de esta función El comentario lo explica bien:

// 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

No estás comprometido, funciona según lo previsto

Tiene sentido ya que el mensaje solo apareció una vez. En resumen, ¿fue este un caso raro en el que Geth hizo una búsqueda binaria porque los bloques principales no coincidían?
Honestamente, no lo sé, no mantengo registros, así que no puedo comentar sobre eso.

Cuando el último bloque extraído se corresponde con el último bloque disponible (consulte https://testnet.etherscan.io/ ). Si ejecuta su nodo con "consola" al final, podría escribir "eth.syncing" en la consola para ver información sobre el proceso de sincronización, por ejemplo:

> eth.syncing

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

En tu caso, el último bloque extraído cuando escribiste esta publicación fue el #1805595 y el último bloque disponible según etherscan es el #1805643, por lo que ya estás sincronizado.

Acerca del posible ataque de reescritura, consulte: mensaje "potencial ataque de reescritura" en Geth

Para verificar si los bloques están sincronizados, use eth.syncing(como se indica en la respuesta anterior) oeth.blockNumber

pero para el ataque de reescritura : creo que está conectado a un compañero que está tratando de darle bloques de la otra cadena (bifurcada), así que actualice su geth o simplemente reinícielo.

Probablemente tenga algunos bloques de Morden en su directorio de datos.

el valor predeterminado datadires:

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

Elimine el chaindatasubdirectorio que encuentre.

Luego descargue el archivo de bloque Ropsten genesis desde aquí

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