Each Tezos node maintains a representation of the current state of the ledger. That state includes things like the storage of each contract, the balance of different addresses, etc. The goal of the blockchain is to allow a decentralized network of participants to reach consensus on what that state is.
Since the chain can have reorganizations, it's sometimes ...
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 ...
I am talking from memory of the transition from proto 002 to proto 003 so hopefully I got it right.
If you go on tzscan you will see that there is a counter for addresses
When this counter is not zero it means the address is « alive » which means in practice that it has a non-zero balance and on ...
The chain_id is computed from the genesis block hash as follows.
First, in pseudocode:
blake2b(msg = tezosB58CheckDecode('B', genesisBlockHash),
size = 32)))
Take the genesis block hash. For example, in mainnet, this is "BLockGenesisGenesisGenesisGenesisGenesisf79b5d1CoW2".
My suggestion would be using tzscan API.
For example checking all activations until you find a match
something like this:
index = 0
loop while true
compare each item
It has a timestamp for each activation
Correct way of doing it with tzscan
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.
Double baking is the act of creating two blocks at the same level - this in effect creates a fork, where the next bakers can choose from multiple blocks.
Endorsements help to improve the fitness of the chain, and is usually used to resolve any potential fork attempts. If an endorser endorses multiple blocks at the same level, they are effectively improving ...
The Tezos protocol is defined by its OCaml implementation. When amendment to the protocol are proposed, the delegates vote on hashes of amended implementations.
That being said, some parts of the protocol have been formalized. Most notably, the semantics of the Michelson smart-contract language has been formalized in several semantic frameworks: Coq, Ott, K, ...
You basically have no guarantee of synchronicity for several reasons.
We’re talking about a blockchain with no instant finality (yet) so a transaction can be “reversed” in the (real world) future so when you send a transaction, you don’t know if it will still be there in 30 or 1000 blocks.
Off chain views use a node that may or may not be synchronized with ...
Choosing the order in which operations are applied is a privilege of the baker. So yes, frontrunning is possible on Tezos and can either be done by setting high fees (the default baker strategy is to apply transactions with high fees first) or by the bakers themselves when they build their blocks. The simplest protection against frontrunning is to run your ...
If there has been any transactions to or from any of these wallets they will be on the chain forever.
You can "forget" them on your tezos node using:
tezos-client forget address <name> -f
The -f (force) option will remove the keys from disk (if present).
If you want to do it with Taquito, the confirmation method on the operation object returns a promise with different information like the block, the status, etc. You can also use confirmationObservable to get the same information with an observable.
For more detailed information, you will have to use an indexer like Better Call Dev (although Taquito is ...
The src/bin_node/tezos-sandboxed-node.sh script that launches a sandboxed node is meant to be used with the src/bin_client/tezos-init-sandboxed-client.sh one that sets some env variables and bash aliases. The tutorial documentation for these scripts is here: https://tezos.gitlab.io/user/sandbox.html.
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:
Which is the node's block level, the last block timestamp and your system's timestamp.
Run it a few times, waiting 10 - 20 ...
If you didn't figure this out: You can actually change the directory that kiln uses for the tezos node data. It's a bit odd that the symlinks break things, but you ought to be able to not need a symlink.
Blockchain file directory change in Kiln
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.