{sign|verify}message replacement

This would allow verifiers to determine if they know the version number and report inconclusive results if they don't. He also proposes the idea of double verification, where the signature is checked against both consensus rules and standardness rules. If both verifications are valid, the signature is considered valid. If both are invalid, the signature is considered invalid. If the verifications yield different results, the validation is reported as inconclusive. Pieter believes that the double verify approach shows promise.In response to RPC commands, Pieter suggests extending the existing signmessage/verifymessage RPC. However, he acknowledges that there may be dependencies on the legacy behavior in some cases, so adding a legacy mode or using the old way for 1xx addresses should be sufficient.Pieter also warns about the danger of using prehashed messages for message signing. He cautions that this could be used to trick someone into signing an actual transaction unintentionally. To avoid this, he recommends always forcibly prefixing "Bitcoin signed message" to the message being signed.Karl Johan Alm proposes a replacement for the currently broken message signing tools that only work for legacy 1xx addresses. He suggests introducing a new structure called SignatureProof, which is a container for scriptSig and witnessProgram. Pieter Wuille suggests adding more logic to handle softforks and compatibility. One possible solution is to include a version number in the signature that corresponds to a set of validation flags. This way, if a verifier encounters a version number it doesn't know, it can report the validation as inconclusive.The conversation on the bitcoin-dev mailing list revolves around finding a solution for proving present possession of funds without compromising fungibility or hot/cold wallet separation. One proposal suggests using a FORKID in a transaction to allow for a mempool acceptance test that returns true even if the signature is not valid according to Bitcoin consensus, but only due to the FORKID. Another suggestion is to include time conditions for spending the funds. The default SIGHASH_ALL is recommended for simplicity, but an additional byte may need to be appended to the signature for encoding checks to pass. There is some debate about whether the sighash flag affects the outcome of verification.Luke Dashjr and Jim Posen discuss using sign messages to prove the availability of funds without compromising fungibility or hot/cold wallet separation. They suggest including nLockTime and nSequence in the proof container, with default values of 0 and 0xFFFF respectively. It is suggested to append a byte at the end of the signature for encoding checks, but keeping it as 0x00 since it does not affect the outcome of the verification. The participants also suggest assuming sufficient time/height on CLTV/CSV checks when there are no inputs.Luke Dashjr suggests that the current message signing feature should support "proof of funds" as a separate feature in addition to proving ownership of coins. Karl Johan Alm points out that such a feature could compromise fungibility and make hot/cold wallet separation impossible. Instead, he suggests that the feature should allow users to prove the availability of funds.The context discusses the idea of a custom signature checker that uses a specified address to derive a sighash and scriptPubKey. The proposed solution involves using the VerifyScript function with a new signature checker class. If the verify function returns true, it indicates a successful check, while false indicates an unsuccessful check. Feedback on this proposal is welcome.To implement this, the suggestion is to use the VerifyScript function along with the new signature checker class. When the sign parameter is set to true, the sighash is derived from the specified address. However, when sign is false, sha256d(message) is used instead. This approach allows for flexibility and customization in the process, ensuring that the appropriate parameters are used based on the situation.