We changed our privacy policy. Read more.

Hot answers tagged

7

Take a byte representation of a particular block header: http://rpc.tzkt.io/mainnet/chains/main/blocks/head/header/raw. The format of the block header is described in the docs. Get a BLAKE2b (32bit) hash digest of it Prepend two bytes '\x01\x34' (they are responsible for "B" letter) Base58 encode it with checksum There is no randomness. The baker ...


6

1) Here they are $ ./tezos-client rpc get /chains/main/blocks/1/context/contracts | grep KT1 "KT1WPEis2WhAc2FciM2tZVn8qe6pCBe9HkDp", "KT1W148mcjmfvr9J2RvWcGHxsAFApq9mcfgT", "KT1VvXEpeBpreAVpfp4V8ZujqWu2gVykwXBJ", "KT1VsSxSXUkgw6zkBGgUuDXXuJs9ToPqkrCg", "KT1Um7ieBEytZtumecLqGeL56iY6BuWoBgio", "KT1TzamC1SCj68ia2E4q2GWZeT24yRHvUZay", "...


6

Those 22 bytes are: 2 bytes - encoded prefix (tz1, tz2, tz3, KT1); 20 bytes - depending on the address type: for tz-addresses it's public key hash; for KT-addresses it's hash of the origination operation (see details in @enforser's answer). Here is a code on C#, I believe you will understand it :) var bytes = Hex.Parse("...


4

The priority 1 baker (Foundation Baker 5) stole this baking right from you due to its higher fitness (i.e. their block received 2 more endorsements than yours, 33 to 31), as you can see here. Difficult to say why this happened, as it can have multiple reasons, such as connectivity issues to other nodes, your node's hardware (especially performance of your ...


4

This happens when the network is running late. This estimated_time is computed on the "every baker at priority 0 will bake" hypothesis. Each time a block is baked by the baker of priority 1, it is baked later and every following block has to be baked "later"... Reference Thanks to @Pierre Boutillier for helping with this


4

You can request the current head of your node using ./tezos-client rpc get /chains/main/blocks/head (and look for the level and hash information). Then, use your favorite block explorer to know the level of the current head. Alternatively, the ./tezos-client bootstrapped command aims to hang and return only when the node is synchronized.


3

Something to note from the accepted answer is that the KT1 addresses do not have a "public key hash". The hash used there is the blake2b 20 byte digest hash of the operation group hash and the index of the origination operation within that group that created the address. More details here: https://tezos.stackexchange.com/a/2270/5435. @Groxan is ...


2

An example of a token I may want to track is tzBTC, which does call transfer internally - and it does show up in the RPC response. That is the answer, isn't that? :) So, you need to iterate over transactions in a block and check for those where destination is {tzBTC} and parameters.entrypoint is "transfer". Then you need to analyze the parameters....


2

This depends on what assumptions one makes on the stake an attacker trying to revert a transaction/block has, on the exact question one asks, on the degree of confidence one would like to have, and on further assumptions about the behavior of the network... For a more detailed answer see this blog post: https://blog.nomadic-labs.com/analysis-of-emmy.html. ...


2

In 005-Babylon, fitness became a monotonically increasing number, simply representing the height of the block. Fitness is no longer calculated based on the number of endorsements within the block. "confirmations" is simply the level of the current head block minus the level of the block with your transaction. If you want to mess with fitness still, treat ...


1

Here's my goto command. tezos-client rpc get /chains/main/blocks/head/ | jq -r '.header.level, .header.timestamp';date --iso-8601=seconds The output will look something like: 544640 2019-07-31T10:53:57Z 2019-07-31T10:54:10+00:00 Which is the node's block level, the last block timestamp and your system's timestamp. Run it a few times, waiting 10 - 20 ...


1

In addition to the hard gas limit, there's a limit on the size of the block (in bytes)1. The maximum size of the list of operations in a block is 512kB2.


1

ask tezos-node to tell me the contents of the block it would produce No, because tezos-node does not create blocks. tezos-baker-0XX is responsible for creating blocks and it does not have an RPC interface. tezos-baker polls tezos-node first for rights, then if and only if, it is your turn, does tezos-baker then poll for the contents of mempool. tezos-baker ...


1

See also here this section of the documentation: https://tezos.gitlab.io/008/proof_of_stake.html#blocks


1

https://tezos.gitlab.io/008/rpc.html#get-block-id https://mainnet-tezos.giganode.io/chains/main/blocks/head Most fields, IMO, are semi-self-explanatory by their name depending on what you are looking for.


1

Part 1 of my question was answered by Michael. What about the second part? Well, I just had a look at it. What I did is: extract the full series of hash codes, from block 1 to the latest (VERY LONG). extract the numbers contained in such hash codes (i.e. remove letters). analyse the "randomness" of this series of numbers with purposely designed tests. The ...


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