Skip to content

Conversation

@TheBlueMatt
Copy link
Contributor

No description provided.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: update this comment?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@dcousens
Copy link
Contributor

dcousens commented Sep 7, 2015

utACK, concept ACK.

@sipa
Copy link
Member

sipa commented Sep 7, 2015

Untested ACK.

@sdaftuar
Copy link
Member

sdaftuar commented Sep 8, 2015

ACK.

FYI I think that it's worth thinking about this code again if we consider merging #6216, because I believe with the anti-fee sniping use of nlocktime we may end up purging a lot of transactions from the mempool whenever there is a reorg.

@sipa
Copy link
Member

sipa commented Sep 8, 2015 via email

@TheBlueMatt
Copy link
Contributor Author

I'm not too worried about changing the mempool invariant...mostly because I think (someone should audit to be sure), that this code would work as-is if it were just called once at the end of a reorg instead of after each bock disconnect.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, the reason why you test both !coins and against COINBASE_MATURITY is because AccessCoins() will return a CCoins result for immature coins, right?

I smell a future refactoring, but for now please add a comment describing those two cases and why there are two tests.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, and come to think of it your test above doesn't actually test both those cases; you need to do a >COINBASE_MATURITY reorg as well, to a chain that is equally long.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm? I didnt change this code at all, only its indentation. And, yes, I know the test-case is not complete, but creating a testcase that is complete is kinda a PITA (or, which case are you claiming should be implemented?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, arguably that's not your fault, agreed. :)

I'm really thinking of the case where we change this to be called end-of-reorg; if that isn't the case in theory this !coins check should be redundant.

Might be reasonable to leave this code as-is, and make a separate end-of-reorg function that just removes non-final transactions from the mempool.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it would be my fault, I think I wrote that code, too :p.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are redundant checks to make code more reviewable and more clearly not segfault-y bad?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They're not bad! I just think it'd help if they were explained with comments. (and testing all ways of invoking them is always good)

@petertodd
Copy link
Contributor

@sipa I was the one who added that invariant in the first place, and I only meant it as a DoS attack defence, not as a true invariant. In fact, IIRC my original proposal was that we'd allow txs into the mempool so long as they'd be valid in the next two or three blocks.

As for calling it at the end of a reorg, that looks fine to me modulo issues raised in my comments.

@TheBlueMatt
Copy link
Contributor Author

Rebased at #6915

@TheBlueMatt TheBlueMatt closed this Nov 5, 2015
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jan 9, 2016
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jan 9, 2016
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jan 9, 2016
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jan 10, 2016
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jan 10, 2016
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants