Enhancement: Tx Unlocker

[tigh-latte]

The current signer is restrictive in both language an implementation, as it assumes only checksig based unlocking will be used.

To sort this, I've added an Unlocker interface and tx.Unlock functions which can take any type of unlocking implementation, and provided our p2pkh signing implementation out of the box as a LocalP2PKHUnlocker.

[codecov-commenter]

Codecov Report

Merging #67 (3fb5ff2) into master (201dbcc) will increase coverage by 0.33%.
The diff coverage is 58.13%.

@@            Coverage Diff             @@
##           master      #67      +/-   ##
==========================================
+ Coverage   84.75%   85.09%   +0.33%     
==========================================
  Files          28       28              
  Lines        3011     3012       +1     
==========================================
+ Hits         2552     2563      +11     
+ Misses        325      313      -12     
- Partials      134      136       +2     

Impacted Files	Coverage Δ
signaturehash.go	70.86% <0.00%> (+0.09%)	⬆️
localunlocker.go	58.82% <58.82%> (ø)
txunlock.go	60.86% <60.86%> (ø)
bscript/script.go	59.79% <100.00%> (+0.45%)	⬆️
txoutput.go	82.50% <0.00%> (+1.41%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 201dbcc...3fb5ff2. Read the comment docs.

[theflyingcodr]

LGTM, just a really tiny thing I found

[jadwahab]

nice

[jadwahab]

i think you forgot this

[tigh-latte]

yep, fixed here:

# tigh in ~/go/src/github.com/libsv/go-bt on git:enhancement/tx-unlocker o
> grep -rsn LocalSignatureUnlocker

# tigh in ~/go/src/github.com/libsv/go-bt on git:enhancement/tx-unlocker o

[jadwahab]

@Tigh-Gherr I'm realising that I really don't like the double negative here with the "unlocking" especially where we have txs which are not yet unlocked and then we settled for "incomplete transactions".

I think we should take a step back and revert to something similar to what we had before. "Signing" and "unsigned" txs are not accurate anymore after genesis since the locking/unlocking scripts are not restricted to only p2pkh scripts. However, what if we change it to "signoff" and "unsignedoff" txs so it's still similar but instead of signing a tx you would be signing it off and that makes sense in the general form. I think it's much better than the double negative with "unlocking" and "incomplete" txs that was pretty confusing.

What do you think? @Tigh-Gherr

[tigh-latte]

@jadwahab we are talking about the fund itself being locked/unlocked, not the tx. So we take a locked UTXO, provide the script to unlock it, and boom, we've all the money. So we unlock a locked fund.

The "incomplete" term comes exclusively from test code, there isn't a public interface anywhere in go-bt (that I know off) that names it such. The closest public interface we have to performing this behaviour is the Fund function. We fund an unfunded tx, then we unlock those funds.

In my opinion, a locked fund that we unlock paints a much clearer image over a fund that isn't signed off, which we then sign off. Especially because signing off does imply a signature.

Also, "unlock" is shorter to type than "sign off".

[jadwahab]

Hahahaha gtfoh mate @Tigh-Gherr

Yeah I agree with you the the fund is locked and unlocked but I was talking about the tx inputs. So basically where we have tx.Unlock (which is tx.Sign in v1) for each input in the tx. We used to have a concept of an "unsigned" tx where the inputs are there but not signed/unlocked - this is where the double negative becomes confusing and why we had to resort to using the "incomplete tx" in the tests (we will also use this term in other parts of the code since "unsigned" txs are used in so many places).

So in order to avoid saying the "not unlocked" tx (or the "locked tx" which sounds really weird - UTXOs are locked but transactions don't really make sense to be locked in this context and can easily be confused for txs locked with nLockTime) - I think it would be better to use "unsignedoff" inputs and transactions. That's also closer to v1 and legacy terminology where they used to be "unsigned" inputs and txs.

TLDR: "unsignedoff" is shorter to type than "not unlocked" 😅

[tigh-latte]

Aw shit @jadwahab I think we're at a stalemate:

>>> len("notunlocked")
11
>>> len("unsignedoff")
11

If the worry is around the tx.Unlock func, we can rename it to tx.UnlockInputs, tx.UnlockFunds, or even tx.SignOff.

My issue about reverting back is that, we'd be regressing on the terminology at the fund level just to make it a bit friendlier at the level of a tx (and being honest, I'm sceptical that this makes it friendlier at the level of a tx). It's a common analogy that's really pervasive throughout programming, and something we meet every single day of our lives in real life. It's a much more familiar than the idea of a signed off/unsigned off entity.

A locked/unlocked entity also paints a far clearer picture of both the state of the current fund/tx, and is generally more applicable to the language around the possible uses of locking/unlocking scripts. To bring it into terms of the travelling salesman problem, it's more intiuative to say you unlock the fund with a solution to the problem, as opposed to saying you signed off on the fund with a solution to the problem.

In regards to the implementation of this, we'd have to consider our interface and struct implementation names:

type SignOffer interface {}
type SignOfferGetter interface {}
type LocalSignOffer struct {}
type LocalSignOfferGetter struct {}

[jadwahab]

Yupp we can keep those as Unlocker since they apply to the locking script directly. And then have tx.Signoff and unsignedOffTx so we basically get the best of both 👍