9

The counter always increases by 1 for every operation - the difference is where the counter "starts". When an implicit (tz*) account becomes active (goes from 0 balance to more than 0), it adopts the "global" counter. This is to save storage space, as when an implicit account is no longer active we don't need to track the counter anymore. It's important to ...


7

$ ./tezos-client rpc schema post /chains/main/blocks/head/helpers/forge/operations | jq '.input.definitions."operation.alpha.contents".oneOf | .[] | .properties.kind.enum | .[0]' "endorsement" "seed_nonce_revelation" "double_endorsement_evidence" "double_baking_evidence" "activate_account" "proposals" "ballot" "reveal" "transaction" "origination" "delegation"...


7

This means that your node is not fully synchronized yet or the fee you specified/defaulted is too low for any baker to include the operation. Verifying if node is Synchronized: ./tezos-client get timestamp && date -u -Isec or ./alphanet.sh client get timestamp && date -u -Isec ( For Docker Users ) Those commands will return two UTC ...


6

The problem is that /parse/operations expects signed operations. You can just add 64 zero bytes to the end: { "operations": [ { "data": "...


6

This happened directly as part of the context "stitching". When a new protocol is activated, an initialization function is called which lets the new protocol performs some housekeeping on the context to make it compatible with the new code base. This can include changing some of the data structures involved in representing the ledger (e.g. roll base) but, in ...


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 ...


6

Before sending transactions from an account, a 'reveal' operation must be made for the account. It looks like this account may have been activated, but not yet revealed. To make this work we would need to include the reveal operation in the list of operations: sotez.rpc.getHead() .then(head => { const operation = { branch: head.hash, ...


5

Period is a 32-bit integer, the current period is 10 so you'd encode this as: 0000000a Proposal is just the hext bytes of the unencoded proposal hash, so you would b58cdecode the proposal hash and convert that to hex. For Pt24m4xiPbLDhVgVfABUjirbmda3yohdN82Sp9FeuAXJ4eV9otd you would do: eztz.utility.buf2hex(eztz.utility.b58cdecode("...


5

The idea is pretty simple: failed - operations which failed with some particular error (not enough balance, gas limit, etc); backtracked - operations which were successful but reverted due to one of the following operations in the same operation group was failed; skipped - all the operations after the failed one. However, after Babylon update some errors ...


4

From my understanding, yes and no. There are four groups of operations: Baking - endorsements Voting - proposals and ballots Annonymous - seed_nonce_revelation, double_bake/endorse, activate_account Manager - reveal, delegation, transaction, origination I believe you can combine different operations from the same group.


4

The fee computation follows the formula. The only subtle thing here is that the fee itself can affect the size of the operation in binary. This usually doesn't matter, but to handle the general case, the client currently loops: Start with the draft op with fee set to zero (with its gas_limit and storage_limit chosen appropriately). Measure the op size in ...


4

Docs in tezos.git Docs by TezTech To copy from the tezos.git docs: fees >= (minimal_fees + minimal_nanotez_per_byte * size + minimal_nanotez_per_gas_unit * gas) (size is the size of the operation in binary.) With current defaults: minimal_fees = 0.000 1 ꜩ (100 µꜩ) minimal_nanotez_per_gas_unit = 100 nꜩ/gu (0.000 000 1 ꜩ/gu) ...


4

There is no formula that will give you the full cost and gas usage of smart contract invocation. The best method is to simulate. Contract code size and storage directly affects costs through storage burn. Parameter size indirectly affect fees through gas size. See: Here for an overview on different fees and burns in Tezos. Here for a more detailed ...


4

The counter is simply a number that is incremented with each operation. I think the documentation refers to a replay attack. If operations where not tagged with a counter, that is signed along with the original operation by the author, then an attacker could inject the same operation again. For instance, if you forge an operation that transfers tokens to me, ...


3

If we put the hex strings next to each other and find out where they match it becomes easy to see why they differ. ...


3

It's called CHECK_SIGNATURE in Michelson.


3

You can use the tezos-codec binary from the latest mainnet-staging branch to parse these bytes. So, signing request are indeed prefixed by the tag 1 + <chain_id> for the block cases. The remaining part is the unsigned block header itself which can be decoded : ./tezos-codec decode 005-PsBabyM1.block_header.unsigned from ...


3

In case your node isn't fully bootstrapped, you can run: tezos-client bootstrapped This command will let you know in case your node isn't fully synced.


3

You can call toTransferParams({amount: 5}) on the method you want to estimate, and pass that result to Tezos.estimate.transfer() The results of which will look something like: Estimate { _gasLimit: 66993, _storageLimit: 0, opSize: 216, baseFeeMutez: 100 } Full example: Tezos.contract.at('KT1KBhwoSeqJt26oK8yjubTfdSgDuaVC87xR')) .then(contract =>...


3

Here is a short description of how operations can affect balance: Transaction - transfer | fee Revelation - fee Origination - transfer | fee Delegation - fee Endorsement - reward Seed_nonce_revelation - reward Double_endorsement_evidence - reward | loss Double_baking_evidence - reward | loss Activate_account - income Proposals - doesn't affect Ballot - ...


3

I don't agree that the mempool behavior indicate that the fee is all good. On the contrary. Public nodes like Giganode generally don't reject operations based on fee in the prevalidation, while most other nodes do apply the default filter. The fee is most likely too low. I don't know exactly how many bytes you got there, but increasing the fee with 10 mutez ...


3

After working with @taquito/rpc for a little while and having success there I also discovered in the main @taquito/taquito package there's some useful things you can subscribe to on the stream. A simple example to listen for new block hashes: const tezos = new TezosToolkit("http://localhost:8732"); const blockSub = tezos.stream.subscribe("...


2

The preapply/operations endpoint requires an array of operations to be submitted. Just wrap your call around square brackets and it should work. This is how it's done in eztz.


2

Unless I am reading it wrong, there was one operation injecting both proposals: https://tzscan.io/onydFJLWdGhfKNBfbnSLmqDu93j9NRimkbQm9WqLWYG8eyZUyTF in Block 332624: https://tzscan.io/BMVgMmYjA6zLbdGGKFme1VZ98GBPFgtBoJAigsH6578Yf3b8m5U These are the two proposals: A: https://tzscan.io/Pt24m4xiPbLDhVgVfABUjirbmda3yohdN82Sp9FeuAXJ4eV9otd B: https://...


2

The operation should look like: const operation = { branch: 'BLDnyGuzjz6TuDvxgBtHUZmvY2zZqJ7VShDjZsHsxXQtnzrCrPf', // current head hash contents: [{ kind: 'transaction', source: 'tz1htPf3VPXrHBTX1E7y3tBteib6hA9Teosj', fee: '50000', counter: '31204', gas_limit: '10200', storage_limit: '0', amount: '100000000', destination: ...


2

In short, no you can't as your delegators would be using standard KT1 accounts to receive their funds which means you're limited with what you can do with it. You can capture the operation hash when injecting and use that in exchange with the tzscan API.


2

In general, there would be some logic to prioritize local operations versus remote operations. Yet, that would only be needed when a baker has both a baking slot, and the need to emit new operations in the same block, something that does not happen very often. So, no, right now, there is prioritizing of operations based on their sender. Indeed, that could ...


2

The signature in hex is the last 64 bytes (128 hex characters). edsigtXomBKi5CTRf5cjATJWSyaRvhfYNHqSUGrn4SdbYRcGwQrUGjzEfQDTuqHhuA8b2d8NarZjz8TRf65WkpQmo423BtomS8Q is the signature of 64 zero bytes, also referred to as the zero signature. This can be used when you don't need to validate the signature (for example simulating operations) as well as anonymous ...


2

That 257000 µꜩ is "origination burn". Simply put, when creating(or transferring to) a new address, there is a cost and the current value is 257000 µꜩ. Since this is a "burn", it's actually a deflation as no one is the recipient. This burn is mostly to prevent spamming. Creating a KT address has always had such requirement, but for tz address, this is ...


2

Currently, the cardinality of the valid operations set in the mempool is hard-coded at 2000. Whereas branch delayed operations (e.g. counter in the future, insufficient balance, etc.) are stored in a ring buffer of size 1000 with the semantics being that when the maximum number of operations stored has been reached, the oldest operation will be removed to ...


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