sikkienl/dash
1
0
Fork 0
mirror of https://github.com/dashpay/dash.git synced 2024-12-24 19:42:46 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
24,165 Commits 24 Branches 554 Tags 573 MiB
v20.x
Commit Graph

1896 Commits

Author SHA1 Message Date
UdjinM6
acd3ce7783
fix: ignore triggers from the past when voting (#5798) 
## Issue being fixed or feature implemented
we should not vote on triggers from the past

## What was done?

## How Has This Been Tested?
n/a

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2024-01-10 19:50:03 +07:00
Konstantin Akimov
4ebdaf69bc
fix: withdrawal (asset unlock) txes to use Platform Quorum on RegTest (#5800) 
## Issue being fixed or feature implemented
Asset Unlock tx uses platform's quorum on devnets, testnet, mainnet, but
still quorum type "Test (100)" on Reg Tests
That's part II PR, prior work is here:
https://github.com/dashpay/dash/pull/5618

## What was done?
- Removed `consensus.llmqTypeAssetLocks` which has been kept only for
RegTest - use `consensus.llmqTypePlatform` instead.
- Functional test `feature_asset_locks.py` uses `llmq_type_test = 106`
instead `llmq_type_test = 100` for asset unlock tx
- there's 4 MNs + 3 evo nodes instead 3 MNs as before: evo nodes
requires to have IS to be active


## How Has This Been Tested?
Run unit/functional tests


## Breaking Changes
Asset Unlock tx uses correct quorum "106 llmq_test_platform" on reg test
instead "100 llmq_test"

## 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
- [x] I have assigned this pull request to a milestone
 2024-01-10 19:49:54 +07:00
UdjinM6
3e5a6ef649
fix(rpc): pass blockhash into TxToJSON so that getspecialtxes could show correct instantlock/chainlock values (#5774) 
## Issue being fixed or feature implemented
`instantlock` and `chainlock` are broken in `getspecialtxes`

kudos to @thephez for finding the issue

## What was done?
pass the hash and also rename the variable to self-describing

## How Has This Been Tested?
run `getspecialtxes` on a node with and without the patch

## Breaking Changes
`instantlock` and `chainlock` will show actual values and not just
`false` all the time now (not sure if that qualifies for "breaking"
though)

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-12-24 12:04:41 -06:00
PastaPastaPasta
7c966c9db0 Merge pull request #5718 from knst/mac-improvements 
backport: bitcoin#24603, #26694, #24669, #22546, #22199, #25817 (mac build)
 2023-12-04 17:04:30 +02:00
UdjinM6
c49628de54
fix: should not notify about mnlist changes while ConnectBlock isn't done yet (#5711) 
## Issue being fixed or feature implemented
`ConnectBlock` can fail after `ProcessSpecialTxsInBlock`, we shouldn't
be notifying too early. Same for `DisconnectBlock` but that's less of an
issue imo.

## What was done?
Move notifications to the end of `ConnectBlock`/`DisconnectBlock`. There
is no `connman` in `CChainState` and I don't want to pass it in updates
struct so I changed `NotifyMasternodeListChanged` and used `connman`
from `CDSNotificationInterface` instead.

## How Has This Been Tested?
run unit test, run testnet qt wallet

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-11-16 12:37:07 -06:00
UdjinM6
c2db29439a
fix: rename SPORK_24_EHF to SPORK_24_TEST_EHF, make sure it has no effect on mainnet (#5691) 
## Issue being fixed or feature implemented
Be more explicit about the fact that spork24 is for non-mainnet only,
enforce it in code.

NOTE: I know we have EHF signalling disabled for mainnet in v20 but I
think it still makes sense to make sure spork24 condition won't slip
into mainnet in some future version accidentally.

## What was done?
pls see individual commits

## How Has This Been Tested?

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-11-13 10:03:46 -06:00
UdjinM6
704c594237
fix: some fixes for block payee validation and corresponding tests (#5684) 
## Issue being fixed or feature implemented
1. we _should not_ skip masternode payments checks below
nSuperblockStartBlock or when governance is disabled
2. we _should_ skip superblock payee checks while we aren't synced yet
(should help recovering from missed triggers)

## What was done?
pls see individual commits. 

## How Has This Been Tested?
run tests, sync w/ and w/out `--disablegovernance`, reindexed on testnet

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-11-13 10:02:52 -06:00
Odysseas Gabrielides
d5b2c260a4
test: ensure that mining is possible without CL info (#5689) 
## Issue being fixed or feature implemented
With DIP29 added to v20, miners include best CL Signature in CbTx.
The purpose of this test, is to ensure that mining is still possible
when CL information isn't available.
In such case, miners are expected to copy best CL Signature from CbTx of
previous block.

## What was done?
Two scenarios are implemented:

- Add dynamically a node, make sure `getbestchainlock()` fails, let it
mine a block.
- Disable `SPORK_19_CHAINLOCKS_ENABLED`, add dynamically a node, make
sure `getbestchainlock()` fails, let it mine a block.

In both tests, we make sure the block is accepted by everyone and that
the `bestCLSignature` in CbTx is copied from previous block.

## How Has This Been Tested?
`feature_llmq_chainlocks.py`

## Breaking Changes
no

## Checklist:
- [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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_

---------

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
 2023-11-10 08:32:01 -06:00
Konstantin Akimov
216a5f7563
refactor: make MNActivationHeight in Params() indeed constant (#5658) 
## Issue being fixed or feature implemented
Addressed issues and comments from [PR
comment](https://github.com/dashpay/dash/pull/5469#discussion_r1317886678)
and [PR
comment](https://github.com/dashpay/dash/pull/5469#discussion_r1338704082)

`Params()` should be const; global variable `CMNHFManager` is a better
out-come.


## What was done?
The helpers and direct calls of `UpdateMNParams` for each block to
update non-constant member in `Params()` is not needed anymore. Instead
`CMNHFManager` takes cares about status of Signals for each block,
update them dynamically and save in evo db.


## How Has This Been Tested?
Run unit/functional tests.

## Breaking Changes
Changed rpc `getblockchaininfo`. 
the field `ehf` changed meaning: it's now only a flag -1/0; but it is
introduced a new field `ehf_height` now that a height.


## 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
- [x] I have assigned this pull request to a milestone

---------

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
Co-authored-by: thephez <thephez@users.noreply.github.com>
 2023-11-10 08:31:12 -06:00
Odysseas Gabrielides
c293593be2
test: v20 earlier activation for regtest (#5668) 
## Issue being fixed or feature implemented
Currently, on functional tests v20 activates at height 1440 which is
later than needed.

## What was done?
Reduced the window size of v20 from 480 to 400 which activates v20 at
1200.
Adjusted tests to this change.

Note regarding the window analysis for MN payments in
`feature_llmq_evo.py` (reduced from 256 to 48 blocks):
48 window is enough to analyse 4 MNs and 5 EvoNodes (Weighted count=24)

On my machine using develop:
`python3 feature_llmq_rotation.py 145.45s user 30.00s system 68% cpu
4:16.93 total`

With this PR:
`python3 feature_llmq_rotation.py 119.26s user 24.61s system 62% cpu
3:50.89 total`


## How Has This Been Tested?
all tests


## Breaking Changes
no

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-11-07 08:03:03 -06:00
UdjinM6
c61fe0aacd
fix: actually vote NO on triggers we don't like, some additional cleanups and tests (#5670) 
## Issue being fixed or feature implemented
MNs don't really vote NO on triggers that do not match their local
candidates because:
1. they bail out too early when they see that they are not the payee
2. the hash for objects to vote NO on was picked incorrectly. 

## What was done?
Moved voting out of `CreateGovernanceTrigger` and into its own
`VoteGovernanceTriggers`. Refactored related code to use `optional`
while at it, dropped useless/misleading `IsValid()` call. Added some
safety belts, logging, tests.

## How Has This Been Tested?
Run tests.

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-11-06 23:45:42 +03:00
Odysseas Gabrielides
a612b31aab
test: getblockchaininfo projected activation_height test (#5665) 
## Issue being fixed or feature implemented
https://github.com/dashpay/dash/issues/5640

## What was done?
Tests that `activation_height` projected by `getblockchaininfo` during
locked_in phase.
Now, this test is only possible with v20 activation since v19, dip0024
are buried and mn_rr uses MNEF.

Enabled this test only in `feature_llmq_rotation.py`.

## How Has This Been Tested?
tests

## Breaking Changes
no

## Checklist:
- [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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_

---------

Co-authored-by: Konstantin Akimov <knstqq@gmail.com>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
 2023-11-06 13:32:05 -06:00
UdjinM6
66223aed51
fix: FundTransaction should follow the same bip69 rules CreateTransaction does (#5667) 
## Issue being fixed or feature implemented
fixes #5666

kudos to @tinshen for discovering the issue 👍 

## What was done?
add missing logic in FundTransaction

## How Has This Been Tested?
implement/run tests, test rpc manually

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-11-03 10:05:37 -05:00
UdjinM6
25ee1677ca
test: fix feature_governance.py (#5657) 
## Issue being fixed or feature implemented
```
test/functional/feature_governance.py:205:59: F821 undefined name 'p0_amount'
test/functional/feature_governance.py:205:95: F821 undefined name 'p1_amount'
test/functional/feature_governance.py:205:131: F821 undefined name 'p2_amount'
```

## What was done?
add missing `self.`

## How Has This Been Tested?
run linter and `feature_governance.py`

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-10-31 09:01:05 -05:00
fanquake
51ccdca24d Merge bitcoin/bitcoin#25803: refactor: Drop boost/algorithm/string/replace.hpp dependency 
fea75ad3caa29972db32d3ce7e0fe125ec77a0eb refactor: Drop `boost/algorithm/string/replace.hpp` dependency (Hennadii Stepanov)
857526e8cbb0847a865e9c2509425960d458f535 test: Add test case for `ReplaceAll()` function (Hennadii Stepanov)

Pull request description:

  A new implementation of the `ReplaceAll()` seems enough for all of our purposes.

ACKs for top commit:
  adam2k:
    ACK Tested fea75ad3caa29972db32d3ce7e0fe125ec77a0eb
  theStack:
    Code-review ACK fea75ad3caa29972db32d3ce7e0fe125ec77a0eb

Tree-SHA512: dacfffc9d2bd1fb9f034baf8c045b1e8657b766db2f0a7f8ef7e25ee6cd888f315b0124c54aba7a29ae59186b176ef9868a8b709dc995ea215c6b4ce58e174d9
 2023-10-31 08:40:25 -05:00
UdjinM6
965f5b2063
fix: adjust GetPaymentsLimit to work correctly with historical blocks, adjust sb params on regtest, tweak tests (#5641) 
## Issue being fixed or feature implemented
Noticed a couple of things while I was trying to figure out if an
[issue](https://github.com/dashpay/dash/pull/5627#discussion_r1367153099)
@knst mentioned in #5627 could actually exist:
1. `GetPaymentsLimit()` won't work correctly with historical blocks rn.
We don't use it that way internally but it could be done via rpc and it
should provide correct results.
2. superblock params on regtest are too small to test them properly
3. because of (2) and a huge v20 activation window (comparing to sb
params) `feature_governance.py` doesn't test v20 switching states.
There's also no "sb on v20 activation block" test.

~NOTE: based on #5639 atm~

## What was done?
fix it, pls see individual commits

## How Has This Been Tested?
run tests

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-10-30 18:12:07 +03:00
UdjinM6
fa19c5ffee
fix: adjust LLMQ_TEST_DIP0024 params, mine_cycle_quorum should use correct size (#5655) 
## Issue being fixed or feature implemented
Small dip0024 related cleanups, regtest only.

## What was done?
pls see individual commits

## How Has This Been Tested?
run tests

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-10-30 10:03:22 -05:00
UdjinM6
7d1e3d4d0d
fix: do not trim values in payment_amounts (#5647) 
## Issue being fixed or feature implemented
sb produced by sentinel:
>"DataString": ... \"payment_amounts\": \"20.00000000|20.00000000\", ...
>...
> "YesCount": 83,

sb produced by core:
>"DataString": ... \"payment_amounts\": \"20.00|20.00\", ...
> "YesCount": 13,

These 2 triggers are for the same block (900552), proposal hashes and
addresses are also the same but the difference in `payment_amounts`
format makes it look like a different trigger for core and this creates
a race.

## What was done?
Use `ValueFromAmount` instead of `FormatMoney` to avoid trimming

## How Has This Been Tested?
run tests

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-10-27 19:59:44 -05:00
fanquake
6e7b402fe9 partial Merge bitcoin/bitcoin#27483: Bump python minimum version to 3.8 
fac395e5eb2cd3210ba6345f777a586a9bec84e3 ci: Bump ci/lint/Dockerfile (MarcoFalke)
fa6eb6516727a8675dc6e46634d8343e282528ab test: Use python3.8 pow() (MarcoFalke)
88881cf7ac029aea660c2413ca8e2a5136fcd41b Bump python minimum version to 3.8 (MarcoFalke)

Pull request description:

  There is no pressing reason to drop support for 3.7, however there are several maintenance issues:

  * There is no supported operating system that ships 3.7 by default. (debian:buster is EOL and unmaintained to the extent that it doesn't run in the CI environment. See https://github.com/bitcoin/bitcoin/pull/27340#issuecomment-1484988445)
  * Compiling python 3.7 from source is also unsupported on at least macos, according to https://github.com/bitcoin/bitcoin/pull/24017#issuecomment-1107820790
  * Recent versions of lief require 3.8, see https://github.com/bitcoin/bitcoin/pull/27507#issuecomment-1517561645

  Fix all maintenance issues by bumping the minimum.

ACKs for top commit:
  RandyMcMillan:
    ACK fac395e
  fjahr:
    ACK fac395e5eb2cd3210ba6345f777a586a9bec84e3
  fanquake:
    ACK fac395e5eb2cd3210ba6345f777a586a9bec84e3

Tree-SHA512: c198decdbbe29d186d73ea3f6549d8a38479383495d14a965a2f9211ce39637b43f13a4c2a5d3bf56e2d468be4bbe49b4ee8e8e19ec69936ff43ddf2b714c712
 2023-10-23 10:48:39 -05:00
Konstantin Akimov
6b5b8973cc fix: missing changes from Merge #15404: [test] Remove -txindex to start nodes 2023-10-23 10:46:52 -05:00
fanquake
4cd51487c4 fix: missing changes from Merge #16917: tests: Move common function assert_approx() into util.py 
96299a9d6c0a6b9125a58a63ee3147e55d1b086b Test: Move common function assert_approx() into util.py (fridokus)

Pull request description:

  To reduce code duplication, move `assert_approx` into common framework `util.py`.

  `assert_approx()` is used in two functional tests.

ACKs for top commit:
  theStack:
    ACK 96299a9
  practicalswift:
    ACK 96299a9d6c0a6b9125a58a63ee3147e55d1b086b -- DRY is good and diff looks correct
  fanquake:
    ACK 96299a9d6c0a6b9125a58a63ee3147e55d1b086b - thanks for contributing 🍻

Tree-SHA512: 8e9d397222c49536c7b3d6d0756cc5af17113e5af8707ac48a500fff1811167fb2e03f3c0445b0b9e80f34935f4d57cfb935c4790f6f5463a32a67df5f736939
 2023-10-23 10:46:52 -05:00
UdjinM6
faba796c73
fix: actually show json for assetlock/unlock txes (#5633) 
## Issue being fixed or feature implemented
The bug was introduced in the original PR #5026 and refactored later
(which is good actually cause we shouldn't mix refactoring and
bug-fixing :) )

## What was done?
fix conditions, add tests

## How Has This Been Tested?
`feature_asset_locks.py`

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-10-23 10:36:50 -05:00
PastaPastaPasta
c51cec606d
refactor: add gsl::not_null to get compile time / run time pointer guarantees (#5595) 
## Issue being fixed or feature implemented
Current implementation relies either on asserts or sometimes checks then
returning a special value; In the case of asserts (or no assert where we
use the value without checks) it'd be better to make it explicit to
function caller that the ptr must be not_null; otherwise gsl::not_null
will call terminate.

See
https://github.com/microsoft/GSL/blob/main/docs/headers.md#user-content-H-pointers-not_null
and
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-nullptr

I'm interested in a conceptual review; specifically on if this is
beneficial over just converting these ptrs to be a reference?

## What was done?
 *Partial* implementation on using gsl::not_null in dash code


## How Has This Been Tested?
Building

## Breaking Changes
None

## 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
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_

---------

Signed-off-by: pasta <pasta@dashboost.org>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
 2023-10-22 09:14:30 -05:00
Konstantin Akimov
63ed462c54
feat: auto generation EHF and spork+EHF activation for MN_RR (#5597) 
Implementation EHF mechanism, part 4. Previous changes are: 
 - https://github.com/dashpay/dash/pull/4577
 - https://github.com/dashpay/dash/pull/5505
 - https://github.com/dashpay/dash/pull/5469

## Issue being fixed or feature implemented
Currently MN_RR is activated automatically by soft-fork activation after
v20 is activated.
It is not flexible enough, because platform may not be released by that
time yet or in opposite it can be too long to wait.
Also, any signal of EHF requires manual actions from MN owners to sign
EHF signal - it is automated here.

## What was done?
New spork `SPORK_24_MN_RR_READY`; new EHF manager that sign EHF signals
semi-automatically without manual actions; and send transaction with EHF
signal when signal is signed to network.
Updated rpc `getblockchaininfo` to return information about of EHF
activated forks.
Fixed function `IsTxSafeForMining` in chainlock's handler to skip
transactions without inputs (empty `vin`).

## How Has This Been Tested?
Run unit/functional tests. Some tests have been updated due to new way
of MN_RR activation: `feature_asset_locks.py`, `feature_mnehf.py`,
`feature_llmq_evo.py` and unit test `block_reward_reallocation_tests`.


## Breaking Changes
New way of MN_RR activation.

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_

---------

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
 2023-10-17 22:31:40 -05:00
Odysseas Gabrielides
cecf63e0b7
feat!: exclude fees when calculating platformReward (#5612) 
## Issue being fixed or feature implemented
Calculation of `platformReward` should ignore fees and rely only on
Block subsidy.

cc @QuantumExplorer 

## What was done?
From now on, the following formula is applied:
```
blockReward = blockSubsidy + feeReward
masternodeReward = masternodeShare(blockSubsidy)
platformReward = platformShare(masternodeReward)
masternodeReward += masternodeShare(feeReward)
```


## How Has This Been Tested?


## Breaking Changes
`plaftormReward` differs in networks where `mn_rr` is already active

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_

---------

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
 2023-10-17 22:07:37 -05:00
Odysseas Gabrielides
848ed765e0
feat!: constant subsidy base for blocks in v20 (#5611) 
## Issue being fixed or feature implemented
Currently, the `nSubsidyBase` calculation relies on difficulty. This
leads to variable Block Subsidity.
When Platform will be live, it would constantly require blocks
difficulty in order to calculate the `platformReward` (which relies on
Block Subsidy)

cc @QuantumExplorer 

## What was done?
Starting from v20 activation, `nSubsidyBase` will no longer rely on
difficulty and will be constant to 5.

## How Has This Been Tested?


## Breaking Changes
Block rewards will differ.

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-10-17 15:50:23 -05:00
Odysseas Gabrielides
5ca6382bfa
test: correct calculation of coinbasevalue in feature_asset_locks.py (#5603) 
## Issue being fixed or feature implemented
Fixed a problem forgotten in #5588 in feature_asset_locks.py.

## What was done?
Avoid floating operations when calculating `coinbasevalue`

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_

---------

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
 2023-10-11 08:13:29 -05:00
UdjinM6
30f3f50928
fix: Let CDeterministicMN::ToJson() return correct collateralAddress for spent collaterals (#5607) 
## Issue being fixed or feature implemented
Historical masternode data returned via rpcs like `protx listdiff` can
be broken because some collaterals might be spent already and
`GetUTXOCoin` wasn't able to get any info.

## What was done?
Use `GetTransaction` as a fallback.

## How Has This Been Tested?
run tests

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-10-09 11:14:51 -05:00
UdjinM6
2004a855d9
fix!: avoid float calculations in PlatformShare (#5604) 
## Issue being fixed or feature implemented
avoid potential discrepancies in block reward calculations

## What was done?
use integers (int64_t) only when dealing with block rewards, no
float/double

## How Has This Been Tested?
run tests

## Breaking Changes
might fork off on devnets that use previous version

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-10-09 09:15:23 -05:00
UdjinM6
4b046bb608 use deployment nStartTime as a signal expiration mark, adjust tests 
if a signal is mined prior to nStartTime then it means it was mined for one of the previous deployments with the same bit and we can ignore it
 2023-10-06 11:02:15 -05:00
Konstantin Akimov
d83dbd287a fix: fix previous commit with fixes 2023-10-06 11:02:15 -05:00
Konstantin Akimov
5e31bd5545 refactor: multiple fixes, cleanups, improvements and refactorings 2023-10-06 11:02:15 -05:00
Konstantin Akimov
92be5e0be7 fix: now EHF transactions expires after nExpiryEHF blocks 2023-10-06 11:02:15 -05:00
Konstantin Akimov
3973f2b925 feat: update functional tests for Mn EHF - to use same bit more than once 2023-10-06 11:02:15 -05:00
Konstantin Akimov
ef14b53b3d feat: add functional test for unknown and invalid version bits of EHF release 2023-10-06 11:02:15 -05:00
Konstantin Akimov
2c4597db9f feat: improve functional tests for MnEHF to check block reconsideration 2023-10-06 11:02:15 -05:00
Konstantin Akimov
b85a497cca feat: new functional test for feature MnEHF 2023-10-06 11:02:15 -05:00
Konstantin Akimov
33ab3187b2 feat: add CMNHFManager and logic to make hard-forks accordingly received signals 2023-10-06 11:02:15 -05:00
Konstantin Akimov
612faa8868 feat: imlemented new hard-fork mechanism that uses MN Activation Height 
Altough, it's still disabled because no calls of related methods after processing MnEHF tx
 2023-10-06 11:02:15 -05:00
UdjinM6
c814dcaaea
fix: Move CreditPoolDiff checks out of ProcessSpecialTxsInBlock, use correct block reward (#5594) 
## Issue being fixed or feature implemented
The block reward calculation logic in `SetTarget` doesn't work on
superblocks.

## What was done?
Move `CreditPoolDiff` checks out of `ProcessSpecialTxsInBlock` to use
correct block reward.

## How Has This Been Tested?
run tests

## Breaking Changes
n/a, sb blocks should now be processed correctly, non-sb blocks
shouldn't be affected

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-10-04 12:47:21 -05:00
Odysseas Gabrielides
e72eb40024
feat!: Block Reward Reallocation (Doubling Treasury) (#5588) 
## Issue being fixed or feature implemented
Implementation of accepted proposal:
https://www.dashcentral.org/p/TREASURY-REALLOCATION-60-20-20

## What was done?
Once Masternode Reward Location Reallocation activates:
- Treasury is bumped to 20% of block subsidy.
- Block reward shares are immediately set to 75% for MN and 25% miners.
(Previous reallocation periods are dropped)
MN reward share should be 75% of block reward in order to represent 60%
of the block subsidy. (according to the proposal)
- `governancebudget` is returned from `getgovernanceinfo` RPC.

## How Has This Been Tested?
`block_reward_reallocation_tests`

## 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
- [x] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_

---------

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
 2023-10-03 09:32:53 -05:00
PastaPastaPasta
7ca61abed0
refactor: remove some now unneeded cppcheck suppressions (#5589) 
## Issue being fixed or feature implemented
Unneeded suppressions were present

## What was done?
Removed them

## How Has This Been Tested?
Running linter

## Breaking Changes
None

## 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
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
 2023-09-29 07:53:22 -05:00
Kittywhiskers Van Gogh
c3b4b6746a merge bitcoin#20966: save the banlist in a JSON format on disk 2023-09-24 09:50:50 -05:00
Kittywhiskers Van Gogh
5d7367e366 merge bitcoin#22050: remove tor v2 support 2023-09-24 09:50:50 -05:00
Kittywhiskers Van Gogh
4b29a74904 merge bitcoin#20852: allow CSubNet of non-IP networks 2023-09-24 09:50:50 -05:00
Konstantin Akimov
633cc3260f
feat: new rpc `gettxchainlocks' to get transaction statuses by batch (#5578) 
## Issue being fixed or feature implemented
Requested by @QuantumExplorer for platform needs

## What was done?
New rpc `gettransactionsarelocked` that returns list of txes.
it does less heavy calculations and transfer less data by gRPC.


## How Has This Been Tested?
```
$ src/dash-cli gettransactionsarelocked  '["e469de7994b9c1da8efd262fee8843efd7bdcab80c700dc1059c98b28f7c5c1b", "0d9fdf00c9568ff9103742b64e6b8287794633072f8824fa2c475f59e71dbace","0d3f48eebead54d640a7fc5692ddfcba619d8b49347d9a7c04586057c02dec9f"]'

[
  {
    "height": 907801,
    "chainlock": true
  },
  {
    "height": 101,
    "chainlock": true
  },
  {
    "height": -1,
    "chainlock": false
  }
]
```
Limiter tested by this call:
```
src/dash-cli gettransactionsarelocked  '["", "","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""]'  | wc
```

## 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
- [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-09-20 09:07:24 -05:00
merge-script
90285f5327 Merge bitcoin/bitcoin#22790: test: add aarch64-apple-darwin platform entry to get_previous_releases 
f6e4db27ceb67157dc13d13f34351cb87fec2be5 test: add aarch64-apple-darwin platform entry to get_previous_releases (Zero-1729)

Pull request description:

  Over the course of reviewing a PR, I had to edit `test/get_previous_releases.py` (after I ran `git clean -xdff`) to run the backwards compatibility tests (e.g. `wallet_upgradewallet`, `feature_backwards_compatibility`, etc.), as currently on master, running the script as indicated in [`test/README.md`](https://github.com/bitcoin/bitcoin/blob/master/test/README.md), for example, on an M1 machine results in the following error, as the `aarch64-apple-darwin*` platform entry is presently not recognised:

  > Output from an M1 machine running macOS v11.5.2

  ```sh
  $ test/get_previous_releases.py -b v0.20.1 v0.19.1 v0.18.1 v0.17.2 v0.16.3 v0.15.2
  Releases directory: releases
  Not sure which binary to download for aarch64-apple-darwin20.6.0
  ```

  As a quick fix, this PR adds the missing `aarch64-apple-darwin*` platform entry. Running the script now results in fetching the old binaries, as expected:

  ```sh
  $ test/get_previous_releases.py -b v0.20.1 v0.19.1 v0.18.1 v0.17.2 v0.16.3 v0.15.2

  Releases directory: releases
  Fetching: https://bitcoincore.org/bin/bitcoin-core-0.20.1/bitcoin-0.20.1-osx64.tar.gz
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
    0 20.9M    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
  100 20.9M  100 20.9M    0     0   136k      0  0:02:37  0:02:37 --:--:-- 95607
  Checksum matched

  …

  Checksum matched
  ```

  After this patch, the backwards compatibility tests also run successfully, as expected.

  **Note**: I am open to other possible solutions.

  ---

  Steps to reproduce:

  > Ensure you take out the binaries in `releases` if they already exist.

  Try running `test/get_previous_releases.py -b v0.15.2` or similar to fetch the old release binaries.

Top commit has no ACKs.

Tree-SHA512: a238d909b70a61be622234bc49b05d2e91a8acfc5ea348d29f2c8a927fb793cb97365e558571e3f46d6a5650c4f3c6e28fa126c6e56b38e1eb98f7c3e3594d0f
 2023-09-19 08:54:12 -05:00
Konstantin Akimov
f878b281ba fix: fillow-up Merge #18774: test: added test for upgradewallet RPC 
- partial dashification
 - disabling this test so far as it does not work anyway
 2023-09-19 08:54:12 -05:00
Konstantin Akimov
fab1031a70 fix: missing changes from Merge #18873: Fix intermittent sync_blocks failures 2023-09-19 08:54:12 -05:00
Sjors Provoost
fe1e8c2d13 fix: missing changes from Merge #18067: wallet: Improve LegacyScriptPubKeyMan::CanProvide script recognition 
[test] check for addmultisigaddress regression
 2023-09-19 08:54:12 -05:00