Add a comment that explains why the initial "getheader" requests are
made starting from the block preceding the currently best one.
Thanks to sdaftuar for the explanation!
There is no exact science to setting this parameter, but 5000
(just over 1 US cent at the time of writing) is higher than the
cost to relay a transaction around the network (the new benchmark
due to mempool limiting).
After each transaction which is added to mempool, we first call
Expire() to remove old transactions, then throwing away the
lowest-feerate transactions.
After throwing away transactions by feerate, we set the minimum
relay fee to the maximum fee transaction-and-dependant-set we
removed, plus the default minimum relay fee.
After the next block is received, the minimum relay fee is allowed
to decrease exponentially. Its halflife defaults to 12 hours, but
is decreased to 6 hours if the mempool is smaller than half its
maximum size, and 3 hours if the mempool is smaller than a quarter
its maximum size.
The minimum -maxmempool size is 40*-limitdescendantsize, as it is
easy for an attacker to play games with the cheapest
-limitdescendantsize transactions. -maxmempool defaults to 300MB.
This disables high-priority transaction relay when the min relay
fee adjustment is >0 (ie when the mempool is full). When the relay
fee adjustment drops below the default minimum relay fee / 2 it is
set to 0 (re-enabling priority-based free relay).
(note the 9x multiplier on (void*)'s for CTxMemPool::DynamicMemoryUsage
was accidentally introduced in 5add7a7 but should have waited for this
commit which adds the extra index)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This message is to inform you that I, Paul Rabahy have rolled over GPG
keys.
My old key = EA695E0CE2D0DCB0D65167A8D1CBA2A21BCD88F6
My new key = D62A803E27E7F43486035ADBBCD04D8E9CCCAC2A
My new key now has an offline primary key with an online subkey that I
will be
using for normal communications.
I have signed this message with both the old and new key so it should show
up
as validly signed. Please add my new key to your keyring so that future
communication will be properly verified.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWB3/LAAoJENHLoqIbzYj2LBwQAMgH5u2KDuxK2gmpRjEpVXe8
XPOon+SRL5zXfu1dFInXCg8APJEVaXhSeY+/s0GmUq0INRpK4r0tvZVN84X2UoHz
y88P6BeHzQI7dsCStINhW4Hb7DVpFvkHAxsRhy05/geD56/IOXnsG+5SvsH3essJ
O6DuRQOipDWkZ9NQuQPrqzlkcBErMbL4Cs0ED5DOOYccntnt5HM909KDHfKcG8iJ
/qNTVzVFYMGbLn6MVq89reatmIOxuVBkbixsqad5M4P9rQ3iGPnUzIEp4wn7/Ssd
XDiCZypzlHkcs1GKBLtWnYWahlWHItcd/Yz3AiHLfUehcZb52p0mvIaTf4lyAR5p
kQFTXZwrrzJDaomSE2Y2IeMIATZE7/7RInkHD6okUTFSoCFgxOeAxLBI6sxLH5x5
xLIdv45iiv3P5fz1gungfzn2OYy+dHgT74bJ32N18hs+xwZM2G6AYYvVvkTSDqC0
c3AopnjEV4i+4Aq0QfDD9fXpBc0QuDN7c5GkcFCiFlhN+gffjT8hkFliiW3e2X5K
Vsycv1sYXFSS/YYZ7RCixWgTkpi18ABaLu/N1ses7hLNMxx9ovjrMIJ5gC6Nyga9
2BiumvNMh0iE9yhPiN0a4YsZZnW/tc5K1+OJxnKZvxWrXqOgIhnKZA1U1Y83COgA
6pI5uKrggGQWgQFJxTmciQEcBAEBCAAGBQJWB3/LAAoJEDJeXsBcJ6amLBwH/ib+
wiD3wDy+VeTDFvh4AgQqDRCk+CvGEKJlcoBLm3ZDwzi+/26XB/BCFoopW9h67ZmC
yMFhgvCJ3RwPcVGgZBOZ//88E2symcYRBSZJVwMN/n3McmEKBmmEH6/tTqhLeBal
2pynse7qgfZV7P/rSMcqFdhzMYq6Jt25obTl3IqTo939G1oOxRK8ORNT3Hs4/uiF
7xsx+nUBe/L6dvw2Rxr8bWm7WKi/LF7fKN/HZuBfK2qH0S4ctG49fiBw3DTV+erO
lYHdOMA9sjk90Le5sNBw75Hyr4WMLUkGFkh9SvDK1Xe3bUCfCpBTpcPnRUqnHL32
9GbqORFiaUGPRCnaWKQ=
=JR4m
-----END PGP SIGNATURE-----
4e2efb3 tests: update transaction_tests for new dust threshold (Wladimir J. van der Laan)
28e3249 Bump minrelaytxfee default (Wladimir J. van der Laan)
Common sentiment is that the miniupnpc codebase likely contains further
vulnerabilities.
I'd prefer to get rid of the dependency completely, but a compromise for
now is to at least disable it by default.
To bridge the time until a dynamic method for determining this fee is
merged.
This is especially aimed at the stable releases (0.10, 0.11) because
full mempool limiting, as will be in 0.12, is too invasive and risky to
backport.
MarcoFalke