9
Public keys in Tezos are stored in compressed form:
<1 byte prefix>|X
Prefix is b'\x02' if Y is even, b'\x03' otherwise, now you have a compressed key of 33 bytes long;
Add tezos prefix b'\x03\xfe\xe2V' for secp256k1, b'\x03\xb2\x8b\x7f' for p256;
Encode with Base58 algo with checksum.
Checkout pytezos.crypto sources for implementation examples.
6
1) Here they are
$ ./tezos-client rpc get /chains/main/blocks/1/context/contracts | grep KT1
"KT1WPEis2WhAc2FciM2tZVn8qe6pCBe9HkDp",
"KT1W148mcjmfvr9J2RvWcGHxsAFApq9mcfgT",
"KT1VvXEpeBpreAVpfp4V8ZujqWu2gVykwXBJ",
"KT1VsSxSXUkgw6zkBGgUuDXXuJs9ToPqkrCg",
"KT1Um7ieBEytZtumecLqGeL56iY6BuWoBgio",
"KT1TzamC1SCj68ia2E4q2GWZeT24yRHvUZay",
"...
6
Look at this file https://gitlab.com/tezos/tezos/blob/master/src/lib_crypto/base58.ml
The relevant section is the Prefix module at the end
module Prefix = struct
(* 32 *)
let block_hash = "\001\052" (* B(51) *)
let operation_hash = "\005\116" (* o(51) *)
let operation_list_hash = "\133\233" (* Lo(52) *)
let operation_list_list_hash = "\029\159\...
5
Why can I convert between address and contract. But not between address and key_hash?
There is the (IMPLICIT_ACCOUNT) instruction to go from key_hash to address. For the other direction, there was (a feature request) but it was closed because no use case has been presented to motivate it.
5
key_hash is blake2b hash of a public key, in the base58 encoded form it can start only with tz, but address is more general, it can also hold KT accounts;
There are no instructions for that, probably because it's a rare and arguable case; EDIT: as pointed out by Raphaël, you can convert key_hash to contract and then to address using IMPLICIT_ACCOUNT ; ...
5
Try https://github.com/murbard/pytezos/blob/master/pytezos/crypto.py
from pytezos.crypto import Key
key = Key(key='mnemonic', passphrase='******', email='foo@bar.com')
key.public_key_hash()
>>> edpk...
4
When your originate a contract, you send an "operation" to the network. This operation is then serialized into byte format and a hash is derived - this is the operation hash for the given operation.
If an operation generates a new contract, you can manually calculate the new KT1 address by hashing the operation hash + an index byte (starting from 0). We use ...
4
You can not derive Ed25519 keys in a way that is compatible with bip32 or bip44. Bip32 only defines a derivation scheme for secp256k1, and bip44 depends on bip32. To get around this problem there's a SLIP-10 specification that adapt bip32 in a way that makes it possible to derive keys for other signature schemes than secp256k1. The most important takeaways ...
3
In the contract, you cannot obtain the public key from an address but if you are given both the public key and the address you can check that the public key corresponds to the address. In Michelson, assuming you have the address and the public key at the top of your stack this is done with HASH_KEY; IMPLICIT_ACCOUNT; ADDRESS; COMPARE; EQ.
In the client, you ...
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.
3
As said in the glossary, tz accounts are called "implicit accounts" and KT1 accounts are called "originated accounts" or "smart contracts" (these two expressions are synonyms since Babylon).
3
Yes, you can send transactions from TZ1 to KT1 addresses and back 👍
3
The only role of the KT1 hash is to be a unique handle. It's computed from the parameters of the origination operation so that no two operations can yield the same handle.
See origination_nonce in https://gitlab.com/tezos/tezos/blob/master/src/proto_alpha/lib_protocol/contract_repr.ml
2
You can see in the commit 1c7d7ce7 that the prefix was previously "TZ1". The case was used to distinguish between the two types of adresses. This commit changed the letters to "limit confusion with tz1". Regarding the choice of the new letters, there is no official explanation as far as I can tell but, according to rumors, it may be a reference the first ...
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-...
2
There is a high chance you got scammed by a fake TezBox site. Go back and carefully check the URL. TezBox has been "dead" and unsupported for almost a year and half. There have been several fakes that have surfaced and your story sounds exactly like the others.
Unfortunately, if this is indeed the case, there is absolutely no way to get your Tez ...
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
You cannot convert an address to a string in Michelson. You could cheat by going through pack and inspecting the binary representation but it is unlikely something you would want to do.
2
It is not possible to do from inside a contract. But you can use the following RPC:
https://tezos.gitlab.io/alpha/rpc.html#get-block-id-context-contracts-contract-id-manager-key
Example:
https://florencenet.smartpy.io/chains/main/blocks/head/context/contracts/tz1aWXP237BLwNHJcCD4b3DutCevhqq2T1Z9/manager_key
1
Any tezos address can receive transactions without revealing. When an address takes any active action on the chain, it must be revealed, and a fee must be paid for revelation. This fee is burnt immediately and not collected by any other address. This was introduced in the Babylon protocol to prevent address creation spam as with more addresses in use, the ...
1
I'm not a cryptographic expert but, the issues that you mentioned in Bitcoin involved weak signatures (same K value bug), which when used multiple times enabled the guessing of the private key. This has now been fixed.
There is still a case for advocating against address re-use, especially for addresses used for long term storage of large amounts of value: ...
1
You can now burn Anything on the Crunchy DeFi firepit....
I have a question of my own though...
How did ArthurB generate tz1burnburnburnburnburnburnburjAYjjX ?
I want to burn a large portion of the Tezos Till We Bezos token to a MacKenzie themed burn address
Is it possible to replace some of the "Burn" with MacKenzie?
I tried ...
1
You could use something like tz1burnburnburnburnburnburnburjAYjjX.
1
For implicit accounts, the address is nothing more than the hash of the public key so this means that you can compute the address from the public key but not the other way around.
In Michelson, you have:
HASH_KEY : key -> key_hash
IMPLICIT_ACCOUNT : key_hash -> contract unit
ADDRESS : contract _ -> address
I don't understand how I would apply this ...
1
The address data type is ordered lexicographically, so that tz2... comes before tz3... and tz2a... comes before tz2b... etc. But originated accounts, addresses that start with KT1, come after any implicit accounts, those that start with tz. So all addresses starting with KT1 are ordered lexicographically but they come after all tz addresses.
This ordering is ...
1
I think we are in the third case:
Maybe useful but none has yet proposed it with convincing use cases?
It is true that the keys must be given from the outside but so are the signatures so if one needs to combine signature checking and address-based authentication it is always possible to replace all occurrences of signature with pair key signature and ...
1
The PDF you received from the ICO contains everything you need to activate your address, including your public hash (starts with tz1, tz2, or tz3).
Only top voted, non community-wiki answers of a minimum length are eligible