d8bc47fde4 depends: switch to secure download of all dependencies (Ulrich Kempken)
Pull request description:
Even if we potentially check the integrity of the downloaded file via hash comparison, we should make use of SSL since it is available.
ACKs for commit d8bc47:
jonasschnelli:
utACK d8bc47fde46ca0711fa54a0d70ff5d066c708e50
practicalswift:
utACK d8bc47fde46ca0711fa54a0d70ff5d066c708e50
dongcarl:
tACK d8bc47fde46ca0711fa54a0d70ff5d066c708e50
Tree-SHA512: e47702f6d243ed7f498ca84c193244382f16f08df6a297caa224b4468f501f3da6fe542fcf3a0dd9c24ab1b0b38bbc51478068e6006a92854ded23abf90de3c8
df0e97ccb1 RPC: Hint for importmulti in help output of importpubkey and importaddress (Kristaps Kaupe)
Pull request description:
Similar to #12702. Hint for `importmulti` also in help output of `importpubkey` and `importaddress`.
ACKs for commit df0e97:
promag:
utACK df0e97ccb13a28825a2731b95d2bb17f355f6920.
jonasschnelli:
utACK df0e97ccb13a28825a2731b95d2bb17f355f6920
Tree-SHA512: db7358d7f4d463a50874e605bbca35a1a40dbefbb1d35cf51fe2f2aa34bef90c3ca398f4ffbcb9d7d43887a03eb8d81b6ef59066a3c7eda18a7eea876f6592e7
fa2b52af32f6a4b9c22c270f36e92960c29ef364 Disallow extended encoding for non-witness transactions (take 3) (MarcoFalke)
Pull request description:
(previous title "p2p: Disallow extended encoding for non-witness transactions (take 3)")
Remote peers can send us illegally encoded txs and thus have us write to stderr. Fix that by not writing to stderr.
This is a follow up to the previous (incomplete) attempts at this:
* Disallow extended encoding for non-witness transactions #14039
* Add test for superfluous witness record in deserialization #15893
ACKs for commit fa2b52:
laanwj:
utACK fa2b52af32f6a4b9c22c270f36e92960c29ef364
ryanofsky:
utACK fa2b52af32f6a4b9c22c270f36e92960c29ef364. Would change title to something like "Avoid logging transaction decode errors to stderr" instead of "Disallow extended encoding for non-witness transactions." The current title is confusing because this PR isn't really allowing or disallowing anything, just logging the condition differently. "Disallow" also seems to contradict the "Allow exceptions from..." comments in the actual code.
Tree-SHA512: c66990e69b432d00dc1c5510bf976a1188664d0890a32d1e5c6459094e7e27da82a5d227627afcbc203676f5540eec74b7d9b1d71d2c62d3b2069e1781824b4d
* merge 15638: Move CheckTransaction from lib_server to lib_consensus
* merge 15638: Move policy settings to new src/policy/settings unit
* merge 15638: Move rpc utility methods to rpc/util
* merge 15638: Move rpc rawtransaction util functions to rpc/rawtransaction_util.cpp
* merge 15638: Move several units into common libraries
* merge 15638: Move wallet load functions to wallet/load unit
* merge 15638: Document src subdirectories and different libraries
* [build] Add several util units (cleanup)
* build: resolve missing declarations by re-specifying headers
706340150f3ae26fce4659f8fa0a5d57149d2fb3 Elaborate on the need to re-login on Debian-based systems to use tor following usermod (clashicly)
Pull request description:
Starting bitcoind with `-onlynet=onion` immediately after adding bitcoind user to debian-tor group will yield the following notice on debug.log:
"tor: Authentication cookie /run/tor/control.authcookie could not be opened (check permissions)"
Elaborate on the need to re-login to ensure debian-tor group has been applied to bitcoind user after:
sudo usermod -a -G debian-tor username
Verification can be done via `groups` command in shell.
Otherwise operator may not be aware at first launch they are not running a tor enabled node.
ACKs for top commit:
fanquake:
ACK 706340150f3ae26fce4659f8fa0a5d57149d2fb3 - Thanks for following up.
Tree-SHA512: 3473966fb43b4f1c86bd8841dd6ea8c2798256c2ca926b10bd08cd655b954a9e77f0278c4fe63160e69cc75e240a3580af00ea46bf960fde2788aa88f03510b2
82e53f37e1bfa6e34eac16b33329d70c3c0127da doc: add comments clarifying how local services are advertised (James O'Beirne)
Pull request description:
Recent questions have come up regarding dynamic service registration
(see https://github.com/bitcoin/bitcoin/pull/16442#discussion_r308702676
and the assumeutxo project ~~which needs to dynamically flip NODE_NETWORK~~).
While investigating how dynamic service registration might work, I was
confused about how we convey local services to peers. This adds some
documentation that hopefully clarifies this process.
ACKs for top commit:
laanwj:
ACK 82e53f37e1bfa6e34eac16b33329d70c3c0127da
darosior:
ACK 82e53f37e1bfa6e34eac16b33329d70c3c0127da
Tree-SHA512: a30c1020387d7a75b5b3cdde45f8b7f2ae46293da97e6227b2ee17e290b93deb5b16c0bbc2b1676972300e5c3c2ad74eb8b3910d6b93e028dac1ae2700468ef9
66ad75472f47e219ff980f7aba249795403dd7e0 [Doc] Add documentation for the new whitelist permissions (nicolas.dorier)
Pull request description:
Documenting the new feature https://github.com/bitcoin/bitcoin/pull/16248 . Ping Sjors .
ACKs for top commit:
Sjors:
Indeed, re-ACK 66ad75472
Tree-SHA512: e6860bb6fae921287da7920a8db534e6a1a23871dd78dd6da030f00adf23e204cd23b194d67361bf34d4ef5a7815fc3fd7c81a3f2f35e4cfbe6ee2f2e6daec25
20ea9ef6ce9228a5258b99eeeeb40e6dfae2299f [doc] mention whitelist is inbound, and applies to blocksonly (Sjors Provoost)
Pull request description:
* `-whitelist` only impacts inbound nodes (see #9923). This is obvious in the context of allowing those nodes to connect to you, but there are additional whitelist features where this is less obvious, such as mempool relay behavior.
* `whitelistrelay` (on by default) explains that `-blocksonly` makes an exception for transactions from whitelisted nodes, but it wasn't documented (nor obvious imo) the other way around. See also https://github.com/bitcoin/bitcoin/pull/15984#issuecomment-490645552
Top commit has no ACKs.
Tree-SHA512: 03e363a5da5d81ad147d1c7e38bf11114df8bb89bdd66fb551520b25f810efa886ec6e649d3b435c4935e0ae4f39bb718bc7bb5778b9de6aa0b71e970a431af8
6576a8765f67716aa6b87a2f0296fbac5956bec0 doc: Improve versionbits.h documentation (Antoine Riard)
Pull request description:
While reviewing burying of BIP 9 deployments, seen that versionbits.h wasn't that much documented. This is an attempt to improve it. It can be useful, given after burying this code isn't going to be used anymore and isn't straightforward at first sight.
ACKs for top commit:
jnewbery:
ACK 6576a8765f67716aa6b87a2f0296fbac5956bec0
ajtowns:
ACK 6576a8765f67716aa6b87a2f0296fbac5956bec0
fanquake:
ACK 6576a8765f67716aa6b87a2f0296fbac5956bec0
Tree-SHA512: 906463e0b22b988f89d77f798bf94d294f70467d29975088b87384764fb5d0dd1350be67562cc264656f61f1eada2cba20f99c0d797d1d7f90203c269e34c714
c7f6ce74d3a5cf2a0c5bac20eab1efd997175a72 docs: Improve netbase comments (Carl Dong)
Pull request description:
Second in a series of PRs documenting the net stack. Contributed with sincere thanks to sipa, laanwj, and gmaxwell for providing much of the history, context, and rationale.
ACKs for top commit:
laanwj:
ACK c7f6ce74d3a5cf2a0c5bac20eab1efd997175a72
Tree-SHA512: ad83054d3b8d0c8c3fb55be011bcf294176e7509513bf61326866afd53e8159644e0d59bb3a2f404717f525cbf736096d4c1990e61cfd89845d51fa6b5394b7c
e91f0a7af2 doc: Remove travis badge from readme (MarcoFalke)
Pull request description:
The readme(s) are shipped in the released source-code archive, in which case the travis badge is useless since it doesn't link to the travis result of the correct commit/tag/branch. GitHub embeds the correct links for each tag or commit that ci ran on, so we don't need this link in the readme.
ACKs for commit e91f0a:
hebasto:
ACK e91f0a7af2aec7d924f00da25c69d8f46e0dd33d
Tree-SHA512: 860435a58b38a9bd0bc62a1e74b3a63c138c9a2f09008a090d5ecc7fd86fa908d2e5eda41d16606507a238d9488fa5323405364a9556b670684a2e4838aead2d
faebd2ef40 doc: Move wallet lock annotations to header (MarcoFalke)
Pull request description:
We put the annotations in a central place (the header) as opposed to spreading them over the cpp files, where they easily get outdated.
Tree-SHA512: 18d8c7329efd3471713de18fe8d63d67c50fcb9fa99bc372294d829aa7668ea33e10d44e9e50121a04d8cc3302d5fd7759224f7935451a4693c4498a555257e6
b67978529a Add comments to Python ECDSA implementation (John Newbery)
8c7b9324ca Pure python EC (Pieter Wuille)
Pull request description:
This removes the dependency on OpenSSL for the interaction tests, by providing a pure-Python
toy implementation of secp256k1.
ACKs for commit b67978:
jnewbery:
utACK b67978529ad02fc2665f2362418dc53db2e25e17
Tree-SHA512: 181445eb08b316c46937b80dc10aa50d103ab1fdddaf834896c0ea22204889f7b13fd33cbcbd00ddba15f7e4686fe0d9f8e8bb4c0ad0e9587490c90be83966dc
fa1c8e297 Resolve the qt/guiutil <-> qt/optionsmodal CD (251)
Pull request description:
This pull request attempts to resolve the `qt/guiutil` <-> `qt/optionsmodel` circular dependency.
The `Intro` class in `qt/intro` has a static member function `getDefaultDataDirectory` which is used by `qt/optionsmodel` and creates the circular dependency
`qt/guiutil -> qt/walletmodel -> qt/optionsmodel -> qt/intro -> qt/guiutil`.
This circular dependency is resolved by moving `Intro::getDefaultDataDirectory` to `GUIUtil::getDefaultDataDirectory` without modifying the implementation.
ACKs for commit fa1c8e:
MarcoFalke:
utACK fa1c8e297825fbaeda049c8bf36f39de919a9989
promag:
utACK fa1c8e2.
hebasto:
utACK fa1c8e297825fbaeda049c8bf36f39de919a9989
practicalswift:
utACK fa1c8e297825fbaeda049c8bf36f39de919a9989
jonasschnelli:
utACK fa1c8e297825fbaeda049c8bf36f39de919a9989
Tree-SHA512: 58cc4aee937c943d8de9dc97ef1789decfddb0287308f44e7e3a3b497c19e51da184988e17207544fff410168ec98dd49a3e62c47e84ad1f0cf6ef7247a80fb5
3c3e31c3a4 [tests] Add wallet-tool test (João Barbosa)
49d2374acf [tools] Add wallet inspection and modification tool (Jonas Schnelli)
Pull request description:
Adds an offline tool `bitcoin-wallet-tool` for wallet creation and maintenance.
Currently this tool can create a new wallet file, display information on an existing wallet, and run the salvage and zapwallettxes maintenance tasks on an existing wallet. It can later be extended to support other common wallet maintenance tasks.
Doing wallet maintenance tasks in an offline tool makes much more sense (and is potentially safer) than having to spin up a full node.
Tree-SHA512: 75a28b8a58858d9d76c7532db40eacdefc5714ea5aab536fb1dc9756e2f7d750d69d68d59c50a68e633ce38fb5b8c3e3d4880db30fe01561e07ce58d42bceb2b
3109a1f948f3c8fd500defbdc4e59bfb2953c30b refactor: Avoid locking cs_main in ProcessNewBlockHeaders (João Barbosa)
Pull request description:
Builds on #16774, this change avoids locking `cs_main` in `ProcessNewBlockHeaders` when the tip has changed - in this case the removed lock was necessary to just log a message.
Top commit has no ACKs.
Tree-SHA512: 31be6d319fa122804f72fa813cec5ed041dd7e4aef3c1921124a1f03016925c43cd4d9a272d80093e77fa7600e3506ef47b7bb821afcbffe01e6be9bceb6dc00
dcc448e3d2b97f7e4e23f5ed174762cec3530306 Avoid unnecessary "Synchronizing blockheaders" log messages (Jonas Schnelli)
Pull request description:
Fixes#16773
I'm not entirely sure why 16773 happend, but probably due to headers fallback in a compact block.
However, this PR should fix it and should have been included in #15615.
ACKs for top commit:
ajtowns:
ACK dcc448e3d2b97f7e4e23f5ed174762cec3530306 ; code review only, haven't compiled or tested.
promag:
ACK dcc448e3d2b97f7e4e23f5ed174762cec3530306.
TheBlueMatt:
utACK dcc448e3d2b97f7e4e23f5ed174762cec3530306. Went and read how pindexBestHeader is handled and this code looks correct (worst case it breaks a LogPrint, so whatever). I also ran into this on #16762.
fanquake:
ACK dcc448e3d2b97f7e4e23f5ed174762cec3530306
Tree-SHA512: f8cac3b6eb9d4e8fab53a535b55f9ea9b058e3ab6ade64801ebc56439ede4f54b5fee36d5d2b316966ab987b65b13ab9dc18849f345d08b81ecdf2722a3f5f5a
d75e704ac08fb43320e3ebcdde0d2a5392fdec9f Add log output during initial header sync (Jonas Schnelli)
Pull request description:
The non debug log output is completely quiet during the header sync. I see two main reasons to add infos about the state of the initial header sync...
* users may think the node did fail to start sync
* it's a little complicate to check if your getting throttled during header sync (repeatedly calling `getchaintips` or similar)
ACKs for top commit:
fanquake:
Concept ACK d75e704ac0
practicalswift:
utACK d75e704ac08fb43320e3ebcdde0d2a5392fdec9f
laanwj:
Tested ACK d75e704ac08fb43320e3ebcdde0d2a5392fdec9f
Tree-SHA512: 2e738571b703d7251290864603c3a829729645962c2fa3187250bab0585e66a5f01fce892e9b5b98da451fab2b40a2e4784f9b2e5a9cad75ff62c535affe7430
* Handle attempts to read non-existent records from isdb properly
* Do not reject blocks that conflict with islocks while still syncing
Otherwise you can stuck with no new blocks/headers which means you won't be able to verify new chainlocks that might override stored islocks
* Handle duplicates/conflicting islocks better
* More constness
