17
Yes, Tezos supports three types of keys associated with 3 kinds of elliptic curves
tz1 for Ed25519 keys,
tz2 for Secp256k1 keys (same as Bitcoin/Ethereum)
tz3 for NIST P256 keys which may have led to some amount of controversy but is one of the most used elliptic curve, including native support in some mobile devices like the iphone
Source:
http://www....
8
It's not clear what decrypting data from within a smart contract would achieve since all operations are public.
8
There are currently no encrypt/decrypt instructions for Michelson. You can view the full list of instructions here: http://tezos.gitlab.io/mainnet/whitedoc/michelson.html
7
We will need these operations:
blake2b: size 32
concat: concatenation of byte arrays
Also, let zero_bytes be 32 zero bytes.
My answer is based on seed_storage.ml and seed_repr.ml, with some experimentation.
Initial seeds
Let's start at the beginning.
The initial preserved_cycles+2 = 7 seeds were determined ahead of time, as follows. The first seed is ...
6
Ethereum way of retrieving the public key only works with some signing algorithms, ECDSA with secp256k1 in its case. It is also used by Tezos for tz2 (and P-256 for tz3), but not for tz1 which uses EdDSA. In general, Tezos wants to support new signature algorithms in the future. From this point of view, Reveal is more general and will work with probably all ...
4
TezBox currenty only supports the ed25519 curve, this is because the underlying library (eztz.js) only supports this curve. We are about to release support for the other two curves in eztz.js in the next few weeks, and will likely roll out support to TezBox after that.
The alternate HD paths will be available in the wallet after that, but currently you will ...
4
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 signature.
Tezos expects exactly 64 bytes for a secp256k1 signature
https://gitlab.com/tezos/tezos/-/blob/master/src/lib_crypto/base58.ml
Per this question you ...
3
If using pytezos that would be:
>>> from pytezos import Key
... Key.from_encoded_key('edskReYTc3xorfemyNAcrYb6Sz8Wgj6e1PfevpZ6uysf4KXWBNxXcoLA4KBtZp7hmUCy6V3bhtWZRMSuya5DgXA1TU2JXYeDmG').secret_key()
<<< 'edsk2pR4GssrHRPDFBci4wkLGAH97HcwmLAWMEGWh6D9zyTUvbQb1p'
Under the hood:
Base58 decode (with checksum)
Cut first 4 bytes
That's ed25519 ...
3
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 the correctness of the code generally.
2
KT addresses are the addresses of smart contract (aka. "originated accounts"). Contrary to tz addresses (aka. "implicit accounts"), smart contracts are not associated with a pair of cryptographic keys because there is no secret place at which they could store a secret key.
As the name "originated account" suggests, the existence ...
2
Not a direct answer, but workaround
python-ecdsa lib generates non-deterministic signatures by default (see more at https://tools.ietf.org/html/rfc6979#section-3.2). Each time you run your code you get a new result.
I've experienced this issue and eventually switched to secp256k1 package (there were several extra reasons for that):
https://github.com/baking-...
1
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 bitcoinjs-lib.
Only top voted, non community-wiki answers of a minimum length are eligible