From 7613d3c4332c73012f30c13d4fab7a0fda4d8f4d Mon Sep 17 00:00:00 2001 From: fanquake Date: Fri, 6 Nov 2020 15:34:44 +0800 Subject: [PATCH 01/13] Merge #20298: macOS deploy: use the new plistlib API 04a69c200e0d18ae63c7e47898f85d1b4cb5c23d macOS deploy: use the new plistlib API (Jonas Schnelli) Pull request description: See https://docs.python.org/3/library/plistlib.html. The old API was deprecated in 3.4 and removed in 3.9. ~~AFAIK the macdeployplus scripts is only used when calling `make deploy` locally (on macOS). The linux cross compile build (like gitian) are not affected by this PR.~~ ACKs for top commit: fanquake: ACK 04a69c200e0d18ae63c7e47898f85d1b4cb5c23d - I checked that `make deploy` on macOS currently fails when building master and using Python 3.9. This PR fixes that, and it's fine to use (and backport) these changes as they only require Python 3.4. Related note: I think we could just about drop our native_biplist dependency entirely given some changes upstream. practicalswift: ACK 04a69c200e0d18ae63c7e47898f85d1b4cb5c23d: patch looks correct Tree-SHA512: c5bb60c5157b371d680c82e0978470a488f3edc58cd09e1be635fed59420f227dd113e901c28e15a463da6fe81dc64d08a701b1fdfeb4502f418785707dbebbc --- contrib/macdeploy/macdeployqtplus | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contrib/macdeploy/macdeployqtplus b/contrib/macdeploy/macdeployqtplus index ce1203f0f0..fe6b3456b9 100755 --- a/contrib/macdeploy/macdeployqtplus +++ b/contrib/macdeploy/macdeployqtplus @@ -544,7 +544,8 @@ if len(config.fancy) == 1: sys.exit(1) try: - fancy = plistlib.readPlist(p) + with open(p, 'rb') as fp: + fancy = plistlib.load(fp, fmt=plistlib.FMT_XML) except: if verbose >= 1: sys.stderr.write("Error: Could not parse fancy disk image plist at \"%s\"\n" % (p)) From e8a9c28c823cc7907f54cdc49a1da2baab72630a Mon Sep 17 00:00:00 2001 From: Jonas Schnelli Date: Fri, 13 Nov 2020 08:26:50 +0100 Subject: [PATCH 02/13] Merge #20378: wallet: fix potential division by 0 in WalletLogPrintf 440f8d3abe97b96f434dad5216d417a08fc10253 fix potential devision by 0 (Jonas Schnelli) Pull request description: #20344 removed the divide-by-zero sanitizer suppression in `wallet/wallet.cpp` but kept a potential devision by zero in `wallet.cpp`'s fee logging. Detected here https://bitcoinbuilds.org/index.php?job=ffb7d59f-379f-4f27-a273-a5595b8c5f07 ACKs for top commit: practicalswift: ACK 440f8d3abe97b96f434dad5216d417a08fc10253 laanwj: Code review ACK 440f8d3abe97b96f434dad5216d417a08fc10253 hebasto: re-ACK 440f8d3abe97b96f434dad5216d417a08fc10253 Tree-SHA512: 9f7903d1e567497c5f972d39e9629c059151e705dbed0a6b88f7c6650c50ecf820f78e3e0f3e629c661d45a938c5d7659faae7c61e47ca8b3bdb029661bca55a --- src/wallet/wallet.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/wallet/wallet.cpp b/src/wallet/wallet.cpp index 9f696abd79..6d30528cfd 100644 --- a/src/wallet/wallet.cpp +++ b/src/wallet/wallet.cpp @@ -3937,10 +3937,10 @@ bool CWallet::CreateTransaction(const std::vector& vecSend, CTransac WalletLogPrintf("Fee Calculation: Fee:%d Bytes:%u Tgt:%d (requested %d) Reason:\"%s\" Decay %.5f: Estimation: (%g - %g) %.2f%% %.1f/(%.1f %d mem %.1f out) Fail: (%g - %g) %.2f%% %.1f/(%.1f %d mem %.1f out)\n", nFeeRet, nBytes, feeCalc.returnedTarget, feeCalc.desiredTarget, StringForFeeReason(feeCalc.reason), feeCalc.est.decay, feeCalc.est.pass.start, feeCalc.est.pass.end, - 100 * feeCalc.est.pass.withinTarget / (feeCalc.est.pass.totalConfirmed + feeCalc.est.pass.inMempool + feeCalc.est.pass.leftMempool), + (feeCalc.est.pass.totalConfirmed + feeCalc.est.pass.inMempool + feeCalc.est.pass.leftMempool) > 0.0 ? 100 * feeCalc.est.pass.withinTarget / (feeCalc.est.pass.totalConfirmed + feeCalc.est.pass.inMempool + feeCalc.est.pass.leftMempool) : 0.0, feeCalc.est.pass.withinTarget, feeCalc.est.pass.totalConfirmed, feeCalc.est.pass.inMempool, feeCalc.est.pass.leftMempool, feeCalc.est.fail.start, feeCalc.est.fail.end, - 100 * feeCalc.est.fail.withinTarget / (feeCalc.est.fail.totalConfirmed + feeCalc.est.fail.inMempool + feeCalc.est.fail.leftMempool), + (feeCalc.est.fail.totalConfirmed + feeCalc.est.fail.inMempool + feeCalc.est.fail.leftMempool) > 0.0 ? 100 * feeCalc.est.fail.withinTarget / (feeCalc.est.fail.totalConfirmed + feeCalc.est.fail.inMempool + feeCalc.est.fail.leftMempool) : 0.0, feeCalc.est.fail.withinTarget, feeCalc.est.fail.totalConfirmed, feeCalc.est.fail.inMempool, feeCalc.est.fail.leftMempool); return true; } From f2f4a8f085f7c698796d6647ea5757aa99e9d15c Mon Sep 17 00:00:00 2001 From: fanquake Date: Tue, 17 Nov 2020 13:56:11 +0800 Subject: [PATCH 03/13] Merge #20405: p2p: avoid calculating onion address checksum when version is not 3 d355a302d9b7e4aaac04edaa0671ced3b3eaef45 Break circuit earlier (lontivero) Pull request description: Currently when parsing an onion v3 address the pubic key checksum is calculated in order to compare it with the received address checksum. However this step is not necessary if the address version byte is not 3, in which case the method can return with false immediately. ACKs for top commit: jonatack: ACK d355a302d9b7e4aaac04edaa0671ced3b3eaef45 practicalswift: ACK d355a302d9b7e4aaac04edaa0671ced3b3eaef45 -- patch looks correct hebasto: ACK d355a302d9b7e4aaac04edaa0671ced3b3eaef45, I have reviewed the code and it looks OK, I agree it can be merged. sipa: utACK d355a302d9b7e4aaac04edaa0671ced3b3eaef45 Tree-SHA512: 9e4506793b7f4a62ce8edc41a260a8c125ae81ed2f90cd850eb2a9214d323c446edc7586c7b0590dcbf3aed5be534718b77bb19c45b48f8f52553d32a3663a65 --- src/netaddress.cpp | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/netaddress.cpp b/src/netaddress.cpp index 4d43550ba8..9129474955 100644 --- a/src/netaddress.cpp +++ b/src/netaddress.cpp @@ -257,10 +257,14 @@ bool CNetAddr::SetSpecial(const std::string& str) Span input_checksum{input.data() + ADDR_TORV3_SIZE, torv3::CHECKSUM_LEN}; Span input_version{input.data() + ADDR_TORV3_SIZE + torv3::CHECKSUM_LEN, sizeof(torv3::VERSION)}; + if (input_version != torv3::VERSION) { + return false; + } + uint8_t calculated_checksum[torv3::CHECKSUM_LEN]; torv3::Checksum(input_pubkey, calculated_checksum); - if (input_checksum != calculated_checksum || input_version != torv3::VERSION) { + if (input_checksum != calculated_checksum) { return false; } From a9b5723556d112829f61d8da4093dbe2fc2cb685 Mon Sep 17 00:00:00 2001 From: "Wladimir J. van der Laan" Date: Thu, 19 Nov 2020 11:44:25 +0100 Subject: [PATCH 04/13] Merge #19968: doc: clarify CRollingBloomFilter size estimate d9141a0002bb508b2e94e206a1bd28ef8f97ffde doc: clarify CRollingBloomFilter size estimate (Anthony Towns) Pull request description: Based on #19130, this change improves the comment for `CRollingBloomFilter` in `bloom.h`: - Give examples to illustrate the heuristic "1.8 bytes per element per factor 0.1 of false positive rate" - Add some Python code which can be copy/pasted for convenient filter size calculation (in an interpreter) - Reconcile the newly added code with the existing approximation ACKs for top commit: laanwj: ACK d9141a0002bb508b2e94e206a1bd28ef8f97ffde Tree-SHA512: e7138b3c531883a750ead06368975c750863fde7ef6f2633b137eca011079226e9205316217322014399fba05a48f294c788dd700bb7d479c58fe1f23e40419f --- src/bloom.h | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/bloom.h b/src/bloom.h index e808a265fe..981fa4251d 100644 --- a/src/bloom.h +++ b/src/bloom.h @@ -109,7 +109,18 @@ public: * insert()'ed ... but may also return true for items that were not inserted. * * It needs around 1.8 bytes per element per factor 0.1 of false positive rate. - * (More accurately: 3/(log(256)*log(2)) * log(1/fpRate) * nElements bytes) + * For example, if we want 1000 elements, we'd need: + * - ~1800 bytes for a false positive rate of 0.1 + * - ~3600 bytes for a false positive rate of 0.01 + * - ~5400 bytes for a false positive rate of 0.001 + * + * If we make these simplifying assumptions: + * - logFpRate / log(0.5) doesn't get rounded or clamped in the nHashFuncs calculation + * - nElements is even, so that nEntriesPerGeneration == nElements / 2 + * + * Then we get a more accurate estimate for filter bytes: + * + * 3/(log(256)*log(2)) * log(1/fpRate) * nElements */ class CRollingBloomFilter { From d40eedbf01c207345d8be72eb4e37ec7329bff37 Mon Sep 17 00:00:00 2001 From: MarcoFalke Date: Thu, 17 Dec 2020 10:00:34 +0100 Subject: [PATCH 05/13] Merge #19050: doc: Add warning for rest interface limitation 5c3eaf9983043db1b61a98c95d692a6958670b86 doc: Add warnings for http interfaces limitations (Fabian Jahr) Pull request description: `libevent`, which is used for our rest interface, can use up all of the available file descriptors in a system if too many connections are opened at once. If a new block is connected at the same time and can not be written to disk because there are no file descriptors available, the node crashes. Based on my investigation so far the issue is best solved upstream which means we have to wait for the next release (2.2). In the meantime it would be good if we would warn users of this limitation. See #11368 for more background. ACKs for top commit: MarcoFalke: ACK 5c3eaf9983043db1b61a98c95d692a6958670b86 Tree-SHA512: 73914538588477ead19068f5832fdcc8e0eb736e51f73b3aca501c93165e5ad634c2511a3fcffff251adcd3efda23a742b48211ad9d3b2a29cdeac17201d06a1 --- doc/JSON-RPC-interface.md | 11 +++++++++++ doc/REST-interface.md | 12 ++++++++++++ 2 files changed, 23 insertions(+) diff --git a/doc/JSON-RPC-interface.md b/doc/JSON-RPC-interface.md index 42d784a400..491bde26f9 100644 --- a/doc/JSON-RPC-interface.md +++ b/doc/JSON-RPC-interface.md @@ -34,3 +34,14 @@ wallet would reflect the removal of these mempool transactions in the state. However, the wallet may not be up-to-date with the current state of the mempool or the state of the mempool by an RPC that returned before this RPC. + +## Limitations + +There is a known issue in the JSON-RPC interface that can cause a node to crash if +too many http connections are being opened at the same time because the system runs +out of available file descriptors. To prevent this from happening you might +want to increase the number of maximum allowed file descriptors in your system +and try to prevent opening too many connections to your JSON-RPC interface at the +same time if this is under your control. It is hard to give general advice +since this depends on your system but if you make several hundred requests at +once you are definitely at risk of encountering this issue. diff --git a/doc/REST-interface.md b/doc/REST-interface.md index 1611bea7df..985fb4690c 100644 --- a/doc/REST-interface.md +++ b/doc/REST-interface.md @@ -11,6 +11,18 @@ REST Interface consistency guarantees The [same guarantees as for the RPC Interface](/doc/JSON-RPC-interface.md#rpc-consistency-guarantees) apply. +Limitations +----------- + +There is a known issue in the REST interface that can cause a node to crash if +too many http connections are being opened at the same time because the system runs +out of available file descriptors. To prevent this from happening you might +want to increase the number of maximum allowed file descriptors in your system +and try to prevent opening too many connections to your rest interface at the +same time if this is under your control. It is hard to give general advice +since this depends on your system but if you make several hundred requests at +once you are definitely at risk of encountering this issue. + Supported API ------------- From 5a7e219d81200939230fe69a002084db72026e3c Mon Sep 17 00:00:00 2001 From: MarcoFalke Date: Sun, 14 Feb 2021 09:48:28 +0100 Subject: [PATCH 06/13] Merge #20986: docs: update developer notes to discourage very long lines aa929abf8dc022e900755234c857541faeea8239 [docs] Update developer notes to discourage very long lines (John Newbery) Pull request description: Mandatory rules on line lengths are bad - there will always be cases where a longer line is more readable than the alternative. However, very long lines for no good reason _do_ hurt readability. For example, this declaration in validation.h is 274 chars: ```c++ bool ConnectTip(BlockValidationState& state, const CChainParams& chainparams, CBlockIndex* pindexNew, const std::shared_ptr& pblock, ConnectTrace& connectTrace, DisconnectedBlockTransactions& disconnectpool) EXCLUSIVE_LOCKS_REQUIRED(cs_main, m_mempool.cs); ``` That won't fit on one line without wrapping on my 27" monitor with a comfortable font size. Much easier to read is something like: ```c++ bool ConnectTip(BlockValidationState& state, const CChainParams& chainparams, CBlockIndex* pindexNew, const std::shared_ptr& pblock, ConnectTrace& connectTrace, DisconnectedBlockTransactions& disconnectpool) EXCLUSIVE_LOCKS_REQUIRED(cs_main, m_mempool.cs); ``` Therefore, _discourage_ (don't forbid) line lengths greater than 100 characters in our developer style guide. 100 chars is somewhat arbitrary. The old standard was 80, but that seems very limiting with modern displays. ACKs for top commit: fanquake: ACK aa929abf8dc022e900755234c857541faeea8239 - this is basically just something to point too when a PR has unreasonably long lines for no particularly reason. practicalswift: ACK aa929abf8dc022e900755234c857541faeea8239 amitiuttarwar: ACK aa929abf8dc022e900755234c857541faeea8239 theStack: ACK aa929abf8dc022e900755234c857541faeea8239 glozow: ACK https://github.com/bitcoin/bitcoin/commit/aa929abf8dc022e900755234c857541faeea8239 Tree-SHA512: 17f1b11f811137497ede8851ede93fa612dc622922b5ad7ac8f065ea026d9a718db5b92325754b74d24012b4d45c4e2cd5cd439a6a8d34bbabf5da927d783970 --- doc/developer-notes.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/doc/developer-notes.md b/doc/developer-notes.md index d265508fd0..9e13bf4ff8 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -66,6 +66,11 @@ tool to clean up patches automatically before submission. on the same line as the `if`, without braces. In every other case, braces are required, and the `then` and `else` clauses must appear correctly indented on a new line. + - There's no hard limit on line width, but prefer to keep lines to <100 + characters if doing so does not decrease readability. Break up long + function declarations over multiple lines using the Clang Format + [AlignAfterOpenBracket](https://clang.llvm.org/docs/ClangFormatStyleOptions.html) + style option. - **Symbol naming conventions**. These are preferred in new code, but are not required when doing so would need changes to significant pieces of existing From 0dcf7e35791f7d2e1cc68ceb44c84d5aef8bdc82 Mon Sep 17 00:00:00 2001 From: fanquake Date: Tue, 23 Feb 2021 10:54:03 +0800 Subject: [PATCH 07/13] Merge #21263: doc: Clarify that squashing should happen before review fa1f3a26a7541ba82a28c2a5fd09401be825c888 doc: Clarify that squashing should happen before review (MarcoFalke) Pull request description: Unlike other repos, in our repo code review happens before merge, ideally. Thus, rebases, solving merge conflicts and squashing should happen before review, which again happens before merge. ACKs for top commit: theStack: ACK fa1f3a26a7541ba82a28c2a5fd09401be825c888 fanquake: ACK fa1f3a26a7541ba82a28c2a5fd09401be825c888 Tree-SHA512: e9222191a6e9cf9867bd1f29982526dd7b746b70dd2cc94f485256ec98ff2d3941c9b40728935e151d13795239334e334b71ad41044909cb2849f57776811a94 --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7f2b853007..5072d4194e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -109,7 +109,7 @@ Note: Code review is a burdensome but important part of the development process, If your pull request contains fixup commits (commits that change the same line of code repeatedly) or too fine-grained commits, you may be asked to [squash](https://git-scm.com/docs/git-rebase#_interactive_mode) your commits -before it will be merged. The basic squashing workflow is shown below. +before it will be reviewed. The basic squashing workflow is shown below. git checkout your_branch_name git rebase -i HEAD~n From 9ff78a0644b941d430d231303377e7727311e40c Mon Sep 17 00:00:00 2001 From: MarcoFalke Date: Fri, 19 Mar 2021 20:00:43 +0100 Subject: [PATCH 08/13] Merge #21481: doc: Tell howto install clang-format on Debian/Ubuntu ea76f4ac7d6e8c268d301d7ae6c8d4d8d804d55f Doc: Tell howto install clang-format on Debian/Ubuntu (wodry) Pull request description: Because only macOS wasy mentioned, I was unsure if this would be a macOS specific tool. I guess Linux is more used than Mac, so Linux guide should be there, too. ACKs for top commit: hebasto: ACK ea76f4ac7d6e8c268d301d7ae6c8d4d8d804d55f, every system upgrade via clean installation I do the same. Tree-SHA512: 75c28540e8815cb41f4cf92784b6349978988b679e4deef9ae77ede951f93516ca13ec7b313ab72865b01273e115b49ed2b67cdcd68015af1b643a6186b190dd --- contrib/devtools/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contrib/devtools/README.md b/contrib/devtools/README.md index 39e14c4452..9d5aed0efe 100644 --- a/contrib/devtools/README.md +++ b/contrib/devtools/README.md @@ -7,7 +7,8 @@ clang-format-diff.py A script to format unified git diffs according to [.clang-format](../../src/.clang-format). -Requires `clang-format`, installed e.g. via `brew install clang-format` on macOS. +Requires `clang-format`, installed e.g. via `brew install clang-format` on macOS, +or `sudo apt install clang-format` on Debian/Ubuntu. For instance, to format the last commit with 0 lines of context, the script should be called from the git root folder as follows. From cfd9a8929863d5d5ae702706b0b4291f98c943fd Mon Sep 17 00:00:00 2001 From: MarcoFalke Date: Tue, 23 Mar 2021 11:10:58 +0100 Subject: [PATCH 09/13] Merge #18030: doc: Coin::IsSpent() can also mean never existed 1404c574037da331c233317618b9b90d3329ed33 [doc] Coin: explain that IsSpent() can also mean never existed (Sjors Provoost) Pull request description: This can be especially confusing where `AccessCoin()` is used with logic like this: ```c++ while (iter.n < MAX_OUTPUTS_PER_BLOCK) { const Coin& alternate = view.AccessCoin(iter); if (!alternate.IsSpent()) return alternate; ``` ACKs for top commit: practicalswift: ACK 1404c574037da331c233317618b9b90d3329ed33 MarcoFalke: ACK 1404c574037da331c233317618b9b90d3329ed33 jnewbery: utACK 1404c574037da331c233317618b9b90d3329ed33 Tree-SHA512: 418618dd7e08bd5cc8360e3501d0f57e34100e5101ad3b8e0a819923fa860f44c7f2fada0f8447a1af3c2601fd72bfe619b91ff2f26f7133ceaeb0c98b017b12 --- src/coins.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/coins.h b/src/coins.h index dc34309798..e7995f9641 100644 --- a/src/coins.h +++ b/src/coins.h @@ -72,6 +72,9 @@ public: ::Unserialize(s, Using(out)); } + /** Either this coin never existed (see e.g. coinEmpty in coins.cpp), or it + * did exist and has been spent. + */ bool IsSpent() const { return out.IsNull(); } From 289c8772a8448c580753b3313d6e3f9f7c64c963 Mon Sep 17 00:00:00 2001 From: MarcoFalke Date: Thu, 10 Jun 2021 07:38:18 +0200 Subject: [PATCH 10/13] Merge bitcoin/bitcoin#22204: doc: remove obsolete `okSafeMode` RPC guideline from developer notes 6780a095d8526a46c3c2b20a14831687e9fc2462 doc: remove obsolete `okSafeMode` RPC guideline from developer notes (Sebastian Falbesoner) Pull request description: Since the flag has been removed from the RPC command table in commit ec6902d0ea2bbe75179684fc71849d5e34647a14 (PR #11179), this guideline is not relevant anymore and can be removed. ACKs for top commit: MarcoFalke: ACK 6780a095d8526a46c3c2b20a14831687e9fc2462. Also, safe mode was removed completely in commit 2ae705d84178fb9faa49f92091206e92379a2c63 Tree-SHA512: 2a6b002ae302e979ce403171b79a892e32f5083792c3b0b8204edb5eb08c6b24ab77bbeeae0e3bb6d6564a6f1678cfce00eb7b5b82063b7741f89a96b0c0aef3 --- doc/developer-notes.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/doc/developer-notes.md b/doc/developer-notes.md index 9e13bf4ff8..f0c531e90e 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -908,13 +908,6 @@ A few guidelines for introducing and reviewing new RPC interfaces: - *Rationale*: If not, the call can not be used with name-based arguments. -- Set okSafeMode in the RPC command table to a sensible value: safe mode is when the - blockchain is regarded to be in a confused state, and the client deems it unsafe to - do anything irreversible such as send. Anything that just queries should be permitted. - - - *Rationale*: Troubleshooting a node in safe mode is difficult if half the - RPCs don't work. - - Add every non-string RPC argument `(method, idx, name)` to the table `vRPCConvertParams` in `rpc/client.cpp`. - *Rationale*: `dash-cli` and the GUI debug console use this table to determine how to From 8bf157ee8071dab74a566e03ad23ee6a0a3d68c3 Mon Sep 17 00:00:00 2001 From: MarcoFalke Date: Mon, 31 May 2021 13:59:49 +0200 Subject: [PATCH 11/13] Merge bitcoin/bitcoin#22080: doc: add maxuploadtarget to bitcoin.conf example 947f9734daab4e47c0abdc6ef7d52812102ecb6b doc: add maxuploadtarget to bitcoin.conf example (apitko) Pull request description: picking up #21499, author has stated they [can't squash](https://github.com/bitcoin/bitcoin/pull/21499#issuecomment-849277632). This adds the maxuploadtarget option to the `bitcoin.conf` example file. This is useful for those looking to configure their bandwidth utilization. **Changes from Original PR:** - squash commits - fix typo in commit message + reword commit message to be more appropriate - Implement review suggestions ([1](https://github.com/bitcoin/bitcoin/pull/21499#discussion_r615409982), [2](https://github.com/bitcoin/bitcoin/pull/21499#discussion_r615410337), [3](https://github.com/bitcoin/bitcoin/pull/21499#pullrequestreview-659357756)) - Fix spacing ACKs for top commit: jonatack: ACK 947f9734daab4e47c0abdc6ef7d52812102ecb6b theStack: re-ACK 947f9734daab4e47c0abdc6ef7d52812102ecb6b Tree-SHA512: 658ce6e1f204cd1c1c6f8977fd46ba1631f417d3f492e6d777b0ca49ffecc2ecfa4fbd86ca0e08c0dd5d6df4e32f0b56693e0a71bd7eafafd019e93bbcf9420f --- contrib/debian/examples/dash.conf | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/contrib/debian/examples/dash.conf b/contrib/debian/examples/dash.conf index 28478ff6f4..917699c336 100644 --- a/contrib/debian/examples/dash.conf +++ b/contrib/debian/examples/dash.conf @@ -56,6 +56,12 @@ # Maximum number of inbound+outbound connections. #maxconnections= +# Maximum upload bandwidth target in MiB per day (e.g. 'maxuploadtarget=1024' is 1 GiB per day). +# This limits the upload bandwidth for those with bandwidth limits. 0 = no limit (default: 0). +# -maxuploadtarget does not apply to peers with 'download' permission. +# For more information on reducing bandwidth utilization, see: doc/reduce-traffic.md. +#maxuploadtarget= + # # JSON-RPC options (for controlling a running Dash/dashd process) # From 7cfcb9a74c550d53e5c3097f029a40941bbfdf79 Mon Sep 17 00:00:00 2001 From: "Wladimir J. van der Laan" Date: Thu, 19 Nov 2020 15:28:37 +0100 Subject: [PATCH 12/13] Merge #20024: init: Fix incorrect warning "Reducing -maxconnections from N to N-1, because of system limitations" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ea93bbeb26948c0ddba39b589bd166eaecf446c8 init: Fix incorrect warning "Reducing -maxconnections from N to N-1, because of system limitations" (practicalswift) Pull request description: Fix incorrect warning `Reducing -maxconnections from N to N-1, because of system limitations`. Before this patch (only the first warning is correct): ``` $ src/bitcoind -maxconnections=10000000 | grep Warning 2020-09-26T01:23:45Z Warning: Reducing -maxconnections from 10000000 to 1048417, because of system limitations. $ src/bitcoind -maxconnections=1000000 | grep Warning 2020-09-26T01:23:45Z Warning: Reducing -maxconnections from 1000000 to 999999, because of system limitations. $ src/bitcoind -maxconnections=100000 | grep Warning 2020-09-26T01:23:45Z Warning: Reducing -maxconnections from 100000 to 99999, because of system limitations. $ src/bitcoind -maxconnections=10000 | grep Warning 2020-09-26T01:23:45Z Warning: Reducing -maxconnections from 10000 to 9999, because of system limitations. $ src/bitcoind -maxconnections=1000 | grep Warning 2020-09-26T01:23:45Z Warning: Reducing -maxconnections from 1000 to 999, because of system limitations. $ src/bitcoind -maxconnections=100 | grep Warning [no warning] ``` After this patch (no incorrect warnings): ``` $ src/bitcoind -maxconnections=10000000 | grep Warning 2020-09-26T01:23:45Z Warning: Reducing -maxconnections from 10000000 to 1048417, because of system limitations. $ src/bitcoind -maxconnections=1000000 | grep Warning [no warning] $ src/bitcoind -maxconnections=100000 | grep Warning [no warning] $ src/bitcoind -maxconnections=10000 | grep Warning [no warning] $ src/bitcoind -maxconnections=1000 | grep Warning [no warning] $ src/bitcoind -maxconnections=100 | grep Warning [no warning] ``` ACKs for top commit: n-thumann: tACK https://github.com/bitcoin/bitcoin/pull/20024/commits/ea93bbeb26948c0ddba39b589bd166eaecf446c8, Ran on other systems running Debian 10.5 (4.19.0-8-amd64) and Debian bullseye/sid (5.3.0-1-amd64) and was able to reproduce the issue exactly as you described above on both of them. After applying your patch the issue is fixed :v: laanwj: Code review ACK ea93bbeb26948c0ddba39b589bd166eaecf446c8 theStack: tACK ea93bbeb26948c0ddba39b589bd166eaecf446c8 Tree-SHA512: 9b0939a1a51fdf991d11024a5d20b4f39cab1a80320b799a1d24d0250aa059666bcb1ae6dd79c941c2f2686f07f59fc0f6618b5746aa8ca6011fdd202828a930 --- src/init.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/init.cpp b/src/init.cpp index b5e35c4e25..738f0af111 100644 --- a/src/init.cpp +++ b/src/init.cpp @@ -1284,7 +1284,7 @@ bool AppInitParameterInteraction() // Trim requested connection counts, to fit into system limitations // in std::min(...) to work around FreeBSD compilation issue described in #2695 - nFD = RaiseFileDescriptorLimit(nMaxConnections + MIN_CORE_FILEDESCRIPTORS + MAX_ADDNODE_CONNECTIONS); + nFD = RaiseFileDescriptorLimit(nMaxConnections + MIN_CORE_FILEDESCRIPTORS + MAX_ADDNODE_CONNECTIONS + nBind); #ifdef USE_POLL int fd_max = nFD; #else From 76b337b35f9778a449b467ad3e3a636df76b75d0 Mon Sep 17 00:00:00 2001 From: Jonas Schnelli Date: Fri, 20 Nov 2020 09:34:41 +0100 Subject: [PATCH 13/13] Merge bitcoin-core/gui#21: Update pruning tooltip, original author BitcoinErrorLog 2fc5efc55c886f1b874ce6cd02c9082b5bb6435a Update pruning tooltip, original author BitcoinErrorLog (Riccardo Spagni) Pull request description: Squashed commits from BitcoinErrorLog at his request, per the original discussion on #15: this tooltip has been adjusted to be more user-friendly and reflect what the net effect of pruning is for the user. ACKs for top commit: harding: Untested ACK 2fc5efc55c886f1b874ce6cd02c9082b5bb6435a Sjors: utACK 2fc5efc55c886f1b874ce6cd02c9082b5bb6435a and welcome to the dark side! jonasschnelli: ACK 2fc5efc55c886f1b874ce6cd02c9082b5bb6435a Tree-SHA512: 45d6a7efbf4d34d20b9de439c988a39c739591b854726b6682c4cffcb23dff7d9131afab572fa0c9a8bc033c46c3878efdfbf8a984aafde632e1dfc1caa1cbbb --- src/qt/forms/optionsdialog.ui | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qt/forms/optionsdialog.ui b/src/qt/forms/optionsdialog.ui index bf786a692d..896aa31312 100644 --- a/src/qt/forms/optionsdialog.ui +++ b/src/qt/forms/optionsdialog.ui @@ -164,7 +164,7 @@ - Disables some advanced features but all blocks will still be fully validated. Reverting this setting requires re-downloading the entire blockchain. Actual disk usage may be somewhat higher. + Enabling pruning significantly reduces the disk space required to store transactions. All blocks are still fully validated. Reverting this setting requires re-downloading the entire blockchain. Prune &block storage to