Introduce assumevalid setting to skip validation presumed valid scripts.

gmaxwell commented at 11:18 pm on January 6, 2017: contributor

This disentangles the script validation skipping from checkpoints.

A new option is introduced “assumevalid” which specifies a block whos ancestors we assume all have valid scriptsigs and so we do not check them when they are also burried under the best header by a weeks worth of work.

Unlike checkpoints this has no influence on consensus unless you set it to a block with an invalid history. Because of this it can be easily be updated without risk of influencing the network consensus.

This results in a massive IBD speedup.

This approach was independently recommended by Peter Todd and Luke-Jr since POW based signature skipping (see PR#9180) does not have the verifiable properties of a specific hash and may create bad incentives.

The downside is that, like checkpoints, the defaults bitrot and older releases will sync slower. On the plus side users can provide their own value here, and if they set it to something crazy all that will happen is more time will be spend validating signatures.

Checkblocks and checklevel are also moved to the hidden debug options: Especially now that checkblocks has a low default there is little need to change these settings, and users frequently misunderstand them as influencing security or IBD speed. By hiding them we offset the space added by this new option.

gmaxwell commented at 11:23 pm on January 6, 2017: contributor

par=4 chainstate reindex with dbcache 2000 goes from 6.15 hours to 2.96 hours. @petertodd I know you had a reservation about keeping the default in chainparams but we also have a number of other similar heuristics there (such as bip34 height, total work in the best chain, various flags). I’d suggest in the future we should move those more policy like things into their own section of chain params.

I’d rather do that as a separate refactor later than spread this setting out away from the other ones that need to get changed as part of the review process.

fanquake added the label Validation on Jan 7, 2017

in doc/release-process.md: in d5988db393 outdated

12@@ -13,6 +13,11 @@ Before every minor and major release:
13 * Update version in sources (see below)
14 * Write release notes (see below)
15 * Update `src/chainparams.cpp` nMinimumChainWork with information from the getblockchaininfo rpc.
16+* Update `src/chainparams.cpp` defaultAssumeValid  with information from the getblockhash rpc.
17+  - The selected value must not be orphaned so it may be useful to set the value two blocks back from the tip.

TheBlueMatt commented at 7:06 pm on January 7, 2017:

I assume when you saiy “set the value two blocks back” you mean “set the value two blocks back from the tip at around the time rcs begin, so that it is a month back when release actually happens”?

gmaxwell commented at 10:23 pm on January 7, 2017:

I don’t intend for it to be a month back at the release. There is no reason to set it back at all except that if the block falls out of the chain the speedup will be lost. Another possiblity would be to advise setting it at the tip with a note that it must be fixed if the block falls out of the chain.

I also don’t see a reason that this couldn’t be updated at the last RC or even between an RC and a release. In general we should set it as far forward as possible… there is no benefit in setting it back, and the more forward it is, the longer it takes for the cached value to rot.

TheBlueMatt commented at 11:20 pm on January 7, 2017:

OK. Fair enough, though I disagree that it should be allowed to change pre-release post-rc…for a parameter like this we really want lots of eyes and a few days of letting people reindex prior to release.

luke-jr commented at 11:32 pm on January 7, 2017:

There is no reason to set it back at all except that if the block falls out of the chain the speedup will be lost.

Note we could make it smart enough to see the common parent block, but I’m not sure it’s worth the additional effort.

I also don’t see a reason that this couldn’t be updated at the last RC or even between an RC and a release. In general we should set it as far forward as possible…

If we’re setting it last minute, I do think more than 2 blocks back would be best. Maybe 10.

in src/validation.cpp: in d5988db393 outdated

1740+                //  into accepting an invalid block through telling users they must manually set assumevalid.
1741+                //  Requiring a software change or burrying the invalid block, regardless of the setting, makes
1742+                //  it hard to hide the implication of the demand.  This also avoids having release candidates
1743+                //  that are hardly doing any signature verification at all in testing without having to
1744+                //  artificially set the default assumed verified block further back.
1745+                fScriptChecks = (GetBlockProofEquivalentTime(*pindexBestHeader, *pindex, *pindexBestHeader, chainparams.GetConsensus()) < 60 * 60 * 24 * 7);

TheBlueMatt commented at 7:11 pm on January 7, 2017:

Is there any meaningful difference here between a month and a week? (let the bikeshedding begin!).

gmaxwell commented at 10:20 pm on January 7, 2017:

I don’t think so. I picked a week here because (1) that is the minimum time in our process between an RC and a release and (2) I think two days is likely sufficient for the purpose in the comment– enough time for a widespread public response.

But if people preferred a month, that would be okay too. I was half expecting this test to get bikesheded out rather than cranked up.

One downside of a longer value is that users on really slow devices who might put a very current value in from another node of theirs would get a diminished synctime improvement.

TheBlueMatt commented at 11:19 pm on January 7, 2017:

Hum, at the risk of overdesign, I’d be ok with only a week or so if the user explicitly specified a trust anchor, but for default-release, I’m afraid a week isnt all that long in the context of relying on widespread public outcry to prevent failures.

gmaxwell commented at 1:02 am on January 8, 2017:

You’re concerned about it with respect to the default? I don’t think that makes sense: It’s correct or it isn’t and stepping a few blocks back there doesn’t make it more correct. If not for the extra complexity and the benefit that block validation gets better tested in the RC cycle I would have exempted the default from this test.

If the review process won’t catch an invalid block in the chain– a simple comparison with a constant– how is it going to catch the invalidity being simply made valid by indirect and subtle changes to the consensus behavior?

Petertodd’s argument for this approach was that the review effort for these values is trivial compared to any of the rest of the software, making it safe and easy to update them with a minimum of additional scrutiny. @luke-jr

Note we could make it smart enough to see the common parent block, but I’m not sure it’s worth the additional effort.

We could ship a tool that performed the entire set of updates for a release, it would be pretty easy to have such a tool use chain-tips to go back further if there is a competing fork. Similarly, the tool could also be used to check, like we have for signed commits. (though if we do that I think it should be a separate PR.)

sipa commented at 10:42 pm on January 9, 2017:

This seems weird. You’re checking

Whether the to-be-connected block is an ancestor of the assumed-valid block.
Whether a specific headers chain is at least a week ahead of the to-be-connected block.

There is no guarantee however that pindexBestHeader descends from the to-be-connected block, so what is the relevance of it here?

gmaxwell commented at 8:15 pm on January 10, 2017:

Okay, fixed, I also require the block to be an ancestor of the BestHeader.

jtimon commented at 9:00 pm on January 12, 2017:

I personally don’t like this part. I think it’s simpler to just “artificially set the default assumed verified block further back”, don’t see that as a big deal. But no strong opinion, if that’s a concern, the solution seems good.

jtimon commented at 11:09 pm on January 12, 2017:

Micro-nit: regardless of the value chosen, 60 * 60 * 24 * 7 could use a const or #define.

TheBlueMatt commented at 7:11 pm on January 7, 2017: member

Concept ACK. I like this approach.

luke-jr commented at 11:33 pm on January 7, 2017: member

if they set it to something crazy all that will happen is more time will be spend validating signatures.

That’s not the worst-case scenario. They could set it to a block with invalid scripts in the history, which would break from consensus. I do think this is an acceptable risk, but maybe should get at least some warning.

gmaxwell commented at 0:03 am on January 8, 2017: contributor

@luke-jr yes but only if it is buried by a week (in current code), which is the reason for that additional test. The logprint that it’s assuming valid was my warning.. but if you’d like to suggest something more…

in src/init.cpp: in d6598eeb19 outdated

920@@ -920,6 +921,12 @@ bool AppInitParameterInteraction()
921     fCheckBlockIndex = GetBoolArg("-checkblockindex", chainparams.DefaultConsistencyChecks());
922     fCheckpointsEnabled = GetBoolArg("-checkpoints", DEFAULT_CHECKPOINTS_ENABLED);
923 
924+    hashAssumeValid = uint256S(GetArg("-assumevalid", chainparams.GetConsensus().defaultAssumeValid.GetHex()));

robmcl4 commented at 5:34 am on January 9, 2017:

This seems to result in an out-of-bounds memory access when -assumevalid= (with no value) is supplied. uint256S(..) invokes base_blob::SetHex(const char *), which assumes a supplied length of at least 1. An out-of-bounds access then occurs at src/uint256.cpp:39.

gmaxwell commented at 10:59 am on January 9, 2017:

GetArg returns a std:string, base_blob::SetHex(const std::string& str) invokes c_str() on the pinput and calls the c_str argumented version (which is null terminated). On a zero length input the input array with be pointer to a null byte. This will fail the psz[0] == ‘0’ (note the quotes). No out of bounds access will occur on line 39 (nor below). What am I misreading?

robmcl4 commented at 1:11 pm on January 9, 2017:

Oh of course, the short-circuit eval there slipped my mind. Never mind, all good!

in doc/release-notes.md: in d6598eeb19 outdated

78+  scripts/signatures.  Although the verification must pass to ensure the security
79+  of the system, no other result from this verification is needed: If the node
80+  knew the history of a given block were valid it could skip checking scripts
81+  for its ancestors.
82+
83+- A new configuration option 'assumevalid' is provided to express this knoweldge

sipa commented at 10:23 pm on January 9, 2017:

knowledge

gmaxwell commented at 3:43 am on January 10, 2017:

fixed.

in src/init.cpp: in d6598eeb19 outdated

328@@ -329,8 +329,7 @@ std::string HelpMessage(HelpMessageMode mode)
329     strUsage += HelpMessageOpt("-blocknotify=<cmd>", _("Execute command when the best block changes (%s in cmd is replaced by block hash)"));
330     if (showDebug)
331         strUsage += HelpMessageOpt("-blocksonly", strprintf(_("Whether to operate in a blocks only mode (default: %u)"), DEFAULT_BLOCKSONLY));
332-    strUsage += HelpMessageOpt("-checkblocks=<n>", strprintf(_("How many blocks to check at startup (default: %u, 0 = all)"), DEFAULT_CHECKBLOCKS));
333-    strUsage += HelpMessageOpt("-checklevel=<n>", strprintf(_("How thorough the block verification of -checkblocks is (0-4, default: %u)"), DEFAULT_CHECKLEVEL));
334+    strUsage +=HelpMessageOpt("-assumevalid=<hex>", strprintf(_("If this block is in the chain _assume_ that it and its ancestors are valid and potentially skip their script verification (0 to verify all, default: %s, testnet: %s)"), Params(CBaseChainParams::MAIN).GetConsensus().defaultAssumeValid.GetHex(), Params(CBaseChainParams::TESTNET).GetConsensus().defaultAssumeValid.GetHex()));

sipa commented at 10:26 pm on January 9, 2017:

Do we use _text_ anywhere else in the help output? It seems a bit strange.

gmaxwell commented at 3:44 am on January 10, 2017:

removed.

in src/validation.h: in d6598eeb19 outdated

184@@ -185,6 +185,9 @@ extern CAmount maxTxFee;
185 extern int64_t nMaxTipAge;
186 extern bool fEnableReplacement;
187 
188+/** Block hash whos ancestors we will assume to have valid scripts without checking them. */

sipa commented at 10:43 pm on January 9, 2017:

whose

gmaxwell commented at 3:44 am on January 10, 2017:

fixed.

in doc/release-notes.md: in d6598eeb19 outdated

70@@ -71,6 +71,27 @@ P2P connection management
71 
72 - New connections to manually added peers are much faster.
73 
74+Introduction of assumed-valid blocks
75+-------------------------------------
76+
77+- A signfigant portion of the initial block download time is spent verifying

sipa commented at 10:43 pm on January 9, 2017:

significant

gmaxwell commented at 3:43 am on January 10, 2017:

fixed.

in src/chainparams.cpp: in d6598eeb19 outdated

 98@@ -99,6 +99,9 @@ class CMainParams : public CChainParams {
 99         // The best chain should have at least this much work.
100         consensus.nMinimumChainWork = uint256S("0x0000000000000000000000000000000000000000002cb971dd56d1c583c20f90");
101 
102+        // By default assume that the signatures in ancestors of this block are valid.
103+        consensus.defaultAssumeValid = uint256S("0x0000000000000000030abc968e1bd635736e880b946085c93152969b9a81a6e2");

sipa commented at 10:45 pm on January 9, 2017:

Maybe list the height/time of that block in a comment?

gmaxwell commented at 3:44 am on January 10, 2017:

added height. I’m trying to not make the update procedure too much work.

sipa commented at 11:09 pm on January 11, 2017: member

utACK 739983db5dd799424738bc752eee7721fc94f1fb

theuni commented at 1:20 am on January 12, 2017: member

utACK 739983db5dd799424738bc752eee7721fc94f1fb. I like the approach as well.

jnewbery commented at 4:24 pm on January 12, 2017: member

Looks good to me. I’m going to try to write a test case.

One comment: please remove or update the comment in CheckInputs() (validation.cpp, line 1392):

0        // Skip ECDSA signature verification when connecting blocks before the
1        // last block chain checkpoint. Assuming the checkpoints are valid this
2        // is safe because block merkle hashes are still computed and checked,
3        // and any change will be caught at the next checkpoint. Of course, if
4        // the checkpoint is for a chain that's invalid due to false scriptSigs
5        // this optimization would allow an invalid chain to be accepted.

in src/consensus/params.h: in 739983db5d outdated

61@@ -62,6 +62,7 @@ struct Params {
62     int64_t nPowTargetTimespan;
63     int64_t DifficultyAdjustmentInterval() const { return nPowTargetTimespan / nPowTargetSpacing; }
64     uint256 nMinimumChainWork;
65+    uint256 defaultAssumeValid;

jtimon commented at 8:08 pm on January 12, 2017:

This can be in CChainParams instead of Consensus::Params, which is the consensus “section of chainparams”.

in doc/release-notes.md: in 739983db5d outdated

82+
83+- A new configuration option 'assumevalid' is provided to express this knowledge
84+  to the software.  Unlike the 'checkpoints' in the past this setting does not
85+  force the use of a particular chain: chains that are consistent with it are
86+  processed quicker, but other chains are still accepted if they'd otherwise
87+  be chosen as best. Also unlike 'checkpoints' the user can configure which

jtimon commented at 8:50 pm on January 12, 2017:

unlike with ‘checkpoints’?

in doc/release-notes.md: in 739983db5d outdated

89+  sync more quickly if the setting is updated by the user.
90+
91+- Because the validity of a chain history is a simple objective fact it is much
92+  easier to review this setting.  As a result the software ships with a default
93+  value adjusted to match the current chain shortly before release.  The use
94+  of this default value can be disabled by setting -assumevalid=0

jtimon commented at 8:54 pm on January 12, 2017:

Perhaps add “To avoid releasing software with a ’too recent’ default ‘assumevalid’, checks will never be skipped for blocks that are only a week or less away from the most-work known tip.”. Or something of the sort.

jtimon commented at 10:45 pm on January 12, 2017:

Nah, I’m now convinced about using the mechanism, but not “To avoid releasing software with a ’too recent’ default ‘assumevalid’”, rather “To avoid using being fooled with too recent invalid ‘assumevalid’”.

gmaxwell commented at 3:09 pm on January 13, 2017:

I don’t think the fine details of the implementation are of general interest for the release nodes. If people think this is less secure than it is – thats not the end of the world, and a separate FAQ would be fine if there is confusion/concern.

in src/validation.cpp: in 739983db5d outdated

1732+        //  relative to a piece of software is an objective fact these defaults can be easily reviewed.
1733+        // This setting doesn't force the selection of any particular chain but makes validating some faster by
1734+        //  effectively caching the result of part of the verification.
1735+        BlockMap::const_iterator  it = mapBlockIndex.find(hashAssumeValid);
1736+        if (it != mapBlockIndex.end()) {
1737+            if (it->second->GetAncestor(pindex->nHeight) == pindex && pindexBestHeader->GetAncestor(pindex->nHeight) == pindex) {

jtimon commented at 8:55 pm on January 12, 2017:

pindexBestHeader->GetAncestor(pindex->nHeight) == pindex could be moved to first if. Maybe with no gain and perhaps this is clearer.

gmaxwell commented at 3:10 pm on January 13, 2017:

That test should pretty much never fail, so it runs later to avoid wasting time trying it for blocks past the assumedvalid point.

jtimon commented at 9:05 pm on January 12, 2017: contributor

utACK 739983d modulo small nits that I guess can be fixed later.

TheBlueMatt commented at 11:11 pm on January 12, 2017: member

utACK 739983db5dd799424738bc752eee7721fc94f1fb if we change the time for comparison to anything above 2 weeks, though open to further discussion on IRC.

TheBlueMatt commented at 11:35 pm on January 12, 2017: member

Another thing that just occurred to me - do we want -checkpoints=0 to imply -assumevalid=0? They seem rather equivalent in usage.

On January 12, 2017 3:09:16 PM PST, “Jorge Timón” notifications@github.com wrote:

jtimon commented on this pull request.
   // We've been configured with the hash of a block which has
been externally verified to have a valid history.
   // A suitable default value is included with the software and
updated from time to time. Because validity
   //  relative to a piece of software is an objective fact these
defaults can be easily reviewed.
   // This setting doesn't force the selection of any particular
chain but makes validating some faster by
   //  effectively caching the result of part of the
verification.
   BlockMap::const_iterator  it =
mapBlockIndex.find(hashAssumeValid);
   if (it != mapBlockIndex.end()) {
       if (it->second->GetAncestor(pindex->nHeight) == pindex) {
           // This block is a member of the assumed verified
chain: potentially disable script checks
           // The equivalent time check discourages hashpower
from extorting the network via DOS attack
           //  into accepting an invalid block through telling
users they must manually set assumevalid.
           //  Requiring a software change or burrying the
invalid block, regardless of the setting, makes
           //  it hard to hide the implication of the demand. 
This also avoids having release candidates
           //  that are hardly doing any signature verification
at all in testing without having to
           //  artificially set the default assumed verified
block further back.
           fScriptChecks =
(GetBlockProofEquivalentTime(*pindexBestHeader, *pindex, *pindexBestHeader, chainparams.GetConsensus()) < 60 * 60 * 24 * 7);

Micro-nit: regardless of the value chosen, 60 * 60 * 24 * 7 could use a const or #define.

– You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/9484

TheBlueMatt commented at 11:39 pm on January 12, 2017: member

Actually I vote no - we dont need more parameter interactions and if folks are using -checkpoints=0 to avoid trusting the software they’re running without reading the changelog (or the realease notes), then they’re really not getting what they want. But others might have a different view?

fanquake commented at 8:55 am on January 13, 2017: member

Tested this with -reindex-chainstate -dbcache=4096 -par=8 Reindex time to 447885 was 2h12m.

gmaxwell commented at 3:24 pm on January 13, 2017: contributor

Updated, added a test against nMinimumChainWork to address some concerns, and moved the depth check to two weeks to satisfy Matt. I think it’s overkill (and it would be better to have some different sanity checks) but it could be reduced in the future; and it’s still better than we are now.

Introduce assumevalid setting to skip presumed valid scripts.

This disentangles the script validation skipping from checkpoints.

A new option is introduced "assumevalid" which specifies a block whos
 ancestors we assume all have valid scriptsigs and so we do not check
 them when they are also burried under the best header by two weeks
 worth of work.

Unlike checkpoints this has no influence on consensus unless you set
 it to a block with an invalid history.  Because of this it can be
 easily be updated without risk of influencing the network consensus.

This results in a massive IBD speedup.

This approach was independently recommended by Peter Todd and Luke-Jr
 since POW based signature skipping (see PR#9180) does not have the
 verifiable properties of a specific hash and may create bad incentives.

The downside is that, like checkpoints, the defaults bitrot and older
 releases will sync slower.  On the plus side users can provide their
 own value here, and if they set it to something crazy all that will
 happen is more time will be spend validating signatures.

Checkblocks and checklevel are also moved to the hidden debug options:
 Especially now that checkblocks has a low default there is little need
 to change these settings, and users frequently misunderstand them as
 influencing security or IBD speed.  By hiding them we offset the
 space added by this new option.

e440ac7ef3

in src/validation.cpp: in bbdb254951 outdated

1389@@ -1389,11 +1390,10 @@ bool CheckInputs(const CTransaction& tx, CValidationState &state, const CCoinsVi
1390         // Only if ALL inputs pass do we perform expensive ECDSA signature checks.
1391         // Helps prevent CPU exhaustion attacks.
1392 
1393-        // Skip ECDSA signature verification when connecting blocks before the
1394-        // last block chain checkpoint. Assuming the checkpoints are valid this
1395+        // Skip script verification when connecting blocks under the
1396+        // assumedvalid block. Assuming the that block is valid this

jnewbery commented at 3:32 pm on January 13, 2017:

nit: s/the that/that the

gmaxwell commented at 3:42 pm on January 13, 2017:

fixed

instagibbs commented at 4:42 pm on January 13, 2017: member

utACK e440ac7ef3b6f3ad1cd8fc7027cece40413202d9

Travis may need a kick

TheBlueMatt commented at 5:07 pm on January 13, 2017: member

utACK e440ac7ef3b6f3ad1cd8fc7027cece40413202d9

morcos commented at 5:12 pm on January 13, 2017: member

utACK e440ac7 , will also try to find time to test

jnewbery commented at 9:05 pm on January 13, 2017: member

tested ACK.

I’ve written a new qa testcase that exercises the assumevalid parameter here: https://github.com/jnewbery/bitcoin/commit/fffb047ecf838ca4ccce1dc1347263aef8e90cda

Tests:

without assumevalid we reject a chain containing a transaction with an invalid signature
with assumevalid we reject a chain containing a transaction with an invalid signature where the invalid signature is buried by less than two weeks’ blocks
with assumevalid we accept a chain containing a transaction with an invalid signature where the invalid signature is buried by more than two weeks’ blocks

in src/chainparams.cpp: in e440ac7ef3 outdated

 98@@ -99,6 +99,9 @@ class CMainParams : public CChainParams {
 99         // The best chain should have at least this much work.
100         consensus.nMinimumChainWork = uint256S("0x0000000000000000000000000000000000000000002cb971dd56d1c583c20f90");
101 
102+        // By default assume that the signatures in ancestors of this block are valid.
103+        consensus.defaultAssumeValid = uint256S("0x0000000000000000030abc968e1bd635736e880b946085c93152969b9a81a6e2"); //447235

sdaftuar commented at 10:27 pm on January 13, 2017:

ACK 0x0000000000000000030abc968e1bd635736e880b946085c93152969b9a81a6e2

sipa commented at 5:46 pm on January 15, 2017:

ACK 0000000000000000030abc968e1bd635736e880b946085c93152969b9a81a6e2

instagibbs commented at 9:37 pm on January 16, 2017:

ACK 0000000000000000030abc968e1bd635736e880b946085c93152969b9a81a6e2

theuni commented at 10:15 pm on January 16, 2017:

post-merge ACK 0000000000000000030abc968e1bd635736e880b946085c93152969b9a81a6e2

rebroad commented at 1:49 am on January 18, 2017:

ACK the block, but NACK making this on by default. I love the feature, but I think there needs to be express consent by the user to avoid setting a potentially dangerous precedent. Also, it would be nice to allow the user to stipulate their own block by which to do this - perhaps they trust a particular node on the network and would based their block chosen on that.

MarcoFalke commented at 11:17 am on January 21, 2017:

@rebroad This is possible, please read the docs. Also, if you are unsure about the block hash, you can always set -noassumevalid

theuni commented at 2:55 am on January 14, 2017: member

Edit: ACK.

fanquake added this to the milestone 0.14.0 on Jan 14, 2017

sipa commented at 3:44 am on January 14, 2017: member

Please include @jnewbery’s tests.

Add assumevalid testcase

Adds a qa testcase testing the new "-assumevalid" option. The testcase builds
a chain that includes and invalid signature for one of the transactions and
sends that chain to three nodes:

 - node0 has no -assumevalid parameter and rejects the invalid chain.
 - node1 has -assumevalid set and accepts the invalid chain.
 - node2 has -assumevalid set but the invalid block is not buried deep
   enough to assume invalid, and so rejects the invalid chain.

7b5e3fe0cc

gmaxwell commented at 10:19 pm on January 14, 2017: contributor

Neat tests, I was surprised at how small it is for what it does.

sipa commented at 5:47 pm on January 15, 2017: member

utACK 7b5e3fe0ccb434821927c9cc2e9f2fb0d7f01dc4

morcos commented at 7:01 pm on January 15, 2017: member

did some additional light testing… still ACK

sipa commented at 9:35 pm on January 16, 2017: member

Tested a full reindex together with #9512 with asan/lsan/ubsan, all good.

sipa merged this on Jan 16, 2017

sipa closed this on Jan 16, 2017

sipa referenced this in commit 812714fd80 on Jan 16, 2017

btcdrak commented at 9:19 am on January 17, 2017: contributor

utACK 7b5e3fe

in doc/release-notes.md: in 7b5e3fe0cc

48@@ -49,7 +49,7 @@ Low-level RPC changes
49   than two arguments.
50 
51 Removal of Priority Estimation
52-------------------------------
53+-------------------------------

rebroad commented at 1:47 am on January 18, 2017:

?

in src/validation.cpp: in 7b5e3fe0cc

1389@@ -1389,11 +1390,10 @@ bool CheckInputs(const CTransaction& tx, CValidationState &state, const CCoinsVi
1390         // Only if ALL inputs pass do we perform expensive ECDSA signature checks.
1391         // Helps prevent CPU exhaustion attacks.
1392 
1393-        // Skip ECDSA signature verification when connecting blocks before the

rebroad commented at 1:51 am on January 18, 2017:

no longer ECDSA?

sipa commented at 0:28 am on January 21, 2017:

Script verification includes ECDSA verification, but does much more.

sipa commented at 3:26 pm on January 21, 2017: member

@rebroad The reasoning is that people are already relying on peer review to make sure the consensus logic isn’t being changed (which could also lead to invalid blocks being accepted), and that is much harder than checking whether a single block hash is part of a valid chain. This is different from chrckpoints, which do have an effect beyond skipping validation, and need much more careful choosing.

Vagabond referenced this in commit 56232b2000 on Aug 19, 2019

MarcoFalke locked this on Sep 8, 2021

Introduce assumevalid setting to skip validation presumed valid scripts. #9484