This week I have been adding block replay into MultiBit for the bcj 0.8-MASTER code. I have it working but it is not as robust as it could be.
The main area is of trouble is the AbstractBlockChain#findSplit and related methods. This is typical:
14:02:25.127 [New I/O worker #2] WARN com.google.bitcoin.core.Peer - [80.218.174.253]:8333 - java.lang.NullPointerException: Attempt to follow an orphan chain at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:204) ~[multibit-exe.jar:na] at com.google.bitcoin.core.AbstractBlockChain.findSplit(AbstractBlockChain.java:615) ~[multibit-exe.jar:na] at com.google.bitcoin.core.AbstractBlockChain.handleNewBestChain(AbstractBlockChain.java:524) ~[multibit-exe.jar:na] at com.google.bitcoin.core.AbstractBlockChain.connectBlock(AbstractBlockChain.java:483) ~[multibit-exe.jar:na] at com.google.bitcoin.core.AbstractBlockChain.add(AbstractBlockChain.java:359) ~[multibit-exe.jar:na] at com.google.bitcoin.core.AbstractBlockChain.add(AbstractBlockChain.java:247) ~[multibit-exe.jar:na] at com.google.bitcoin.core.Peer.endFilteredBlock(Peer.java:741) ~[multibit-exe.jar:na] at com.google.bitcoin.core.Peer.processMessage(Peer.java:257) ~[multibit-exe.jar:na] at com.google.bitcoin.core.Peer.access$400(Peer.java:48) ~[multibit-exe.jar:na] at com.google.bitcoin.core.Peer$PeerHandler.messageReceived(Peer.java:237) ~[multibit-exe.jar:na] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) ~[multibit-exe.jar:na] at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) ~[multibit-exe.jar:na] at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:536) ~[multibit-exe.jar:na] at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) ~[multibit-exe.jar:na] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) ~[multibit-exe.jar:na] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) ~[multibit-exe.jar:na] at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) ~[multibit-exe.jar:na] at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) ~[multibit-exe.jar:na] at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312) ~[multibit-exe.jar:na] at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) ~[multibit-exe.jar:na] at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) ~[multibit-exe.jar:na] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [na:1.6.0_43] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [na:1.6.0_43] at java.lang.Thread.run(Thread.java:680) [na:1.6.0_43]
The net result of this is that the Peer gets dropped and so you waste time creating a new one. It still works but is not ideal.
Also to get the SPVBlockStore to replay ok I am creating a brand new SPVBlockStore on replay. If I don't, I precondition 'higher and lower are reversed' in AbstractBlockChain#getPartialChain
Again, recreating a new blockstore works but you always end up having to sync back to the last checkpoint even though you have all the block headers since then in the SPVBlockStore. This is a bit inefficient.
The code in the MultiBit mb-0.5-bcj-v0.8 branch is what I am working on.
