Commit Graph

23011 Commits

Author SHA1 Message Date
MeshCollider
d5269332a4 Merge #16026: Ensure that uncompressed public keys in a multisig always returns a legacy address
a49503402b6bc21e3878e151c07529941d36aed0 Make and get the multisig redeemscript and destination in one function instead of two (Andrew Chow)

Pull request description:

  `CreateMultisigRedeemscript()` is changed to `AddAndGetMultisigDestination()` so that the process of constructing the redeemScript and then getting the `CTxDestination` are done in the same function. This allows that function to see what the keys in the multisig are so that the correct address type is returned from `AddAndGetDestinationForScript()`.

  This only effects the `createmultisig` and `addmultisigaddress` RPCs and does not change signing logic as #16022 does.

  Alternative to #16022 and #16012

  Fixes #16011

ACKs for commit a49503:

Tree-SHA512: 5b0154a714deea3b2cc3a54beb420c95eeeacf4ca30c40ca80940d9d640f8b03611b0fc14c2f0710bfd8a79e8d27ad7d9ae380b4b83d52b40ab201624f2a63f0
2023-03-19 11:08:31 -05:00
PastaPastaPasta
fb205ed59f
Merge pull request #5258 from kittywhiskers/update_dashbls
depends: update 'src/dashbls' to dashpay/bls-signatures@9329803 as c1992c1
2023-03-17 10:40:05 -05:00
UdjinM6
b05f62709b
chore: Move logs about nConsecutivePayments under MNPAYMENTS debug category (#5251)
## Issue being fixed or feature implemented
These messages are pretty annoying on reindex and shouldn't really be
shown in logs unless you actually need to debug mn payments.

## What was done?
move messages under `MNPAYMENTS` debug category

## How Has This Been Tested?
reindex

## Breaking Changes
n/a

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-16 11:47:59 -05:00
Kittywhiskers Van Gogh
a82d0efcd0 build: stop tracking cmake dependency relic_conf.h.in 2023-03-16 16:37:02 +00:00
Kittywhiskers Van Gogh
8561022174 depends: update 'src/dashbls' to dashpay/bls-signatures@9329803 as c1992c1 2023-03-16 16:34:18 +00:00
Kittywhiskers Van Gogh
c1992c149e Squashed 'src/dashbls/' changes from 22b066020c..9329803969
9329803969 wip: fix FromBytesUnchecked (#68)
767713de3d feat: js bindings in camel case (#66)
06df92693a chore(release): bump version (#64)
73593feefd fix: the JS bundle script and bindings (#47)
38a8f768c6 Merge pull request #61 from kittywhiskers/compat_support
d9b375145e ci: ensure that CMakeFiles are compatible with LTS-bundled cmake
5ba1b520cc build: restore CMake 3.14.0 compatibility
d1c1b66e5f backport: merge bls-signatures#332 (Python 3.11)

git-subtree-dir: src/dashbls
git-subtree-split: 9329803969fd325dc0d5c9029ab15669d658ed5d
2023-03-16 16:34:17 +00:00
Kittywhiskers Van Gogh
3621d073f5 revert: stop tracking cmake dependency relic_conf.h.in 2023-03-16 16:33:50 +00:00
Odysseas Gabrielides
e7badf1da1
fix: check HPMNs duplicate on tx broadcast (#5257)
<!--
*** Please remove the following help text before submitting: ***

Provide a general summary of your changes in the Title above

Pull requests without a rationale and clear improvement may be closed
immediately.

Please provide clear motivation for your patch and explain how it
improves
Dash Core user experience or Dash Core developer experience
significantly:

* Any test improvements or new tests that improve coverage are always
welcome.
* All other changes should have accompanying unit tests (see
`src/test/`) or
functional tests (see `test/`). Contributors should note which tests
cover
modified code. If no tests exist for a region of modified code, new
tests
  should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or
an
explanation of the potential issue as well as reasoning for the way the
bug
  was fixed.
* Features are welcome, but might be rejected due to design or scope
issues.
If a feature is based on a lot of dependencies, contributors should
first
  consider building the system outside of Dash Core, if possible.
-->

## Issue being fixed or feature implemented
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->
Before this fix, uniqueness of HPMN `platformNodeID` was checked only
while processing a block containing a `ProRegTx` or a `ProUpServTx`.
This is not enough as a `ProRegTx` or `ProUpServTx` containing duplicate
HPMN `platformNodeID` must be rejected at tx broadcast level.

## What was done?
<!--- Describe your changes in detail -->
Checking uniqueness when calling respective RPC and when receiving such
txs.

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->


## Breaking Changes
<!--- Please describe any breaking changes your code introduces -->


## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [x] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-16 18:28:38 +02:00
UdjinM6
125a2bbbe5
chore: bump version to 18.2.2 2023-03-14 23:50:32 +03:00
UdjinM6
8083569641
chore: add 18.2.2 release notes 2023-03-14 23:50:32 +03:00
UdjinM6
a9826f5f19
chore: archive 18.2.1 release notes 2023-03-14 20:58:01 +03:00
UdjinM6
f08488d0cb
refactor: tweak GetLLMQ to fail gracefully and let caller handle results accordingly (#5247)
This allows us to have a bit more granular control over GetLLMQ results,
removes code duplication and also optimises things a tiny bit by
replacing "HasLLMQ + GetLLMQParams" calls with simply "GetLLMQParams".

Use `optional` in `GetLLMQ`, drop `HasLLMQ`.

run tests, reindex on testnet/mainnet

n/a

- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-14 20:38:35 +03:00
Odysseas Gabrielides
0fa86b3446
feat(llmq): llmq_25_67 for Platform (Testnet only) (#5225)
- Added new LLMQ type `llmq_25_67`
- The above LLMQ is added only for Testnet and it is activated with v19
fork.

- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone

---------

Co-authored-by: pasta <pasta@dashboost.org>
2023-03-14 20:15:00 +03:00
PastaPastaPasta
c4cf446100
Merge pull request #5250 from PastaPastaPasta/v19/bump-rc.6
[v19.x] backport: backports and rc.6 bump
2023-03-13 11:56:31 -05:00
pasta
cdb9d68720
chore: bump to rc.6 2023-03-13 11:26:25 -05:00
UdjinM6
b428c55db8
refactor: tweak GetLLMQ to fail gracefully and let caller handle results accordingly (#5247)
This allows us to have a bit more granular control over GetLLMQ results,
removes code duplication and also optimises things a tiny bit by
replacing "HasLLMQ + GetLLMQParams" calls with simply "GetLLMQParams".

Use `optional` in `GetLLMQ`, drop `HasLLMQ`.

run tests, reindex on testnet/mainnet

n/a

- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-13 11:25:18 -05:00
Odysseas Gabrielides
bb4a1add2c
feat: Bumped v19 start time for v19 (#5244)
## Issue being fixed or feature implemented
Delayed activation to reexperience rc.6

## What was done?


## How Has This Been Tested?

## Breaking Changes

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-13 11:24:24 -05:00
Odysseas Gabrielides
ee60e8a6c4
feat(rpc): Return HPMN fields (#5243)
## Issue being fixed or feature implemented
HPMN fields were missing when selecting a HPMN in Masternodes tab of Qt
client.

## What was done?
Return HPMN fields in JSON reply of `CDeterministicMNState`.

## How Has This Been Tested?


## Breaking Changes


## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-13 11:24:06 -05:00
Odysseas Gabrielides
323b290545
fix: governance correct sig check (#5242)
## Issue being fixed or feature implemented

## What was done?
When verifying signature of `CGovernanceVote`/`CGovernanceObject` we
need to use the active scheme.

## How Has This Been Tested?

## Breaking Changes

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-13 11:23:56 -05:00
Odysseas Gabrielides
adcd52e678
chore(rpc): removed protx_revoke_legacy (#5241)
## Issue being fixed or feature implemented


## What was done?
Removed protx_revoke_legacy since it required a BLS secret key and not a
BLS public key.
(BLS scheme is not applicable to secret keys)

## How Has This Been Tested?

## Breaking Changes

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-13 11:23:39 -05:00
Odysseas Gabrielides
5f26a7b85c
fix: BLS checkMalleable protection (#5240)
<!--
*** Please remove the following help text before submitting: ***

Provide a general summary of your changes in the Title above

Pull requests without a rationale and clear improvement may be closed
immediately.

Please provide clear motivation for your patch and explain how it
improves
Dash Core user experience or Dash Core developer experience
significantly:

* Any test improvements or new tests that improve coverage are always
welcome.
* All other changes should have accompanying unit tests (see
`src/test/`) or
functional tests (see `test/`). Contributors should note which tests
cover
modified code. If no tests exist for a region of modified code, new
tests
  should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or
an
explanation of the potential issue as well as reasoning for the way the
bug
  was fixed.
* Features are welcome, but might be rejected due to design or scope
issues.
If a feature is based on a lot of dependencies, contributors should
first
  consider building the system outside of Dash Core, if possible.
-->

## Issue being fixed or feature implemented
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->


## What was done?
<!--- Describe your changes in detail -->


## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->


## Breaking Changes
<!--- Please describe any breaking changes your code introduces -->


## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone

---------

Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
2023-03-13 11:23:30 -05:00
Odysseas Gabrielides
ce524c4a54
fix: mnUniquePropertyMap repopulate for v19 (#5239)
## Issue being fixed or feature implemented
`CDeterministicMNList` stores internally a map containing the hashes of
all properties that needed to be unique.
`pubKeyOperator` don't differ between the two schemes (legacy and
basic(v19)) but their serialisation do: hence their hash.
Because this internal map stores only hashes, then we need to
re-calculate hashes and repopulate.

So when we tried to revoke a masternode after the fork, the `ProUpRevTx`
couldn't be mined because the hash of the `pubKeyOperator` differed.

## What was done?
When retrieving a `CDeterministicMNList` for a given block, if v19 is
active for that block, then we repopulate the internal map.

## How Has This Been Tested?
Without this fix, `feature_dip3_v19.py` is failing with
`failed-calc-cb-mnmerkleroot` (Error encountered on Testnet)

## Breaking Changes

## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone

---------

Co-authored-by: pasta <pasta@dashboost.org>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2023-03-13 11:23:20 -05:00
Odysseas Gabrielides
14c63af1ef
docs(rpc): correct help for protx legacy versions (#5234)
## Issue being fixed or feature implemented
Help text for protx legacy versions were adjusted.

## What was done?


## How Has This Been Tested?

## Breaking Changes

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [x] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone

---------

Co-authored-by: thephez <thephez@users.noreply.github.com>
2023-03-13 11:23:07 -05:00
Odysseas Gabrielides
9b8c32e619
feat: Bumped v19 start time for v19 (#5244)
## Issue being fixed or feature implemented
Delayed activation to reexperience rc.6

## What was done?


## How Has This Been Tested?

## Breaking Changes

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-13 11:12:09 -05:00
UdjinM6
3a2ef2da07
refactor: tweak GetLLMQ to fail gracefully and let caller handle results accordingly (#5247)
## Issue being fixed or feature implemented
This allows us to have a bit more granular control over GetLLMQ results,
removes code duplication and also optimises things a tiny bit by
replacing "HasLLMQ + GetLLMQParams" calls with simply "GetLLMQParams".

## What was done?
Use `optional` in `GetLLMQ`, drop `HasLLMQ`.

## How Has This Been Tested?
run tests, reindex on testnet/mainnet

## Breaking Changes
n/a

## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-13 11:11:17 -05:00
Odysseas Gabrielides
577fb9883e
docs(rpc): correct help for protx legacy versions (#5234)
## Issue being fixed or feature implemented
Help text for protx legacy versions were adjusted.

## What was done?


## How Has This Been Tested?

## Breaking Changes

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [x] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone

---------

Co-authored-by: thephez <thephez@users.noreply.github.com>
2023-03-11 11:46:49 -06:00
Odysseas Gabrielides
181622d8cf
feat(rpc): Return HPMN fields (#5243)
## Issue being fixed or feature implemented
HPMN fields were missing when selecting a HPMN in Masternodes tab of Qt
client.

## What was done?
Return HPMN fields in JSON reply of `CDeterministicMNState`.

## How Has This Been Tested?


## Breaking Changes


## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-11 11:45:49 -06:00
Odysseas Gabrielides
593ff7e929
fix: governance correct sig check (#5242)
## Issue being fixed or feature implemented

## What was done?
When verifying signature of `CGovernanceVote`/`CGovernanceObject` we
need to use the active scheme.

## How Has This Been Tested?

## Breaking Changes

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-11 11:44:35 -06:00
Odysseas Gabrielides
8822b73012
chore(rpc): removed protx_revoke_legacy (#5241)
## Issue being fixed or feature implemented


## What was done?
Removed protx_revoke_legacy since it required a BLS secret key and not a
BLS public key.
(BLS scheme is not applicable to secret keys)

## How Has This Been Tested?

## Breaking Changes

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-11 11:43:33 -06:00
Odysseas Gabrielides
673e4cd17d
fix: mnUniquePropertyMap repopulate for v19 (#5239)
## Issue being fixed or feature implemented
`CDeterministicMNList` stores internally a map containing the hashes of
all properties that needed to be unique.
`pubKeyOperator` don't differ between the two schemes (legacy and
basic(v19)) but their serialisation do: hence their hash.
Because this internal map stores only hashes, then we need to
re-calculate hashes and repopulate.

So when we tried to revoke a masternode after the fork, the `ProUpRevTx`
couldn't be mined because the hash of the `pubKeyOperator` differed.

## What was done?
When retrieving a `CDeterministicMNList` for a given block, if v19 is
active for that block, then we repopulate the internal map.

## How Has This Been Tested?
Without this fix, `feature_dip3_v19.py` is failing with
`failed-calc-cb-mnmerkleroot` (Error encountered on Testnet)

## Breaking Changes

## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone

---------

Co-authored-by: pasta <pasta@dashboost.org>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2023-03-11 11:42:27 -06:00
Odysseas Gabrielides
9cbc360f8a
fix: BLS checkMalleable protection (#5240)
<!--
*** Please remove the following help text before submitting: ***

Provide a general summary of your changes in the Title above

Pull requests without a rationale and clear improvement may be closed
immediately.

Please provide clear motivation for your patch and explain how it
improves
Dash Core user experience or Dash Core developer experience
significantly:

* Any test improvements or new tests that improve coverage are always
welcome.
* All other changes should have accompanying unit tests (see
`src/test/`) or
functional tests (see `test/`). Contributors should note which tests
cover
modified code. If no tests exist for a region of modified code, new
tests
  should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or
an
explanation of the potential issue as well as reasoning for the way the
bug
  was fixed.
* Features are welcome, but might be rejected due to design or scope
issues.
If a feature is based on a lot of dependencies, contributors should
first
  consider building the system outside of Dash Core, if possible.
-->

## Issue being fixed or feature implemented
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->


## What was done?
<!--- Describe your changes in detail -->


## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->


## Breaking Changes
<!--- Please describe any breaking changes your code introduces -->


## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone

---------

Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
2023-03-09 10:13:00 +02:00
Vijay Das Manikpuri
8676139de8
(partial) Merge #18011: Replace current benchmarking framework with nanobench 2023-03-03 23:07:18 +05:30
Wladimir J. van der Laan
c49e573e47
Merge #18437: util: Detect posix_fallocate() instead of assuming
182dbdf0f4b6e6484b0d4588aaefacc75862a99c util: Detect posix_fallocate() instead of assuming (Vasil Dimov)

Pull request description:

  Don't assume that `posix_fallocate()` is available on Linux and not
  available on other operating systems. At least FreeBSD has it and we
  are not using it.

  Properly check whether `posix_fallocate()` is present and use it if it
  is.

ACKs for top commit:
  laanwj:
    ACK 182dbdf0f4b6e6484b0d4588aaefacc75862a99c

Tree-SHA512: f9ed4bd661f33ff6b2b1150591e860b3c1f44e12b87c35e870d06a7013c4e841ed2bf17b41ad6b18fe471b0b23a4b5e42cf1400637180888e0bc56c254fe0766
2023-03-03 23:07:18 +05:30
MarcoFalke
5ef0a3c1a7
Merge #18777: wallet: Recommend absolute path for dumpwallet
fa501700e91b8667d4d2f116c3705e3ab9a1c8c3 wallet: Recommned absolute path for dumpwallet (MarcoFalke)

Pull request description:

  Avoids misunderstandings such as #9564

ACKs for top commit:
  kristapsk:
    utACK fa501700e91b8667d4d2f116c3705e3ab9a1c8c3

Tree-SHA512: f675ef607992857ffeb556a2945b5436a70b39c5d83f05a8be15a6fccc84cbe9d03e52f8239e28d159e41ed7c6f119b7a38e8ab327029f04609f63c559c12c49
2023-03-03 23:07:17 +05:30
MarcoFalke
10750000d5
Merge #18754: bench: add CAddrMan benchmarks
a9b957740e3490d87e5ce0b7f1b93ba43bb19764 bench: add CAddrMan benchmarks (Vasil Dimov)

Pull request description:

  The added benchmarks exercise the public methods Add(), GetAddr(),
  Select() and Good().

ACKs for top commit:
  naumenkogs:
    utACK a9b9577
  MarcoFalke:
    ACK a9b957740e3490d87e5ce0b7f1b93ba43bb19764

Tree-SHA512: af54b2fbd97db34faf4cc6c9bacb20d2c97d0aaddb9cf91b220bc2e09227b55345402ed17e34450745493e3a2b286c176c031cdeb477415570a757cee16b06a8
2023-03-03 23:07:17 +05:30
MarcoFalke
11801edddf
Merge #18756: refactor: test: use wait_for_getdata() in p2p_compactblocks.py
c4027e735072c3de4b4ffb20eecd7187ff36bad7 refactor: test: use wait_for_getdata() in p2p_compactblocks.py (Sebastian Falbesoner)

Pull request description:

  The method `wait_for_getdata()` was recently changed to be more precise by waiting for a specified list of hashes, instead of only matching _any_ `getdata` message (see Issue #18614 and PR  #18690). This PR replaces the remaining occurences of manual inspection of `last_messages` with this call.

ACKs for top commit:
  robot-visions:
    ACK c4027e735072c3de4b4ffb20eecd7187ff36bad7

Tree-SHA512: e10b346742f235b6ee2ef1f32f7fd74406c1a277389f020fb9913a93e94cc9530e1e9414872b83c9d2ae652ebce2b09b2c8c8372260c1afb4e0e54fbf7a935b0
2023-03-03 23:07:17 +05:30
MarcoFalke
881816d531
Merge #18733: doc: Add wallet release notes for 0.21.0
facaefadd3b0cd53d375890e8339303a202c2a8b doc: Add wallet release notes for 0.21.0 (MarcoFalke)
faa4243c1157c3e67111b6e5e979cdc3e1452a94 Add release notes skeleton, so that notes can be filled easier (MarcoFalke)

Pull request description:

ACKs for top commit:
  fjahr:
    ACK facaefadd3b0cd53d375890e8339303a202c2a8b
  achow101:
    ACK facaefadd3b0cd53d375890e8339303a202c2a8b

Tree-SHA512: a17ab86e422ca3d3e53deffa7fecf09cdd9b816588deeded3a15e80a1c268ff1e8b56a0e052a417f1a091872099cd3d2b89993d4773a86516b0bdef880a949a0
2023-03-03 23:07:16 +05:30
Wladimir J. van der Laan
7666b675b7
Merge #18665: Do not expose and consider -logthreadnames when it does not work
b91e4ae0d8ab2ae6b77585c97c52d825f56ed539 Do not expose and consider -logthreadnames when it does not work (Hennadii Stepanov)

Pull request description:

  There are conditions when the `HAVE_THREAD_LOCAL` macro is undefined what causes the `-logthreadnames` option does not work -- instead of thread names empty strings `[]` only are printed in the `debug.log` file.

  This PR does not exposes the `-logthreadnames` option in such cases.

  Refs:
  - #16059
  - #18652

ACKs for top commit:
  MarcoFalke:
    ACK b91e4ae0d8ab2ae6b77585c97c52d825f56ed539, looked at the diff, didn't test

Tree-SHA512: 3bd58e5ea603c69686589ddc94d6fa441cab4f712004378f2f1661e12638804ca03cfb6426e6393e55b6a095b325f3161d3c5371af05d7fc79d6d328227bf40c
2023-03-03 23:07:16 +05:30
fanquake
afdb731442
Merge #18088: build: ensure we aren't using GNU extensions
0ae8f18dfe143051fec6ae10ea7df10142e3ff2f build: add -Wgnu to compile flags (fanquake)
3a0fd7726b8b916de6cce33bb67f48990575f923 Remove use of non-standard zero variadic macros (Ben Woosley)
49f6178c3e5e3ad54a419da9d8523207da17fc64 Drop unused LOG_TIME_MICROS helper (Ben Woosley)
5d4999951ee32e333b511245862628e80f83b703 prevector: Avoid unnamed struct, which is a GNU extension (DesWurstes)

Pull request description:

  Since we [started using](https://github.com/bitcoin/bitcoin/pull/7165) the `ax_cxx_compile_stdcxx.m4` macro we've been passing `[noext]` to indicate that we don't want to use an extended mode, i.e GNU extensions. Speaking to Cory he clarified that the intention was to "require only vanilla c++11 and turn _off_ extension support so they would fail to compile".

  However in the codebase we are currently making use of some GNU extensions. We should either remove there usage, or at least amend our CXX compiler checks. I'd prefer the former.

  #### anonymous structs
  ```bash
  ./prevector.h:153:9: warning: anonymous structs are a GNU extension [-Wgnu-anonymous-struct]
          struct {
  ```

  This is fixed in b849212c1e.

  #### variadic macros

  ```bash
  ./undo.h:57:50: warning: must specify at least one argument for '...' parameter of variadic macro [-Wgnu-zero-variadic-macro-arguments]
              ::Unserialize(s, VARINT(nVersionDummy));
  ```

  This is taken care of in #18087.

  The `LOG_TIME_*` macros introduced in #16805 make use of a [GNU extension](https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html).

  ```bash
  In file included from validation.cpp:22:
  ./logging/timer.h:99:99: warning: token pasting of ',' and __VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
      BCLog::Timer<std::chrono::milliseconds> PASTE2(logging_timer, __COUNTER__)(__func__, end_msg, ## __VA_ARGS__)
                                                                                                    ^
  ./logging/timer.h:99:99: warning: token pasting of ',' and __VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
  ./logging/timer.h:99:99: warning: token pasting of ',' and __VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
  ./logging/timer.h:99:99: warning: token pasting of ',' and __VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
  ./logging/timer.h:99:99: warning: token pasting of ',' and __VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
  ./logging/timer.h:101:92: warning: token pasting of ',' and __VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
      BCLog::Timer<std::chrono::seconds> PASTE2(logging_timer, __COUNTER__)(__func__, end_msg, ## __VA_ARGS__)
                                                                                             ^
  6 warnings generated.
  ```

  This is fixed in 081a0ab64eb442bc85c4d4a4d3bc2c8e97ac2a6d and 612e8e138b97fc5ad2f38847300132a8fc423c3f.

  #### prevention
  To ensure that usage doesn't creep back in we can add [`-Wgnu`](https://clang.llvm.org/docs/DiagnosticsReference.html#wgnu) to our compile time flags, which will make Clang warn whenever it encounters GNU extensions.

  This would close #14130.
  Also related to #17230, where it's suggested we use a GNU extension, the `gnu::pure` attribute.

ACKs for top commit:
  practicalswift:
    ACK 0ae8f18dfe143051fec6ae10ea7df10142e3ff2f -- diff looks correct
  MarcoFalke:
    ACK 0ae8f18dfe143051fec6ae10ea7df10142e3ff2f
  vasild:
    utACK 0ae8f18df
  dongcarl:
    ACK 0ae8f18dfe143051fec6ae10ea7df10142e3ff2f

Tree-SHA512: c517404681ef8edf04c785731d26105bac9f3c9c958605aa24cbe399c649e7c5ee0c4aa8e714fd2b2d335e2fbea4d571e09b0dec36678ef871f0a6683ba6bb7f
2023-03-03 23:07:16 +05:30
MarcoFalke
cb3be0fd3b
Merge #18859: Remove CCoinsViewCache::GetValueIn(...)
b56607a89ba112083f2b0a7b64ab18d66b26e2be Remove CCoinsViewCache::GetValueIn(...) (practicalswift)

Pull request description:

  Remove `CCoinsViewCache::GetValueIn(...)`.

  Fixes #18858.

  It seems like `GetValueIn` was added in #748 ("Pay-to-script-hash (OP_EVAL replacement)", merged in 2012) and the last use in validation code was removed in #8498 ("Near-Bugfix: Optimization: Minimize the number of times it is checked that no money...", merged in 2017).

  `CCoinsViewCache::GetValueIn(…)` performs money summation like this:

  ```c++
  CAmount CCoinsViewCache::GetValueIn(const CTransaction& tx) const
  {
      if (tx.IsCoinBase())
          return 0;

      CAmount nResult = 0;
      for (unsigned int i = 0; i < tx.vin.size(); i++)
          nResult += AccessCoin(tx.vin[i].prevout).out.nValue;

      return nResult;
  }
  ```

  Note that no check is done to make sure that the resulting `nResult` is such that it stays within the money bounds (`MoneyRange(nResult)`), or that the summation does not trigger a signed integer overflow.

  Proof of concept output:

  ```
  coins.cpp:243:17: runtime error: signed integer overflow: 9223200000000000000 + 2100000000000000 cannot be represented in type 'long'
  GetValueIn = -9221444073709551616
  ```

  Proof of concept code:

  ```c++
  CMutableTransaction mutable_transaction;
  mutable_transaction.vin.resize(4393);

  Coin coin;
  coin.out.nValue = MAX_MONEY;
  assert(MoneyRange(coin.out.nValue));

  CCoinsCacheEntry coins_cache_entry;
  coins_cache_entry.coin = coin;
  coins_cache_entry.flags = CCoinsCacheEntry::DIRTY;

  CCoinsView backend_coins_view;
  CCoinsViewCache coins_view_cache{&backend_coins_view};
  CCoinsMap coins_map;
  coins_map.emplace(COutPoint{}, std::move(coins_cache_entry));
  coins_view_cache.BatchWrite(coins_map, {});

  const CAmount total_value_in = coins_view_cache.GetValueIn(CTransaction{mutable_transaction});
  std::cout << "GetValueIn = " << total_value_in << std::endl;
  ```

ACKs for top commit:
  MarcoFalke:
    ACK b56607a89ba112083f2b0a7b64ab18d66b26e2be
  promag:
    Code review ACK b56607a89ba112083f2b0a7b64ab18d66b26e2be.
  jb55:
    ACK b56607a89ba112083f2b0a7b64ab18d66b26e2be
  hebasto:
    ACK b56607a89ba112083f2b0a7b64ab18d66b26e2be, I have not tested the code, but I have reviewed it and it looks OK, I agree it can be merged.

Tree-SHA512: 2c8402b5753ec96703d12c57c3eda8eccf999ed3519134a87faaf0838cfe44b94ef384296af2a524c06c8756c0245418d181af9083548e360905fac9d79215e6
2023-03-03 23:07:15 +05:30
MarcoFalke
54e2bd6702
Merge #18732: test: Remove unused, undocumented and misleading CScript.__add__
faff9e4bb431919a4bc7e4dc4a9ca188e2d18113 test: Remove unused, undocumented and misleading CScript.__add__ (MarcoFalke)

Pull request description:

  See the corresponding pull #18612

ACKs for top commit:
  laanwj:
    ACK faff9e4bb431919a4bc7e4dc4a9ca188e2d18113 provided it passes Travis

Tree-SHA512: 5d9c4d5b6453c70b24a6960d3b42834e9b31f6dbb99ac47a6abfd85f2739d5372563e7188c22aceabeee1c37eb218bf580848356f4a77268d65f178a9419b269
2023-03-03 23:07:15 +05:30
PastaPastaPasta
4f97133dd6
Merge pull request #5232 from PastaPastaPasta/v19.x-delay-hf-rc.5
[V19.x] backport: delay hf rc.5
2023-03-02 11:00:06 -06:00
pasta
103523d221
chore: bump to rc.5 2023-03-02 10:57:39 -06:00
UdjinM6
66b0cf74ce
fix: postpone v19 hf start time on testnet (#5231)
## Issue being fixed or feature implemented
Block 847000 hf should happen somewhere around March 4th. We need mining
nodes to be upgraded to follow that chain and mine correct blocks.
However we don't want v19 to be activated shortly after (~300 blocks),
we want to give it a little bit of time to let (new) platform quorums
form and make sure everything is ok. With this patch we should have ~2
days (instead of half of a day).

## What was done?
bumped v19 activation start time to March 6th


## How Has This Been Tested?
n/a

## Breaking Changes
yes :)

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [ ] I have assigned this pull request to a milestone
2023-03-02 10:56:43 -06:00
UdjinM6
b5900767ea
fix: postpone v19 hf start time on testnet (#5231)
## Issue being fixed or feature implemented
Block 847000 hf should happen somewhere around March 4th. We need mining
nodes to be upgraded to follow that chain and mine correct blocks.
However we don't want v19 to be activated shortly after (~300 blocks),
we want to give it a little bit of time to let (new) platform quorums
form and make sure everything is ok. With this patch we should have ~2
days (instead of half of a day).

## What was done?
bumped v19 activation start time to March 6th


## How Has This Been Tested?
n/a

## Breaking Changes
yes :)

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [ ] I have assigned this pull request to a milestone
2023-03-02 10:55:44 -06:00
PastaPastaPasta
a79d434d84
Merge pull request #5228 from PastaPastaPasta/v19-new-llmq
[v19.x] backport: new llmq and rc.4 bump
2023-03-01 14:43:39 -06:00
UdjinM6
45da082dda
fix(doc): fix release-notes-5225.md (#5230)
## Issue being fixed or feature implemented
make linter happy, fix failures like
https://gitlab.com/dashpay/dash/-/jobs/3858504407

## What was done?
drop trailing whitespace

## How Has This Been Tested?
`COMMIT_RANGE=1a810ca07d..HEAD ./test/lint/lint-whitespace.sh `
fails on develop, passes on this branch

## Breaking Changes
n/a

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-01 13:52:03 -06:00
UdjinM6
d41f282843
fix(doc): fix release-notes-5225.md (#5230)
## Issue being fixed or feature implemented
make linter happy, fix failures like
https://gitlab.com/dashpay/dash/-/jobs/3858504407

## What was done?
drop trailing whitespace

## How Has This Been Tested?
`COMMIT_RANGE=1a810ca07d..HEAD ./test/lint/lint-whitespace.sh `
fails on develop, passes on this branch

## Breaking Changes
n/a

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-01 13:51:36 -06:00
pasta
f63676ba5f
chore: bump version to rc.4 2023-03-01 13:09:00 -06:00
Odysseas Gabrielides
0bcf96311f
feat(llmq): llmq_test_dip0024 adjustments (#5229)
## Issue being fixed or feature implemented

## What was done?

## How Has This Been Tested?

## Breaking Changes
After the DIP24 fork, instant locks will still be served by
`llmq_test_instantsend`, since no `llmq_test_dip0024` will be formed
with less than 4 nodes.

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation

**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
2023-03-01 13:09:00 -06:00