Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sign unknown inputs #85

Closed

Conversation

Mister-EA
Copy link

When the script type is unknown the current version of the library does not try to sign the input. In this PR the input is signed by placing the signature and public key in the input script. This is the best attempt to sign. If the input is segwit then the signature will be placed in the final witness, and if it is P2SH the signature will be placed in the sigscript.

@paulmillr
Copy link
Owner

tests are failin

@Mister-EA
Copy link
Author

@paulmillr pls can you check again?

@paulmillr
Copy link
Owner

I guess this superseeds it? https://github.com/paulmillr/scure-btc-signer/releases/tag/1.3.0

@paulmillr paulmillr closed this Apr 17, 2024
@Mister-EA
Copy link
Author

I don't think the v.1.3.0 release implements this feature, as I don't see it making use of the input.partialSig[0][1] and input.partialSig[0][0]] values for unknown scripts in the finalizeIdx function.

@paulmillr
Copy link
Owner

It is exactly what it does, but for taproot only. You can now add script parser (see micro-ordinals), which will have finalizeTaproot for your custom script

@Mister-EA
Copy link
Author

My use case is a wsh-unknown script , which is not currently supported. Any chance this script type might be supported as well?

@paulmillr
Copy link
Owner

Why should it follow your code and not some other logic? It can work in "any" way if i'm not mistaken

@Mister-EA
Copy link
Author

Well, then there must be a way to support the redeeming witness creation based on the signature , public key and potentially other data. If the Bitcoin scripting language allows for arbitrary locking script creation, then shouldn't the library here also support arbitrary unlocking script creation?

If that's not so easy to implement at this stage, then the best attempt to unlock seems to be placing the signature and public key in front of the script.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants