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

Remove explicit DER/Compact decoding #459

Merged
merged 3 commits into from
May 14, 2018
Merged

Remove explicit DER/Compact decoding #459

merged 3 commits into from
May 14, 2018

Conversation

dcousens
Copy link
Contributor

@dcousens dcousens commented Sep 8, 2015

None of ECSignature, except parseScriptSignature, 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

@dcousens
Copy link
Contributor Author

Rebased and addressed #459 (comment)

@jprichardson
Copy link
Member

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.

@dcousens
Copy link
Contributor Author

Rebased, obviously still 3.0.0 though

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
Copy link
Contributor Author

@dcousens dcousens Jul 11, 2016

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

@jprichardson
Copy link
Member

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.

@dcousens
Copy link
Contributor Author

This seems like would be very low-priority.

Indeed my thoughts. However, this could make the movement to secp256k1 easier due to less specialised / non-generic interfaces?

@dcousens
Copy link
Contributor Author

dcousens commented Oct 13, 2016

This is ultimately part of #407.
With #456 merged, and bip66 being a separate module... there is literally no reason to have toDER and toCompact.

This finalises that move.
This is hopefully the last non-trivial (aka documentation) PR for 3.0.0.

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.

@dcousens
Copy link
Contributor Author

dcousens commented Oct 13, 2016

Known breaks for code in the wild (based on a GitHub search):

https://github.com/sabakaio/mnemoauth-client/blob/a46202351a976e4346277ddf9827661a29ca30be/index.js#L19

It would need to become

var signature = authKey.sign(messageHash)
var encoded = bip66.encode(signature.r, signature.s)

Manual unpacking... yay? 😕


https://github.com/darkwallet/darkwallet/blob/4c51dacacb8541305f1442ef7fa1628eb7c19a79/src/js/dwutil/multisig.js#L202
Very weird usage there?
Not sure why, but, again, should be a straight bip66 drop in.


https://github.com/BitGo/BitGoJS/blob/5a06433c4c424e5f7bebe1ef2895b857622751b6/src/bitcoin.js#L114

They are using secp256k1 for performance, and then double serialising? Interesting... would be a bip66.decode(...)


https://github.com/Colu-platform/colu-access/blob/b03bac5b8d23110b48383a1b319939ef817246ea/src/coluaccess.js#L317

Straight up replacement with bip66 module.

@dcousens
Copy link
Contributor Author

If no consensus is reached within 24 hours, I'm going to bump this to 4.0.0 and start the 3.0.0 release process.

@rubensayshi
Copy link
Contributor

rubensayshi commented Oct 13, 2016

🚀

the BitGo case would actually just become return secp256k1.signatureExport(sig) right? they overload the ECPair.sign and then go from Buffer -> Signature, but now they can just return that buffer.

the others are odd use cases for which the bip66 package is a perfect solution.

@dcousens
Copy link
Contributor Author

dcousens commented Oct 13, 2016

@rubensayshi for PR to be complete in that respect, just realised it needs to serialize r in ecdsa.sign and deserialize in ecdsa.verify

Maybe we should just return a bip66 signature there instead?
Save everyone of that hassle?

script.signature.encode would then just work on the DER signature... aka just adding the extra byte

@dcousens dcousens modified the milestones: 4.0.0, 3.0.0 Nov 2, 2016
@dcousens
Copy link
Contributor Author

dcousens commented Nov 2, 2016

Bumped to 4.0.0...

@dcousens
Copy link
Contributor Author

Rebased

module.exports = {
fromRSBuffer,
decode: decode,
encode: encode
Copy link
Contributor Author

@dcousens dcousens Apr 13, 2018

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.

@dcousens
Copy link
Contributor Author

dcousens commented May 14, 2018

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 standard issue, that will be promptly fixed, no point waiting further)

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

Successfully merging this pull request may close these issues.

4 participants