Commit Graph

1292 Commits

Author SHA1 Message Date
UdjinM6
5d8ffe56dc
fix: add rpc help text for "ehf" field (#5628)
## Issue being fixed or feature implemented
#5597 follow-up 

## What was done?
add missing filed description

## How Has This Been Tested?
`help getblockchaininfo`

## 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-20 10:04:55 -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
Konstantin Akimov
a699ad187d refactor: removing usage of ::ChainActive::Tip() form masternode/payments 2023-10-17 08:25:51 -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
8eda85a451
refactor: make all ToJson functions return a UniValue instead of return by reference; add nodiscard (#5592)
## Issue being fixed or feature implemented
Return by reference is generally not ideal, and especially as there is
only one return path per function, all returns will be done via NRVO.
Additionally, call sites are simpler now.

## What was done?
Refactored to return by value


## How Has This Been Tested?
Building

## Breaking Changes
Should be 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 12:56:52 -05:00
UdjinM6
c034ff0c26
fix: debug rpc should return a list of active debug categories, not all of them (#5585)
## Issue being fixed or feature implemented
This restores previous behaviour which was changed/broken here
e554d3a02e (diff-0ba691cbdd97c095286e9373ed8d5be87d559234440487956326965e16cbb421R75)

## What was done?
Fix `debug` rpc results

## How Has This Been Tested?
Run rpc, check results

## 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)_

---------

Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
2023-09-28 07:47:45 -05:00
Kittywhiskers Van Gogh
93ddd3f7e8 refactor: consolidate P2PK{H} types to P2PK_OR_P2PKH 2023-09-25 22:57:42 +05:30
Kittywhiskers Van Gogh
f011c31b1a refactor: make AddressType a strong enum, remove uint8_t for address_type
Co-authored-by: Konstantin Akimov <knstqq@gmail.com>
2023-09-25 22:57:42 +05:30
Kittywhiskers Van Gogh
c65a10f349 refactor: use structure binding in for loop in rpc/misc
Co-authored-by: Konstantin Akimov <knstqq@gmail.com>
2023-09-25 22:57:41 +05:30
Kittywhiskers Van Gogh
109f57c83e refactor: use range-based loops instead of iterators
Co-authored-by: Konstantin Akimov <knstqq@gmail.com>
2023-09-25 22:57:41 +05:30
Kittywhiskers Van Gogh
5c34da0675 refactor: cleanup spentindex structs, use fixed-length integers 2023-09-25 20:21:07 +05:30
Kittywhiskers Van Gogh
53977827ff refactor: cleanup addressindex structs, use fixed-length integers 2023-09-25 20:20:32 +05:30
Kittywhiskers Van Gogh
5faf29d318 refactor: use scoped weak enum instead of bare values for address type
strong enums (enum class) cannot be converted implicitly to another
type, requiring you to either use a static_cast or use to_underlying,
which is a part of C++23, which this codebase doesn't support.

the idea of scoping a weak enum into a namespace is courtesy of
https://stackoverflow.com/a/46294875/13845753
2023-09-24 21:59:07 +05:30
Kittywhiskers Van Gogh
dba0dc9501 merge bitcoin#20464: Treat CDataStream bytes as uint8_t 2023-09-24 09:50:50 -05:00
Kittywhiskers Van Gogh
ee313525ad
refactor: decouple db hooks from CFlatDB-based C*Manager objects, migrate to *Store structs (#5555)
## Motivation

As highlighted in https://github.com/dashpay/dash-issues/issues/52,
decoupling of `CFlatDB`-interacting components from managers of objects
like `CGovernanceManager` and `CSporkManager` is a key task for
achieving deglobalization of Dash-specific components.

The design of `CFlatDB` as a flat database agent relies on hooking into
the object's state its meant to load and store, using its
(de)serialization routines and other miscellaneous functions (notably,
without defining an interface) to achieve those ends. This approach was
taken predominantly for components that want a single-file cache.

Because of the method it uses to hook into the object (templates and the
use of temporary objects), it explicitly prevented passing arguments
into the object constructor, an explicit requirement for storing
references to other components during construction. This, in turn,
created an explicit dependency on those same components being available
in the global context, which would block the backport of bitcoin#21866,
a requirement for future backports meant to achieve parity in
`assumeutxo` support.

The design of these objects made no separation between persistent (i.e.
cached) and ephemeral (i.e. generated/fetched during initialization or
state transitions) data and the design of `CFlatDB` attempts to "clean"
the database by breaching this separation and attempting to access this
ephemeral data.

This might be acceptable if it is contained within the manager itself,
like `CSporkManager`'s `CheckAndRemove()` but is utterly unacceptable
when it relies on other managers (that, as a reminder, are only
accessible through the global state because of restrictions caused by
existing design), like `CGovernanceManager`'s `UpdateCachesAndClean()`.

This pull request aims to separate the `CFlatDB`-interacting portions of
these managers into a struct, with `CFlatDB` interacting only with this
struct, while the manager inherits the struct and manages
load/store/update of the database through the `CFlatDB` instance
initialized within its scope, though the instance only has knowledge of
what is exposed through the limited parent struct.

## Additional information

* As regards to existing behaviour, `CFlatDB` is written entirely as a
header as it relies on templates to specialize itself for the object it
hooks into. Attempting to split the logic and function definitions into
separate files will require you to explicitly define template
specializations, which is tedious.

* `m_db` is defined as a pointer as you cannot instantiate a
forward-declared template (see [this Stack Overflow
answer](https://stackoverflow.com/a/12797282) for more information),
which is done when defined as a member in the object scope.

* The conditional cache flush predicating on RPC _not_ being in the
warm-up state has been replaced with unconditional flushing of the
database on object destruction (@UdjinM6, is this acceptable?)

## TODOs

This is a list of things that aren't within the scope of this pull
request but should be addressed in subsequent pull requests

* [ ] Definition of an interface that `CFlatDB` stores are expected to
implement
* [ ] Lock annotations for all potential uses of members protected by
the `cs` mutex in each manager object and store
* [ ] Additional comments documenting what each function and member does
* [ ] Deglobalization of affected managers

---------

Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com>
2023-09-24 09:50:21 -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
PastaPastaPasta
400d171d04
feat(rpc): add fundingthreshold to output of getgovernanceinfo (#5581)
## Issue being fixed or feature implemented
DashCentral and DMT are both providing incorrect funding thresholds;
output this from core to communicate this more clearly

## What was done?
Added RPC output

## How Has This Been Tested?
Running on main net

## 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-19 21:30:13 +03:00
Kittywhiskers Van Gogh
41a6613fba
refactor: subsume CoinJoin objects under CJContext, deglobalize coinJoin{ClientQueueManager,Server} (#5337)
## Motivation

CoinJoin's subsystems are initialized by variables and managers that
occupy the global context. The _extent_ to which these subsystems
entrench themselves into the codebase is difficult to assess and moving
them out of the global context forces us to enumerate the subsystems in
the codebase that rely on CoinJoin logic and enumerate the order in
which components are initialized and destroyed.

Keeping this in mind, the scope of this pull request aims to:

* Reduce the amount of CoinJoin-specific entities present in the global
scope
* Make the remaining usage of these entities in the global scope
explicit and easily searchable

## Additional Information

* The initialization of `CCoinJoinClientQueueManager` is dependent on
blocks-only mode being disabled (which can be alternatively interpreted
as enabling the relay of transactions). The same applies to
`CBlockPolicyEstimator`, which `CCoinJoinClientQueueManager` depends.

Therefore, `CCoinJoinClientQueueManager` is only initialized if
transaction relaying is enabled and so is its scheduled maintenance
task. This can be found by looking at `init.cpp`
[here](93f8df1c31/src/init.cpp (L1681-L1683)),
[here](93f8df1c31/src/init.cpp (L2253-L2255))
and
[here](93f8df1c31/src/init.cpp (L2326-L2327)).
  
For this reason, `CBlockPolicyEstimator` is not a member of `CJContext`
and its usage is fulfilled by passing it as a reference when
initializing the scheduling task.

* `CJClientManager` has not used `CConnman` or `CTxMemPool` as `const`
as existing code that is outside the scope of this PR would cast away
constness, which would be unacceptable. Furthermore, some logical paths
are taken that will grind to a halt if they are stored as `const`.

  Examples of such a call chains would be:

* `CJClientManager::DoMaintenance >
CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating >
CCoinJoinClientSession::DoAutomaticDenominating >
CCoinJoinClientSession::StartNewQueue > CConnman::AddPendingMasternode`
which modifies `CConnman::vPendingMasternodes`, which is non-const
behaviour

* `CJClientManager::DoMaintenance >
CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating >
CCoinJoin::IsCollateralValid > AcceptToMemoryPool` which adds a
transaction to the memory pool, which is non-const behaviour

* There were cppcheck [linter
failures](https://github.com/dashpay/dash/pull/5337#issuecomment-1685084688)
that seemed to be caused by the usage of `Assert` in
`coinjoin/client.h`. This seems to be resolved by backporting
[bitcoin#24714](https://github.com/bitcoin/bitcoin/pull/24714). (Thanks
@knst!)
    * Depends on #5546

---------

Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com>
Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
2023-09-13 12:52:38 -05:00
PastaPastaPasta
38e70430b9
refactor: governance constification and deglobalization (#5572)
## Issue being fixed or feature implemented
Some relatively simple refactoring; inspired by reviewing #5569; adds
some constification and some deglobalization

## What was done?
Partial deglobalization and constification

## 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)_
2023-09-10 14:05:49 -05:00
UdjinM6
45a1dfd3cc
fix: add/tweak thread safety annotations around governance objects map, add missing lock (#5569)
## Issue being fixed or feature implemented
Tidy up things a bit, address concerns expressed in
https://github.com/dashpay/dash/pull/5565#discussion_r1315258917

## What was done?
Implemented changes to make sure `mapObjects` is protected

## How Has This Been Tested?
Run tests, run local node

## 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-09-07 10:36:41 -05:00
Konstantin Akimov
f8befc811c
fix: add missing includes and remove obsolete includes (#5562)
## Issue being fixed or feature implemented
Some headers or modules are used objects from STL without including it
directly, it cause compilation failures on some platforms for some
specific compilers such as #5554

## What was done?
Added missing includes and removed obsolete includes for `optional`,
`deque`, `tuple`, `unordered_set`, `unordered_map`, `set` and `atomic`.

Please, note, that this PR doesn't cover all cases, only cases when it
is obviously missing or obviously obsolete.

Also most of changes belongs to to dash specific code; but for cases of
original bitcoin code I keep it untouched, such as missing <map> in
`src/psbt.h`

I used this script to get a list of files/headers which looks suspicious
`./headers-scanner.sh std::optional optional`:
```bash
#!/bin/bash

set -e

function check_includes() {
    obj=$1
    header=$2
    file=$3

    used=0
    included=0

    grep "$obj" "$file" >/dev/null 2>/dev/null && used=1
    grep "include <$header>" $file >/dev/null 2>/dev/null && included=1
    if [ $used == 1 ] && [ $included == 0 ]
        then echo "missing <$header> in $file"
    fi
    if [ $used == 0 ] && [ $included == 1 ]
        then echo "obsolete <$header> in $file"
    fi
}
export -f check_includes

obj=$1
header=$2

find src \( -name '*.h' -or -name '*.cpp' -or -name '*.hpp' \) -exec bash -c 'check_includes "$0" "$1" "$2"'  "$obj" "$header"  {} \;
```

## How Has This Been Tested?
Built code locally

## 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
2023-09-07 09:07:02 -05:00
Konstantin Akimov
a77dc95b78 refactor: fix bad naming of namespace CMasternodePayments -> MasternodePayments 2023-09-05 11:25:28 -05:00
Kittywhiskers Van Gogh
9964cbe772 merge bitcoin#23411: Avoid integer overflow in ApplyStats when activating snapshot 2023-09-04 20:50:27 -05:00
Konstantin Akimov
ba68ea50f9
feat: various Asset Locks improvement (#5527)
## What was done?
 - remove dependency of Asset Lock txes on CCreditPool
- new case for functional tests of Asset Locks - more than one output
for Asset Lock tx.


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

## Breaking Changes
Slightly changes behaviour of TxMempool. Tx can be accepted in mempool
even if Asset Unlock transaction with same index is already mined. But
final consensus rules are same.


## 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
2023-08-31 12:28:17 -05:00
Odysseas Gabrielides
811f6177ba
feat(rpc): Disable submission of triggers and gobject vote-conf RPC (#5552)
## Issue being fixed or feature implemented
With #5525 , MNs shouldn't use Sentinel anymore. 

## What was done?
In order to force them to remove Sentinel:
-  `gobject submit` RPC won't accept triggers anymore.
-  `gobject vote-conf` RPC isn't available anymore.


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

## Breaking Changes
Normally, only Sentinel should be broken.

## 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
- [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-08-31 12:09:05 -05:00
Samuel Dobson
0d4198c519 Merge #17509: gui: save and load PSBT
764bfe4cba35c24f7627cc425d9e7eba56e98964 [psbt] add file size limit (Sjors Provoost)
1cd8dc2556b847e11a238b9e69493cd8fbeecc6c [gui] load PSBT (Sjors Provoost)
f6895301f768220f3ea70231d5cc5b45ecbf4488 [gui] save PSBT to file (Sjors Provoost)
1d05a9d80b1211b47af465ba6958b0ec5a8c33ab Move DEFAULT_MAX_RAW_TX_FEE_RATE to node/transaction.h (Sjors Provoost)
86e22d23bb90383971a68ead0666f225ddd632fb [util] GetFileSize (Sjors Provoost)
6ab3aad9a51cc5e97a8e2ae7dbd5082272163c30 [gui] send dialog: split on_sendButton_clicked (Sjors Provoost)

Pull request description:

  This adds:
  * a dialog after Create Unsigned, which lets you save a PSBT file in binary format, e.g. to an SD card
  * a "Load PSBT" menu entry lets you pick a PSBT file. We broadcast the transaction if complete

  ## Save flow
  <img width="482" alt="Schermafbeelding 2020-01-04 om 20 39 34" src="https://user-images.githubusercontent.com/10217/71765684-ba60d580-2f32-11ea-8dea-0c4398eb6e15.png">

  <img width="287" alt="Schermafbeelding 2020-01-04 om 20 40 35" src="https://user-images.githubusercontent.com/10217/71765677-a0bf8e00-2f32-11ea-8172-12dfd34a89f3.png">

  <img width="594" alt="Schermafbeelding 2020-01-04 om 20 41 12" src="https://user-images.githubusercontent.com/10217/71765681-aa48f600-2f32-11ea-8e2c-c4f6bf9f5309.png">

  <img width="632" alt="Schermafbeelding 2020-01-04 om 20 41 28" src="https://user-images.githubusercontent.com/10217/71765691-d19fc300-2f32-11ea-97ff-70f5dd59987a.png">

  By default the file name contains the destination address(es) and amount(s).

  We only use the binary format for files, in order to avoid compatibility hell. If we do want to add base64 file format support, we should use a different extension for that (`.psbt64`?).

  ## Load flow

  Select a file:
  <img width="649" alt="Schermafbeelding 2020-01-04 om 21 08 57" src="https://user-images.githubusercontent.com/10217/71766089-2ba28780-2f37-11ea-875d-074794b5707d.png">

  Offer to send if complete:

  <img width="308" alt="Schermafbeelding 2020-01-04 om 21 09 06" src="https://user-images.githubusercontent.com/10217/71766088-2a715a80-2f37-11ea-807d-394c8b840c59.png">

  Tell user if signatures are missing, offer to copy to clipboard:
  <img width="308" alt="Schermafbeelding 2020-01-04 om 21 15 57" src="https://user-images.githubusercontent.com/10217/71766115-702e2300-2f37-11ea-9f62-a6ede499c0fa.png">

  Incomplete for another reason:

  <img width="309" alt="Schermafbeelding 2020-01-04 om 21 07 51" src="https://user-images.githubusercontent.com/10217/71766090-2c3b1e00-2f37-11ea-8a22-6188377b67a1.png">

ACKs for top commit:
  instagibbs:
    re-ACK  764bfe4cba
  achow101:
    ACK 764bfe4cba35c24f7627cc425d9e7eba56e98964
  jb55:
    Tested ACK 764bfe4cba35c24f7627cc425d9e7eba56e98964
  jonatack:
    ACK 764bfe4c
  promag:
    Code review ACK 764bfe4cba35c24f7627cc425d9e7eba56e98964.

Tree-SHA512: d284ed6895f3a271fb8ff879aac388ad217ddc13f72074725608e1c3d6d90650f6dc9e9e254479544dd71fc111516b02c8ff92158153208dc40fb2726b37d063
2023-08-29 22:00:59 -05:00
Konstantin Akimov
4aa197dbdb Merge #18673: scripted-diff: Sort test includes
fa4632c41714dfaa699bacc6a947d72668a4deef test: Move boost/stdlib includes last (MarcoFalke)
fa488f131fd4f5bab0d01376c5a5013306f1abcd scripted-diff: Bump copyright headers (MarcoFalke)
fac5c373006a9e4bcbb56843bb85f1aca4d87599 scripted-diff: Sort test includes (MarcoFalke)

Pull request description:

  When writing tests, often includes need to be added or removed. Currently the list of includes is not sorted, so developers that write tests and have `clang-format` installed will either have an unrelated change (sorting) included in their commit or they will have to manually undo the sort.

  This pull preempts both issues by just sorting all includes in one commit.

  Please be aware that this is **NOT** a change to policy to enforce clang-format or any other developer guideline or process. Developers are free to use whatever tool they want, see also #18651.

  Edit: Also includes a commit to bump the copyright headers, so that the touched files don't need to be touched again for that.

ACKs for top commit:
  practicalswift:
    ACK fa4632c41714dfaa699bacc6a947d72668a4deef
  jonatack:
    ACK fa4632c41714dfaa, light review and sanity checks with gcc build and clang fuzz build

Tree-SHA512: 130a8d073a379ba556b1e64104d37c46b671425c0aef0ed725fd60156a95e8dc83fb6f0b5330b2f8152cf5daaf3983b4aca5e75812598f2626c39fd12b88b180
2023-08-29 22:00:59 -05:00
MarcoFalke
a298eb2b93 Merge #20584: Declare de facto const reference variables/member functions as const
31b136e5802e1b1e5f9a9589736afe0652f34da2 Don't declare de facto const reference variables as non-const (practicalswift)
1c65c075ee4c7f98d9c1fac5ed7576b96374d4e9 Don't declare de facto const member functions as non-const (practicalswift)

Pull request description:

  _Meta: This is the second and final part of the `const` refactoring series (part one: #20581). **I promise: no more refactoring PRs from me in a while! :)** I'll now go back to focusing on fuzzing/hardening!_

  Changes in this PR:
  * Don't declare de facto const member functions as non-const
  * Don't declare de facto const reference variables as non-const

  Awards for finding candidates for the above changes go to:
  * `clang-tidy`'s [`readability-make-member-function-const`](https://clang.llvm.org/extra/clang-tidy/checks/readability-make-member-function-const.html)  check ([list of `clang-tidy` checks](https://clang.llvm.org/extra/clang-tidy/checks/list.html))
  * `cppcheck`'s `constVariable` check ([list of `cppcheck` checks](https://sourceforge.net/p/cppcheck/wiki/ListOfChecks/))

  See #18920 for instructions on how to analyse Bitcoin Core using Clang Static Analysis, `clang-tidy` and `cppcheck`.

ACKs for top commit:
  ajtowns:
    ACK 31b136e5802e1b1e5f9a9589736afe0652f34da2
  jonatack:
    ACK 31b136e5802e1b1e5f9a9589736afe0652f34da2
  theStack:
    ACK 31b136e5802e1b1e5f9a9589736afe0652f34da2 ❄️

Tree-SHA512: f58f8f00744219426874379e9f3e9331132b9b48e954d24f3a85cbb858fdcc98009ed42ef7e7b4619ae8af9fc240a6d8bfc1c438db2e97b0ecd722a80dcfeffe
2023-08-29 21:40:46 -05:00
MarcoFalke
e554d3a02e Merge #18669: log: Use Join() helper when listing log categories
faec0638872798b58b9882ee079014555bc8393e log: Use Join() helper when listing log categories (MarcoFalke)

Pull request description:

  This removes the global `ListLogCategories` and replaces it with a one-line member function `LogCategoriesString`, which just calls `Join`.

  Should be a straightforward refactor to get rid of a few LOC.

ACKs for top commit:
  laanwj:
    ACK faec0638872798b58b9882ee079014555bc8393e
  promag:
    ACK faec0638872798b58b9882ee079014555bc8393e, I also think it's fine as it is (re https://github.com/bitcoin/bitcoin/pull/18669#discussion_r412944724).

Tree-SHA512: 2f51f9ce1246eda5630015f3a869e36953c7eb34f311baad576b92d7829e4e88051c6189436271cd0a13732a49698506345b446b98fd28e58edfb5b62169f1c9
2023-08-29 21:40:46 -05:00
MarcoFalke
9daa8a2fd0 (Partial) Merge #21053: rpc, test: document {previous,next}blockhash as optional
ba7e17e073f833eccd4c7c111ae9058c3f123371 rpc, test: document {previous,next}blockhash as optional (Sebastian Falbesoner)

Pull request description:

  This PR updates the result help of the following RPCs w.r.t. the `previousblockhash` and `nextblockhash` fields:
  - getblockheader
  - getblock

  Also adds trivial tests on genesis block (should not contain "previousblockhash") and best block (should not contain "nextblockhash").

Top commit has no ACKs.

Tree-SHA512: ef42c5c773fc436e1b4a67be14e2532e800e1e30e45e54a57431c6abb714d2c069c70d40ea4012d549293b823a1973b3f569484b3273679683b28ed40abf46bb
2023-08-28 11:24:41 -05:00
Konstantin Akimov
54e0e0f5cd
refactor: new function GetBlockSubsidyPrev for simplification of usage (#5524)
## Issue being fixed or feature implemented
Unlike bitcoin we are using PREVIOUS block in `GetBlockSubsidy()`.

That creates special case for genesis block, because it doesn't have
previous block. In this special case instead of calling
`GetBlockSubsidy` should be used pre-calculated value. To avoid
confusion for new code and simplify implementation, there's introduced a
new method `GetBlockSubsidyPrev` that has other interface: it takes
pointer `CBlockIndex* prev` in agruments instead pair of height + nbits.

These changes are follow-up for #5501 

## What was done?
Implemented new method `GetBlockSubsidyPrev()` and used instead of
`GetBlockSubsidy` when it is more convenient.

## How Has This Been Tested?
Run unit/functional 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

---------

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2023-08-27 16:24:30 -05:00
PastaPastaPasta
690f47c493
Merge pull request #5490 from vijaydasmp/bp22_2
backport: Merge bitcoin#20023, 21713, 20575, 21989, 20971, 20964, 20497, 20425, 19980, (partial) 20125
2023-08-20 23:39:50 -05:00
Odysseas Gabrielides
93f8df1c31
refactor: Global renaming from hpmn to evo (#5508)
## Issue being fixed or feature implemented

## What was done?
Renaming of all classes/variables/functions/rpcs from `hpmn` to `evo`.

## How Has This Been Tested?
All unit and func tests are passing.
Sync of Testnet.

## Breaking Changes
All protx RPCs ending with `_hpmn` were converted to `_evo`.
`_hpmn` RPCs are now deprecated.
Although, they can still be enabled by adding `-deprecatedrpc=hpmn`.


## 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
- [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: thephez <thephez@users.noreply.github.com>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2023-08-17 14:01:12 -05:00
MarcoFalke
04a0baad8d Merge #20731: rpc: Add missing description of vout in getrawtransaction help text
b23349b8804fb60c6b3d7d0e2a95927a0d1b49b9 rpc: Add missing description of vout in getrawtransaction help text (Ben Carman)

Pull request description:

  In `getrawtransaction` the vout did not have a description. I gave it the same description as the one used in `decoderawtransaction`.

ACKs for top commit:
  MarcoFalke:
    ACK b23349b8804fb60c6b3d7d0e2a95927a0d1b49b9 🏯

Tree-SHA512: 3833b97c82a46dfeb7ac825d4b2514b4b05ce54ac41f2144a8e2f2093b3411fe1d090c1e5b0c3d09200a2ea164c8d17ece12cdb43bbaeaeccc51a9da6dd7b7a3
2023-08-08 06:33:29 -05:00
MarcoFalke
560e5589cb Merge #18532: rpc: Avoid initialization-order-fiasco on static CRPCCommand tables
fa1a92224dd78de817d15bcda35a8310254e1a54 rpc: Avoid initialization-order-fiasco on static CRPCCommand tables (MarcoFalke)

Pull request description:

  Currently the fiasco is only theoretical because all content of the table are compile-time constants. However, the fiasco materializes should they ever become run-time constants (e.g. #18531).

ACKs for top commit:
  promag:
    ACK fa1a92224dd78de817d15bcda35a8310254e1a54.
  practicalswift:
    ACK fa1a92224dd78de817d15bcda35a8310254e1a54 -- fiasco bad :)

Tree-SHA512: cccadb0ad56194599b74f04264d74c34fa865958580a850efc6474bbdc56f30cadce6b2e9a6ad5472ff46c3f4c793366acd8090fad409a45b25d961f2d89da19
2023-08-03 11:16:41 -05:00
Kittywhiskers Van Gogh
4e9d9a69e8 merge bitcoin#21767: Prune g_chainman usage in auxiliary modules 2023-08-02 10:19:02 -05:00
Kittywhiskers Van Gogh
d97dcb22e1 merge bitcoin#22047: Coinstatsindex follow-ups 2023-08-02 10:19:02 -05:00
Kittywhiskers Van Gogh
040cd922f6 merge bitcoin#19521: Coinstats Index 2023-08-02 10:19:02 -05:00
fanquake
de28a0e10c Merge #20530: lint, refactor: Update cppcheck linter to c++17 and improve explicit usage
1e62350ca20898189904a88dfef9ea11ddcd8626 refactor: Improve use of explicit keyword (Fabian Jahr)
c502a6dbfb854ca827a5a3925394f9e09d29b898 lint: Use c++17 std in cppcheck linter (Fabian Jahr)

Pull request description:

  I found the `extended-lint-cppcheck` linter still uses `std=c++11` when reviewing #20471. The only difference in the output after this change is one line is missing:

  ```
  src/script/descriptor.cpp:159:5: warning: Struct 'PubkeyProvider' has a constructor with 1 argument that is not explicit. [noExplicitConstructor]
  ```

  After some digging, I am still not sure why this one is ignored with c++17 when 40 other`noExplicitConstructor` warnings were still appearing.

  In the second commit, I fix these warnings, adding `explicit` where appropriate and adding fixes to ignore otherwise.

ACKs for top commit:
  practicalswift:
    cr ACK 1e62350ca20898189904a88dfef9ea11ddcd8626: patch looks correct!
  MarcoFalke:
    review ACK 1e62350ca20898189904a88dfef9ea11ddcd8626

Tree-SHA512: dff7b324429a57160e217cf38d9ddbb6e70c6cb3d3e3e0bd4013d88e07afc2292c3df94d0acf7122e9d486322821682ecf15c8f2724a78667764c05d47f89a12
2023-08-01 12:24:36 -05:00
Wladimir J. van der Laan
b25fa7dcb9 Merge #20568: doc: Use FeeModes doc helper in estimatesmartfee
fa8abdc9953e381715493b259908e246914793b0 rpc: Use FeeModes doc helper in estimatesmartfee (MarcoFalke)

Pull request description:

  Not sure why this doesn't use the doc helper, probably an oversight?

ACKs for top commit:
  laanwj:
    Code review ACK fa8abdc9953e381715493b259908e246914793b0

Tree-SHA512: 1f2dc8356e3476ddcf9cafafa7f9865ad95bed1e3067c0edab8e3c483e374bdbdbecc066167554b4a1b479e28f6a52c4ae6a75a70c67ee4e1ff4f3ba36b04001
2023-08-01 12:21:16 -05:00
Odysseas Gabrielides
6bacf5423b
feat: v20 evonodes payment adjustment (#5493)
## Issue being fixed or feature implemented
Since v19, Evo nodes are paid 4x blocks in a row.
This needs to be reverted when MN Reward Reallocation activates.

## What was done?
Starting from MN Reward Reallocation activation, Evo nodes are paid one
block in a row (like regular masternodes).
In addition, `nConsecutivePayments` isn't incremented anymore for Evo
nodes.

## How Has This Been Tested?
`feature_llmq_hpmn.py` with MN Reward Reallocation activation.

## 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>
2023-07-31 23:52:48 -05:00
Konstantin Akimov
9bb1b10871
refactor: improved initialization of members of LLMQContext and related changes (#5150)
LLMQContext uses RAII to initialize all members. Ensured that all
members always initialized correctly in proper order if LLMQContext
exists.

BlockAssembler, CChainState use too many agruments and they are making
wrong assumption that members of LLMQContext can be constructed and used
independently, but that's not true. Instead, let's pass LLMQContext
whenever possible.

## Issue being fixed or feature implemented
https://github.com/dashpay/dash-issues/issues/52

## How Has This Been Tested?
Run unit/functional test and introduce no breaking changes.


## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
2023-07-29 20:23:02 -05:00
Kittywhiskers Van Gogh
d40f28edb4 merge bitcoin#19762: Allow named and positional arguments to be used together 2023-07-28 00:18:27 -05:00
Kittywhiskers Van Gogh
b1643e7c86 merge bitcoin#21575: Create blockstorage module 2023-07-28 00:18:27 -05:00
Kittywhiskers Van Gogh
9307a22117 merge bitcoin#19550: Add getindexinfo RPC 2023-07-28 00:18:27 -05:00
Kittywhiskers Van Gogh
77963ba29d rpc: Prune g_chainman usage within Dash-specific RPC modules 2023-07-28 00:18:27 -05:00
Kittywhiskers Van Gogh
60e93cabeb merge bitcoin#21391: Prune g_chainman usage in RPC modules 2023-07-28 00:18:27 -05:00
thephez
54a8c393cc
chore: correct rpc typo in mempoolentry help (#5512)
## Issue being fixed or feature implemented
RPC help for mempoolentry incorrectly called the "instantsend" field
"time". The "instantsend" and "unbroadcast" fields were also in a
different order than the actual response.

## What was done?
Changed "time" -> "instantsend" and flipped order of
"instantsend"/"unbroadcast"

## How Has This Been Tested?
Built and checked locally

## Breaking Changes
N/A


## 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-07-27 09:46:19 -05:00
Wladimir J. van der Laan
331991b0d0
Merge #20964: rpc: Add specific error code for "wallet already loaded"
a6739cc86827759c543bf81f5532ec46e40549c3 rpc: Add specific error code for "wallet already loaded" (Wladimir J. van der Laan)

Pull request description:

  Add a separate RPC error code for "wallet already loaded" to avoid having to match on message to detect this.
  Requested by shesek for rust-bitcoinrpc.

  If concept ACKed needs:
  - [ ]  Release note
  - [x]  A functional test (updated the existing test to make it pass, I think this is enough)

ACKs for top commit:
  jonasschnelli:
    Code Review ACK a6739cc86827759c543bf81f5532ec46e40549c3
  promag:
    Code review ACK a6739cc86827759c543bf81f5532ec46e40549c3.

Tree-SHA512: 9091872e6ea148aec733705d6af330f72a02f23b936b892ac28f9023da7430af6332418048adbee6014305b812316391812039e9180f7f3362d11f206c13b7d0
2023-07-26 09:37:52 +05:30