alex-linhares/breadwallet

breadwallet - bitcoin wallet

breadwallet's Issues

Mainnet Sync Stops at block 889055

Opened this issue for brainstorming this problem... For background see:

https://www.reddit.com/r/litecoin/comments/4buflm/ios_walletdev_could_fixedpeersplist_point_to_a/

Currently we are working on making mainnet syncing work, we are for some reason experiencing issues with the target.

(Mainnet is, of course as opposed to testnet).

For background on the target see:

1. https://en.bitcoin.it/wiki/Target
2. peritus#1
3. https://bitcoin.stackexchange.com/questions/2924/how-to-calculate-new-bits-value/2926#2926

The following error appears endlessly in the console:

2016-03-27 01:44:47.120 breadwallet[85671:2965805] 71.52.17.184:9333 relayed orphan block <3c12da0f 993ea8f8 9104a790 81c2038e a6f969d3 a06344b7 072da348 4c8cf216>, previous <396e9b4d 0382f8da 4e2aede3 330da4c3 ea14cb46 c33fcfc3 323196f5 fabcc9aa>, last block is <bf031254 b9f52ea6 0dc95c19 3fd7f177 0e81d9f6 a5abcb17 71864414 9e3047e6>, height 889055.

So here there's some interesting things that might point to solutions:

• (A) As in the reddit post above, I have found the bytes in the hash are in reverse order. But this is probably nothing imo because it's working just fine in bitcoin's original Breadwallet. For example, this error may appear there as:

`2016-03-25 11:37:29.756 breadwallet[21787:2261023] 104.153.211.83:8333 relayed orphan block <27d5c8ea 34cd4f2c 76a28810 9e90bc23 17e7de57 52d74b01 00000000 00000000>, previous <77fe4d98 f2997f75 772febe2 a4831aa7 d098165e 8de6e901 00000000 00000000>, last block is <e1cd613c f7c1325c 291ddb5f 33f5f188 e8371b1f 9e5e3d01 00000000 00000000>, height 403714, for which the hash is 00000000 00000000 013d5e9e 1f1b37e8 88f1f53... so, in there we also have bytes in reverse order (This reverse order thing might come in handy one day so I will link it here).

• (B) Every 2016 blocks a new target is set. Now, notice that the checkpoints in the code stop at block 887040, so we have a problem exactly 2016 blocks after that one, as block 889056 should retarget, but somehow things get stuck.

It could be some issue with computing the new target.

But it could also be a little more complex: an edge case in which block x is an orphan and block x+1 is a re-target block. This would happen with probability 1/2016*p, where p=probability (orphan @ block(x)).

Bitcoin also retargets at 2016 blocks. According to blockchain.info, the maximum number of orphans in a day has been 7.

Now I believe Dogecoin retargets every block, so they have already handled that edge case. Bitcoin has 144 blocks/day, and if we use the maximum as 7, we have p= 7/144 = 0.04861111111.

So 1/2016p = 0.00002411265. This should happen at the magnitude of hundreds of thousands of blocks. Maybe it's the case here, but as I said, it's a longshot... still, I am now curious to see how breadwallet is handling it.

Might be of use:

a) Litecoin's code for computing targets:
https://github.com/litecoin-project/litecoin/blob/master-0.10/src/pow.cpp
which calls uint256: https://github.com/litecoin-project/litecoin/blob/master-0.10/src/uint256.cpp#L251