To backup your wallet you will need to make a copy of the key file(s) located in your ethereum directory.
The file should look something like this:
I've suggested just saving the keystore ...
A replay attack is a valid data transmission that is maliciously or fraudulently repeated or delayed.
Extending this to blockchains, a replay attack is taking a transaction on one blockchain, and maliciously or fraudulently repeating it on another blockchain.
For example, an attacker taking someone's testnet transaction, and repeating it on the "real" ...
PLEASE MAKE SURE TO ALSO BACKUP YOUR PASSWORDS
Each key file (as described in @Ethan's answer) is encrypted and only usable with the correct password.
Another safety tip: Before deleting any key files, after you have done the backup, please try the import/restore process on another system to make sure you can send a small amount of Ether. (To import, copy ...
It means that a transaction that was valid on the Olympic testnet was still valid for next release (Frontier).
If you made a transaction T in Olympic that sends Ether from address A to B, and then reuse the key behind address A in the Frontier release, that transaction T could be broadcasted again (replayed) and the transfer from A to B would happen in ...
Some of the links in the comments helped me get the answers to my questions. I have collected all that information combined with my own (recently acquired) knowledge of cryptography from the Coursera Cryptography-I class (for the answer to question number 3).
A1. The private key is never (or should never be) saved unencrypted on disk. It is generated from ...
Forgot about this question until I saw some people up voting it. Now I know the answer so I'll share the differences between these two types of private keys.
Account Extended Private Key: This represents the extended private key derived with the BIP 44 derivation path m / purpose' / coin_type' / account' / chain / address_index
BIP32 Extended Private Key: ...
Ethereum is not your typical PKI infrastructure.
The public key is derived in a deterministic way from the private key - same private key always leads to the same public key. The public key is not "validated" in that sense by any authority - it's always valid. The private key can be chosen with whatever means.
Furthermore, the public key is used to ...
To avoid replay attack use EIP155 transaction types which are available since block 2675000. They incorporate chainID to the transaction signature. Make sure your wallet software is EIP155 enabled and you will be safe
Yes, all of the addresses shown in Mist are public keys. The encrypted private keys are stored in the keystore folder
The whole point of using scrypt is to make it costly to mount a brute force attack.
For a normal user to open an encrypted wallet it doesn't make much difference between scrypt and sha2, both are below 1 second.
But it makes a huge differece if you want to crack an encrypted wallet. For example let's say for each attempt with an scrypt wallet it will take ...
To answer a different part of your question, contracts are not black boxes. The entire code and storage is available for inspection by any external actor. Thus, it's impossible for an Ethereum smart contract to hold bitcoin--anyone could inspect the code and just sweep the keys.
Even if this was not the case, anyone could fork the blockchain and submit a ...
No, currenctly it is not possible to do it in a trustless way.
The difficult part is the interaction between the two chains. To make sure for a valid transaction in the ethereum contract there's a corresponding valid transaction in bitcoin, and viceversa.
There are some alternatives like BTC Relay, but they are not trustless.
There's a similar question: ...
Say I am an exchange that has many users. When I ask a user to deposit ETH I give him a unique address so I can attribute the ETH to him.
With Bitcoin this is easy. The bitcoin wallet software handles this and I can have BTC on multiple addresses and it's treated as one account.
I understand that with Ethereum this is different.
Not sure I understand what ...
As Ismail pointed out in the comments, I was generating the incorrect key type. Additionally, I was able to generate the key by concatenating the X and Y arrays from JWK. Here's my sample code I was playing with in F#. It uses BouncyCastle for the Keccak hash function.
Important thing to note is the use of "EC-HSM" key type. This is part of the Premium SKU ...
This does not seem too hard to achieve off chain.
You, and only you know the function signature of the withdrawal method in the deployed contract. As such, assuming you do not 'verify' the contract on a blockchain explorer, only you can sign a transaction to call that function.
There is nothing more to it..
Only sign a transaction for a user if they meet ...
There is no secrecy in Ethereum, hashing will not help you here. The only thing that comes to my mind here is
allow registered users to send HTTP requests to a nodejs server
this (and only this) server has access to a node with an unlocked account, whose address
corresponds to the address you give permission in your smart contract to do withdrawals.