As of 003_PsddFKi3:
An originated account is forever.
An implicit account is 'allocated' and 'deleted' as its balance goes above and back to zero (if it is not a delegate).
Currently you must pay a storage burn to allocate an implicit account, and there is no refund upon deletion. The storage_limit for an operation accounts for this burn (...
In the command line
./tezos-client get contract storage for KT1BRudFZEXLYANgmZTka1xCDN5nWTMWY7SZ
You could also just call the RPC
1) Here they are
$ ./tezos-client rpc get /chains/main/blocks/1/context/contracts | grep KT1
The difference is very simple :) The parameter is made of data that are sent to the contract with a transaction while the storage holds the state of the contract (i.e all the data that the contract saves to be reused later).
It is true that both the storage and the parameter can be seen as inputs because they are fed to the contract at the beginning of its ...
In the FA2.0 standard the sender and receiver is send as Bytes (vs. send as string for FA1.2).
Both token standards say that sender and receiver are Michelson addresses. Michelson addresses have two allowed representations, as strings (readable representation) and as bytes (optimized representation).
What is the extra byte used for?
The extra byte is used ...
Why can I convert between address and contract. But not between address and key_hash?
There is the (IMPLICIT_ACCOUNT) instruction to go from key_hash to address. For the other direction, there was (a feature request) but it was closed because no use case has been presented to motivate it.
key_hash is blake2b hash of a public key, in the base58 encoded form it can start only with tz, but address is more general, it can also hold KT accounts;
There are no instructions for that, probably because it's a rare and arguable case; EDIT: as pointed out by Raphaël, you can convert key_hash to contract and then to address using IMPLICIT_ACCOUNT ; ...
You cannot create a contract and call it immediately.
It goes like this, chronologically:
Your script is running. You invoke CREATE_CONTRACT or CREATE_ACCOUNT. An operation and address are returned and your script continues on. The operation will create the account after your script returns it. Right now, the account does not exist.
You now immediately try ...
No, whitespace and comments do not affect storage or gas costs.
The syntax of Michelson code and values is called "Micheline".
The concrete syntax (the way you actually write Micheline expressions in text, with whitespace and comments, etc) is used by clients for the convenience of humans. It is also validated to prevent some obfuscation tricks -- ...
In a scenario where both the TZ1 and KT1 addresses have been emptied, you can still send funds to your KT1 address. The KT1 contract never gets destroyed. You will however need fund your manager account again (TZ1 address) in order to move the funds you just sent to your KT1 address.
The delegation would remain active as long as you don't change or cancel ...
No - these are helper functions that provide typecheck and testing features.
You originate a contract via an operation (with kind origination), and you call it via a standard transaction and the parameter field.
In my understanding, you can call a contract by sending a parametrised transaction, that's injected as an operation under /injection/operation.
You can trace the flow above in the source of eztz.js.
/injection/operation doesn't return much more, but a hash of the operation you've just injected. (there is a mention of a $unistring although i'm not sure what ...
You are using a private key which do not correspond to any account on the alphanet.
It works with
liquidity --tezos-node http://alphanet-node.tzscan.io:80 --private-key edsk2j7Ka5nRzh2QkGCtcD1dFLbHYvYw7XAafWL3YEAQQ3Zd61NiqS --protocol alphanet simple.liq --deploy
Main contract Simple
New contract KT18bLbXyH5yMY9ShDfCwtiXegWHMTa4aS8H deployed in operation ...
As I understand the concepts, transferring tezos is one kind of contract. It has amount to move from account to another and the move is containing a transaction to track, that the operation gets through in meaningful time. So, actually tezos transfer is a small contract, sort of.
What about smart contract data types (is it amount of money in tezos, dollars, ...
The babylonnet was terminated about 2 weeks ago. It is no longer supported. You should be on carthagenet now.
"Waiting for the node to be bootstrapped" means your node is not yet synchronized with the rest of the network. You cannot submit operations until you are in sync. On carthagenet, this might take about 24 hrs to sync.
You created a contract which can only transfer funds when it receives a call to do so from its "manager" account which was specified at origination and is the only value the contract has in its storage.
The contract can be seen here https://better-call.dev/main/KT1VSiaepk9USGAHDjJQAm4aaYRC6J8dTBHG/operations
You can see that the storage has the value ...
The correct way to do this is simply:
def withdraw(self, amount):
The solidity translation tool I used didn't handle this properly
There is https://github.com/baking-bad/netezos, a .NET Standard 2.0 library for working with Tezos. You can easily use it to interact with Tezos node via RPC, manage keys (it also supports Ledger), forge and send operations, etc.
This library is actively developing (by the way, mscappini, author of Tz.Net, is also working with us on Netezos v2) and soon we ...
There is a bug in the SmartPy template (just discovered it).
You should either:
add other entry points to onEven and onOdd;
or remove the specification of sp.contract(..., entry_point = "run") in the main contract.
When you originated the Collatz contract, you needed two addresses for the initial storage; these two addresses have to be the addresses that you got when you originated the two previous contracts. Can you please show all the commands that you typed and all the answers that you got?
I think we are in the third case:
Maybe useful but none has yet proposed it with convincing use cases?
It is true that the keys must be given from the outside but so are the signatures so if one needs to combine signature checking and address-based authentication it is always possible to replace all occurrences of signature with pair key signature and ...
After further contract investigation, I found out that these operations are used for internal blockchain operations like transferring tez to an account or calling a contract with parameters.
These operations are created from Michelson stack elements and are a series of bytes which represent a forged operation.
There is a example on the official Tezos ...
The best way to estimate it is to use the CLI like you've done. Otherwise, you need to know the contract's high water mark (the most storage it ever held), the current size of its storage, whether the operation will increase the storage beyond the high water mark and if so by how much.
However, I note that in your screenshot you are transferring from a tz1 ...