-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Remove explicit DER/Compact decoding #459
Conversation
Rebased and addressed #459 (comment) |
Funny, I just updated https://github.com/cryptocoinjs/ecdsa to track bitcoinjs-lib/ecdsa. I suppose these methods can rest in there for the time being. |
Rebased, obviously still |
src/transaction_builder.js
Outdated
scriptSig = bscript.pubKeyInput(pkSignature) | ||
break | ||
|
||
case 'multisig': | ||
var msSignatures = input.signatures.map(function (signature) { | ||
return signature && signature.toScriptSignature(input.hashType) | ||
return signature && bscript.signature.encode(signature, input.hashType) | ||
}) | ||
|
||
// fill in blanks with OP_0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file outlines the real differences that users will feel.
IMHO it is an improvement, but @jprichardson I'd be up to hear your opinion.
Less magic, clear parameters and a functional style.
The only thing I don't like is that .decode(signature).signature
is a thing.
Perhaps
{
r: "...",
s: "...",
hashType: 0
}
Would be better as the decode result
Given that signatures need to be serialized, parsed, and validated, I'm not so sure I'd be quick to call the abstraction useless - yes, maybe this implementation, but an implementation, probably not. This seems like would be very low-priority. I'd be in favor of ditching it for 3.0 - but I think 3.0 should just focus on the move to secp2561k and other pending breaking changes. |
Indeed my thoughts. However, this could make the movement to |
This is ultimately part of #407. This finalises that move. Ping @jprichardson @rubensayshi @afk11 https://www.npmjs.com/package/bip66 is very explicit in its purpose... and I think that explicit nature is a bonus to everyone, provided we document that pathway for people to easily understand. |
Known breaks for code in the wild (based on a GitHub search): It would need to become
Manual unpacking... yay? 😕 https://github.com/darkwallet/darkwallet/blob/4c51dacacb8541305f1442ef7fa1628eb7c19a79/src/js/dwutil/multisig.js#L202 They are using Straight up replacement with |
If no consensus is reached within 24 hours, I'm going to bump this to |
🚀 the BitGo case would actually just become the others are odd use cases for which the |
@rubensayshi for PR to be complete in that respect, just realised it needs to serialize Maybe we should just return a
|
Bumped to |
Rebased |
src/script_signature.js
Outdated
module.exports = { | ||
fromRSBuffer, | ||
decode: decode, | ||
encode: encode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For 4.0.0
, the signature
parameter will probably become a 64-byte RS Buffer
, for direct compatability with secp256k1
libraries.
This implementation accepts the { r, s }
tuple for now as it is a simpler transition path, even if it never gets published.
The intention is that ECPair.sign
should pass directly to these functions without issue.
So when ECPair.sign
changes, this will change.
Rebased (and tests passing locally, incl. integration tests). Will merge on green tick if no ACKs appear 👍 Part of #1049 (viewing Travis log, there was a |
None of
ECSignature
, exceptparseScriptSignature
, is relevant to bitcoin or this libraries intended use.Ideally #394 might allow us to expose these functions for general purpose in the underlying ECC library.
Since we don't expose raw
ecdsa
, that would be the best place for it.It is basically a pointless abstraction for this library.
IMHO.
Chained on #456