Previously all conflicting transactions were evaluated as a whole to
determine if the feerate was being increased. This meant that low
feerate children pulled the feerate down, potentially allowing a high
transaction with a high feerate to be replaced by one with a lower
feerate.
Replaces transactions already in the mempool if a new transaction seen
with a higher fee, specifically both a higher fee per KB and a higher
absolute fee. Children are evaluateed for replacement as well, using the
mempool package tracking to calculate replaced fees/size. Transactions
can opt-out of transaction replacement by setting nSequence >= maxint-1
on all inputs. (which all wallets do already)
Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket
API, to create and destroy 'ephemeral' hidden services programmatically.
https://stem.torproject.org/api/control.html#stem.control.Controller.create_ephemeral_hidden_service
This means that if Tor is running (and proper authorization is available),
bitcoin automatically creates a hidden service to listen on, without user
manual configuration. This will positively affect the number of available
.onion nodes.
- When the node is started, connect to Tor through control socket
- Send `ADD_ONION` command
- First time:
- Make it create a hidden service key
- Save the key in the data directory for later usage
- Make it redirect port 8333 to the local port 8333 (or whatever port we're listening on).
- Keep control socket connection open for as long node is running. The hidden service will
(by default) automatically go away when the connection is closed.
Process `getheaders` messages from whitelisted peers even if we are in
initial block download. Whitelisted peers can always use a node as a
block source.
Also log a debug message when the request is ignored, for
troubleshooting.
Fixes#6971.
Previously, the undo weren't being flushed during a reindex because
fKnown was set to true in FindBlockPos. That is the correct behaviour
for block files as they aren't being touched, but undo files are
touched.
This changes the behaviour to always flush when switching to a new file
(even for block files, though that isn't really necessary).
The docs talk about bits 2 and 4 instead of 2 and 3, and bits are being
indexed from both 1 (describing nCode) and 0 (in second example).
Changed to use zero-indexing for all.
Moves the call Initialize() from init.cpp to CreateWithArguments() and handles the
return value. Moves the call Shutdown() from init.cpp to destructor.
Changes Initialize() and Shutdown() to protected members.
Revert "Revert "Add rules--presently disabled--for using GetMedianTimePast as endpoint for lock-time calculations""
This reverts commit 40cd32e835.
After careful analysis it was determined that the change was, in fact, safe and several people were suffering
momentary confusion about locktime semantics.
When processing a new transaction, in addition to spending the Coins of its txin's it creates a new Coins for its outputs. The existing ModifyCoins function will first make sure this Coins does not already exist. It can not exist due to BIP 30, but because of that the lookup can't be cached and always has to go to the database. Since we are creating the coins to match the new tx anyway, there is no point in checking if they exist first anyway. However this should not be used for coinbase tx's in order to preserve the historical behavior of overwriting the two existing duplicate tx pairs.
This reverts commit 9d55050773.
As noted by Luke-Jr, under some conditions this will accept transactions which are invalid by the network
rules. This happens when the current block time is head of the median time past and a transaction's
locktime is in the middle.
This could be addressed by changing the rule to MAX(this_block_time, MTP+offset) but this solution and
the particular offset used deserve some consideration.
* Introduce new constant MIN_CHANGE and use it instead of the
hardcoded "CENT"
* Add test case for MIN_CHANGE
* Introduce new constant for -mintxfee default:
DEFAULT_TRANSACTION_MINFEE = 1000
Reduce the default limits on maximum number of transactions and the cumulative size of those transactions in both ancestor and descendant packages to 25 txs and 101kb total size.
Update the unittest that is meant to catch a transaction that is invalid
because it has a null input. The old test failed not because of that
but because it was considered a coinbase with too large script. This is
already checked with a different test, though.
The new test is *not* a coinbase since it has two inputs, but one of
them is null. This really checks the corresponding code path in
CheckTransaction.
Peter Todd