Try to display a nicer message instead of dumping raw JSON object when possible. If the error
somehow doesn't have the required 'code' and 'message' fields, fall back to printing raw JSON object.
- re-order Qt Actions and connect() calls to match the real GUI layout,
which makes things easier to read and understand
- remove signMessageAction and verifyMessageAction from tabGroup as we
didn't use them anyway (as tooltips are not displayed in the menu remove
these too)
- update 2 comments
- be clear we don't "Show/Hide Bitcoins", but just the client window
- remove the tooltip for toggleHideAction as this is not shown anyway
- update a comment to be more general
If our IRC nick is in use (because some other node thinks it has
the same address we think we have) don't fruitlessly try to reconnect
using that name forever. After three tries, give up and use a random
nick. Either we'll learn a new local address from IRC and switch
to that, or it was right and the other guy is advertising for us.
This avoids a pessimal case where a second testnet node behind
a nat is unable to get any peers because he can't get on IRC.
Previously Bitcoin would refuse to use IRC if it was either not
accepting inbound connections or not making outbound. Instead this
changes it to not use IRC only if it's not doing either or if
IPv4 is off completely. If Bitcoin is not listening this will use
the default random nicks rather than the IP based ones.
Hard-code a special nId=max int alert, to be broadcast if the
alert key is ever compromised. It applies to all versions, never
expires, cancels all previous alerts, and has a fixed message:
URGENT: Alert key compromised, upgrade required
Variations are not allowed (ignored), so an attacker with
the private key cannot broadcast empty-message nId=max alerts.
This fixes two alert system vulnerabilities found by
Sergio Lerner; you could send peers unlimited numbers
of invalid alert message to try to either fill up their
debug.log with messages and/or keep their CPU busy
checking signatures.
Fixed by disconnecting/banning peers if they send 10 or more
bad (invalid/expired/cancelled) alerts.
Windows & WindowsXP style have a problem with displaying the block progress.
Add a custom stylesheet as workaround, but only when one of those renderers is active,
otherwise leave the theme alone (issue #1071).
- add a new label, which can be updated independently from the whole
license information stuff
- the benefit is, we don't need to re-translate that whole wall of text
every year the copyright info changes
- update to the same copyright string we use in the source and in the
bitcoin-qt.exe meta-data information
- removes an obsolete entry from the ui-file
- Show address receiving the generation, and include it in the correct "account"
- Multiple entries in listtransactions output if the coinbase has multiple outputs to us
This applies on top of the coincontrol listaddressgroupings patch
and makes finding eligible outputs from the groups returned
by listaddressgroupings possible.
Logic:
- If sending a transaction, assign its timestamp to the current time.
- If receiving a transaction outside a block, assign its timestamp to the current time.
- If receiving a block with a future timestamp, assign all its (not already known) transactions' timestamps to the current time.
- If receiving a block with a past timestamp, before the most recent known transaction (that we care about), assign all its (not already known) transactions' timestamps to the same timestamp as that most-recent-known transaction.
- If receiving a block with a past timestamp, but after the most recent known transaction, assign all its (not already known) transactions' timestamps to the block time.
For backward compatibility, new accounting data is stored after a \0 in the comment string.
This way, old versions and third-party software should load and store them, but all actual use (listtransactions, for example) ignores it.
Replace direct calls to mlock.
Also, change the class to lock the memory areas in the constructor and unlock them again in the destructor. This makes sure that locked pages won't leak.
Memory locks do not stack, that is, pages which have been locked several times by calls to mlock()
will be unlocked by a single call to munlock(). This can result in keying material ending up in swap when
those functions are used naively. In this commit a class "LockedPageManager" is added
that simulates stacking memory locks by keeping a counter per page.
R E Broadley