TomZ
2aa462f8bb
This is part of the protocol upgrade for 2020-05-15, and in general it seems to go the direction of "we did this before, lets do this again". The spec is clear enough, but there is still a lack of questioning and testing. The problem this attempts to fix has been neutered for years[1]. The spec states: > The essential idea of SigChecks is to perform counting solely in the > spending transaction, and count actual executed signature check > operations. This, however nobel and logical, ignores that the check-for-being-too-costly just pulled in a UTXO lookup and the loading of the output script from the historical chain. The goal that we protect against CPU over-use may be reached, but the price is a total system slowdown. You can have multiple CPUs, but the bus to permanent storage has one, max 2 parallel pipes. To ensure theHub stays the number one scalable node, I didn't blindly follow the spec, while making sure that the Hub is correctly going to follow/reject consensus violations of newly mined blocks. As a result the implementation in Flowee the Hub: * does not check sigcheck-counts on historical blocks (more than 1000 blocks in the past). This may increase the risk of chain-splits ever so slightly, but the cost of disk-IO would be too high. * No longer stores the value in the mempool, nor uses it for the CPU-miner. * Ties the sigcheck-limits to the user-set block-size-accept-limit. This is contrary to the spec which mistakenly thinks that BCH has a max block-size in the consensus rules. The effect is the same, though. * The per-intput standardness suggestion is not implemented because standardness checks don't currently fetch the previous outputs and that would be too expensive to add. * Standardness rules for the whole transaction are moved to the mempool-acceptance logic instead. The cost would be too great otherwise, similar to the previous point. Again, the effect is the same as likely intented. --- 1) since the intro of the CachingTransactionSignatureChecker
32 lines
1.3 KiB
C++
32 lines
1.3 KiB
C++
/*
|
|
* This file is part of the Flowee project
|
|
* Copyright (C) 2011-2015 The Bitcoin Core developers
|
|
* Copyright (C) 2017 Tom Zander <tomz@freedommail.ch>
|
|
*
|
|
* This program is free software: you can redistribute it and/or modify
|
|
* it under the terms of the GNU General Public License as published by
|
|
* the Free Software Foundation, either version 3 of the License, or
|
|
* (at your option) any later version.
|
|
*
|
|
* This program is distributed in the hope that it will be useful,
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
* GNU General Public License for more details.
|
|
*
|
|
* You should have received a copy of the GNU General Public License
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
*/
|
|
|
|
#include "TestMemPoolEntryHelper.h"
|
|
|
|
CTxMemPoolEntry TestMemPoolEntryHelper::FromTx(CMutableTransaction &tx, CTxMemPool *pool)
|
|
{
|
|
CTransaction txn(tx);
|
|
bool hasNoDependencies = pool ? pool->HasNoInputsOf(tx) : hadNoDependencies;
|
|
// Hack to assume either its completely dependent on other mempool txs or not at all
|
|
CAmount inChainValue = hasNoDependencies ? txn.GetValueOut() : 0;
|
|
|
|
return CTxMemPoolEntry(txn, nFee, nTime, dPriority, nHeight,
|
|
hasNoDependencies, inChainValue, spendsCoinbase, lp);
|
|
}
|