-
Notifications
You must be signed in to change notification settings - Fork 35.7k
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
Optional late, block submission, difficulty test #22119
Comments
How is this different from getblocktemplate proposal? |
It is no changes to any rules or validation, only one change to the order in which they are done, to optionally do the difficulty test last rather then where it is now done. |
They BIP says: "The block data MUST be validated and checked against the server's usual acceptance rules (excluding the check for a valid proof-of-work)", which is what your feature request is asking for, no? I am saying this is already implemented unless I am missing something. |
I'm under the impression that not all validity and consensus tests are done on a block submitted, that only fails the difficulty test, and is valid under all other rules. |
@kanoi Note that @MarcoFalke is referring to the "block proposal" mode of |
Ah OK, I am referring to submitblock - but I'm not sure if he meant there is some method in getblocktemplate with the workid, to later use that workid to submit a low difficulty block with otherwise full testing. |
I agree this is a bit hidden, but I linked you the RPC documentation and the section in the BIP that explains this. |
Since this was changed to 'Help' ... The normal submit is of course is: Looking at the rpc/mining.cpp code for 0.21.1 getblocktemplate when it sees the 'mode' of 'proposal' it says (skipping some parts):
So, if instead I do this with the same data: So to verify this I remove the difficulty test from the code pow.cpp: Now the above submitblock replies: So what I can make of all this is either the code is deprecated and not been updated, or there's some other data required for the proposal, that isn't needed until it gets to whatever causes "bad-witness-nonce-size" So my suggestion, then, since a completely unexpected designed interface exists for submitting a proposal, that the 'submitblock' should be passed an optional 'proposal' and do the: i.e. from the code point of view, how my original suggested change could be best implemented and used in a manner that makes sense using 'submitblock' not 'getblocktemplate' Edit: and in case it wasn't obvious, the line in validation.cpp that gives this error is: |
Though I've not yet attempted to test the change to determine if it is related to the TestBlockValidity() issue, #20749 So I guess for the issue I've brought up about TestBlockValidity() possibly not working since at least 0.17, I'll shortly do some more testing with the current git to see if that's related or not. |
I've noticed that the TestBlockValidity() issue is still the same even with V23.0 Having read through the code to consider a simple implementation to place the POW check last when requested but leave it first if the latePOW isn't requested, I've found that the check code repeats many checks when it gets a block submission. To be specific: src/rpc/mining.cpp submitblock() does some checks then calls src/validation.cpp ProcessNewBlock() However ProcessNewBlock() repeats checks due to: These two overlap some checks and also do some different checks. Thus to optionally run the POW check last, it would have to disable it everywhere CheckBlockHeader() is called I wonder if this convolution is due to the unnecessary TestBlockValidity() code that appears to be unsupported and poorly documented. If anyone has the nous to work out how to implement this cleanly, that would be much appreciated. |
Software development for any bitcoin mining, solo or pooled, requires an excessively large hash rate to ensure block submission is correct.
Effectively to submit a full difficulty network block before there is some certainly of the validity of the block generation code developed.
Many developers do not test this properly and have lost blocks due to the developer's ignorance or negligence.
If instead the difficulty of the block submitted could optionally only be tested last, then testing block generation by submitting a low difficulty block, that would fail with {"result":"high-hash","error":null,"id":1} could directly imply that all other requirements and consensus tests have passed, only the low difficulty of the block has failed.
Implementing this would greatly simplify testing block generation code, since testing could be run on a bitcoin on the live network which would also be under the full validation and consensus rules of the live network.
A developer could simply stop their live bitcoin, restart it with the late difficulty validation flag and then run any testing required, then restart it without the flag.
This change would, of course, have to be optional, since saving one of the quickest and easiest tests of hashing the block header, moved much later in the validation, might open a DDoS exploit.
The bitcoin code could have two paths doing the difficulty validation and run one or the other depending upon the runtime flag.
Using testnet is not an exact test of the bitcoin block validation code due to varying code paths and varying consensus rules.
My normal process to test this is to hack the difficulty test in current bitcoin code and submit a lower difficulty block.
This however, means I must lock the development bitcoin behind a completely closed wall, since should it attempt to transmit the low difficulty block, it's IP would be appropriately ostracized by the live network.
The further result of this is the bitcoin having invalid blocks in it's database, which I have found it unable to roll back on a restart during re-validation with an unmodified bitcoin, and thus having to delete it.
Using a live online bitcoin, with a simple restart with a flag to enable full testing other than difficulty being last, should promote better development of mining generation software.
The text was updated successfully, but these errors were encountered: