SomberNight
0508625afc
This new `Transaction.verify_sig_for_txin` function is an instance method of `Transaction` instead of `PartialTransaction`.
It takes a complete txin, a pubkey and a signature, and verifies the signature.
- `get_preimage_script` is renamed to `get_scriptcode_for_sighash` and now effectively has two implementations:
- the old impl became `PartialTxInput.get_scriptcode_for_sighash`
- this assumes we are the ones constructing a spending txin and can have knowledge beyond what will be revealed onchain
- the new impl is in the base class, `TxInput.get_scriptcode_for_sighash`
- this assumes the txin is already "complete", and mimics a consensus-verifier by extracting the required fields
from the already complete witness/scriptSig and the scriptpubkey of the funding utxo
- `serialize_preimage` now does not require a PartialTransaction, it also works on the base class Transaction
-----
I intend to use this for debugging only atm: I noticed TxBatcher sometimes creates invalid signatures by seeing
that bitcoind rejects txs with `mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation)`.
However the txs in question have multiple txins, with some txins containing multiple signatures, and bitcoind does not tell us
which txin/signature is invalid. Knowing which signature is invalid would be a start, but I can now add some temp debug logging
to `serialize_preimage` to compare the message being signed with the message being verified.
As can be seen from the tests, the signature and the pubkey needs to be manually extracted from the txin to be verified:
we still don't have a script interpreter so we don't have logic to "verify a txin". However this new code adds logic
to verify a signature for a txin/pubkey combo (which is a small part of an interpreter/verifier).
Plugin rules: * The plugin system of Electrum is designed to allow the development of new features without increasing the core code of Electrum. * Electrum is written in pure python. if you want to add a feature that requires non-python libraries, then it must be submitted as a plugin. If the feature you want to add requires communication with a remote server (not an Electrum server), then it should be a plugin as well. If the feature you want to add introduces new dependencies in the code, then it should probably be a plugin. * We expect plugin developers to maintain their plugin code. However, once a plugin is merged in Electrum, we will have to maintain it too, because changes in the Electrum code often require updates in the plugin code. Therefore, plugins have to be easy to maintain. If we believe that a plugin will create too much maintenance work in the future, it will be rejected. * Plugins should be compatible with Electrum's conventions. If your plugin does not fit with Electrum's architecture, or if we believe that it will create too much maintenance work, it will not be accepted. In particular, do not duplicate existing Electrum code in your plugin. * We may decide to remove a plugin after it has been merged in Electrum. For this reason, a plugin must be easily removable, without putting at risk the user's bitcoins. If we feel that a plugin cannot be removed without threatening users who rely on it, we will not merge it.