Dec 1, 2018

Thanks for posting @jungly!

I expect we'll be doing some more comparison tests of our own as version4 is closer to launch. ~5 hours for a core sync sounds way faster than anything I've experienced, although I hadn't tried a full sync on 0.17 ni particular yet

Hm, why did he comment out all the checkpoints? I remember they are identical to core?

For the full validation

It sounds like he wants a "full_validation = true" option that ignores all checkpoints post genesis (?)

While that hypothetical option could be confusing (messing with checkpoints and they're not working because that option is set), it seemed it was difficult to remove the pre-populated checkpoints: "the hardest part was removing the hardcoded block checkpoints". Not sure, I don't find that so difficult, and perhaps now that he knows, it may not be as difficult (?)

The "recompiling for full validation" part confuses me. Anyone know what he means by that?

Oh, unless he means switching between core consensus vs native(?). Actually, I'm curious if he used native consensus (I don't think it says, but maybe I missed that)

Maybe he means rebuilding the stack from his fork with the his changes to take out checkpoints?

Hrm, maybe, but there's no need for that since he can just edit the config, which he already did.

True. I misread what he was saying. Weird he had to rebuild. Maybe we should mention that on the tweet thread Check out @lopp’s Tweet: https://twitter.com/lopp/status/1068900532788563968?s=09

Go for it, I don't tweet myself 😉

Btw - does libbitcoin have a lax DER parser for pre bip66 signatures in earlier blocks? I guess it used to be openssl, but that isn’t a dependency obviously...

@James C. https://github.com/libbitcoin/libbitcoin/blob/master/src/math/elliptic_curve.cpp#L310

Perfect thank you @neillm !

He apparently failed to recognize that providing a genesis only checkpoint eliminates all checkpoints. However this is non-consensus behavior, so not why it’s useful.

Switching between use of libconsensus and native does not require a recompile.

The way core gets “faster” is by not validating most of the chain by using “known good” blocks (our v4 milestones). If he didn’t disable this it’s not a reasonable comparison.

What’s the difference between known-blocks and checkpoints?

The later treat a hash mismatch at the height as invalid.

Ah, so core just has a white-list of known subsequent header hashes it specifically fetches for the first n blocks?

No, like checkpoints except that if they are not found they are ignored but if found allow skipping validation of ancestry.

Theoretically: If “known blocks” are not bound to a specific height, and no known blocks are found, does core begin to validate at genesis at some hard-coded height?

It just validates after the last standard checkpoint.

And they don’t have to be height bound but could be. The hash is identified via header sync and then all blocks prior can skip validation.

Cool, think I get it: so it foregoes validation until it reaches the last “known” block, and otherwise resorts to most recent “known-block” or even checkpoint as a starting point for validation (Assuming these “known blocks” are all higher than checkpoints).

Just wondering when it “gives up” on finding all known-blocks if they aren’t bound to height…

Logically you just check every strong chain header against milestones and when matched, treat the branch up to that point as prevalidated. In our implementation these are concurrent activities, but that just represents an implementation detail.

I like implementation details!