* Harden Spork6
Spork6 was previously activated on testnet, but we then developed an alternative fix for the issue and never activated spork6 on mainnet. At this point, Spork6 will not be activated on mainnet.
As such, it makes sense to harden Spork6 and ensure that spork6 will never be activated on mainnet. So, we just change from checking Spork6 to checking if we are on testnet. If we are on testnet, use spork6 logic, else don't.
Signed-off-by: pasta <pasta@dashboost.org>
* remove now unused SPORK_6_NEW_SIGS
Signed-off-by: pasta <pasta@dashboost.org>
* force fSporkSixActive to be correct, otherwise return
Signed-off-by: pasta <pasta@dashboost.org>
* Harden spork6 even more
* Add TODO in chainparams as a reminder to drop all spork6 related code on next testnet reset
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
* Use GetRealOut... instead of Capped
Signed-off-by: pasta <pasta@dashboost.org>
* Add "ps_salt" value to walletdb
This value is used to deterministically pick a random number of rounds to mix, between N and N + GetRandomRounds. A salt is needed in addition to the inputs hash to ensure that an attacker learns nothing from looking at the blockchain.
Signed-off-by: pasta <pasta@dashboost.org>
* Implement Random Round Mixing
This implements "Random Round Mixing." Previously, attempted attacks on PrivateSend assumed that all inputs had been mixed for the same number of rounds. Noramlly assuming 2,4,8 or 16.
While none of these attacks have been successful, they still teach what we can do to make our system more robust, and one of those ways is to implement "Random Round Mixing".
Under the previous system, inputs were mixed up until N rounds (configured by user). At this point, the input was considered mixed, and could be private-sent. Under this new system, an input will be mixed to N rounds like prior. However, at this point, Sha256d(input, salt) will be calculated (note: this likely could be a more efficient hash function than double sha256, but that can be done in another PR / version if needed). If (hash % 2 == 0), then the input will be mixed again.
This results in an exponential decay where if you mix a set of inputs, half of those inputs will be mixed for N rounds, 1/4 will be mixed N+1, 1/8 will be mixed N+2, etc. This current implementation caps it at N+2. This results in mixing an average of N+0.875 rounds. If you removed the cap, you would mix on average N+1 rounds.
Signed-off-by: pasta <pasta@dashboost.org>
* Make PS salt a private member of CWallet, tweak the way it's initialized
* Introduce `CWallet::IsFullyMixed` and use it everywhere instead of comparing rounds directly to ensure consistency between coin selection logic, balance calculations and gui
* Tweak `GetRealOutpointPrivateSendRounds` to respect random rounds
* Tweak IsFullyMixed to make decision on a per-outpoint basis instead of a per-tx one
* make a comment doxygen
Signed-off-by: pasta <pasta@dashboost.org>
* Rename GetPrivateSendSalt InitPrivateSendSalt, since it is not a getter
Signed-off-by: pasta <pasta@dashboost.org>
* move the comment below GetRounds call
Signed-off-by: pasta <pasta@dashboost.org>
* don't use GetCappedOutpointPrivateSendRounds when printing to RPC
Signed-off-by: pasta <pasta@dashboost.org>
* Simplify hashing in IsFullyMixed
Uses just 1 sha256 instead of 3 (1 in SerializeHash + 2 in Hash)
* undo comment change
Signed-off-by: pasta <pasta@dashboost.org>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
* test: Fix importwallet_rescan test
The wallet should be removed after the dumpwallet() call otherwise it
may lead to unepexted behaviour in other wallet tests since the wallet
stays in vpwallets then.
* tests: Change where RemoveWallet call is to be more in line with upstream
Signed-off-by: pasta <pasta@dashboost.org>
Co-authored-by: pasta <pasta@dashboost.org>
* Print exception origin in crash messages
We use `PrintExceptionContinue` in many places and we pass crash origin to it as a param but we never use it. Also, change the param name to better match its meaning.
* Update src/util.cpp
Co-authored-by: dustinface <35775977+xdustinface@users.noreply.github.com>
Co-authored-by: dustinface <35775977+xdustinface@users.noreply.github.com>
It seems like the idea here was to avoid announcing already available sigshares for a signhash to everyone if concentrated recovery is enabled. But by returning there if `IsAllMembersConnectedEnabled` equals to `false` we disable the re-announcements prior to the spork activation, where we want to still have them and re-enable if the spork is enabled where we don't want to have them.
* Mostly trivial clang-tidy changes in masternode
Signed-off-by: pasta <pasta@dashboost.org>
* uint -> size_t
Signed-off-by: pasta <pasta@dashboost.org>
* Make GetSyncStatus const not static and ProcessMessage const
Signed-off-by: pasta <pasta@dashboost.org>
For some reason Travis doesn't seem to like having the same name on different stages and ignores the cache that was built earlier. Making job names stage specific fixes cache issues.
* Adjust CDeterministicMNState, add helper methods
Changes all setting of `nPoSeBanHeight` into a call to `BanIfNotBanned`
Adds a helper method `IsBanned` that just is `return nPoSeBanHeight != -1`
In my opinion this makes the code generally more readable and easy to understand
Adds `Revive` helper method
I don't feel too strongly about this, because from what I have seen, this revive code is only done in one place,
but I generally think it makes sense to be a helper method of it's own
Signed-off-by: pasta <pasta@dashboost.org>
* Add `!` that was accidentally not added
Signed-off-by: pasta <pasta@dashboost.org>
* Make nPoSeBanHeight private
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Prior to this commit there are (imo) flaws in the behaviour of the PrivateSend tab.
- If you enter an address, label, add a recipient, do whatever in the normal Send tab its also reflected in
the PrivateSend tab
- If you select fully mixed coins in the Send tab's CoinControl they are also selected
in the PrivateSend tab if you switch over.
- If you select non-fully mixed coins in the Send tab's CoinControl you
get a warning when switching over to PrivateSend tab due to non-fully
mixed coins selected in CoinControl.
With giving the private send tab separate instances of `SendCoinsDialog` and `CCoinControl` they are independent
from each other which just makes more sense imo and by doing this the points above are solved.
I would say this just better reflects the actual behaviour of a tab.
* Introduce FAST_MODE Gitlab variable
Default: "false". When "true", only run linter on arm and unit/functional tests on linux64, skip everything else.
* fix ordering I accidentially somehow changed
Signed-off-by: pasta <pasta@dashboost.org>
* remove x86_64-unknown-linux-gnu
Signed-off-by: pasta <pasta@dashboost.org>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Currently Travis displays env vars which make it hard to identify individual jobs by simply looking at the list because all env vars start with the same strings.
21be609b49 In lint-format-strings, open files sequentially (Glenn Willen)
Pull request description:
In lint-format-strings, we use python argparse to read our file arguments. In
this mode, argparse opens all the files simultaneously. On OS X, where the
default filehandle limit is 128, this causes the lint to fail. Instead, ask
argparse for our filename arguments as strings, and open them one at a time
using 'with open'.
Tree-SHA512: 4c7dabf98818a7c5d83ab10c61b89a26957fe399e39e933e30c561cb45c5e8ba6f6aedcde8343da0c32ee340289a8897db6a33708e35ee381334ee27e3f4d356
341f7c7b0e macOS fix: Check for correct version of flake8 to avoid spurious warnings. The brew installed flake8 version is Python 2 based and does not work. (practicalswift)
908a559f33 macOS fix: Add excludes for checks added in the newer shellcheck version installed by brew (practicalswift)
ec4d57bbb3 macOS fix: Work around empty (sub)expression error when using BSD grep (practicalswift)
b57d7d92fe macOS fix: Avoid mapfile due to ancient version of bash shipped with macOS (practicalswift)
Pull request description:
The linters are thoroughly tested under Ubuntu which is what we use in Travis. When reading #14041 I understood that some developers were experiencing problems when running the linters on their local machines.
Assuming these local machines were running macOS I installed a fresh macOS VM, followed the instructions in `build-osx.md` and ran the linters.
This PR contains the changes needed to make `lint-all.sh` run as expected.
Ideally the linters would continuously run also under a Travis macOS environment to make sure we catch these kind of issues before merge.
Tree-SHA512: b39c9a970d14d27db1fb592539923c0bc676b5217f415d02fda3f17bf54d46faa172376e8a3ecab07ca68a3acba9aebe00b2b1b2161b2a36b85fbb672e7efb5c
fa3c910bfeab00703c947c5200a64c21225b50ef test: Move linters to test/lint, add readme (MarcoFalke)
Pull request description:
This moves the checks and linters from `devtools` to a subfolder in `test`. (Motivated by my opinion that the dev tools are mostly for generating code and updating the repo whereas the linters are read-only checks.)
Also, adds a readme to clarify that checks and linters are only meant to prevent bugs and user facing issues, not merely stylistic preference or inconsistencies. (This is motivated by the diversity in developers and work flows as well as existing code styles. It would be too disruptive to change all existing code to a single style or too burdensome to force all developers to adhere to a single style. Also note that our style guide is changing, so locking in at the wrong style "too early" would only waste resources.)
Tree-SHA512: 9b10e89f2aeaf0c8a9ae248aa891d74e0abf0569f8e5dfd266446efa8bfaf19f0ea0980abf0b0b22f0d8416ee90d7435d21a9f9285b66df43f370b7979173406
506c5785fb Enable Travis checking for two Python linting rules we are currently not violating (practicalswift)
Pull request description:
Enable Travis checking for two Python linting rules we are currently not violating:
* E101: indentation contains mixed spaces and tabs
* E129: visually indented line with same indent as next logical line
Tree-SHA512: 955ea5ce4576a5bdd561f9d2bbcfaa82f66a23391c84ddb806830ed15e321e4742457ccc801f457819f626d4a66a1ffcaecee28c3b9f3f907ab8401323743485
4b75dcf devtools: Make linter check LogPrint calls (MarcoFalke)
ff2ad2d Add missing newlines to LogPrint debug logging (Wladimir J. van der Laan)
Pull request description:
~~Don't we have a linter that should catch these?~~
Tree-SHA512: 1a58eca01ded9c1719e943c09447deeb59bb06dba00528cf460eefe857fdf95b42671fbdebc87cdd2f51e931e86942d06587ffd097cbb0d8dd9eb7a0ba17a8f0
bcd4b0f5cdde2a1b562a612c78ec1ef1fe47d3dd Add linting of WalletLogPrintf(...) format strings (practicalswift)
a3e455694901a887e0feef69bd63e3aa122ea44b build: Add format string linter (practicalswift)
Pull request description:
Add format string linter.
This linter checks that the number of arguments passed to each variadic format string function matches the number of format specifiers in the format string.
Example output:
```
$ test/lint/lint-format-strings.sh
src/init.cpp: Expected 2 argument(s) after format string but found 1 argument(s):
LogPrintf("We have a mismatch here: foo=%s bar=%d\n", foo)
src/init.cpp: Expected 1 argument(s) after format string but found 2 argument(s):
LogPrint(BCLog::RPC, "RPC stopped. This is a mismatch: %s\n", s1, s2)
$ echo $?
1
```
Tree-SHA512: 19ab844a63f04bf193d66682ca42745a1c7d6c454b30222491b9fe8dc047054c4a6d3ee7921ec0676fb9ca2e7f6f93bd6c97996fb09667269bd491cb875349f3
00db418176 Add aarch64 qt depends support for cross compiling bitcoin-qt (TheCharlatan)
Pull request description:
This also adds a generic qt linux target in packages.mk . I am a bit confused by the existing docs for the RISC addition. Are there boards that would support running bitcoin-qt, or at the very least forwarding X over ssh? Is everybody building depends with `NO_QT=1` when targeting RISC? If not, I will revert the change for a generic qt linux package definition back to the piecemeal solution.
This pull request should close#13495
Tree-SHA512: 519b951bf50f214ad725e5330094582a212333cd85b0ae442c67f9afec5629995dfad130258c7706a61f7b7cccbfa49bce69b9931f7e30cf12b382cd9a0a4749