hash.ToString(), nFees, txMinFee),
REJECT_INSUFFICIENTFEE, "insufficient fee");
- // Continuously rate-limit free (really, very-low-fee)transactions
+ // Continuously rate-limit free (really, very-low-fee) transactions
// This mitigates 'penny-flooding' -- sending thousands of free transactions just to
// be annoying or make others' transactions take longer to confirm.
if (fLimitFree && nFees < ::minRelayTxFee.GetFee(nSize))
}
if (fRejectInsaneFee && nFees > ::minRelayTxFee.GetFee(nSize) * 10000)
- return error("AcceptToMemoryPool: : insane fees %s, %d > %d",
+ return error("AcceptToMemoryPool: insane fees %s, %d > %d",
hash.ToString(),
nFees, ::minRelayTxFee.GetFee(nSize) * 10000);
// This is done last to help prevent CPU exhaustion denial-of-service attacks.
if (!CheckInputs(tx, state, view, true, STANDARD_SCRIPT_VERIFY_FLAGS, true))
{
- return error("AcceptToMemoryPool: : ConnectInputs failed %s", hash.ToString());
+ return error("AcceptToMemoryPool: ConnectInputs failed %s", hash.ToString());
}
// Store transaction in memory
pool.addUnchecked(hash, entry);
return error("LoadBlockIndex() : genesis block not accepted");
if (!ActivateBestChain(state, &block))
return error("LoadBlockIndex() : genesis block cannot be activated");
- // Force a chainstate write so that when we VerifyDB in a moment, it doesnt check stale data
+ // Force a chainstate write so that when we VerifyDB in a moment, it doesn't check stale data
return FlushStateToDisk(state, FLUSH_STATE_ALWAYS);
} catch(std::runtime_error &e) {
return error("LoadBlockIndex() : failed to initialize block database: %s", e.what());
}
}
- //After new samples are added, we have to clear the sorted lists,
- //so they'll be resorted the next time someone asks for an estimate
+ // After new samples are added, we have to clear the sorted lists,
+ // so they'll be resorted the next time someone asks for an estimate
sortedFeeSamples.clear();
sortedPrioritySamples.clear();
case TX_MULTISIG:
{
// Only consider transactions "mine" if we own ALL the
- // keys involved. multi-signature transactions that are
+ // keys involved. Multi-signature transactions that are
// partially owned (somebody else has a key that can spend
// them) enable spend-out-from-under-you attacks, especially
// in shared-wallet situations.