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

Better signing/unlocking #143

Open
jadwahab opened this issue Mar 22, 2023 · 5 comments
Open

Better signing/unlocking #143

jadwahab opened this issue Mar 22, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@jadwahab
Copy link
Member

Is your feature request related to a problem? Please describe.
Signing/unlocking in v2 is really complicated at times

Describe the solution you'd like
Should be refactored to be made easier (potentially in a breaking way so might need to do v3). Also passing in input script and sats as function params instead having them on the input and then returning an error when trying to sign/unlock and those fields aren't added.

@jadwahab jadwahab added the enhancement New feature or request label Mar 22, 2023
@powco-dev
Copy link

powco-dev bot commented Mar 22, 2023

Thank you for making this issue!

Please get it some attention by boosting it here https://powco.dev/github/libsv/go-bt/issues/143

Bounties may be sent to this address https://whatsonchain.com/address/1FRs8zSd5xtWvZdSfvMMFnRYxmni1p26ap and will be paid to the worker who completes your issue.

@jadwahab
Copy link
Member Author

Does the unlocker for p2pkh check if it's signing the right input with the right key? I remember doing this in the past but I can't seem to find it for some reason...

@sirdeggen
Copy link
Contributor

sirdeggen commented Mar 30, 2023

Ah amazing it seems like what we've been talking about, you've already raised right here.

I'd suggest something more explicit rather than the "smart solution" where the key finds all the inputs it can sign.

Something like this where you're passing in the transaction inputs and outputs, with optional change.

tx := bt.NewTx(inputs, outputs, change)

Prior to that step you'd step up the inputs, with their unlocking requirements.

input := bt.NewInput(utxo, P2PKH, privateKey)

So you're passing the input the utxo, an Predicate interface, and the arguments needed by this Predicate type's unlock func.

The lock outputs would be similar:

output := bt.NewOutput(P2PKH, publicKey)

Passing the output a Predicate interface and the arguments needed by this Predicate type's lock func.

@sirdeggen
Copy link
Contributor

sirdeggen commented Mar 30, 2023

Above is all pseudo code, but something like this:

input := bt.NewInput(utxo, P2PKH, privateKey)
output := bt.NewOutput(P2PKH, publicKey)

inputs := []bt.Inputs{input}
outputs := []bt.Outputs{output}
change := bt.Change{{ predicateType: P2PKH, args: publicKey }}

tx := bt.BuildTx(inputs, outputs, change)

// at this point tx would already be signed, the BuildTx would take all the args from within each input to create the whole tx.

unsignedTx := bt.NewTx(inputs, outputs, change) // if you don't want to sign it immediately.

@jadwahab
Copy link
Member Author

jadwahab commented Apr 9, 2023

this is how v1 worked, separating the inputs and output and then constructing them in the tx and caused lots of confusions and issues. in v2 we decided to keep the funcs directly as receivers on the Tx object. so you would create a tx and then add inputs and outputs (err := tx.From() for the inputs and err := tx.To() or err := tx.AddOpReturnOutput() etc.)

The main issue was that we were passing the input data (including the previous tx script and prev tx sats) when creating the input as opposed to when signing. the best way to fix imo is to only add the prev txid and prev vout when adding the input (since that's all that's in the input) and then when signing (or filling the input with the unlocking script), you would add the prev tx script and prev tx sats - so they would need to be added to the UnlockerParams in unlocker.go

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

No branches or pull requests

2 participants