Skip to content

Conversation

@morcos
Copy link
Contributor

@morcos morcos commented Jun 8, 2017

Previously it was possible for HaveCoinInCache to return true for a spent
coin. It is more clear to keep the semantics the same. HaveCoinInCache is
used for two reasons:

  • tracking coins we may want to uncache, in which case it is unlikely there
    would be spent coins we could uncache (not dirty)
  • optimistically checking whether we have already included a tx in the
    blockchain, in which case a spent coin is not a reliable indicator that we have.

This makes the logic in #10557 more obviously correct, although it is ok without this PR

Previously it was possible for HaveCoinInCache to return true for a spent
coin. It is more clear to keep the semantics the same. HaveCoinInCache is
used for two reasons:
- tracking coins we may want to uncache, in which case it is unlikely there
would be spent coins we could uncache (not dirty)
- optimistically checking whether we have already included a tx in the
blockchain, in which case a spent coin is not a reliable indicator that we have.
@gmaxwell
Copy link
Contributor

gmaxwell commented Jun 8, 2017

Don't we want to skip fetching a spent coin, e.g. in net_processing.cpp:AlreadyHave ?

@morcos
Copy link
Contributor Author

morcos commented Jun 8, 2017

@gmaxwell I think the logic is we don't know if it has been spent or disconnected

@gmaxwell
Copy link
Contributor

gmaxwell commented Jun 8, 2017

Even if its been disconnected do we really want to fetch it again?

@morcos
Copy link
Contributor Author

morcos commented Jun 8, 2017

I don't think it really matters much either way, we're talking about real edge cases:

  • a tx being announced to us which recently appeared in a block and has already had its output spent. And I think we must be talking about a case where a flush happened in between the tx and it's spend otherwise the coin would have been fresh and erased and HaveCoinInCache would never have returned true anyway.
  • a disconnected tx which wasn't accepted to the mempool during reorg but is now being reannounced to us.

My opinion is that there are pros and cons either way, but the simplicity of having the semantics be the same is the deciding factor.

@gmaxwell
Copy link
Contributor

gmaxwell commented Jun 9, 2017

I think the semantics change should happen. My doubt is only if AlreadyHave should be using this call; or perhaps one that will also potentially return spent entries.

@sipa
Copy link
Member

sipa commented Jun 9, 2017

Do you feel like changing CCoinsViewMemPool::HaveCoin to also check for non-spentness? I believe that function is in fact not called anywhere, so perhaps it can assert instead. The point is that having a consistent definition everywhere would be nice.

@morcos
Copy link
Contributor Author

morcos commented Jun 12, 2017

@sipa I agree it is not currently used. I'm on the fence about changing it, but happy to if that's what everyone else wants. I feel like the definition is a bit different anyway if it's in the mempool, since you could for instance still create a new transaction that spends that coin which would be accepted (as a replacement).

@sipa
Copy link
Member

sipa commented Jun 12, 2017

@morcos Ok, let's discuss that independently perhaps - it has much less real effect anyway.

utACK

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

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

utACK 5257698. #10581 also includes this change so either or both of these PRs could be merged.

@TheBlueMatt
Copy link
Contributor

utACK 5257698

@laanwj
Copy link
Member

laanwj commented Jun 26, 2017

utACK 5257698

@laanwj laanwj merged commit 5257698 into bitcoin:master Jun 26, 2017
laanwj added a commit that referenced this pull request Jun 26, 2017
5257698 Change semantics of HaveCoinInCache to match HaveCoin (Alex Morcos)

Tree-SHA512: 397e9ba28646b81fffa53e55064735d4d242aaffdf8484506825f785b0e414f334e4c5cd1e4e1dd9a4b6d1f6954c7ecad15429934a1c4e8d39f596cbd9f5dd80
codablock pushed a commit to codablock/dash that referenced this pull request Oct 26, 2017
…eCoin

5257698 Change semantics of HaveCoinInCache to match HaveCoin (Alex Morcos)

Tree-SHA512: 397e9ba28646b81fffa53e55064735d4d242aaffdf8484506825f785b0e414f334e4c5cd1e4e1dd9a4b6d1f6954c7ecad15429934a1c4e8d39f596cbd9f5dd80
codablock pushed a commit to codablock/dash that referenced this pull request Oct 31, 2017
…eCoin

5257698 Change semantics of HaveCoinInCache to match HaveCoin (Alex Morcos)

Tree-SHA512: 397e9ba28646b81fffa53e55064735d4d242aaffdf8484506825f785b0e414f334e4c5cd1e4e1dd9a4b6d1f6954c7ecad15429934a1c4e8d39f596cbd9f5dd80
schancel pushed a commit to givelotus/lotusd that referenced this pull request Jul 18, 2019
Summary:
5257698 Change semantics of HaveCoinInCache to match HaveCoin (Alex Morcos)

Tree-SHA512: 397e9ba28646b81fffa53e55064735d4d242aaffdf8484506825f785b0e414f334e4c5cd1e4e1dd9a4b6d1f6954c7ecad15429934a1c4e8d39f596cbd9f5dd80

Backport of Core PR10559
bitcoin/bitcoin#10559

Test Plan:
  make check
  test_runner.py

Reviewers: deadalnix, Fabien, jasonbcox, markblundeberg, O1 Bitcoin ABC, #bitcoin_abc

Reviewed By: deadalnix, O1 Bitcoin ABC, #bitcoin_abc

Differential Revision: https://reviews.bitcoinabc.org/D3602
jonspock added a commit to jonspock/devault that referenced this pull request Aug 29, 2019
    Summary:
    5257698 Change semantics of HaveCoinInCache to match HaveCoin (Alex Morcos)

    Tree-SHA512: 397e9ba28646b81fffa53e55064735d4d242aaffdf8484506825f785b0e414f334e4c5cd1e4e1dd9a4b6d1f6954c7ecad15429934a1c4e8d39f596cbd9f5dd80

    Backport of Core PR10559
    bitcoin/bitcoin#10559
proteanx pushed a commit to devaultcrypto/devault that referenced this pull request Sep 4, 2019
    Summary:
    5257698 Change semantics of HaveCoinInCache to match HaveCoin (Alex Morcos)

    Tree-SHA512: 397e9ba28646b81fffa53e55064735d4d242aaffdf8484506825f785b0e414f334e4c5cd1e4e1dd9a4b6d1f6954c7ecad15429934a1c4e8d39f596cbd9f5dd80

    Backport of Core PR10559
    bitcoin/bitcoin#10559
@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.

7 participants