Files
pallectrum/electrum/plugins
SomberNight 3e81cd1f1d trezor: fix regression in sign_transaction for trezor one for multisig
fixes https://github.com/spesmilo/electrum/issues/8813
regression from eef9680743

We started setting the witness field in above commit to be able to provide the witnesses for already pre-signed
external inputs to the device, e.g. for a coinjoin.

Trezor One fw has pretty strict limits on the witness field: max 109 bytes,
probably because that's a ~tight upper bound for a p2wpkh witness:
  <num_witness_items> <len(sig)> <sig> <len(pubkey)> <pubkey>, it comes out to 3+73(high-S and high-R)+33.
ed1785a985/legacy/firmware/protob/messages-bitcoin.options (L35)

Trezor model T seems to have higher limits.

tx_inputs is called for the tx being signed (for_sig=True), and for its parents/prev_txes (for_sig=False).
The witness is only useful for the tx being signed, I think.

Users reported seeing a "DataError: bytes overflow" exception when using a Trezor One to sign 2of3 p2wsh multisig txs.
There were no external inputs involved so for the tx being signed all witnesses were None, however we were also
setting the witness for the inputs of prev_txes.
The witness for a 2of3 pw2sh multisig input is around ~253 bytes.

To sidestep the problem, we now only set the witness in the for_sig=True case.
Note that this means if someone tries to do a coinjoin with a Trezor One involving non-trivial external inputs,
they will run into the same limit and exception.
2024-02-04 00:14:59 +00:00
..
2023-12-04 14:15:39 +08:00
2023-09-05 12:32:38 +00:00
2024-01-17 01:15:14 +00:00

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.