In D4758#115843, @fpelliccioni wrote:

I think I don't get your point.
I am trying to make the same changes that the PR makes, but creating a Diff for each commit.
The final code (the code of the last Diff) should be the equal (or very similar) to PR code.

Oh great, I was going to ask about this.

rebase for D4766 landing; split out the scripterror helper into separate diff; address comments

OK just did a new one, D4796

args defaultness, also missed one place

Good, though please change the description to point to the github.com/bitcoin repo, not to jasonbcox repo.

Apparently core still calls this option -printpriority even after PR9602, how odd...

oh sweet, I didn't realize these were already deprecated and I was wondering if we could remove them suddenly.

In D4758#115130, @fpelliccioni wrote:

In D4758#115041, @markblundeberg wrote:

Something seems a bit off here -- note that ABC has renamed the 'inner' InvalidateBlock to UnwindBlock in D1952 (not sure why). I think you might be putting the lock in the wrong place, and it should rather go on UnwindBlock.

I didn't want to change the semantics of UnwindBlock because this function is used by ParkBlock.
In any case, I will create another Diff to change ParkBlock.

Ah I was going to do this but thanks :-) . I think there are still some priority leftovers after D4745 and this, but not much.

Just FYI, @Fabien and I talked a bit about this -- initially we both wondered whether we really want this (what's the point of banning, if they can just come back), but we both eventually figured it's probably good to do. As Greg says, fresh IP addrs are by no means in short supply...

Something seems a bit off here -- note that ABC has renamed the 'inner' InvalidateBlock to UnwindBlock in D1952 (not sure why). I think you might be putting the lock in the wrong place, and it should rather go on UnwindBlock.

Heh, unfortunate title for this diff now that RewindBlockIndex is gone :-D

In D4728#114829, @fpelliccioni wrote:

It seems that removal of the RewindBlockIndex declaration is missing (src/validation.h).

missed removing from header

There is still more to do on this, but just updating for now.

redo for building on D4678

Thank you Captain Linter!

In D4743#114323, @markblundeberg wrote:

In D4743#114268, @markblundeberg wrote:

It's worth pointing out there is a slight behavioural difference, in that using activatenextupgrade will activate for all blocks after genesis, whereas the MTP activation would only trigger sometimes:

• on the third block (second block after genesis) if only genesis block is old
• activate never if all blocks are old (some tests use old blocks, such as the cached chain which is all old blocks that are relatively empty)

I think that's fine... and maybe even better, since some of our functional tests fail to leave IBD on the ancient chain.

Actually I should mention there is a side effect of this that can happen:

Suppose new flag B requires old flag A that has already activated -- in VerifyScript it might have if (flags & B) assert(flags & A); like we see with CLEANSTACK and P2SH. If you do this -activatenextupgrade then it moves the activation of B back to genesis, before flag A activated. Then the assert will fail.

This Diff passes fine since BIP16Height=0 and magneticAnomalyHeight=0 on regtest, i.e., p2sh always on since genesis (which doesn't really count) and cleanstack turns on at height=1. Well before any script could be executed.

I am not aware of any planned future flags that would incur this problem -- at most you might have restrict flags that require P2SH in order to be strict soft forks (like cleanstack), but I cant imagine any other dependencies.

rebase & update per comments

obsoleted by D4745

Future note: if it is desired to revert this, see the fixes in D4730 and consider some of my comments there, regarding subjectivity of free transactions. Also, try to preserve the behaviour of seen here of putting back *all* free transactions into mempool after a reorg.

(oops, missed removing a comment that is no longer valid)

I am going to be reviving this soon, it makes more sense after having D4745.

(rebase for landed parent)

(rebased for landing D4746 which also touched abc-transaction-ordering)

Memcpy to overlapping memory is also UB right?

Please rename the file that is confusing phab, just for easier review for now. Everything other than that one looks good.

In D4743#114268, @markblundeberg wrote:

It's worth pointing out there is a slight behavioural difference, in that using activatenextupgrade will activate for all blocks after genesis, whereas the MTP activation would only trigger sometimes:

• on the third block (second block after genesis) if only genesis block is old
• activate never if all blocks are old (some tests use old blocks, such as the cached chain which is all old blocks that are relatively empty)

I think that's fine... and maybe even better, since some of our functional tests fail to leave IBD on the ancient chain.

In D4731#114295, @Fabien wrote:

@markblundeberg see https://reviews.bitcoinabc.org/D4680 for a case that uses this assumption (not entirely true since there is a memcpy). I found some other places as well by grepping for (uint8_t *) to find the suspicious casts.

With your rational it makes sense to assert CHAR_BIT==8 as well, or we might want to switch to int32_t everywhere it's needed.

rebase & tweak name

It's worth pointing out there is a slight behavioural difference, in that using activatenextupgrade will activate for all blocks after genesis, whereas the MTP activation would only trigger sometimes:

(as suggested in the rejected D4730)

ok, i'll go with areAllSignaturesNull

(BTW another assumption I don't see documented here is that CHAR_BIT == 8. Just because sizeof(int) == 4, doesn't necessarily mean that it's 32 bits long.)

Thanks for this! I was wondering about it. I have seen some discussions that people want compilers to not count uint8_t as an alias for char. This has the advantage of giving optimization, but, apparently it breaks ABI on existing defined architectures: https://stackoverflow.com/questions/26297571/how-to-create-an-uint8-t-array-that-does-not-undermine-strict-aliasing

In D4730#113949, @deadalnix wrote:

IMO, we should just cleanup this whole thing. If someone wants to keep it alive, they can step up and maintain it. Let's not burden ourselves any more than required.

By the way, this free transaction system does not seem very robust, and it's not suitable for zero conf since it's easy to disturb in malicious ways. For example you can spam someone with a bunch of lowfee high priority transactions that are nonstandard, causing their free limit to fill up (because they add to the free limit regardless of acceptance!). So our default limit of -limitfreerelay=0, which disables this mechanism altogether, is actually a good choice in terms of keeping objective uniform relay policy.

Bump limitfree in the test from 5 to 6, and add explanation for why
these numbers are chosen. Also test that the mempool reloads fully
on restart.

OK looking at debug.log, indeed upon restarting the node, dFreeCount got incremented up to 24705 on startup (while loading the saved mempool). Then 150 more lowfee txns got inserted and the 149th bumped dFreeCount up to 49856.8... and the 150th put it just over the top.

While re-testing locally I got a free-transaction error on line 82 of abc-high_priority_transaction... Probably because I increased the -limitfreerelay just barely enough for it to pass, so it's unreliable.

(see D4730 which exposed this discrepancy)

Always a fan of the deboosting. Too bad about the code ownership but it looks right.

I think we should just remove RewindBlockIndex entirely from here and from init.cpp.

@Fabien suggested we could alternatively use IBD as the marker (though unfortunately this would again impact those tests which fail to leave IBD).

(if you don't believe me, try putting assert(0) as the first line in the while-loop and observe that all tests pass).

I don't think this loop should be removed. If you disconnect a block you absolutely want it to be back in setBlockIndexCandidates. The loop comment is of course completely wrong, since that loop does not modify flags.

One thing I really like about this test: when we add new script flags and script tests, it will hopefully warn the implementor when they are making an additive flag, and make them decide whether they want to make their flag strictly soft forking. Perhaps this requires an assert(other_flags), like the cleanstack thing.

tweak enable_flags freezing slightly; also changed my mind about removing
the stale comment, it can be removed in a later (non-backport) diff.

In D4716#113530, @deadalnix wrote:

Add a test.

In D4642#112088, @deadalnix wrote:

It would be preferable to remove the tests along side the code that they do test. Doing this as this simply reduce test coverage.

Presumably the next step after this is to set graviton activation to height=0 in regtest? It could be combined with this diff, since setting height=0 necessarily will force activation to be untestable. But I think separate diffs is good.

Yeah to be clear, I'm not 100% sure that this is something we want or that this is the right way to do it, and I'm curious what you guys think.

This is the future backport that will make all tests start out of IBD: https://github.com/bitcoin/bitcoin/pull/15419

In D4673#113198, @markblundeberg wrote:

Oh actually you know what? FORKID flag is the same -- if you are doing IBD and are pre BCH activation and someone unsolicitedly sends you a BCH sighash transaction, it will create that "BUG! PLEASE REPORT THIS" log.

So if this is fine behaviour for FORKID, then it's fine for multisig flag too.

Inspired by discussion on D4673.