Closed kyranjamie closed 4 years ago
Merging #123 into master will increase coverage by
0.00%
. The diff coverage is85.71%
.
@@ Coverage Diff @@
## master #123 +/- ##
=======================================
Coverage 83.30% 83.31%
=======================================
Files 28 28
Lines 2156 2163 +7
Branches 444 446 +2
=======================================
+ Hits 1796 1802 +6
- Misses 356 357 +1
Partials 4 4
Impacted Files | Coverage Δ | |
---|---|---|
src/transaction.ts | 79.64% <85.71%> (+0.40%) |
:arrow_up: |
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 0f8686c...cdebc72. Read the comment docs.
I'm not sure I understand the use case here, where would the signature come from? Why not use the TransactionSigner
as per usual? How would this work for Multi-sig?
Is there a case in which spending condition would be undefined?
I can't think of one.
The API we have to work with a Ledger device is a essentially a function with the following type:
(unsignedSerialisedTransaction: string) => Buffer // of the signature created by the device
This PR adds a simple method to add that signature to the unsigned transaction and add a new one.
I'm not sure how this would be achieved with the TransactionSigner
currently. It only accepts a StacksTransaction
.
Example: As a Blockstack developer, I must be able to interact with an API exposed by
StacksTransaction
to add a signature to an unsigned transaction.This change is implemented with an immutable api.
Is there a case in which spending condition would be
undefined
? Would be a lot cleaner if a tx were to always have one.See issue #121
Checklist
npm run test
passes