My 0.8.0rc1 (self compiled from git tag) receives transactions from peers while syncing, which results in them beeing orphaned and the orphan-list filling up.
Suggestion: Do not request or handle incomming transaction while in initial sync or when the client knows its blockchain is old. Also: Start connecting to peers only after every --loadblock entry has been processed
This should be harmless, is there a reason I'm unaware of that it isn't?
No security implications that I can see, but it prolongs initial sync on low-resource nodes.
I don't see how it could non-trivially prolong the initial sync on low resource nodes. (I'm not arguing that it doesn't— but tell me why you believe it does)
As I understand it if the node receives the transaction it has to look up all inputs (which in this case don't exist)
On one of these http://www.pcengines.ch/alix2d2.htm (I admit it's extremely low resource) I saw about 10% increase in syncing speed (accepted blocks / time) from --loadblock between specifying "connect=10.1.2.3" (non existent node -> preventing the client from connecting to the network) in bitcoin.conf and letting the node connect to the network.
10% potential performance improvement during bootstrapping or -loadblock is not enough to justify the testing effort to make sure a change doesn't break anything, in my opinion.
@gavinandresen I generally agree but 10% is more than I would have suspected— might be an interesting scenario to profile and find some low hanging inefficiencies which apply outside of the bootstrap case. (In particular, if isolating a loadblocking node gets you a 10% speedup— there may be a DOS vector lurking in there)
Since on this hardware the bottleneck is the CPU it is entirely possible that the 10% is the CPU load that is normally used to handle network traffic and p2p discovery.
