Removes the limits on number of pubkeys for P2SH CHECKMULTISIG outputs.
Previously with the 500 byte scriptSig limit there were odd restrictions
where even a 1-of-12 P2SH could be spent in a standard transaction(1),
yet multisig scriptPubKey's requiring more signatures quickly ran out of
scriptSig space.
From a "stuff-data-in-the-blockchain" point of view not much has changed
as with the prior commit now only allowing the dummy value to be null
the newly allowed scriptSig space can only be used for signatures. In
any case, just using more outputs is trivial and doesn't cost much.
1) See 779b519480d8c5346de6e635119c7ee772e97ec872240c45e558f582a37b4b73
Mined by BTC Guild.
This is a source of transaction mutability as the dummy value was
previously not checked and could be modified to something other than the
usual OP_0 value.
- replaces checks in SendCoinsDialog::handlePaymentRequest() that belong
to PaymentServer (normal URIs are special cased, as only an isValid
check is done on BTC addresses)
- prevents the client to handle payment requests that do not match the
clients network and shows an error instead (mainly a problem with
drag&drop payment requests onto the client window)
- includes some small comment changes also
Size specifiers are no longer needed now that we use typesafe tinyformat
for string formatting, instead of the system's sprintf.
No functional changes.
This continues the work in #3735.
- fixes error from debug.log:
QMetaObject::connectSlotsByName: No matching signal for
on_recentRequestsView_selectionChanged(QItemSelection,QItemSelection)
- small style fixes (e.g. alphabetical ordering if includes etc.)
- fixes#3992
Generally useless information. Only updates on connect time, not after
that. Peers can easily lie and the median filter is not effective in
preventing that.
In the past it was used for progress display in the GUI but
`CheckPoints::guessVerificationProgress` provides a better way that is now used.
It was too easy to mislead it. Peers do lie about it in practice, see issue #4065.
From the RPC, `getpeerinfo` gives the peer raw values, which are more
useful.
Adds two new info query commands that take over information from
hodge-podge `getinfo`.
Also some new information is added:
- `getblockchaininfo`
- `chain`: (string) current chain (main, testnet3, regtest)
- `verificationprogress: (numeric) estimated verification progress
- `chainwork`
- `getnetworkinfo`
- `localaddresses`: (array) local addresses, from mapLocalHost (fixes#1734)
The year is 2014. All supported operating systems have IPv6 support,
most certainly at build time (this doesn't mean that IPv6 is configured,
of course).
If noone is exercising the functionality to disable it, that means it
doesn't get tested, and IMO it's better to get rid of it.
(it's also not used consistently in RPC/boost and Net code...)
Last update (48be9ce) missed quite a lot, for some reason.
This is also the first update done with the new script
`contrib/devtools/update-translations.py`
Prints the actual version of BerkeleyDB that is linked against, if
wallet support is enabled.
Useful for troubleshooting.
For example:
2014-05-01 07:44:02 Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2014-05-01 07:54:25 Using BerkeleyDB version Berkeley DB 5.1.29: (October 25, 20 11)
Because this class replaces some usages of CBigNum, tests have been added to
verify that they function the same way. The only difference in their usage is
the handling of out-of-range numbers.
While operands are constrained to [-0x7FFFFFFF,0x7FFFFFFF], the results may
overflow. The overflowing result is technically unbounded, but in practice
it can be no bigger than the result of an operation on two operands. This
implementation limits them to the size of an int64.
CBigNum was unaware of this constraint, so it allowed for unbounded results,
which were then checked before use. CScriptNum asserts if an arithmetic
operation will overflow an int64_t, since scripts are not able to reach those
numbers anyway. Additionally, CScriptNum will throw an exception when
constructed from a vector containing more than 4 bytes This mimics the previous
CastToBigNum behavior.
- In wallet and GUI code LOCK cs_main as well as cs_wallet when
necessary
- In main.cpp SendMessages move the TRY_LOCK(cs_main) up, to encompass the call
to IsInitialBlockDownload.
- Make ActivateBestChain, AddToBlockIndex, IsInitialBlockDownload,
InitBlockIndex acquire the cs_main lock
Fixes#3997
All functions that use ChainActive but do not aquire the cs_main
lock themselves, need to be called with the cs_main lock held.
This commit adds assertions to all externally callable functions
that use chainActive or chainMostWork.
This will flag usages when built with -DDEBUG_LOCKORDER.
Drawback: The version string is no longer a valid git identifier.
For this reason the 'g' short hash prefix has been removed.
Exception: When building directly from a tag this behaves exactly like the previous behavior.
This allows formatting release versions with precision i.e. v0.9.2
This also allows arbitrary topicbranch names i.e. v0.9.1-glibc-compat
- prevents unsafe shutdowns on Windows, which is known to be
able to cause problems with wallet.dat
- if a users ends a Windows session, this will initiate a client shutdown
and show a Windows dialog, that tells the user what is going on (for
Windows Vista and higher it will even show a reason for blocking the
Windows session end)
glibc/libstdc++ have added new symbols in later releases. When running a new
binary against an older glibc, the run-time linker is unable to resolve the
new symbols and the binary refuses to run.
This can be fixed by adding our own versions of those functions, so that the
build-time linker does not emit undefined symbols for them.
This enables our binary releases to work on older Linux distros, while not
incurring the downsides of a fully static binary.
Peter Todd