Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bugfix: Package relay / bytespersigop checks #28345

Closed
wants to merge 4 commits into from

Conversation

luke-jr
Copy link
Member

@luke-jr luke-jr commented Aug 26, 2023

GetVirtualTransactionSize(CTransaction&) passes by default 0 sigops and 0 -bytespersigop, which is incorrect. In many cases (ie, wallet), this is harmless since we have control over the transactions and don't do anything absurd in normal usage. But in other cases (including wallet received transactions), this isn't safe. To avoid invisible bugs like this, I delete (or rather, move to bitcoin_test) the function signature that allows for omitting sigop inputs.

This also then fixes the new package relay code to use the correct virtual sizes for its checks, and documents calling locations where the behaviour is broken or safe.

In particular, note that the sendrawtransaction RPC and GUI transaction details remain buggy and not fixed in this PR.

@DrahtBot
Copy link
Contributor

DrahtBot commented Aug 26, 2023

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type Reviewers
Concept ACK glozow, instagibbs, ismaelsadeeq

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #28813 (rpc: permit any ancestor package through submitpackage by glozow)
  • #28785 (validation: return more helpful results for reconsiderable fee failures and skipped transactions by glozow)
  • #26711 (validate package transactions with their in-package ancestor sets by glozow)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@luke-jr
Copy link
Member Author

luke-jr commented Aug 26, 2023

See also bitcoin-core/gui#750

Copy link
Member

@glozow glozow left a comment

Choose a reason for hiding this comment

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

concept ACK

src/txmempool.cpp Outdated Show resolved Hide resolved
src/validation.cpp Outdated Show resolved Hide resolved
src/test/util/transaction_utils.h Outdated Show resolved Hide resolved
src/validation.cpp Outdated Show resolved Hide resolved
src/rpc/mempool.cpp Outdated Show resolved Hide resolved
@glozow glozow requested a review from instagibbs August 30, 2023 09:16
Copy link
Member

@instagibbs instagibbs left a comment

Choose a reason for hiding this comment

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

concept ACK

@@ -158,11 +158,6 @@ int64_t GetVirtualTransactionSize(int64_t nWeight, int64_t nSigOpCost, unsigned
int64_t GetVirtualTransactionSize(const CTransaction& tx, int64_t nSigOpCost, unsigned int bytes_per_sigop);
int64_t GetVirtualTransactionInputSize(const CTxIn& tx, int64_t nSigOpCost, unsigned int bytes_per_sigop);

static inline int64_t GetVirtualTransactionSize(const CTransaction& tx)
Copy link
Member

Choose a reason for hiding this comment

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

Alternative, move to wallet and rename to GetWalletVirtualTransactionSize with tests/assertions/comments saying why it's safe in one location instead of spread around? Would make grepping for the remaining bugs easier as well. e.g., anything like GetVirtualTransactionSize(tx, 0, 0) would be obviously a bug at that point

Copy link
Member

Choose a reason for hiding this comment

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

Would make grepping for the remaining bugs easier as well. e.g., anything like GetVirtualTransactionSize(tx, 0, 0) would be obviously a bug at that point

+1 to this, I think 1b163ae would feel even safer if the new function was called GetBIP141VirtualTransactionSize or even GetUnsafeVirtualTransactionSize since it's 99% test-only.

src/qt/walletmodeltransaction.h Outdated Show resolved Hide resolved
src/txmempool.cpp Outdated Show resolved Hide resolved
@luke-jr
Copy link
Member Author

luke-jr commented Sep 2, 2023

checkChainLimits should probably get a warning-only-for-wallet-use comment too

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Sep 5, 2023
luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Sep 5, 2023
luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Sep 5, 2023
luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Sep 5, 2023
…ly account for non-weight vsize

Github-Pull: bitcoin#28345
Rebased-From: ae232c7
luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Sep 5, 2023
@instagibbs
Copy link
Member

could we work on getting tests working? looking to do some deeper review

@glozow glozow mentioned this pull request Sep 11, 2023
56 tasks
achow101 added a commit to bitcoin-core/gui that referenced this pull request Sep 21, 2023
…ansaction package context

eb8f58f Add functional test to catch too large vsize packages (Greg Sanders)
1a579f9 Handle over-sized (in virtual bytes) packages with no in-mempool ancestors (Greg Sanders)
bc013fe Bugfix: Pass correct virtual size to CheckPackageLimits (Luke Dashjr)
533660c Replace MAX_PACKAGE_SIZE with MAX_PACKAGE_WEIGHT to avoid vbyte confusion (Greg Sanders)

Pull request description:

  (Alternative) Minimal subset of bitcoin/bitcoin#28345 to:

  1) Replace MAX_PACKAGE_SIZE with MAX_PACKAGE_WEIGHT which accounts for additional WU necessary to not exclude default chain limit transactions that would have been accepted individually. Avoids sigops vbyte confusion.
  2) pass correct vsize to chain limit evaluations in package context
  3) stop overly-large packages that have no existing mempool ancestors (also a bugfix by itself if someone sets non-standard chain limits)

  This should fix the known issues while not blocking additional refactoring later.

ACKs for top commit:
  achow101:
    ACK eb8f58f
  ariard:
    Re-Code ACK eb8f58f
  glozow:
    reACK eb8f58f

Tree-SHA512: 1b5cca1a526207e25d387fcc29a776a3198c3a013dc2b35c6275b9d5a64db2476c154ebf52e3a1aed0b9924c75613f21a946577aa760de28cadf0c9c7f68dc39
@luke-jr
Copy link
Member Author

luke-jr commented Sep 22, 2023

The CI failures appear to have been because CFeeRate(0) needed to be special-cased as "no limit" also. Fixed that.

