Topic: Error in BitcoinJ? (Read 4010 times)
At the moment there isn't any way to fix this beyond telling the user to make sure their clock is correct. But you could just fetch the correct time from a trusted server, if this is really a frequent issue. E.g. just make an HTTPS request to google.com/gen_204 and then check the Date header.
Well... Probably if the divergence is of amount of a year, it may lead to unpredictable behavior in many cases. But in my case I can see that after loading several thousands of blocks from blockchain my peer bumps into three blocks that are considered as blocks from the future and it blocks loading process permanently.
Is there any way to workaround this problem apart of telling the user "adjust your system clock" ?
I'm sure if a device doesn't have a correct system clock, then most communications will fail anyway. I had a Windows Phone that was set to 2012 and I couldn't download any app because of a problem with the SSL certificate.
Hi, I've got informed about similar problem within my Android application.
Is there any way to workaround this problem apart of telling the user "adjust your system clock" ?
I've looked through the code and find out that I can't even catch this exception on my application layer as it is caught already within bitcoinJ. But it seems to me that chain loading process is getting stuck as far as it bumps into such exception. Are there any ways to skip suspicious blocks or at least abort loading process?
Is there any way to workaround this problem apart of telling the user "adjust your system clock" ?
I've looked through the code and find out that I can't even catch this exception on my application layer as it is caught already within bitcoinJ. But it seems to me that chain loading process is getting stuck as far as it bumps into such exception. Are there any ways to skip suspicious blocks or at least abort loading process?
There is no error in bitcoinj. That field is meant to be in seconds, as a quick inspection of the usage sites would have shown you.
As you have discovered, your system clock is wrong and that's why blocks were being rejected. Bitcoin requires a correct system clock and always has.
As you have discovered, your system clock is wrong and that's why blocks were being rejected. Bitcoin requires a correct system clock and always has.
Update:
The error is all but confirmed. I changed the clock on my computer; I made it 20 seconds faster. Thus, the blocks now have an acceptable timestamp compared to my computer. Now 100% of all new blocks are accepted like they should be.
I made a pull request on github, but it didn't pass the CI tests I guess. Still, it would be nice to have this bug fixed.
The error is all but confirmed. I changed the clock on my computer; I made it 20 seconds faster. Thus, the blocks now have an acceptable timestamp compared to my computer. Now 100% of all new blocks are accepted like they should be.
I made a pull request on github, but it didn't pass the CI tests I guess. Still, it would be nice to have this bug fixed.
When using BitcoinJ to listen to the blockchain I get an error on the testnet:
[NioClientManager] INFO org.bitcoinj.core.MemoryPool - [192.241.225.155]:18333:
Peer announced new transaction [1] 73e8f6fcc45922fe1ac7db57ed164a0b291ce1cd8b2e2
ee1451d4bdba52896b5
[NioClientManager] ERROR org.bitcoinj.core.AbstractBlockChain - Failed to verify
block:
org.bitcoinj.core.VerificationException: Block too far in future: 1423230446 vs
1423230444
at org.bitcoinj.core.Block.checkTimestamp(Block.java:672)
at org.bitcoinj.core.Block.verifyHeader(Block.java:781)
at org.bitcoinj.core.AbstractBlockChain.add(AbstractBlockChain.java:397)
I had a look at it, and I came across a difference between how Java does timestamping versus Bitcoin Core.
In Core, I think that it defaults to using whole seconds, while in Java the default is milliseconds.
The problem arises on line 53 here:
https://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/core/Block.java?r=0208b426f5ec537cd019378d4261868af9cb9b1e
static final long ALLOWED_TIME_DRIFT = 2 * 60 * 60; // Same value as official client.
My suggestion is that that line should be:
static final long ALLOWED_TIME_DRIFT = 2 * 60 * 60 * 1000; // Same value as official client, converted to milliseconds
It's a problem because the timestamp allowed is different by a factor of three magnitudes compared to official client, and it's throwing exceptions about 50% of the time.
[NioClientManager] INFO org.bitcoinj.core.MemoryPool - [192.241.225.155]:18333:
Peer announced new transaction [1] 73e8f6fcc45922fe1ac7db57ed164a0b291ce1cd8b2e2
ee1451d4bdba52896b5
[NioClientManager] ERROR org.bitcoinj.core.AbstractBlockChain - Failed to verify
block:
org.bitcoinj.core.VerificationException: Block too far in future: 1423230446 vs
1423230444
at org.bitcoinj.core.Block.checkTimestamp(Block.java:672)
at org.bitcoinj.core.Block.verifyHeader(Block.java:781)
at org.bitcoinj.core.AbstractBlockChain.add(AbstractBlockChain.java:397)
I had a look at it, and I came across a difference between how Java does timestamping versus Bitcoin Core.
In Core, I think that it defaults to using whole seconds, while in Java the default is milliseconds.
The problem arises on line 53 here:
https://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/core/Block.java?r=0208b426f5ec537cd019378d4261868af9cb9b1e
static final long ALLOWED_TIME_DRIFT = 2 * 60 * 60; // Same value as official client.
My suggestion is that that line should be:
static final long ALLOWED_TIME_DRIFT = 2 * 60 * 60 * 1000; // Same value as official client, converted to milliseconds
It's a problem because the timestamp allowed is different by a factor of three magnitudes compared to official client, and it's throwing exceptions about 50% of the time.
Jump to: