You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/release-notes.md
+14-174
Original file line number
Diff line number
Diff line change
@@ -1,13 +1,13 @@
1
-
# Dash Core version v19.0.0
1
+
# Dash Core version v19.1.0
2
2
3
3
Release is now available from:
4
4
5
5
<https://www.dash.org/downloads/#wallets>
6
6
7
-
This is a new major version release, bringing new features, various bugfixes
8
-
and other improvements.
7
+
This is a new minor version release, bringing various bugfixes and other improvements.
9
8
10
-
This release is mandatory for all nodes.
9
+
This release is mandatory for all nodes. This release delays v19 hard fork activation and
10
+
will effectively hard fork the network. v19.0.0 nodes must upgrade to continue syncing properly.
11
11
12
12
Please report bugs using the issue tracker at GitHub:
13
13
@@ -34,184 +34,23 @@ downgrade to an older version is only possible with a reindex
34
34
35
35
## Downgrade warning
36
36
37
+
### Downgrade to a version < v19.1.0
38
+
Downgrading below v19.1.0 is not supported as v19.0.0 will attempt to hard fork, however this hardfork is problematic
39
+
and is being delayed with this version
40
+
37
41
### Downgrade to a version < v19.0.0
38
42
Downgrading to a version older than v19.0.0 is not supported due to changes in the evodb database. If you need to use an older version, you must either reindex or re-sync the whole chain.
39
43
40
44
# Notable changes
41
45
42
-
## High-Performance Masternodes
43
-
44
-
In preparation for the release of Dash Platform to mainnet, a new masternode type has been added. High-performance masternodes will be responsible for hosting Dash Platform services (once they are on mainnet) in addition to the existing responsibilities like ChainLocks and InstantSend.
45
-
46
-
Activation of the DashCore v19.0 hard fork will enable registration of the new 4000 DASH collateral masternodes. Until Dash Platform is released to mainnet, high-performance masternodes will provide the same services as regular masternodes with one small exception. Regular masternodes will no longer participate in the Platform-specific LLMQ after the hard fork since they will not be responsible for hosting Dash Platform.
47
-
48
-
Note: In DashCore v19.0 the relative rewards and voting power are equivalent between regular and high-performance masternodes. Masternodes effectively receive one payout and one governance vote per 1000 DASH collateral. So, there is no difference in reward amount for running four regular masternodes or one high-performance masternode. In v19.0, high-performance masternodes simply receive payments in four consecutive blocks when they are selected for payout. Some frequently asked questions may be found at https://www.dash.org/hpmn-faq/.
49
-
50
-
## BLS Scheme Upgrade
51
-
52
-
Once the v19 hard fork is activated, all remaining messages containing BLS public keys or signatures will serialise them using the new basic BLS scheme.
53
-
The motivation behind this change is the need to be aligned with IETF standards.
54
-
55
-
List of affected messages:
56
-
`dsq`, `dstx`, `mnauth`, `govobj`, `govobjvote`, `qrinfo`, `qsigshare`, `qsigrec`, `isdlock`, `clsig`, and all DKG messages (`qfcommit`, `qcontrib`, `qcomplaint`, `qjustify`, `qpcommit`).
57
-
58
-
### `qfcommit`
59
-
60
-
Once the v19 hard fork is activated, `quorumPublicKey` will be serialised using the basic BLS scheme.
61
-
To support syncing of older blocks containing the transactions using the legacy BLS scheme, the `version` field indicates which scheme to use for serialisation of `quorumPublicKey`.
62
-
63
-
| Version | Version Description | Includes `quorumIndex` field |
| 1 | Serialisation of `sig` using legacy BLS scheme |
108
-
| 2 | Serialisation of `sig` using basic BLS scheme |
109
-
110
-
## Wallet
111
-
112
-
## Automatic wallet creation removed
113
-
114
-
Dash Core will no longer automatically create new wallets on startup. It will
115
-
load existing wallets specified by -wallet options on the command line or in
116
-
dash.conf or settings.json files. And by default it will also load a
117
-
top-level unnamed ("") wallet. However, if specified wallets don't exist,
118
-
Dash Core will now just log warnings instead of creating new wallets with
119
-
new keys and addresses like previous releases did.
120
-
121
-
New wallets can be created through the GUI (which has a more prominent create
122
-
wallet option), through the dash-wallet create command or the createwallet RPC.
123
-
124
-
## P2P and Network Changes
125
-
126
-
## Removal of reject network messages from Dash Core (BIP61)
127
-
128
-
The command line option to enable BIP61 (-enablebip61) has been removed.
129
-
130
-
Nodes on the network can not generally be trusted to send valid ("reject")
131
-
messages, so this should only ever be used when connected to a trusted node.
132
-
Please use the recommended alternatives if you rely on this deprecated feature:
133
-
134
-
- Testing or debugging of implementations of the Dash P2P network protocol
135
-
should be done by inspecting the log messages that are produced by a recent
136
-
version of Dash Core. Dash Core logs debug messages
137
-
(-debug=<category>) to a stream (-printtoconsole) or to a file
138
-
(-debuglogfile=<debug.log>).
139
-
140
-
- Testing the validity of a block can be achieved by specific RPCs:
141
-
- submitblock
142
-
- getblocktemplate with 'mode' set to 'proposal' for blocks with
143
-
- potentially invalid POW
144
-
- Testing the validity of a transaction can be achieved by specific RPCs:
145
-
- sendrawtransaction
146
-
- testmempoolaccept
147
-
148
-
## CoinJoin update
149
-
150
-
A minor update in several CoinJoin-related network messages improves support
151
-
for mixing from SPV clients. These changes make it easier for SPV clients to
152
-
participate in the CoinJoin process by using masternode information they can
153
-
readily obtain and verify via [DIP-0004](https://github.com/dashpay/dips/blob/master/dip-0004.md).
154
-
155
-
## Remote Procedure Call (RPC) Changes
156
-
157
-
### The new RPCs are:
158
-
- In order to support BLS public keys encoded in the legacy BLS scheme, `protx register_legacy`, `protx register_fund_legacy`, and `protx register_prepare_legacy` were added.
159
-
-`cleardiscouraged` clears all the already discouraged peers.
160
-
- The following RPCs were added: `protx register_hpmn`, `protx register_fund_hpmn`, `protx register_prepare_hpmn` and `protx update_service_hpmn`.
161
-
These HPMN RPCs correspond to the standard masternode RPCs but have the following additional mandatory arguments: `platformNodeID`, `platformP2PPort` and `platformHTTPPort`.
162
-
-`upgradewallet`
163
-
164
-
### The removed RPCs are:
165
-
166
-
None
167
-
168
-
### Changes in existing RPCs introduced through bitcoin backports:
169
-
170
-
- The `utxoupdatepsbt` RPC method has been updated to take a descriptors
171
-
argument. When provided, input and output scripts and keys will be filled in
172
-
when known. See the RPC help text for full details.
173
-
174
-
175
-
### Dash-specific changes in existing RPCs:
176
-
177
-
-`masternodelist`: New mode `recent` was added in order to hide banned masternodes for more than one `SuperblockCycle`. If the mode `recent` is used, then the reply mode is JSON (can be additionally filtered)
178
-
-`quorum info`: The new `previousConsecutiveDKGFailures` field will be returned for rotated LLMQs. This field will hold the number of previous consecutive DKG failures for the corresponding quorumIndex before the currently active one. Note: If no previous commitments were found then 0 will be returned for `previousConsecutiveDKGFailures`.
179
-
-`bls generate` and `bls fromsecret`: The new `scheme` field will be returned indicating which scheme was used to serialise the public key. Valid returned values are `legacy` and`basic`.
180
-
-`bls generate` and `bls fromsecret`: Both RPCs accept an incoming optional boolean argument `legacy` that enforces the use of legacy BLS scheme for the serialisation of the reply even if v19 is active.
181
-
-`masternode status`: now returns the type of the masternode.
182
-
-`masternode count`: now returns a detailed summary of total and enabled masternodes per type.
183
-
-`gobject getcurrentvotes`: reply is enriched by adding the vote weight at the end of each line. Possible values are 1 or 4. Example: "7cb20c883c6093b8489f795b3ec0aad0d9c2c2821610ae9ed938baaf42fec66d": "277e6345359071410ab691c21a3a16f8f46c9229c2f8ec8f028c9a95c0f1c0e7-1:1670019339:yes:funding:4"
184
-
- Once the v19 hard fork is activated, `protx register`, `protx register_fund`, and `protx register_prepare` RPCs will decode BLS operator public keys using the new basic BLS scheme.
185
-
186
-
Please check `help <command>` for more detailed information on specific RPCs.
187
-
188
-
## Command-line options
189
-
190
-
A number of command-line option changes were made related to testing and
191
-
removal of BIP61 support.
192
-
193
-
New cmd-line options:
194
-
-`llmqplatform` (devnet only)
195
-
-`unsafesqlitesync`
196
-
197
-
Removed cmd-line options:
198
-
-`enablebip61`
199
-
-`upgradewallet`
200
-
201
-
Changes in existing cmd-line options:
202
-
-`llmqinstantsend` and `llmqinstantsenddip0024` can be used in regtest now
203
-
- Passing an invalid `-rpcauth` argument now cause dashd to fail to start.
204
-
205
-
Please check `Help -> Command-line options` in Qt wallet or `dashd --help` for
206
-
more information.
207
-
208
-
## Backports from Bitcoin Core
46
+
## Delaying v19 Hard Fork
209
47
210
-
This release introduces many updates from Bitcoin v0.18-v0.21 as well as numerous updates from Bitcoin v22 and more recent versions. Bitcoin changes that do not align with Dash’s product needs, such as SegWit and RBF, are excluded from our backporting. For additional detail on what’s included in Bitcoin, please refer to their release notes.
48
+
The start date for the v19 Hard Fork has been delayed until June 14th. The earliest hard fork date will be roughly two
49
+
weeks after that date. A new version will be required before this date to ensure a smooth hard fork.
211
50
212
-
# v19.0.0 Change log
51
+
# v19.1.0 Change log
213
52
214
-
See detailed [set of changes](https://github.com/dashpay/dash/compare/v18.2.2...dashpay:v19.0.0).
53
+
See detailed [set of changes](https://github.com/dashpay/dash/compare/v19.0.0...dashpay:v19.1.0).
215
54
216
55
# Credits
217
56
@@ -250,6 +89,7 @@ Dash Core tree 0.12.1.x was a fork of Bitcoin Core tree 0.12.
250
89
251
90
These release are considered obsolete. Old release notes can be found here:
252
91
92
+
-[v19.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-19.0.0.md) released Apr/14/2023
253
93
-[v18.2.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.2.2.md) released Mar/21/2023
254
94
-[v18.2.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.2.1.md) released Jan/17/2023
255
95
-[v18.2.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-18.2.0.md) released Jan/01/2023
0 commit comments