txscript: return multisig signing error for no-op

[norwnd]

Just something I noticed when fiddling with multisigs,

if that change makes sense (after feedback) I'll finish this draft.

All Submissions:

• Submission follows the Code Contribution Guidelines
• There are not any other open Pull Requests for the same update/change
• Commit messages are formatted according to Model Git Commit Messages
• All changes are compliant with the latest version of Go and the one prior to it
• The code being submitted is commented according to the Code Documentation and Commenting section of the Code Contribution Guidelines
• Any new logging statements use an appropriate subsystem and logging level
• Code has been formatted with go fmt
• Running go test does not fail any tests or report any vet issues
• Running golint does not report any new issues that did not already exist

New Feature Submissions:

• Code is accompanied by tests which exercise both the positive and negative (error paths) conditions (if applicable)

Bug Fixes:

• Code is accompanied by new tests which trigger the bug being fixed to prevent regressions

Changes to Core Features:

• An explanation of what the changes do and why they should be included is provided
• Code is accompanied by updates to tests and/or new tests for the core changes (if applicable)

[norwnd]

Since it is
// arguably legal to not be able to sign any of the outputs, no error is
// returned.

Pointing out this comment, I might be missing something, but I don't see why somebody would try to sign multisig transaction unless he expects at least 1 signature to succeed.

[davecgh]

I don't think this can be changed without causing a major breaking change to the wallet RPC server. It definitely can't be changed without also cause a major version bump to the txscript module at a minimum.

Currently, the RPC can be used to determine if a multisig transaction is fully signed by just attempting to sign it and checking the "complete" flag in the result. That would no longer be possible with the proposed change.

Personally, I don't think this should be changed because it would cause a lot of churn for very little gain and also would break the aforementioned which I'm pretty sure various things depend on.

That said, since @jrick is the primary person who works on wallet, his feedback would be good to have on this.

[jrick]

There's a patch on the dcrwallet issue that probably solves this better without making this incompatible change.

[norwnd]

Personally, I don't think this should be changed because it would cause a lot of churn for very little gain and also would break the aforementioned which I'm pretty sure various things depend on.

Yeah. I thought this might not be worth the trouble ... still I hope pointing the issue out doesn't hurt, somebody might find this discovery valuable later on.

Feel free to close, but I'd keep it open until we find resolution on dcrwallet side.