Option 1 Kukai
First make sure you have a secure offline environment for your wallet. You can either have a dedicated computer for it or a bootable Linux USB Flash Drive (with e.g. Tails) that never connects to internet.
Always download the Kukai wallet from the official links on Github and verify the SHA256 checksum. It is ...
Here is how the import works for you:
you download a snapshot from a usb key found in a dark alley
you start importing it, it displays the block hash it is importing
you check in several places that this hash is indeed from the main chain
if it checks up, you let it continue
Here is what the snapshot must contain (full variant):
the current state of the ...
Michelson (and higher level language like Liquidity on top of it) does not allow a smart contract to call another smart contract without commmitting its state/storage first. It makes reentrancy attacks less likely to happen, but not impossible.
All transactions included in the Tezos must reference a block hash within the past 60 block hashes. This acts as an additional layer of notarization of the chain, besides the consensus but it means you need a few extra steps to sign transactions offline.
One way to do this is to use the RPC:
At the present time about 80% of the tezos tokens are actively used to bake/stake so the circulating supply you can buy on exchange is quite low.
Therefore it would not even possible currently for an attacker to purchase 51% of tezos token and become a "majority holder".
Now the consensus protocol itself would not allow a 51% holder to double spend just ...
So this is a huge question and I think there are many people more qualified than me, but I'll offer some initial guidance.
In Software Foundations, a book on Coq, they talk about an implied language called Imp. Imp has a syntax like:
Z ::= X;;
Y ::= 1;;
WHILE ~(Z = 0) DO
Y ::= Y * Z;;
Z ::= Z - 1
Which should be somewhat easily understood as ...
Short answer is no it is not.
DDOS is actually a secondary security concern when baking. First and foremost you should be securing access to your baking server and your private keys. If someone gains access to your server and your keys they can steal your Tezos which is a lot worse than simply loosing your rewards which is the consequence of a DDOS attack.
If the key is generated on their server, you have no way to know.
If the key is generated locally in your browser, you may try to monitor the network to see what the wallet sends to the server. However, it might still find other ways to get the key, for example by waiting a random time before sending it, by encrypting the communication, or just by limiting ...
If we agree that the purpose of analyses is to both prove properties and help users of smart contracts to understand them, I would say:
Values: studying what values each element of the storage can take in the future.
Effects: studying what effects can occur in the future: typically what transfers can occur and on what conditions.
Ownership: who can trigger ...
When you launch the docker node with ./mainnet.sh start, you can add extra arguments such as --private-mode --peer AAA.BBB.CCC.DDD:PORT (you probably need to specify --peer to connect your private node to your public node).
It's something to be careful about. If you look in scripts/version.sh you will see that the opam repository is pinned to a particular hash. This enforces Tezos being compiled against a specific version of the package repository.
This helps a great deal, and protects against the repository being hacked for instance. However, that repo hash may need to be ...
How to check the proof
Currently, the only way to check the proof is to install and run the Coq proof assistant on the manager.tz file. This is automated in the continuous integration script of the Mi-Cho-Coq project so you can see it here.
In the future, we plan to use JsCoq to run Mi-Cho-Coq proofs from web browsers.
What is proved
The family of ...
The trust relies in two elements:
the hash of the last block in the snapshot (is it really on the official chain ?)
the source code of your node (is it really doing what you think it does ?)
For (1), you have to check multiple trusted sources. You can check on TzScan or another block explorer that the hash is in the main chain. You can also directly query ...
Hardware wallets like the Ledger Nano are good cold storage solutions.
Offline-wallet creation in an air-gap device is also a good solution.
Kukai wallet offers you the possibility to do offline-signing so your seed is never exposed to the online world when interacting with the network.
Any wallet software you choose to run comes with risks you should be fully aware of in order to properly protect yourself.
Whether its a web, desktop, or mobile app you are running code that someone else wrote and the best way to reduce the risk is to make sure you are using software that is open source and has been verified by the community as coming from ...
The delegators have nothing to do with the validity of the transactions signed by their delegate/baker. The delegated funds are never at risk and that is why it is always safe to delegate your tokens.
The example you gave of a baker including a "bad" transaction in its block is handled by the endorsers. They will not endorse this block and the bad baker won'...
If you delegate this is not an issue for you. You can delegate to a baking service and then put your keys in cold storage (offline). You still control the funds. This is one of the real nice things about LPOS 😉
The only thing that can happen is that the baker shuts down or misbehaves. In this case you would not lose your tokens, but you would not collect ...
Highly recommend learning how to bake without bake chain. Running a bakery requires certain skills, like being able to work with the tezos client. If that is too daunting, then frankly, you do not inspire much confidence. Also, using VPS makes using Ledger Nano difficult, which is highly recommended to be used for security purposes. Good luck.
With regards to the difference between public key (pk), secret key (sk) and public key hash (pkh).
The public key is used by other people to send encrypted messages to you, and it is also used by other people to verify that messages you send actually are from you
The secret key is used by you to send messages
The public key hash is used to identify your ...
As @utdrmac mentioned, it is not possible to reverse engineer the private key from the public key. Public Key is created from a Private Key using one-way functions (also called trapdoor) which is easy to do but the reverse process of finding a Private Key from a Public Key is practically impossible. Sharing a few links below to give you a better idea about ...
No, it is not. Public keys are derived from the private key. Imagine if I had your public key (which is public information) and all I needed was your password to gain access to all of your funds. That would be extremely insecure. A simple brute-force password guessing system could handle that in a couple weeks, depending on how complex your password is.
Thanks for asking! See the answer I provided on this question - Kiln supporting bip32-ed25519 addreses. I'll copy it here for convenience:
Tezos has adopted this new derivation scheme because it improves security. Backstory: because this update involves BIP32 (Bitcoin Improvement Proposal 32), it is important to contrast how addresses are used in Bitcoin ...
You must sign transactions from tz2 addresses with secp256k1. Eztz's sign function uses Ed25519, so that wont work. Easiest would probably be to just replace libsodium in eztz with something like bitcoinjs-lib.