4

The structure of an encoded operation group is the following: <branch : 32 bytes> <tag#0 : nat> | <content#0> ... <tag#n : nat> | <content#n> <signature (optional) : 64 bytes> Extracting branch: Append 0x0134 prefix Base58 encode with checksum Extracting signature: Append 0x04822b prefix Base58 encode with checksum ...


4

A series of blog posts from Nomadic Labs give a more detailed and up-to-date answer, notably this one: https://blog.nomadic-labs.com/emmy-in-the-partial-synchrony-model.html. Roughly, the answer depends on how much stake an attacker is considered to have. But it also depends on whether the network message delays are reasonable, and on the degree of assurance ...


3

Technically, transaction amount is of mutez type, which is internally represented by 64-bit signed integer. However, in practice, (if we speak about applied transactions) the amount cannot exceed the total supply, wich is currently 873682204744114 (https://api.tzkt.io/v1/statistics/current). And yes, a single transaction can have only one destination address....


2

NB: After the adoption of the Granada protocol, which halves the minimal time between blocks, the max_operation_ttl constant was doubled from 60 to 120 blocks, to roughly preserve the length of the live blocks and operations window when measured in wall-clock time.


2

storage_exhausted means the storage_limit you have set is too low for your operation. You have set 0. Your dry-run came back with "allocated_destination_contract": true. You need to pay an allocation fee to cover the cost of assigning the new address. Set your storage limit to 257


2

The correct way to do this is simply: @sp.entry_point def withdraw(self, amount): sp.set_type(amount, sp.TMutez) sp.send(sp.sender, amount) The solidity translation tool I used didn't handle this properly


2

The main reason is the storage diff resulted from the transaction. Adding 380 items to a big map at once is very expensive. For your use case, storing the corner coordinates should be enough.


1

I would like to clarify some of the beacon behavior. The main responsibility of beacon is establishing and maintaining a communication channel between a dApp and a wallet. Beacon itself does NOT do any type checking or error handling regarding the contents of the tezos operations. The operations are sent to the other side as is, without any changes or error ...


1

Did you try value: { "int" : "10000" }? It seems that: the field value in parameters should be micheline (seeing how Unit is expressed) the entrypoint %stake has type nat (the linked contract says (nat %stake) in the parameter type) the Micheline encoding of the nat 10000 is {"int": "10000"} (this can be verified by ...


1

I suspect you mean amount as transaction size and not as a mutez value. The limits per transaction and block can be found in the following RPC: /chains/main/blocks/head/context/constants Edo Protocol hard_gas_limit_per_block: "10400000" hard_gas_limit_per_operation: "1040000" hard_storage_limit_per_operation: "60000" ...


1

Tezos Taquito has docs on how to drain an account which you can find here: https://tezostaquito.io/docs/drain_account It covers how to drain implicit and originated accounts.


1

[Edit] As Simon has suggested, the fee has been reduced, and the only restriction is to have 1 mutez left on the account or undelegate the account if the account is used for delegation. Jev suggested a link to the newly provided documentation. Tezos does not allow for sending the whole address balance, some dust left on the account is required to be able to ...


1

The answer given by Raphael Cauderlier in the gitlab issue helped solve the issue: "I have tried to reproduce this in sandbox (well, actually in mockup client); I think your problem is that 100 extra gas units are not enough to empty an account, apparently this consumes 400 gas units. Here is what I did (mockup_client is an alias for tezos-client --mode ...


1

Both transactions sent from your address have the same fee 0.01 tez that is not enough, taking into account the gas limit 50000. Try to set the fee 0.015 tez. If this doesn't help, it also can be a problem with the node you use, so try to use another one, like Tezos Giga Node. And yes, operations stay in the mempool for only an hour, however TzKT explorer ...


1

Don't worry, your funds are safe. You need to wait a bit and then try again with a higher fee or lower gas_limit. Why did that happen? You sent a transaction with large gas_limit: 50000 (despite a simple tz-to-tz transfer consumes about 1427 gas) and rather small, for such gas limit, fee:10000. So no one baker picked your transaction to include into a block ...


1

Account's counter is updated when the manager operation is included into the blockchain. It would be weird if the blockchain storage was affected by things not included in that blockchain :)


1

Ledger's central service node (where it fetches balances) is out of sync with the network. If you've confirmed that operation has completed then your funds are indeed safe in the ledger address. It is simply that the Ledger Live application's node is out of sync. https://status.ledger.com/


1

You can use taquito for this. (https://tezostaquito.io/docs/estimate) Operation cost for invoking smart contract


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