Secondly I don't think that all of the problem with the database is the leveldb back end, though there is probably issues there (again maybe cgo option?) and in between that and implementing the interface, common code exists also. First thing I see is that the precompute could optionally be made a lot bigger, to improve performance, and on the other hand, also, using the fastest possible C library for koblitz curves optionally. Two things stand out relating to this from my close work with the code on an old bitcoin fork (parallelcoin). The consensus chain could then be established earlier in the sync process and of course nonconforming blocks, the node serving them up should get a huge banscore increment for this, i mean, weeks of no contact, trying to propagate a fake chain is pretty serious. I think it would make sense to improve this when it is syncing pre-checkpoint to establish several links and download several segments of the chain from several sources at once, while grabbing the blocks-only from a few nodes at the same time. A reasonable figure could be derived from the known hashpower for an algorithm as currently exists on all networks.Īnd yes, the btcd netsync library only downloads from one source at a time. I think it should be on the basis of cumulative weight. Someone mentioned this a long time ago in a btctalk post, the idea of simply disallowing new blocks to attach before some reasonable number of blocks previously. Since checkpoints main purpose, in effect, is simply to reduce time-wasting old forks from clogging up the mempools, it's my opinion that the more effective strategy would be to simply disallow forks that would require an inordinate amount of hashpower to push ahead of the tip. With my work on a forked chain, I am finding that when I set checkpoints, everything after gets orphaned. Checkpoints are mainly to stop miners filling mempools with new blocks forked from ancient blocks, which are extremely unlikely to ever exceed the cumulative work total of the current best block. I'd suggest trying to disable the checkpoints, to eliminate this double-downloading. ![]() This likely actually slows things down during initial sync. When checkpoints are set, it pre-fetches the block headers and compact filters (if available). Still, lowest ping of up to 8 currently connected nodes probably still helps.ītcd as delivered in the git repo has a series of checkpoints. ![]() I made a small alteration that favours selecting the lowest ping out of the connected peers, the code is here: where you need to make the change and here: - I personally would think that more metadata stored about peers could get a more accurate picture of available block sources, such as a record of the last block/second rate when the peer was synced from. I am using the btcd codebase to update the parallelcoin network (it almost even still has malleability vulnerabilities) and looked at the p2p syncmanager stuff.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |