This repository was archived by the owner on Jul 15, 2018. It is now read-only.
Conversation
Contributor
|
:+1 |
ebuchman
approved these changes
Feb 23, 2017
signature.go
Outdated
| const ( | ||
| SignatureTypeEd25519 = byte(0x01) | ||
| SignatureTypeSecp256k1 = byte(0x02) | ||
| SignatureNameEd25519 = "ed25519" |
Contributor
There was a problem hiding this comment.
what about just one NameEd25519 instead of duplicating names for each type?
Contributor
Author
|
Okay, I unified all the types and names with one variable per algorithm in 0e92dd5 I think this is what you wanted with your comment bucky. If you like it, me too. If not, I can just revert the change. |
liamsi
added a commit
to liamsi/go-crypto
that referenced
this pull request
Jun 12, 2018
� This is the 1st commit message: Release/0.8.0 (tendermint#127) https://github.com/Liamsi/go-crypto/blob/8e31aebe2bc23037b9cc11892f3ec4515bbf5991/CHANGELOG.md#080 fix tests, move encoding to encode_test.go, include an example Ledger integration, WIP Fix testcases, all looks OK Prevent unnecessary signatures, improve error messages Bugfix Update to new Ledger API in progress Update to latest upstream, debugging information � This is the commit message tendermint#2: Clarify function names � This is the commit message tendermint#3: Add ed25519, tests will fail until ed25519 verification fix Implement PubKeyLedgerEd25519 Pin to an upstream revision Remove Ledger ed25519 support, for now Move TODOs to tendermint#114 Move from tmlibs #213 (tendermint#115) * move from tmlibs 213 * expose KVPair, simpleproofsfrommap returns keys update ed25519 address scheme (tendermint#112) make PubKeyEd25519.Address() returns the first 20 bytes of the hash of the raw 32-byte pubkey, no amino required forgot PrivKeyLedgerSecp256k1 version bump (tendermint#128) version bump
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Another approach to solve #1
This uses wrapping structs to allow json unmarshalling of interfaces with minimal boilerplate code (which I hope to auto-generate one day). The default behavior with wire.BinaryBytes() and wire.JSONBytes() is not changed at all.
If you use the
encoding/jsonlibrary, we get nice handling of the three interfaces,PubKey,PrivKeyandSignature. You must just store them in a wrapping struct:PubKeyS,PrivKeySorSignatureS. Please take a look at the tests.We use
go-datato export all byte slices (and with custom JSONMarshal also the byte arrays) as hex strings. However this is flexible, and you can set the byte encoding to use hex, base64 or base58 in the main entry of your program and it will affect the encoding of all types that make use ofdata.Bytesordata.Encoder.Example default encodings are for public keys are:
If you use
crypto.PubKeySin your structs, you can cleanly Unmarshal this json into usable PubKey's as well.