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

Add absurdly high fee message to validation state #5913

Merged
merged 1 commit into from Aug 5, 2015

Conversation

shaulkf
Copy link
Contributor

@shaulkf shaulkf commented Mar 17, 2015

Currently error message isn't propagating to RPC.
Not sure how reject constants should be numbered, for now I arbitrarily chose 0x44, please advise.

@sipa
Copy link
Member

sipa commented Mar 17, 2015

There is no need for a reject code, as this can never trigger for peer-to-peer initiated transactions, so it can never result in a reject message.

If you really need a reject code, add a REJECT_LOCAL or something, reserved for conditions that can only trigger locally (and mark it is an implementation detail, not related to BIP 61.

@shaulkf
Copy link
Contributor Author

shaulkf commented Mar 17, 2015

@sipa I believe there should be a code, in case RPC users want to catch the error without having to match the text. Any convention for numbering or could I choose any arbitrary code? (0x60 perhaps)

@sipa
Copy link
Member

sipa commented Mar 17, 2015

Well you can't pick anything that could potentially be later used in the P2P protocol, which why I would prefer no actual code. If there really is a need for RPC error codes separately from what the peer to peer protocol does, perhaps there should just be two codes. In general, I think it's not possible to predict all possible reason for rejecting things, and not really viable to have codes for everything.

@shaulkf
Copy link
Contributor Author

shaulkf commented Mar 17, 2015

I'm not sure what you mean by adding REJECT_LOCAL, should I create an error code which will be overloaded for any local error? How about REJECT_LOCAL = 0x00.

@laanwj
Copy link
Member

laanwj commented Mar 18, 2015

You could use reject codes > 0x100 for local-only conditions. These cannot be passed over the P2P network.

@shaulkf
Copy link
Contributor Author

shaulkf commented Mar 18, 2015

@laanwj Is it okay to change reject message codes to unsigned int for this purpose? If not, please advise is we can assign a dedicated 2 byte code (e.g. 0x00 or 0xFF) for all REJECT_LOCAL errors. I prefer the first solution as RPC users can catch errors with explicit error codes.

@laanwj
Copy link
Member

laanwj commented Mar 24, 2015

@shaulkf Changing the internal type is fine with me, otherwise I wouldn't have suggested it. But be careful that you don't accidentally change the type that is sent in the protocol.

@laanwj
Copy link
Member

laanwj commented Apr 8, 2015

utACK

@luke-jr
Copy link
Member

luke-jr commented Jun 24, 2015

Needs rebase. I suggest leaving the const reject message codes (now in consensus/validation.h) as unsigned char, changing CValidationState as you already do, and putting the local codes in main.h (for now).

@luke-jr
Copy link
Member

luke-jr commented Jun 24, 2015

Also:

main.cpp: In function ‘void InvalidBlockFound(CBlockIndex*, const CValidationState&)’:
main.cpp:1369:56: warning: narrowing conversion of ‘(& state)->CValidationState::GetRejectCode()’ from ‘unsigned int’ to ‘unsigned char’ inside { } is ill-formed in C++11 [-Wnarrowing]
             CBlockReject reject = {state.GetRejectCode(), state.GetRejectReason().substr(0, MAX_REJECT_MESSAGE_LENGTH), pindex->GetBlockHash()};
                                                        ^

@paveljanik
Copy link
Contributor

Needs rebase.
I'd prefer to have something in really soon. RPC returns no clean error message and it is boring to look up the actual error in the debug log.

@shaulkf
Copy link
Contributor Author

shaulkf commented Jun 26, 2015

Rebased and changed according to @luke-jr's recommendation

@shaulkf
Copy link
Contributor Author

shaulkf commented Jun 30, 2015

Thanks @paveljanik, pushed a fix and rebased, this is a remnant from a change I ended up reverting. I agree regarding Invalid and DoS but this should be in a separate PR as it requires reordering the arguments.

@luke-jr
Copy link
Member

luke-jr commented Jul 2, 2015

@shaulkf Please fix the warning.

@paveljanik
Copy link
Contributor

Something like this needed?

diff --git a/src/main.cpp b/src/main.cpp
index f67f1fd..5229f6f 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -182,7 +182,7 @@ namespace {
 namespace {

 struct CBlockReject {
-    unsigned char chRejectCode;
+    unsigned int chRejectCode;
     string strRejectReason;
     uint256 hashBlock;
 };

@luke-jr
Copy link
Member

luke-jr commented Jul 2, 2015

Not sure, that might change the protocol. Maybe:

CBlockReject reject = {(unsigned char)state.GetRejectCode(), state.GetRejectReason().substr(0, MAX_REJECT_MESSAGE_LENGTH), pindex->GetBlockHash()};

@paveljanik
Copy link
Contributor

Right.

@laanwj
Copy link
Member

laanwj commented Aug 5, 2015

Need this for #6519

@sipa
Copy link
Member

sipa commented Aug 5, 2015

utACK.

Maybe this also needs an assert before sending out a reject message that the chRejectCode is in the right range.

@laanwj
Copy link
Member

laanwj commented Aug 5, 2015

Yes, good point. I'll add it during merge.

@laanwj laanwj merged commit a651403 into bitcoin:master Aug 5, 2015
laanwj added a commit that referenced this pull request Aug 5, 2015
5922b67 Add assertion and cast before sending reject code (Wladimir J. van der Laan)
a651403 Add absurdly high fee message to validation state (for RPC propagation) (Shaul Kfir)
@@ -497,4 +497,7 @@ extern CBlockTreeDB *pblocktree;
*/
int GetSpendHeight(const CCoinsViewCache& inputs);

/** local "reject" message codes for RPC which can not be triggered by p2p trasactions */
Copy link

Choose a reason for hiding this comment

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

Nit: Spelling error trasactions.
See theuni#48

@theuni Will there be a Trivial pull before 0.11?

laanwj added a commit to laanwj/bitcoin that referenced this pull request Dec 7, 2015
Ever since we bitcoin#5913 have been sending invalid reject messages
for transactions and blocks.
laanwj added a commit that referenced this pull request Dec 10, 2015
Ever since we #5913 have been sending invalid reject messages
for transactions and blocks.

test: Add basic test for `reject` code

Extend P2P test framework to make it possible to expect reject
codes for transactions and blocks.

Github-Pull: #7179
Rebased-From: 9fc6ed6 2041190
furszy added a commit to PIVX-Project/PIVX that referenced this pull request Jun 20, 2020
ca489c9 [Tests] Fix expected error messages (random-zebra)
9f84c52 Consensus: Remove calls to error() and FormatStateMessage() (random-zebra)
0e4d964 Move mempool rejections to new debug category (random-zebra)
e0db16d Add information to errors in ConnectBlock, CheckBlock (random-zebra)
d4ed81c Remove most logging from transaction validation (random-zebra)
94b2577 Add function to convert CValidationState to a human-readable message (random-zebra)
1ddc88f Introduce REJECT_INTERNAL codes for local AcceptToMempool errors (random-zebra)
55e00a2 Add debug message to CValidationState for optional extra information (random-zebra)
05cf74b Add absurdly high fee message to validation state (for RPC propagation) (random-zebra)

Pull request description:

  - change `CValidationState::chRejectCode` to int
  - add `CValidationState::strDebugMessage` for optional information
  - add `FormatStateMessage` function to convert CValidationState to a human-readable message
  - introduce REJECT_INTERNAL rejection codes for ATMP and make their logging optional
  - remove unnecessary direct logging in `CheckTransaction`, `AcceptToMemoryPool`, `CheckTxInputs`, `CScriptCheck::operator()`
  - add detailed state information to the errors in `CheckBlock` and `ConnectBlock`

  Backported from:

  - bitcoin#5913
  - bitcoin#6519
  - bitcoin#7287

ACKs for top commit:
  Fuzzbawls:
    ACK ca489c9
  furszy:
    re ACK ca489c9 and merging

Tree-SHA512: ab972801fa45c2f84abf84790b0f0f22dc5668e170f51785f3cfbf806bda7988f55bbd43c24ae591ffe3bd62190f6cd99a3b640373c431ab92c0ddcabea1c999
zkbot added a commit to zcash/zcash that referenced this pull request Aug 13, 2021
ZIP 239 preparations 4

Cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#5913
  - Replaces #3111.
  - Includes an extra commit included by upstream in the merge outside the PR.
- bitcoin/bitcoin#6519
- bitcoin/bitcoin#7179
- bitcoin/bitcoin#7853
- bitcoin/bitcoin#7960
zkbot added a commit to zcash/zcash that referenced this pull request Aug 13, 2021
ZIP 239 preparations 4

Cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#5913
  - Replaces #3111.
  - Includes an extra commit included by upstream in the merge outside the PR.
- bitcoin/bitcoin#6519
- bitcoin/bitcoin#7179
- bitcoin/bitcoin#7853
- bitcoin/bitcoin#7960
zkbot added a commit to zcash/zcash that referenced this pull request Aug 17, 2021
ZIP 239 preparations 4

Cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#5913
  - Replaces #3111.
  - Includes an extra commit included by upstream in the merge outside the PR.
- bitcoin/bitcoin#6519
- bitcoin/bitcoin#7179
- bitcoin/bitcoin#7853
- bitcoin/bitcoin#7960
@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.

None yet

6 participants