aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-12-11Add RPC Whitelist Feature from #12248Jeremy Rubin
2019-11-18Merge #17136: tests: Add fuzzing harness for various PSBT related functionsMarcoFalke
49f4c7f0699e5e19ac6e41ef5b607392dd7a2983 tests: Add fuzzing harness for various PSBT related functions (practicalswift) Pull request description: Add fuzzing harness for various PSBT related functions. **Testing this PR** Run: ``` $ CC=clang CXX=clang++ ./configure --enable-fuzz \ --with-sanitizers=address,fuzzer,undefined $ make $ src/test/fuzz/psbt ``` ACKs for top commit: MarcoFalke: re-ACK 49f4c7f0699e5e19ac6e41ef5b607392dd7a2983 🐟 Tree-SHA512: 4cebe62bd8c244ee40a43e829f5bd175ab40e1dfbbab1affb1529374858225820d6c9fa9ba45862bf56c1522845422fd96d620cedbdec52a67ac1449dec4e1b2
2019-11-18tests: Add fuzzing harness for various PSBT related functionspracticalswift
2019-11-18Merge #17503: doc: Remove bitness from bitcoin-qt help message and manpageMarcoFalke
e161bc74d24a381c313aecb950d3b8411e0ed19d doc: Remove bitness from bitcoin-qt help message and manpage (Wladimir J. van der Laan) Pull request description: Remove the `(64-bit)` from the bitcoin-qt help message. Since removing the Windows 32-bit builds, it is no longer information that is often useful for troubleshooting. This never worked for other architectures than x86, and the only 32-bit x86 build left is the Linux one. Linux users tend to know what architecture they are using. It also accidentally ends up in the bitcoin-qt manpage (if you happen to be generating them on a x86 machine), which gets checked in. See for example https://github.com/bitcoin/bitcoin/commit/1bc9988993ee84bc814e5a7f33cc90f670a19f6a#diff-e4b84be382c8ea33b83203ceb8c85296 ACKs for top commit: practicalswift: ACK e161bc74d24a381c313aecb950d3b8411e0ed19d -- rationale makes sense and diff looks correct :) MarcoFalke: Tested ACK e161bc74d24a381c313aecb950d3b8411e0ed19d 🔮 Tree-SHA512: d38754903252896dc86fac6c12ad6615d322c2744db7c02b18574a08c69e8876b2c905e1f09b324002236b111ee93479f89769c562e7b3b2e6eb2992d76464ef
2019-11-18Merge #16669: build: use new fork of osslsigncode for windows gitian signingWladimir J. van der Laan
feb507577797518d0bee1774327d215e19d1ba34 build: use osslsigncode 2.0 in gitian (fanquake) Pull request description: The original osslsigncode project, https://sourceforge.net/projects/osslsigncode, has been marked as abandonware: > This is now - and has been for a long while - abandonware. Feel free to create your own forks etc.". However, a fork has emerged, https://github.com/mtrojnar/osslsigncode, that has incorporated theuni's patches ([add the -pem option in extract-signature mode ](https://github.com/mtrojnar/osslsigncode/commit/36715c11836d07709aff822154a0eed2c43ed5a5) & [add the attach-signature command](https://github.com/mtrojnar/osslsigncode/commit/3be7eb1676a8af8afd9e0aa03e4cac651da14c23)) as well as updated the tool to work with OpenSSL 1.1 and other improvements. This commit switches the windows signer descriptor to use this new version of `osslsigncode`. I've tested using this new version of `osslsigncode` while doing a 0.18.1 gitian build, and it "seems" to work. However this needs a look over from Cory, to check if the tool is still compatible with his usage in the [`detached-sig-create.sh`](https://github.com/bitcoin/bitcoin/blob/master/contrib/windeploy/detached-sig-create.sh) script, as well as some review of the changes to `osslsigncode` itself. Hence WIP and chasing Concept ACKs / NACKs. ACKs for top commit: MarcoFalke: Concept ACK feb507577797518d0bee1774327d215e19d1ba34 given that this upstream is now used in Ubuntu and Debian laanwj: ACK feb507577797518d0bee1774327d215e19d1ba34 Tree-SHA512: c48de6dc32751d96dd04b920bfacca40af47a2883330ba0700371d56c580a7e45cedd8d8a913709d56be036762b63cb1825a98cff7aa77b6d7804fab11220850
2019-11-18Merge #17488: test: fix "bitcoind already running" warnings on macOSWladimir J. van der Laan
1c23ea5fe67b88fd72a1ff640dd1bbb21a34fbf4 test: fix bitcoind already running warnings on macOS (fanquake) Pull request description: On macOS, `pidof` installed via brew returns b'' rather than None. Account for this, to remove spurious warnings from the test_runner. ACKs for top commit: laanwj: ACK 1c23ea5fe67b88fd72a1ff640dd1bbb21a34fbf4 Tree-SHA512: 640f4323d4105eac5c7abb52daf80486d5d3b4a074720490ceeb97c3dd8d73a3de9a988d2550f1e2076c620bb10d452b2959d8b723d2ee64f499878909824e31
2019-11-18Merge #17328: GuessVerificationProgress: cap the ratio to 1Wladimir J. van der Laan
2f5f7d6b135e4eab368bbafd9e6e979aa72398de GuessVerificationProgress: cap the ratio to 1 (darosior) Pull request description: Noticed `getblockchaininfo` would return a `verificationprogress` > 1, especially while generating. This caps the verification progress to `1`. Tried to append a check to functional tests but this would pass even without the patch, so it seems better to not add a superfluous check (but this can easily be reproduced by trying to generate blocks in the background and `watch`ing `getblockchainfo`). ACKs for top commit: laanwj: ACK 2f5f7d6b135e4eab368bbafd9e6e979aa72398de promag: ACK 2f5f7d6b135e4eab368bbafd9e6e979aa72398de. Tree-SHA512: fa3aca12acab9c14dab3b2cc94351082f548ea6e6c588987cd86e928a00feb023e8112433658a0e85084e294bfd940eaafa33fb46c4add94146a0901bc1c4f80
2019-11-18Merge #17470: ci: Use clang-8 for fuzzing to run on aarch64 ci systemsWladimir J. van der Laan
fa2ec9f4518c1da3ab3592537c6cd204693a6069 fuzz: Bump timeout in test_runner to accomodate for slow arm64 CPUs (MarcoFalke) fa6e01b2f3cd8523a95bd1906ac5e62ee3cbf319 ci: Use clang-8 for fuzzing to run on aarch64 ci systems (MarcoFalke) Pull request description: Ubuntu bionic clang is clang version 6, which does not come with libfuzzer. So the ci system breaks down when run on aarch64. Fix that by using clang-8 For reference, the previous error on my ci system was: ``` /usr/bin/ld: cannot find /usr/lib/llvm-6.0/lib/clang/6.0.0/lib/linux/libclang_rt.fuzzer-aarch64.a: No such file or directory ACKs for top commit: laanwj: ACK fa2ec9f4518c1da3ab3592537c6cd204693a6069 Tree-SHA512: 4954dbc36c444d1ae145290115eea6291753c9810c92003ab8d75433c3fe3bfee439d3a99dc394418275527157a8b89f04038c8b16e08c69ec9ded50fb869e70
2019-11-18Merge #17270: Feed environment data into RNG initializersWladimir J. van der Laan
d1c02775aa74a0610809ac54bb241ddad61d2d8c Report amount of data gathered from environment (Pieter Wuille) 64e1e022cedf6776c5dffd488ca2e766adca5dc3 Use thread-safe atomic in perfmon seeder (Pieter Wuille) d61f2bb076d8f17840a8e79f1583d7f6e3e6d09a Run background seeding periodically instead of unpredictably (Pieter Wuille) 483b94292e89587e5ab40a30b8a90e2f56e847f3 Add information gathered through getauxval() (Pieter Wuille) 11793ea22e1298fa7d3b44a5b6d20830248d8cf4 Feed CPUID data into RNG (Pieter Wuille) a81c494b4c9a8c2f1a319a03375826f12863706f Use sysctl for seeding on MacOS/BSD (Pieter Wuille) 2554c1b81bb8c40e1989025c6f18e7935720b156 Gather additional entropy from the environment (Pieter Wuille) c2a262a78c3bcc4d5e13612ab0214874abe15de0 Seed randomness with process id / thread id / various clocks (Pieter Wuille) 723c79666770b30cce9f962bed5ece8cc7d74580 [MOVEONLY] Move cpuid code from random & sha256 to compat/cpuid (Pieter Wuille) cea3902015185adc88adbd031d919f91bc844fd7 [MOVEONLY] Move perfmon data gathering to new randomenv module (Pieter Wuille) b51bae1a5a4fa8ef7825dd1bb09e3f47f96d7a5a doc: minor corrections in random.cpp (fanquake) Pull request description: This introduces a new `randomenv` module that queries varies non-cryptographic (and non-RNG) sources of entropy available on the system; things like user IDs, system configuration, time, statistics, CPUID data. The idea is that these provide a fallback in scenarios where system entropy is somehow broken (note that if system entropy *fails* we will abort regardless; this is only meant to function as a last resort against undetected failure). It includes some data sources OpenSSL currently uses, and more. The separation between random and randomenv is a bit arbitrary, but I felt that all this "non-essential" functionality deserved to be separated from the core random module. ACKs for top commit: TheBlueMatt: utACK d1c02775aa74a0610809ac54bb241ddad61d2d8c. Certainly no longer measuring the time elapsed between a 1ms sleep (which got removed in the latest change) is a fair tradeoff for adding about 2 million other actually-higher-entropy bits :). laanwj: ACK d1c02775aa74a0610809ac54bb241ddad61d2d8c Tree-SHA512: d290a8db6538a164348118ee02079e4f4c8551749ea78fa44b2aad57f5df2ccbc2a12dc7d80d8f3e916d68cdd8e204faf9e1bcbec15f9054eba6b22f17c66ae3
2019-11-18Merge #17466: depends: qt: Fix C{,XX} pickupWladimir J. van der Laan
bc728d12a975934a1ef21e8d06612e157faaff6a depends: qt: Fix C{,XX} pickup (Carl Dong) Pull request description: QT LOVES to do things its own way and simply ignore all environment variables. Even listing `QMAKE_CC=...` in `./configure` flags does't work reliably. This is why we gotta literally edit their config files for them. Thanks QT. ACKs for top commit: laanwj: ACK bc728d12a975934a1ef21e8d06612e157faaff6a Tree-SHA512: 3d6a0535174d70937d11b8f44ac2ab720870345a2d5a541c3e0181163ffa1988ab4f934788e9c841b646d6f53c6dc51a4fe39b294dd042c38976091c0fb96c96
2019-11-18doc: Remove bitness from bitcoin-qt help message and manpageWladimir J. van der Laan
Remove the `(64-bit)` from the bitcoin-qt help message. Since removing the Windows 32-bit builds, it is no longer information that is often useful for troubleshooting. This never worked for other architectures than x86, and the only 32-bit x86 build left is the Linux one. Linux users tend to know what architecture they are using. It also accidentally ends up in the bitcoin-qt manpage.
2019-11-18Merge #17436: Add TheCharlatan's pgp keyWladimir J. van der Laan
0ec967164f30d313e7c54879d1c6565ad75689af Add TheCharlatan's pgp key (TheCharlatan) Pull request description: Since I have submitted my pair of signed gitian assertions, I am now adding my key's fingerprint to the gitian keys list. ACKs for top commit: jonasschnelli: ACK 0ec967164f30d313e7c54879d1c6565ad75689af - confirm key A8FC55F3B04BA3146F3492E79303B33A305224CB Tree-SHA512: bbd5e637186ed1659432e4fcc96bdc57fdbdb608325805701e06a51689726e722d7abeb11b5c9de723d051976d9d7ac23602316403fa74029dceb3cf1e837aea
2019-11-17Merge #17499: refactor, qt: Remove unused signal from WalletView classJonas Schnelli
5fa28e99033c79d50188ee47d9f09d6ade595d71 refactor: Remove unused signal (Hennadii Stepanov) Pull request description: `WalletView::showNormalIfMinimized()` signal was introduced in #2872 (dbc0a6aba2cf94aa1b167145a18e0b9c671aef5b). The only signal emit command was removed in #3144 (2384a2864b6a0b29eec6410057aefe1fd8e7e585) ACKs for top commit: promag: ACK 5fa28e99033c79d50188ee47d9f09d6ade595d71. practicalswift: ACK 5fa28e99033c79d50188ee47d9f09d6ade595d71: nice find emilengler: ACK 5fa28e9 jonasschnelli: utACK 5fa28e99033c79d50188ee47d9f09d6ade595d71 Tree-SHA512: 4714acf8c683594d3c00523c7b14bc6b94d469418f0cebe4f4b5266ca0e4c45c80d4caf358739eae9231ee4a69c9c902caeb35f3866b99443cf653f89d6d825b
2019-11-17refactor: Remove unused signalHennadii Stepanov
2019-11-15test: fix bitcoind already running warnings on macOSfanquake
On macOS, pidof installed via brew returns b'' rather than None. Account for this, to remove spurious warnings from the test_runner.
2019-11-15Merge #17486: build: make Travis catch unused variablesMarcoFalke
18b18f8e813b332d0ce6b0af19c9cb265f043776 [build] ./configure --enable-werror: add unused-variable (Sjors Provoost) Pull request description: The two macOS Travis machines run with `--enable-werror`. This PR adds `-Werror=unused-variable` to the existing `vla`, `switch` and `thread-safety-analysis` checks. This should prevent the need for fixes like b07b07cd8779355ba1dd16e7eb4af42e0ae1c587, 26a93bce29fd813e1402b013f402869c25b656d1, dd777f3e1220dd1a76e8a29cafdd4fe6244c5c0f, 99be644966c63e9917161f97574905551e44360f, fa39f674aed8f2dc5a9bde6a84b0ec52fc49e695, 16bcc1b8237698c96b8ced2fa7eb76388c7ba85e, bb079a0e2c20beb22456c91ad9e11beeae7cdc34, bdaed4755846e8b1e533c14485faa5f9fd1cf18b and ecf9b25a03d8a29f16005ca4485b6533db6efc82 with minimal nuisance. Thoughts for followups: * Travis starts these macOS machines fairly late, so we should consider setting `--enable-werror` on earlier machines as well. * We should encourage the use of `--enable-werror` by developers. Maybe switch it on by default for `--enable-debug`? * See practicalswift's overview of other checks to consider in #17344 ACKs for top commit: MarcoFalke: ACK 18b18f8e813b332d0ce6b0af19c9cb265f043776 practicalswift: ACK 18b18f8e813b332d0ce6b0af19c9cb265f043776 -- nice! Tree-SHA512: 892b471ca5ea547f3c952ac88190cbebf8110cb7aec6f20466aeb312aeb0910bfe990f914e153c40ecb55709c03775ef30770412ad76f9d532ca77055596c582
2019-11-15Merge #17455: tests: Update valgrind suppressionsMarcoFalke
d604b4cc8c112a38976c4662cbdc3217a0e5b370 tests: Update valgrind suppressions (practicalswift) Pull request description: Update `valgrind` suppressions. To test this PR: ``` $ valgrind --suppressions=contrib/valgrind.supp src/test/test_bitcoin $ valgrind --suppressions=contrib/valgrind.supp src/bench/bench_bitcoin -evals=1 \ -scaling=0.0 ``` Top commit has no ACKs. Tree-SHA512: 79cb318b5b9171e74d0bd0b89cc688ad4531b134182b06c2942c46058c19b45723c391b781e8ccd157a14fbf6a14588764c7728c5506c73ae237dde9f44db2f6
2019-11-15Merge #17480: test: add unit test for non-standard txs with too large scriptSigMarcoFalke
5e8a56348b5e1026e9ddcae0b2fa2a68faf4439e test: add unit test for non-standard txs with too large scriptSig (Sebastian Falbesoner) Pull request description: Approaches the first missing test of issue #17394: Checks that the function `IsStandardTx()` returns rejection reason `"scriptsig-size"` if any one the inputs' scriptSig is larger than 1650 bytes. ACKs for top commit: MarcoFalke: ACK 5e8a56348b5e1026e9ddcae0b2fa2a68faf4439e instagibbs: ACK https://github.com/bitcoin/bitcoin/commit/5e8a56348b5e1026e9ddcae0b2fa2a68faf4439e Tree-SHA512: 79977b12ddea9438a37cefdbb48cc551e4ad02a8ccfaa2d2837ced9f3a185e2e07cc366c243b9e3c7736245e90e315d7b4110efc6b440c63dbef7ee2c9d78a73
2019-11-15Merge #17322: Fix input size assertion in wallet_bumpfee.pyMarcoFalke
38516f9078497d3e8456d48300eca40c35a281f2 Fix input size assertion in wallet_bumpfee.py (Gregory Sanders) Pull request description: I was investigating a curious error for https://github.com/bitcoin/bitcoin/pull/17290 and realized that this check should have caught that error earlier in the test. The loop is intended to ensure that only a single input exists the entire time until the change output disappears, a single additional bump occurs, then it leaves the loop. Top commit has no ACKs. Tree-SHA512: 1d2d6ef535ec2c55f516ee5de11352386ceac6bedaabc6842229a486d9f28d35310ad5f57bfcc1f1e654fc397ecff29ec33256f9b3da897500b7e1635004b63a
2019-11-15Fix input size assertion in wallet_bumpfee.pyGregory Sanders
2019-11-15Merge #17469: test: Remove fragile assert_memory_usage_stableMarcoFalke
fac942ca57dce6cfa5655a3ac8664d6a051bc01f test: Remove fragile assert_memory_usage_stable (MarcoFalke) Pull request description: This test fails on arm64 and a fuzz tests seems inappropriate for the functional test suite anyway, so remove it. Example failures: * https://travis-ci.org/bitcoin/bitcoin/jobs/611497963#L14517 * https://travis-ci.org/MarcoFalke/bitcoin-core/jobs/611029104#L3876 ACKs for top commit: jamesob: ACK https://github.com/bitcoin/bitcoin/pull/17469/commits/fac942ca57dce6cfa5655a3ac8664d6a051bc01f Tree-SHA512: 3577e7ce5891d221cb798454589ba796ed0c06621a26351bb919c23bc6bb46aafcd0b11cb02bbfde64b74d67cb2950da44959a7ecdc436491a34e8b045c1ccf4
2019-11-15[build] ./configure --enable-werror: add unused-variableSjors Provoost
Turn corresponding warning on by default (not always covered by -Wall).
2019-11-14Merge #17449: fix uninitialized variable nMinerConfirmationWindowfanquake
edb6b768a4185a4aaa6281ee50a6538f7426cb1e fix uninitialized variable nMinerConfirmationWindow (NullFunctor) Pull request description: It is used for the computation of `BIP9WarningHeight`, and by that time it isn't initialized. ACKs for top commit: jnewbery: utACK edb6b768a promag: ACK edb6b768a4185a4aaa6281ee50a6538f7426cb1e, commit description could be cleaned up though. MarcoFalke: ACK edb6b768a4185a4aaa6281ee50a6538f7426cb1e, used python3 to do the addition locally 📍 practicalswift: ACK edb6b768a4185a4aaa6281ee50a6538f7426cb1e, used `clang++ -O2` on the previous version^W^W^W^W^W^W`bc` to verify the addition locally 🏓 Sjors: Code review ACK edb6b76. Nit: commit description has duplicate text. Tree-SHA512: 6fa0be0ecfbfd5d537f2c5b4a9333c76530c1f3182f777330cc7939b0496e37b75d8f8810cdaf471a9bd3247b425f2e239578300dfa0d5a87cd14a6ccfafa619
2019-11-14test: add unit test for non-standard txs with too large scriptSigSebastian Falbesoner
The function IsStandardTx() returns rejection reason "scriptsig-size" if any one the inputs' scriptSig is larger than 1650 bytes.
2019-11-14fuzz: Bump timeout in test_runner to accomodate for slow arm64 CPUsMarcoFalke
2019-11-14test: Remove fragile assert_memory_usage_stableMarcoFalke
2019-11-13ci: Use clang-8 for fuzzing to run on aarch64 ci systemsMarcoFalke
2019-11-13depends: qt: Fix C{,XX} pickupCarl Dong
2019-11-13tests: Update valgrind suppressionspracticalswift
2019-11-13Merge #17409: build: Avoid hardcoded libfaketime dir in gitianWladimir J. van der Laan
333362991c5219e6d9ede5fa54328bcbb0277cf2 doc: Explain $LIB in LD_PRELOAD in gitian descriptors (MarcoFalke) fab9850ef4a76e4f09278909a2865e5175661653 scripted-diff: Avoid hardcoded libfaketime dir in gitian (MarcoFalke) Pull request description: Without this gitian prints warnings for me: ``` ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ``` ``` $ ls /usr/lib/aarch64-linux-gnu/faketime/libfaketime.so.1 /usr/lib/aarch64-linux-gnu/faketime/libfaketime.so.1 ``` ACKs for top commit: laanwj: ACK 333362991c5219e6d9ede5fa54328bcbb0277cf2 Tree-SHA512: 3e7c4471b69c2ae38c29d0cc0db8b9eae0912085299d7f5ac67eeb4b6a2fdc7eb23d806eeeae0b0c2da22d6d1ba82513cab23652876b97aada9928b2c7d38e7e
2019-11-12fix uninitialized variable nMinerConfirmationWindowNullFunctor
fix uninitialized variable hard code the MinBIP9WarningHeight fix uninitialized var hard code the MinBIP9WarningHeight instead
2019-11-12Report amount of data gathered from environmentPieter Wuille
2019-11-12Use thread-safe atomic in perfmon seederPieter Wuille
Also switch to chrono based types.
2019-11-12Run background seeding periodically instead of unpredictablyPieter Wuille
* Instead of calling RandAddSeedSleep anytime the scheduler goes idle, call its replacement (RandAddSeedPeriodic) just once per minute. This has better guarantees of actually being run, and helps limit how frequently the dynamic env data is gathered. * Since this code runs once per minute regardless now, we no longer need to keep track of the last time strengthening was run; just do it always. * Make strengthening time context dependent (100 ms at startup, 10 ms once per minute afterwards).
2019-11-12Add information gathered through getauxval()Pieter Wuille
Suggested by Wladimir van der Laan.
2019-11-12Feed CPUID data into RNGPieter Wuille
2019-11-12Use sysctl for seeding on MacOS/BSDPieter Wuille
2019-11-12Gather additional entropy from the environmentPieter Wuille
This based on code by Gregory Maxwell.
2019-11-12Seed randomness with process id / thread id / various clocksPieter Wuille
This sort of data is also used by OpenSSL.
2019-11-12[MOVEONLY] Move cpuid code from random & sha256 to compat/cpuidPieter Wuille
2019-11-12[MOVEONLY] Move perfmon data gathering to new randomenv modulePieter Wuille
2019-11-12doc: minor corrections in random.cppfanquake
This should have been part of #17151.
2019-11-12Merge #17435: test: check custom ancestor limit in mempool_packages.pyMarcoFalke
49997813a4db388b2810e5e27ef771e8aa6a1f03 test: check custom ancestor limit in mempool_packages.py (Sebastian Falbesoner) Pull request description: The functional test `mempool_packages.py` starts one node with default ancestor/descendant limit settings and one with a custom, reduced ancestor limit (currently `-limitancestorcount=5`). The effect of the latter had not been tested yet though. This is approached in this PR by checking on the expected mempool contents of node1 after the node0 ancestor tests are done, via the following three conditions: - the # of txs in the node1 mempool is equal to the the limit - all txs in node1 mempool are a subset of txs in node0 mempool - the node1 mempool txs match the start of the constructed tx-chain Note that this still doesn't *fully* check the expected mempool of node1 (e.g. that it isn't influenced by `prioritisetransaction` RPC on node0), hence I add another TODO. In the future it would make sense to also set a custom descendant limit when the second TODO about checking node1's mempool is approached: https://github.com/bitcoin/bitcoin/blob/89e93135aedf984f7a98771f047e2beb6cdbdb8e/test/functional/mempool_packages.py#L228 ACKs for top commit: MarcoFalke: ACK 49997813a4db388b2810e5e27ef771e8aa6a1f03 👲 Tree-SHA512: d3a1d19fb49731238ad08ee7c02e2fa81a227e3b4ef3340d68598de42ddb62be9161134f6b8e08fa76b8c9faa02fecfa01111159642e20e9f358292a757b7608
2019-11-12Merge #17437: rpc: Expose block height of wallet transactionsMarcoFalke
a5e77959c8ff6a8bffa1621d7ea29ee8603c5a14 rpc: Expose block height of wallet transactions (João Barbosa) Pull request description: Closes #17296. ACKs for top commit: practicalswift: ACK a5e77959c8ff6a8bffa1621d7ea29ee8603c5a14 -- diff looks correct now (good catch @theStack!) theStack: ACK a5e77959c8ff6a8bffa1621d7ea29ee8603c5a14 ryanofsky: Code review ACK a5e77959c8ff6a8bffa1621d7ea29ee8603c5a14. Changes since last review getblockhash python test fixes, and removing the last hardcoded height Tree-SHA512: 57dcd0e4e7083f34016bf9cf8ef578fbfde49e882b6cd8623dd1c64716e096e62f6177a4c2ed94f5de304e751fe23fb9d11cf107a86fbf0a3c5f539cd2844916
2019-11-12doc: Explain $LIB in LD_PRELOAD in gitian descriptorsMarcoFalke
2019-11-12Merge #17450: util: Add missing headers to util/fees.cppMarcoFalke
b1315241375211563e9ec00391c4ac5310e1146f util: Add missing headers to util/fees.cpp (Hennadii Stepanov) Pull request description: ACKs for top commit: laanwj: code review ACK b1315241375211563e9ec00391c4ac5310e1146f MarcoFalke: ACK b131524 jnewbery: ACK b1315241375211563e9ec00391c4ac5310e1146f Tree-SHA512: a1ad36bff12219912c6aaacd7d9dcbeccf0fa3373280fa6e804d7a4d267b485433d6e1c01134cfa6732d2fb30ec1ab4629dff6e4bea2fe4c1976180064a3c6ca
2019-11-12util: Add missing headers to util/fees.cppHennadii Stepanov
2019-11-11rpc: Expose block height of wallet transactionsJoão Barbosa
2019-11-11test: check custom ancestor limit in mempool_packages.pySebastian Falbesoner
To test the custom ancestor limit on node1 (passed by the argument -limitancestorcount), we check for three conditions: -> the # of txs in the node1 mempool is equal to the the limit -> all txs in node1 mempool are a subset of txs in node0 mempool -> the node1 mempool txs match the start of the constructed tx-chain
2019-11-11Merge #17442: fix Typo: "merkelRoot" -> "merkleRoot"MarcoFalke
eb880f092b4154cf66fe96fc42ffdeff309e3975 fix Typo: "merkelRoot" -> "merkleRoot" (ianliu) Pull request description: <!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. --> <!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. --> <!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. --> ACKs for top commit: practicalswift: ACK eb880f092b4154cf66fe96fc42ffdeff309e3975 but please change from `merkleRootofHashes` to `merkleRootOfHashes` Tree-SHA512: ada9edceee19da5678bf35e1258163e7102fe176dc5cf40acaa1468fa8b2801494f8bf65d5359dcd0054fbc22f07fdc98d6208cfdb54dd9171fd45c89d71e098