Rebased on top of #28471, partially by reverting its first commit which appears to simply make the bug harder to fix.

@glozow
Copy link
Member

glozow commented Sep 22, 2023 via email

@luke-jr
Copy link
Member Author

luke-jr commented Sep 22, 2023

I don’t think adding a new vsize-based total package limit is
necessary, the existing ancestor size limits are sufficient.

Ok, dropping that (and the revert) then.

Frank-GER pushed a commit to syscoin/syscoin that referenced this pull request Sep 25, 2023
…n package context

eb8f58f Add functional test to catch too large vsize packages (Greg Sanders)
1a579f9 Handle over-sized (in virtual bytes) packages with no in-mempool ancestors (Greg Sanders)
bc013fe Bugfix: Pass correct virtual size to CheckPackageLimits (Luke Dashjr)
533660c Replace MAX_PACKAGE_SIZE with MAX_PACKAGE_WEIGHT to avoid vbyte confusion (Greg Sanders)

Pull request description:

  (Alternative) Minimal subset of bitcoin#28345 to:

  1) Replace MAX_PACKAGE_SIZE with MAX_PACKAGE_WEIGHT which accounts for additional WU necessary to not exclude default chain limit transactions that would have been accepted individually. Avoids sigops vbyte confusion.
  2) pass correct vsize to chain limit evaluations in package context
  3) stop overly-large packages that have no existing mempool ancestors (also a bugfix by itself if someone sets non-standard chain limits)

  This should fix the known issues while not blocking additional refactoring later.

ACKs for top commit:
  achow101:
    ACK eb8f58f
  ariard:
    Re-Code ACK eb8f58f
  glozow:
    reACK eb8f58f

Tree-SHA512: 1b5cca1a526207e25d387fcc29a776a3198c3a013dc2b35c6275b9d5a64db2476c154ebf52e3a1aed0b9924c75613f21a946577aa760de28cadf0c9c7f68dc39
Copy link
Member

@glozow glozow left a comment

Choose a reason for hiding this comment

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

LGTM though agree with @instagibbs' suggestion for the first commit. Could update the title + description? No longer package relay-related.

@@ -158,11 +158,6 @@ int64_t GetVirtualTransactionSize(int64_t nWeight, int64_t nSigOpCost, unsigned
int64_t GetVirtualTransactionSize(const CTransaction& tx, int64_t nSigOpCost, unsigned int bytes_per_sigop);
int64_t GetVirtualTransactionInputSize(const CTxIn& tx, int64_t nSigOpCost, unsigned int bytes_per_sigop);

static inline int64_t GetVirtualTransactionSize(const CTransaction& tx)
Copy link
Member

Choose a reason for hiding this comment

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

Would make grepping for the remaining bugs easier as well. e.g., anything like GetVirtualTransactionSize(tx, 0, 0) would be obviously a bug at that point

+1 to this, I think 1b163ae would feel even safer if the new function was called GetBIP141VirtualTransactionSize or even GetUnsafeVirtualTransactionSize since it's 99% test-only.

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Sep 26, 2023
…n package context

eb8f58f Add functional test to catch too large vsize packages (Greg Sanders)
1a579f9 Handle over-sized (in virtual bytes) packages with no in-mempool ancestors (Greg Sanders)
bc013fe Bugfix: Pass correct virtual size to CheckPackageLimits (Luke Dashjr)
533660c Replace MAX_PACKAGE_SIZE with MAX_PACKAGE_WEIGHT to avoid vbyte confusion (Greg Sanders)

Pull request description:

  (Alternative) Minimal subset of bitcoin#28345 to:

  1) Replace MAX_PACKAGE_SIZE with MAX_PACKAGE_WEIGHT which accounts for additional WU necessary to not exclude default chain limit transactions that would have been accepted individually. Avoids sigops vbyte confusion.
  2) pass correct vsize to chain limit evaluations in package context
  3) stop overly-large packages that have no existing mempool ancestors (also a bugfix by itself if someone sets non-standard chain limits)

  This should fix the known issues while not blocking additional refactoring later.

ACKs for top commit:
  achow101:
    ACK eb8f58f
  ariard:
    Re-Code ACK eb8f58f
  glozow:
    reACK eb8f58f

Tree-SHA512: 1b5cca1a526207e25d387fcc29a776a3198c3a013dc2b35c6275b9d5a64db2476c154ebf52e3a1aed0b9924c75613f21a946577aa760de28cadf0c9c7f68dc39
luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2023
luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2023
…ly account for non-weight vsize

Github-Pull: bitcoin#28345
Rebased-From: ae232c7
luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2023
@DrahtBot
Copy link
Contributor

DrahtBot commented Nov 8, 2023

🐙 This pull request conflicts with the target branch and needs rebase.

Copy link
Member

@ismaelsadeeq ismaelsadeeq left a comment

Choose a reason for hiding this comment

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

Concept ACK

@DrahtBot
Copy link
Contributor

DrahtBot commented Jan 5, 2024

There hasn't been much activity lately and the patch still needs rebase. What is the status here?

  • Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
  • Is it no longer relevant? ➡️ Please close.
  • Did the author lose interest or time to work on this? ➡️ Please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future.

@DrahtBot
Copy link
Contributor

DrahtBot commented Apr 3, 2024

⌛ There hasn't been much activity lately and the patch still needs rebase. What is the status here?

  • Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
  • Is it no longer relevant? ➡️ Please close.
  • Did the author lose interest or time to work on this? ➡️ Please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future.

@achow101
Copy link
Member

achow101 commented Apr 9, 2024

Closing as up for grabs due to lack of activity.

@achow101 achow101 closed this Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants