Hot answers tagged

7 votes
Accepted

base58 prefixes

Base58 encodes characters by appending a prefix, treating the bytes as a big endian number and writing that big endian number in base 58. Therefore, specific prefixes can pin down the most ...
user avatar
  • 4,399
4 votes
Accepted

Secp256k1 with Non-Deterministic Signatures

It shouldn't make a difference how you pick k, deterministically or not. It's random and is supposed to be kept secret by the signer, so there's no way to tell what k was used by just looking at the ...
user avatar
  • 4,399
3 votes

base58 prefixes

Base58 prefixes will always produce a prefixed output for a set length of output. So the input address is 20 bytes + the 3 byte prefix gives a 36 char long address with tz1. You calculate these ...
user avatar
3 votes
Accepted

Unable to get consistent tz2 (secp256pk1) signature

The immediate problem seems to be that you are not getting signatures in "lower S" form. This seems better: sk.sign_digest(digest, sigencode=ecdsa.util.sigencode_string_canonize) I cannot vouch for ...
user avatar
  • 2,466
2 votes

Unable to get consistent tz2 (secp256pk1) signature

Not a direct answer, but workaround python-ecdsa lib generates non-deterministic signatures by default (see more at https://www.rfc-editor.org/rfc/rfc6979#section-3.2). Each time you run your code you ...
user avatar
1 vote
Accepted

How to sign transaction from tz2 address?

You must sign transactions from tz2 addresses with secp256k1. Eztz's sign function uses Ed25519, so that wont work. Easiest would probably be to just replace libsodium in eztz with something like ...
user avatar
  • 1,310

Only top scored, non community-wiki answers of a minimum length are eligible