Added a method testPeginClaimAcceptance to interfaces::CChain. It is not clear
to me that this is meaningfully different from the existing method broadcastTransaction
(with the `relay` flag set to false so it doesn't actually broadcast), except
that this method returns the TxValidationState, which we display to the user
in the RPC error. Worth revisiting this.
Another nonobvious change was replacing a block of mempool-searching logic
in wallet/rpcwallet.cpp with the single line `pwallet->chain().findCoins(coins)`.
This I stole from the current state of upstream #17211, our favorite in-progress
PR from which the original logic came.
asp: the point of this PR was to completely decouple libbitcoin_server from
bitcoin_tool; it removes $(LIBBITCOIN_SERVER) from the `elements_wallet_LDADD`.
I put this back in because our additional code related to pegin claiming makes
heavy use of methods from libbitcoin_server.
If we want to morally accept this PR then we need to do a nontrivial refactoring.
This maintains a persistent list of wallets stored in settings that will
automatically be loaded on startup. Being able to load a wallet automatically
on startup will be more useful in the GUI when the option to create wallets is
added in #15006, but it's reasonable to expose this feature by RPC as well.
This fix is a based on the fix by Antoine Riard <ariard@student.42.fr> in
https://github.com/bitcoin/bitcoin/pull/18600.
Unlike that PR, which implements some new behavior, this just restores previous
wallet notification and status behavior for transactions removed from the
mempool because they conflict with transactions in a block. The behavior was
accidentally changed in two `CWallet::BlockConnected` updates:
a31be09bfd and
7e89994133 from
https://github.com/bitcoin/bitcoin/pull/16624, causing issue
https://github.com/bitcoin/bitcoin/issues/18325.
The change here could be improved and replaced with a more comprehensive
cleanup, so it includes a detailed comment explaining future considerations.
Fixes#18325
Co-authored-by: Antoine Riard <ariard@student.42.fr>
d044e0ec7d refactor: Remove override for final overriders (Hennadii Stepanov)
1551cea2d5 refactor: Use override for non-final overriders (Hennadii Stepanov)
Pull request description:
Two commits are split out from #16710 to make reviewing [easier](https://github.com/bitcoin/bitcoin/pull/16710#issuecomment-625760894).
From [C++ FAQ](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final):
> C.128: Virtual functions should specify exactly one of virtual, override, or final
> **Reason** Readability. Detection of mistakes. Writing explicit `virtual`, `override`, or `final` is self-documenting and enables the compiler to catch mismatch of types and/or names between base and derived classes. However, writing more than one of these three is both redundant and a potential source of errors.
ACKs for top commit:
practicalswift:
ACK d044e0ec7d: consistent use of `override` prevents bugs + patch looks correct + Travis happy
MarcoFalke:
ACK d044e0ec7d, based on my understanding that adding `override` or `final` to a function must always be correct, unless it doesn't compile!?
vasild:
ACK d044e0ec7
Tree-SHA512: 245fd9b99b8b5cbf8694061f892cb3435f3378c97ebed9f9401ce86d21890211f2234bcc39c9f0f79a4d2806cb31bf8ce41a0f9c2acef4f3a2ac5beca6b077cf
