The clue to the solution is in the part of the error saying that Validation of block BK... failed.
It seems that it wasn't checking to see if there was any new free disk space available, it was just reading back the error of why it failed in the first place. And when it failed to validate the block, the block was marked as invalid.
After running ./tezos-...
I was able to solve the issue myself. My node had rejected a seemingly valid block. I found this out by listing the rejected blocks of the node:
tezos-admin-client list rejected blocks
The bond computation (% of tokens you need for a given number of rolls) is not exact, it depends on how many rolls are actually used for baking, and also of what happen on the network:
the mean percentage is computed by supposing that all rolls are activated and used for baking. Given that, you can compute how often you bake for one roll, and how much ...
It is nothing harmful, this message just makes visible a peer disconnection that was formerly only printed in debug mode, and will probably be only visible in debug mode in the future.
And it's normal to be disconnected from peers on a regular basis. It is part of the "connection diversification" process: sometimes a node choose to accept a new incoming ...
You cannot exceed the hard_gas_limit_per_operation = 400000. It will probably be increased in future protocols, though (see e.g. the "Athens" proposals).
Internal transfers can use up a lot of gas.
First, there is a fixed cost of 10000 gas per transfer.
Second, and more importantly, when a contract is 'parsed', the contract's entire code and storage are ...
You can call the checkpoint rpc:
This comment solved it
Did you definitely do step 5? sudo cp -r ~/.tezos-node/context ~/.tezos-node/store /var/lib/kiln/data-dir/tezos-node/[chain-id]/ sudo chown -R kiln:kiln /var/lib/kiln/data-dir/tezos-node/[chain-id]
This is the answer:
sudo chown -R kiln:kiln /var/lib/kiln/data-dir/tezos-node/[chain-id]
or for production:
sudo chown -R kiln:kiln /...
First of all, setting connections limit to 10 is very low, you should either use the default value or use something nearer the default value which is 100. The less peer you have, the less chance you have to receive endorsements in time. Of course you have to manage a balance between a good connectivity and the processing power/memory required too handle the ...
I used this hack because of the lack of hardware rng support. The problem did never appear afterwards.
I already mentioned it in the Gitlab issue linked in the other answer and copied it here for convince.
I fixed the problem just know, the thing here was that i didn't realize until i noticed how i was receiving the balance of the contract that i had to send the atomized value of the amount in tez.
So basically the conversion is quite simple ...
You want the atomized value:
value(int/float) * 1 000 000
You want the int/float value instead of the atomized ...
The first and main issue you have is that setup is a method of class sp.Contract that is broken when you redefine it in your contract.
This should not be the case and must be fixed on the SmartPy side.
So rename setup anything else and it will work.
A second issue, entry points take two parameters self and params, not just one.
A third issue, contract=...
When you send a transaction to an empty address you have to pay 0.257 tez allocation fee and in your case that caused a problem:
At the block 930365 your balance was 1.336011 tez.
At the block 930366 you tried to send a transaction with amount 1.1 tez, baker fee 0.015913 tez and allocation fee 0.257 tez - it's 1.372913 tez in total.
As you can see, you ...
In order to limit storage consumption, the locations in the original .tz file that are used to originate contracts are not stored on chain. The only thing that can be reported from a runtime error is what is called the canonical location; an integer that uniquely determines the position of the FAILWITH instruction that triggered the error. It is computed as ...
First off, never risk more than you can afford. Secondly, your funds are not stuck. If you look at your address, https://tzstats.com/tz1WBKfsPLp94D7wscTRn8KFt9pBfEopdUYr, everything is still there. As the operation shows, the operation backtracked so, no, nothing transfered.
Restart your trezor and try the transfer again. Remember, your tokens are stored on ...
That was fixed in granadanet by this merge request: https://gitlab.com/tezos/tezos/-/merge_requests/2815
You need to add self.add_flag("initial-cast") in the contract constructor to solve the issue until mainnet adopts the new protocol.
Doing math on nats casts them to an int. The value needs to be casted back to a nat after the subtraction:
self.data.shop_items[item_to_purchase.key].amount = sp.as_nat(self.data.shop_items[item_to_purchase.key].amount - item_to_purchase.value)
SmartPy test interpreter already handles internal operations failures really well.
Here is an example: https://smartpy.io/ide?cid=QmV3nwdkwHGXdJbWwV8LDgm3TPbC49Es7Wm6GufMeh8Pz2&k=184987b7b8089b73396a
Please, don't provide incomplete examples. I always find myself wasting tremendous amounts of time just to put those examples to work.
It is not possible to cast an int to a string in Michelson.
I recommend you to have static error messages, such as:
SOME_ERROR = "SOME_ERROR"
# some contract
x_i = (sp.to_int(params.x + I))
y_j = (sp.to_int(params.y + j))
SmartPy also gives you the option to ...
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 ...
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 ...
Which client are you using to send the transaction? In the failing transaction you did not include the origination burn. However it seems that in a subsequent transaction you did include the origination burn and that it worked.
You should probably use the Micheline / JSON version created by SmartPy.io.
This is what is actually sent from SmartPy.io.
You also need to change the conseiljs.TezosParameterFormat.Michelson parameter into conseiljs.TezosParameterFormat.Micheline.
The problem is that the source address you're trying to delegate from is already registered as a baker. There are two situations that lead to the No_deletion error:
trying to withdraw delegation from a contract that is registered as a baker (https://gitlab.com/tezos/tezos/blob/91937213f09b0660482124fede5c9ce3010dbac3/src/proto_005_PsBabyM1/lib_protocol/...
You should find the identity.json, peers.json, version.json and config.json files under the ~/.tezos-node directory if you did not tell Tezos to use another data-dir with the --data-dir command option.
Here, ~/ stands for your home directory. The config.json file may not be present.
I/O errors can be triggered by many events. Most of the time, it is raised when the disk storage is full and the last validated block cannot be stored.
When an error occurs while validating a block, it is marked as rejected in the storage. The error will be raised each time the validator tries to validate that block.
To solve this problem you should first ...