multi send error

[KaneMayfield]

having a problem doing a multi send... getting this error It looks like my "second send" gets hung up or something... im barely technical enough to find the github... i was directed to put it here

Error validating transaction: Error running script for input 0 referencing 117e8bffa27feeccc331f53ff03df9fa0e930404cc96436c9b0565b9fe1c1303 at 0: scriptsig not push only for P2SH.

[adamkrellenstein]

Thanks for submitting this! Unfortunately that's a hard thing to debug... because the transaction is being produced by Freewallet. We going to need some more details of the contents of the transaction, log files, something. :/

Can you reproduce the error reliably? What are the exact steps you take to do so?

[davestaxcp]

So a few members of the community that use Multi-Send very frequently have reported this issue

11/29/23

1/25/24

1/29/24

and there is a few places this issue (or something similar) have been referenced on the Freewallet Github at even earlier dates:

https://github.com/jdogresorg/freewallet-desktop/issues/124

https://github.com/jdogresorg/freewallet-desktop/issues/152

B0BSmiths noted on his experience with using this feature and a Trezor wallet:

"I have found the signing of the second TX in a multisend is problematic on Trezor. The Trezor sees the OP return but it ignores the PS2H encoded inputs. It then consumes and an entire UTXO on mining fees as there is no change in the TX and broadcasts the op return without signing the P2SH encoded inputs, so an unrelated entire utxo is consumed and your multisend fails"

Though to note, in Issue 152, Subterranean mentions he was not using the Hardware wallet functionality at all.

In an early discussion with B0B we assumed it may be something to do with how fees:

At the time there were tx id's with the info on it, but they have since been purged (too low of a few in mempool)

• users at the moment are stuck in a weird place knowing this issue has been reoccuring (and Freewallet is the only wallet to support MPMA at this time), but also in a weird spot to have the dev say its a protocol issue

• take note there has been some ongoing fee estimation changes in new FW versions recently - not sure if this could have fixed the issue recently or not......

---

• as for logs from the wallet when this error happens, I sadly could not find any user that had shared that during their error experience .... though if it happens to me or another user again I'll be sure to ask

---

• as for the "steps to recreate this issue" - I would take an educated guess and say it might have to do with an address with a significant amount of inputs on the address (most artists and users do not consolidate UTXO's)

• also it is not uncommon for users to just smash functions again and again even if the previous tx's are unconfirmed or too low of a fee... so maybe assume a user

1. has alot of UTXO's trying to do this function and

2. usually arent willing to wait and instead: instantaneously try again using a different fee or just pushing through multiple unconfirmed tx's

[adamkrellenstein]

Ach yeah, all of that information is great, but what we need is a way to reproduce the issue reliably. If it only happens rarely, then it won't be productive to just spam MPMA until it happens. We need either:

1. Steps to reproduce the issue reliably, or
2. Logs from Freewallet showing the series of API requests against the API that failed, or
3. Detail from users specifying exactly what parameters they put into Freewallet on what date so we can reproduce (2) ourselves.