Regarding https://bitcointalk.org/index.php?topic=28022.0
main.cpp has: "char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };"
Per discussion on the thread linked, leaving the signedness of
pchMessageStart is unsafe for values > 0x80. This patch specifies
'unsigned char' in main.cpp and net.h.
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
db.cpp has a number of uses of make_tuple and has 'using namespace
std' and 'using namespace boost'. Without qualifying make_tuple,
std::make_tuple is preferred, which is incorrect. This patch qualifies
make_tuple.
Signed-off-by: Jeff Garzik <jgarzik@exmulti.com>
Avoid references to addresses using strings, and use CBitcoinAddress
as much as possible. Also added some validity checks on addresses
entered using RPC.
With the separation of CENT and MIN_TX_FEE, it is now reasonable
to create change outputs between 0.01 and 0.0005, as these are
spendable according to the policy, even though they require a fee
to be paid.
Also, when enough fee was already present, everything can go into
a change output, without further increasing the fee.
Previously, mapAlreadyAskedFor was read from, but never added to.
The original intent was to use mapAlreadyAskedFor to keep track
of the time an item was requested and "Each retry is 2 minutes
after the last".
This implements that intent.
Instead of conversion functions between pubkey/uint160/address in
base58.h, have a fully fledged class CBitcoinAddress (CAddress was
already taken) to represent addresses.
Don't check for a negative parameter count, because not only will it
never happen, it doesn't make any sense either.
Invalid sockets (as returned by socket(2)) are always exactly -1 (not
just negative as negative file descriptors are technically not
prohibited by POSIX) on POSIX systems. Since we store them in SOCKET
(unsigned int), however, that really is ~0U (or MAX_UINT) which happens
to be what INVALID_SOCKET is already defined to, so an additional check
for being negative is not only unnecessary (unsigned integers aren't
*ever* negative) its redundant as well (the INVALID_SOCKET comparison is
enough).
Signed-off-by: Giel van Schijndel <me@mortis.eu>
In the assert()s take advantage of the fact that string constants
("string") are effectively of type 'const char []', which when used in
an expression yield a non-NULL pointer.
An assertion that should always fail can thus be formulated as:
assert(!"fail);
An assertion where a text message should be added to the expression can
be written as such:
assert("message" && expression);
Signed-off-by: Giel van Schijndel <me@mortis.eu>
Venkatesh Srinivas