- ensure warnings always start with "Warning:" and that the first
character after ":" is written uppercase
- ensure the first sentence in warnings ends with an "!"
- remove unneeded spaces from Warning-strings
- add missing Warning-string translation
- remove a "\n" and replace with untranslatable "<br><br>"
* Fix wrong thread name for wallet *relocking* thread
- Was named the unlocking thread
* Use consistent naming
Signed-off-by: Giel van Schijndel <me@mortis.eu>
NOTE: These thread names are visible in gdb when using 'info threads'.
Additionally both 'top' and 'ps' show these names *unless* told to
display the command-line instead of task name.
Signed-off-by: Giel van Schijndel <me@mortis.eu>
Because new nodes pull from the first connected node the load
balancing of the first connection is more important than it should
be. This change puts Pieter's seed first, because its probably
the best maintained right now.
Bitcoin will not make an outbound connection to a network group
(/16 for IPv4) that it is already connected to. This means that
if an attacker wants good odds of capturing all a nodes outbound
connections he must have hosts on a a large number of distinct
groups.
Previously both inbound and outbound connections were used to
feed this exclusion. The use of inbound connections, which can be
controlled by the attacker, actually has the potential of making
sibyl attacks _easier_: An attacker can start up hosts in groups
which house many honest nodes and make outbound connections to
the victim to exclude big swaths of honest nodes. Because the
attacker chooses to make the outbound connection he can always
beat out honest nodes for the consumption of inbound slots.
At _best_ the old behavior increases attacker costs by a single
group (e.g. one distinct group to use to fill up all your inbound
slots), but at worst it allows the attacker to select whole
networks you won't connect to.
This commit makes the nodes use only outbound links to exclude
network groups for outbound connections. Fancier things could
be done, like weaker exclusion for inbound groups... but
simplicity is good and I don't believe more complexity is
currently needed.
- Signals now go directly from the core to WalletModel/ClientModel.
- WalletModel subscribes to signals on CWallet: Prepares for multi-wallet support, by no longer assuming an implicit global wallet.
- Gets rid of noui.cpp, the few lines that were left are merged into init.cpp
- Rename wxXXX message flags to MF_XXX, to make them UI indifferent.
- ThreadSafeMessageBox no longer returns the value `4` which was never used, converted to void.
Gets rid of `MainFrameRepaint` in favor of specific update functions that tell the UI exactly what changed.
This improves the efficiency of various handlers. Also fixes problems with mined transactions not showing up until restart.
The following notifications were added:
- `NotifyBlocksChanged`: Block chain changed
- `NotifyKeyStoreStatusChanged`: Wallet status (encrypted, locked) changed.
- `NotifyAddressBookChanged`: Address book entry changed.
- `NotifyTransactionChanged`: Wallet transaction added, removed or updated.
- `NotifyNumConnectionsChanged`: Number of connections changed.
- `NotifyAlertChanged`: New, updated or cancelled alert. As this finally makes it possible for the UI to know when a new alert arrived, it can be shown as OS notification.
These notifications could also be useful for RPC clients. However, currently, they are ignored in bitcoind (in noui.cpp).
Also brings back polling with timer for numBlocks in ClientModel. This value updates so frequently during initial download that the number of signals clogs the UI thread and causes heavy CPU usage. And after initial block download, the value changes so rarely that a delay of half a second until the UI updates is unnoticable.
Introduce a boolean variable for each "network" (ipv4, ipv6, tor, i2p),
and track whether we are likely to able to connect to it. Addresses in
"addr" messages outside of our network get limited relaying and are not
stored in addrman.
This will make bitcoin relay valid routable IPv6 addresses, and when
USE_IPV6 is enabled, listen on IPv6 interfaces and attempt connections
to IPv6 addresses.
Change internal HTTP JSON-RPC server from single-threaded to
thread-per-connection model. The IP filter list is applied prior to starting
the thread, which then processes the RPC.
A mutex covers the entire RPC operation, because not all RPC operations are
thread-safe.
[minor modifications by jgarzik, to make change upstream-ready]
-externalip=<ip> can be used to explicitly set the public IP address
of your node. -discover=0 can be used to disable the automatic public
IP discovery system.
Keep a global counter for nOutbound, protected with its own waitable
critical section, and wait when all outbound slots are filled, rather
than polling.
This removes the (on average) 1 second delay between a lost connection
and a new connection attempt, and may speed up shutdowns.
not process any already received messages.
The primary reason to do this is if a node spams hundreds of messages
and we ban them, we don't want to continue processing the rest of it.
Design goals:
* Only keep a limited number of addresses around, so that addr.dat does not grow without bound.
* Keep the address tables in-memory, and occasionally write the table to addr.dat.
* Make sure no (localized) attacker can fill the entire table with his nodes/addresses.
See comments in addrman.h for more detailed information.
* do not let vnThreadsRunning[1] go negative
* do not perform locking operations while vnThreadsRunning[1] is decreased
* check vnThreadsRunning[1] at exit
This fixes a potential bug where some NATs may replace the node's
interal IP with its external IP in version messages, causing
incorrect checksums when version messages begin being checksummed
on February 14, 2012.
This also avoids flushing setAddrKnown until 24 hours has passed,
and avoids contacting the external IP services when not listening.
Advertising non-listening nodes is just addr message spam.
It doesn't help the network, in fact it hurts the network,
and it also hurts user's privacy.
Advertising far out of sync nodes doesn't help the network—
they can't even forward (most) transactions and wastes nodes
outbound slots.
