sikkienl/dash
1
0
Fork 0
mirror of https://github.com/dashpay/dash.git synced 2024-12-27 13:03:17 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
73b37219d4
dash/doc/release-notes.md

92 lines
4.6 KiB
Markdown
Raw Normal View History

doc: Empty release notes for next release Now that 0.9 is branched off, the new release notes for 0.10 or 0.11 or 1.0 should be added here. Edits to preliminary 0.9.0 release notes should be made in the 0.9.0 branch.
2014-03-03 09:41:18 +01:00
(note: this is a temporary file, to be added-to by anybody, and moved to
release-notes at release time)
estimatefee / estimatepriority RPC methods New RPC methods: return an estimate of the fee (or priority) a transaction needs to be likely to confirm in a given number of blocks. Mike Hearn created the first version of this method for estimating fees. It works as follows: For transactions that took 1 to N (I picked N=25) blocks to confirm, keep N buckets with at most 100 entries in each recording the fees-per-kilobyte paid by those transactions. (separate buckets are kept for transactions that confirmed because they are high-priority) The buckets are filled as blocks are found, and are saved/restored in a new fee_estiamtes.dat file in the data directory. A few variations on Mike's initial scheme: To estimate the fee needed for a transaction to confirm in X buckets, all of the samples in all of the buckets are used and a median of all of the data is used to make the estimate. For example, imagine 25 buckets each containing the full 100 entries. Those 2,500 samples are sorted, and the estimate of the fee needed to confirm in the very next block is the 50'th-highest-fee-entry in that sorted list; the estimate of the fee needed to confirm in the next two blocks is the 150'th-highest-fee-entry, etc. That algorithm has the nice property that estimates of how much fee you need to pay to get confirmed in block N will always be greater than or equal to the estimate for block N+1. It would clearly be wrong to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay 12 uBTC and it will take LONGER". A single block will not contribute more than 10 entries to any one bucket, so a single miner and a large block cannot overwhelm the estimates.
2014-03-17 13:19:54 +01:00
doc: Update release process The actual release process quite diverged from what was written here, also clarify things a bit.
2016-04-15 13:21:16 +02:00
Bitcoin Core version *version* is now available from:
<https://bitcoin.org/bin/bitcoin-core-*version*/>
This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.
Please report bugs using the issue tracker at github:
<https://github.com/bitcoin/bitcoin/issues>
To receive security and update notifications, please subscribe to:
<https://bitcoincore.org/en/list/announcements/join/>
doc: Mention Windows XP end of support in release notes Closes #7681.
2016-06-22 16:29:00 +02:00
Compatibility
==============
Trim down the XP notice and say more about what we support. The big notice at the top of the release note is not interesting to most users now and apparently comes across poorly to some. Better to provide more information about what we do support.
2017-01-14 02:21:41 +01:00
Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.
Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support).
No attempt is made to prevent installing or running the software on Windows XP, you
can still do so at your own risk but be aware that there are known instabilities.
Please do not report issues about Windows XP to the issue tracker.
Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.
doc: Mention Windows XP end of support in release notes Closes #7681.
2016-06-22 16:29:00 +02:00
Autoprune release notes included
2015-05-26 21:32:25 +02:00
Notable changes
===============
Update release notes to include RPC error code changes.
2017-03-08 20:23:16 +01:00
Low-level RPC changes
---------------------
- Error codes have been updated to be more accurate for the following error cases:
- `getblock` now returns RPC_MISC_ERROR if the block can't be found on disk (for
example if the block has been pruned). Previously returned RPC_INTERNAL_ERROR.
- `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned
because the node is not in pruned mode. Previously returned RPC_METHOD_NOT_FOUND.
- `pruneblockchain` now returns RPC_INVALID_PARAMETER if the blocks cannot be pruned
because the supplied timestamp is too late. Previously returned RPC_INTERNAL_ERROR.
- `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned
because the blockchain is too short. Previously returned RPC_INTERNAL_ERROR.
- `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the supplied IP address
or subnet is invalid. Previously returned RPC_CLIENT_NODE_ALREADY_ADDED.
- `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the user tries to unban
a node that has not previously been banned. Previously returned RPC_MISC_ERROR.
- `removeprunedfunds` now returns RPC_WALLET_ERROR if bitcoind is unable to remove
the transaction. Previously returned RPC_INTERNAL_ERROR.
- `removeprunedfunds` now returns RPC_INVALID_PARAMETER if the transaction does not
exist in the wallet. Previously returned RPC_INTERNAL_ERROR.
- `fundrawtransaction` now returns RPC_INVALID_ADDRESS_OR_KEY if an invalid change
address is provided. Previously returned RPC_INVALID_PARAMETER.
- `fundrawtransaction` now returns RPC_WALLET_ERROR if bitcoind is unable to create
the transaction. The error message provides further details. Previously returned
RPC_INTERNAL_ERROR.
- `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has
descendants in the wallet. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has
descendants in the mempool. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has
has been mined or conflicts with a mined transaction. Previously returned
RPC_INVALID_ADDRESS_OR_KEY.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction is not
BIP 125 replaceable. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has already
been bumped by a different transaction. Previously returned RPC_INVALID_REQUEST.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction contains
inputs which don't belong to this wallet. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has multiple change
outputs. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has no change
output. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the fee is too high. Previously returned
RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the fee is too low. Previously returned
RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the change output is too small to bump the
fee. Previously returned RPC_MISC_ERROR.
doc: Clean out release notes Now that 0.13 has branched, release notes for 0.13 should be maintained there, and the release notes file on master is for 0.14 release notes.
2016-07-18 14:00:05 +02:00
Credits
=======
Thanks to everyone who directly contributed to this release:
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
Reference in New Issue Copy Permalink