In D447#7647, @sickpig wrote:

In D447#7644, @CCulianu wrote:

So you want me to create *two* diffs? One with just formatting (autopep8) stuff and one with my changes?

yes.

I suppose your are using a local branch cloned from master to dev this feature, right?

if it is the case create a new branch based on master, apply the formatting change, arc diff.

The new one will be quickly accepted by @deadalnix (and me fwiw), then you can land it. Once landed (merged) just merge/rebase master onto your local branch, fix conflicts (if any), and then run arc diff to update this diff.

I tested this on a real bitcoin server on mainnet I'm getting BUCash nodes getting banned with the non-mandatory-script-verify-flag message.

@sickpig : I *agree* with you. The thing is I'm between a rock and a hard place. If I don't let the 'arcanist' auto-linter apply the formatting changes, @deadalnix won't accept it because the code has "linter" code style errors. If I allow the linter to run, it produces this huge diff that has formatting stuff mixed in with logic changes.

all ok

@dgenr8: As per your comment in the github issue 63:

In D441#7600, @deadalnix wrote:

I think you screwed up something while updating the diff. Also please run autopep8 in another diff.

Oops.. I didn't mean to accept the revision. Sorry for that!

@dgenr8 : From your github comment:

Updated fix to include reviewer suggestions

Bump. I need more guidance/discussion here from @deadalnix and/or others. Thanks in advance..

Ok, but warning gets really spammy with each new block -- maybe if you do keep the warning, limit it to a maximum number of times it can be issued -- or issue it only once per each unique 'invalid long chain found'.

I need more review and comment since I'm new to this API, honestly. Please advise (see inline comments). Thanks in advance.

After careful reading of the code I concur 100% with you. There's no reason to issue a warning and make RPC go into "safe" mode and fail just because a large *invalid* fork is detected.

Ok, as per @freetrader 's comment in another diff -- you gotta apply these all together.

Looks good

Look good

looks good

Look good

Look good

This doesn't apply to my repository.

Looks good to me. Just as an aside: I'm all for getting rid of the namespace import -- it's considered bad form to import it in larger programs anyway.

I'm approving this because it does no harm regardless and it compiles and runs fine.

Added braces as per @deadalnix coding style, added some additional comments

Unfortunately no remove_if on std::map...

Looks good, make check fine, accepted.

I don't see an obvious/easy way to test this. This is all about an internal data structure that sometimes leaks under very specific conditions.

Runs ok. Note some tests still fail but fewer fail with this series of diffs: D409, D411, D413, D414, so I will accept them since they are a step in the right direction...

Runs ok. Note some tests still fail but fewer fail with this series of diffs: D409, D411, D413, D414, so I will accept them since they are a step in the right direction...

Accepting with caveat that sickpig's comment about putting the var in 1 common place would have been a good idea, but isn't the end of the world either way.

Runs ok. Note some tests still fail but fewer fail with this series of diffs: D409, D411, D413, D414, so I will accept them since they are a step in the right direction...

Looks good. Tested and works.

Looks good, hashes check out.

in D409 @sickpig suggested you put this in 1 place then import the symbol.. any thoughts on that?

I agree with sickpig's suggestion. @deadalnix.. thoughts?

Honestly I don't see the huge advantage in this coding standard of 80 character lines. It really just makes the code uglier.

Looks good to me. Accepting.

OK, tabled for now.

OK, will come up with a test..

Ok, fair enough -- the convert script it will be, then. Makes sense actually to just go that route -- when authoring this I wasn't aware of convert script idea.

I can't figure out where they leak -- but I do know it's related to the crash we had before (for which you had to add a guard to check a stale mapBlockSource entry).

In D412#7015, @deadalnix wrote:

We can bypass all that by having a script read the old folder and move it all into a new one with the new magic and we solve 2 problems at once.

Trying to fix code format issues

In D412#7015, @deadalnix wrote:

We can bypass all that by having a script read the old folder and move it all into a new one with the new magic and we solve 2 problems at once.

On the code itself, it says you have style errors, so requesting changes until this is sorted out.

Eh, reformat some funny formattig create by the linter

Looks good to me.

Also -- might we not want to modify deserialization functions that use the MessageStart() to deserialize data eg in addrdb.cpp (CBanDB::Read is an example) to *also* accept CashMessageStart() in addition to MessageStart() as a header when reading -- in case we want to one day totally get rid of the old magic?

Eventually, we'll get clang-tidy to do it automatically. Also I ran into a few case that are very confusing, like:

if (...) dosomething;
{
  LOCK(...);
  // ...
}

There are a few of these in the codebase, taking advantage of RAII to unlock the mutex. Very confusing.

Note: I am having trouble running rpc-test.py (see attached).

Looks fine. Visually inspected. Just format nit changes so.. this looks fine.

Looks harmless enough. :)

Might we want to add that fUsesCashMagic business to CNodeStats so that RPC JSON can see which peers are using cash magic and which aren't (as part of getpeerinfo RPC call)?

Visually reviewed (my eyes are getting sore now!!) -- looks good. No typos, error, etc that I can see and it compiled, tested, and tests pass.

Jesus wept. Core... core.. core...

Really.. REALLY!? REALLY?!?!!1one

Nitpick: Would it kill you so much to do the C++ cult thing and do '++vcidx'. *ducks*

Note, I went ahead and recompiled bitcoin-abc (current master as of the time of this writing) both with and without prevector.

Really good you did this. I hate the way that call looked before. Good job.

I am all in favor of doing this. I never import the std namespace into my projects. I am pretty sure most C++ programmers frown on that and it's another amanteur hour thing to do so in my mind, so a huge thumbs up on this from me.

Good job on writing the test suite. I know it seems redundant since the CHashVerifier is trivial almost -- but I guess we should all enforce decent habits such as these.

Good question. I'll investigate that and if it's the case that it can be accelerated somehow (maybe using test suite using a specifically constructed test?), I will either add a test case or figure out how it's reproduced.

This from the man who authored D370?

Awesome, glad you're on-board as well. Like I said it's not a huge deal, just in general is good C++ practice. One of those cultural things, I guess, since these days the compiler will issue identical code for ints anyway.

In D362#6214, @freetrader wrote:

Could you explain how validation.cpp:1460 ff. are not using the new template class?

In D362#6150, @freetrader wrote:

Rest of code changes look good, but introducing a new class without a unit test?

Ok, tested with your new "with arrays" addition.. everything checks out. On my Travis-work-alike system your test case failed, but with the patch to streams.h, your test case passed. Looks great.

Useless revision. Was here for my testing. Sorry if this polluted phabricator. Still getting used to phabricator workflow.

I completely agree that a lot of boilerplate is a sign of a bad API. Totally agreed. Like I said, this is just here for reference in case someone gets desperate about the segfault reported.