Merge #12709: [wallet] shuffle sendmany recipients ordering

6acb02d635 add release note for sendmany output shuffling (Gregory Sanders)
cf6ef3c139 shuffle sendmany recipients ordering to shuffle tx outputs (Gregory Sanders)

Pull request description:

  Unless there is something important I'm missing, we're just possible leaking information by preserving whatever ordering json object ordering is giving us (no guarantees at all).

  This is unneeded for `sendtoaddress` since there is only 1 or 2 outputs, and the change output is shuffled in.

  This will not effect `*raw` behavior by design, since users generally want full control using those apis. Further PRs could add optional args to over-ride that behavior.

  Alternative ideas would be to sort the outputs by some deterministic ordering. (this would require more refactoring since change outputs are created and handled by caller)

  related: https://github.com/bitcoin/bitcoin/pull/12699

Tree-SHA512: afdd990dde6a4a9e7eef7bb2e3342a46d11900d7fe6e6e4eb0cc6b5deed89df989fa7931a4bdcbf49b7c2d7a13c90169af3a166466e5760948bacabe3490f572

doc/release-notes.md

@@ -73,6 +73,7 @@ RPC changes
 - Wallet `listreceivedbylabel`, `listreceivedbyaccount` and `listunspent` RPCs
   add `label` fields to returned JSON objects that previously only had
   `account` fields.
+- `sendmany` now shuffles outputs to improve privacy, so any previously expected behavior with regards to output ordering can no longer be relied upon.
 
 External wallet files
 ---------------------

src/wallet/rpcwallet.cpp

@@ -1145,6 +1145,9 @@ UniValue sendmany(const JSONRPCRequest& request)
     if (totalAmount > nBalance)
         throw JSONRPCError(RPC_WALLET_INSUFFICIENT_FUNDS, "Account has insufficient funds");
 
+    // Shuffle recipient list
+    std::shuffle(vecSend.begin(), vecSend.end(), FastRandomContext());
+
     // Send
     CReserveKey keyChange(pwallet);
     CAmount nFeeRequired = 0;