Instead of creating a redeemScript with CreateMultisigRedeemscript and
then getting the destination with AddAndGetDestinationForScript, do
both in the same function.
CreateMultisigRedeemscript is changed to AddAndGetMultisigDestination.
It creates the redeemScript and returns it via an output parameter. Then
it calls AddAndGetDestinationForScript to add the destination to the
keystore and get the proper destination.
This allows us to inspect the public keys in the redeemScript before creating
the destination so that the correct destination is used when uncompressed
pubkeys are in the multisig.
Github-Pull: #16026
Rebased-From: a49503402b6bc21e3878e151c07529941d36aed0
The RPC examples for signrawtransactionwithkey are missing the 2nd parameter.
Github-Pull: #16210
Rebased-From: 71fd628adafdeb2a4b343e0d51d7168cdb186312
Updates text since -whitelistforcerelay was set to false by default in
PR #15193.
Github-Pull: #15890
Rebased-From: e0bb2799992afe88e6f4efc6d90ed82ddf1ec5ec
This helps to distinguish it from CNode::fRelayTxes and avoid bugs like
425278d17bd0edf8a3a7cc81e55016f7fd8e7726
Github-Pull: #15990
Rebased-From: fa1dce7329d3e74d46ab98b93772b1832a3f1819
8602d8b213 Revert "Change in transaction pull scheduling to prevent InvBlock-related attacks" (Suhas Daftuar)
Pull request description:
This is for 0.18, not master -- I propose we revert the getdata change for the 0.18 release, rather than try to continue patching it up. It seems like we've turned up several additional bugs that slipped through initial review (see #15776, #15834), and given the potential severe consequences of these bugs I think it'd make more sense for us to delay releasing this code until 0.19.
Since the bugfix PRs are getting review, I think we can leave #14897 in master, but we can separately discuss if it should be reverted in master as well if anyone thinks that would be more appropriate.
ACKs for commit 8602d8:
Tree-SHA512: 0389cefc1bc74ac47f87866cf3a4dcfe202740a1baa3db074137e0aa5859672d74a50a34ccdb7cf43b3a3c99ce91e4ba1fb512d04d1d383d4cc184a8ada5543f
Hypothetically, someone may wish to begin pruning at a future blockchain size, and there's no reason to limit it lower
Github-Pull: #15801
Rebased-From: 8a33f4d63f9944f4877b3e2814b1582e72ceaa71
Tree-SHA512: 814dc5f004c3418216a12f8e0ef1a8db2c586d98b515d48b31a8ccd7f4e0deb12b9f2b6110bf702576a32802ca1d30e518df5ad7c28046deb4d0e9be46a6e7b8
Without this, an out-of-default-range value gets limited to the range
Github-Pull: #15801
Rebased-From: 4ddeb2f860eee98fbe94725ea8885368068a03f2
Tree-SHA512: 64c18c8be6756fc0130d3fe934edb1ea7758877d4049c5729fa2adb05abb3af4e4bbe1d5f910224e16070aada5470637a35ed14b12391efd48cf035e8a22a949
235550d019 Take non-importing keys into account for spendability warning in descriptor import (Pieter Wuille)
802dcd37d1 Import all origin info in importmulti; even for non-importing pubkeys (Pieter Wuille)
7fcbe7dc11 Keep full pubkeys in FlatSigningProvider::origins (Pieter Wuille)
Pull request description:
Clean backport of #15749 by sipa to 0.18
ACKs for commit 235550:
fanquake:
utACK 235550d
MarcoFalke:
ACK 235550d019 (Checked that they are clean cherry-picks)
Tree-SHA512: 1ccc19f51137ac4ef971c0bcca4c87ab2383610aa51c5d02680c485b9ce6abd698dddd7f4a45946d56b1aa741cc3fd94b4180ff15901824d20eeba89b4f12853
The "addresses" field was confusing because it refered to public keys
using their P2PKH address. It was included in the return object when
needed for backward compatibility. Remove that compatibility now that
the -deprecatedrpc=validateaddress option has been removed.
New applications should use the 'embedded'->'address' field for P2SH or
P2WSH wrapped addresses, and 'pubkeys' for inspecting multisig
participants.
Github-Pull: 15750
Rebased-From: b4338c151d4788c33f4b7c54daaf7f94b193a624
This makes orphan processing work like handling getdata messages:
After every actual transaction validation attempt, interrupt
processing to deal with messages arriving from other peers.
Github-Pull: #15644
Rebased-From: 866c8058a706931f025335b3e794ed2f4d287918
