Tag Info

There are several uses of cryptographic algorithms in the protocol. Accounts/Transactions To move money from one account to another, you need to collect some data (the previous transaction(s) which got you the money, the target account, the amount you want to transfer) and sign them, using the private key which belongs to your account. For this signature ...

For such a scheme to work, if I have some currency, I have to be able to give it to Abel and I have to be able to give it to Beth, but I have to be unable to give it to both Abel and Beth. This means that giving the currency to Abel has to somehow make me unable to give the currency to Beth even though I previously could do that. There are three mechanisms ...

I don't believe that there's any way to generate the vanity hashes without iterating. In base 58, there's $\log_2(58) \approx 5.858$ bits per letter, so fixing 8 letters would need in average $58^8/2 = 2^{\log_2(58)·8}/2 \approx 2^{46}$ iterations. Note that Bitcoin addresses always start with a 1 by convention (this comes from the version field), and ...

I have a list of Bitcoin-related publications here: Bitcoin Bibliography (Crypto & Security) They are all the academic papers (as opposed to whitepapers) that I know about, relating to security or cryptographic aspects (as opposed to economic or implementation aspects) of Bitcoin. Most are published.

Most of what the bitcoin system does consists of using well-known algorithms for their intended purposes. It is unlikely that there will be a fundamental or algorithmic problem in these parts of the system. There may be a software bug in the reference client, of course. There once was such a bug -- an overflow bug that allowed people to create transactions ...

The classic way to do this is to have all parties commit to individual random values by publishing a secure hash of a suitably random-nonce-padded number. Once the commitments have been distributed, the parties open the commitments by publishing the nonce and the number. The numbers are combined in some previously agreed suitable fashion such as adding them ...

All transactions which transfer money from address A need to be signed by the private key for address A which you don't have. The signature of course also covers the destination address B which stops you changing the transaction to redirect the money. The network does not pay attention to blocks which contain invalid signatures.

Here's the Research article on the Bitcoin wiki: http://en.bitcoin.it/wiki/Research You might find some of the authors in the list have related research that is not directly related to Bitcoin so is absent from that list.

SHA-256 uses an internal compression function $f$ which takes two inputs, of size 512 and 256 bits respectively, and outputs 256 bits. Hashing works like this: Input message $M$ is first padded by appending between 129 and 640 bits (inclusive), resulting into a padded message $M'$ whose length (in bits) is a multiple of 512. $M'$ is split into $n$ ...

The SHA-256 algorithm works by applying an encryption function in Davies-Meyer mode and Merkle-Damgård chaining. Merkle-Damgård works by first dividing the message to-be-hashed into chunks. In the case of SHA-256 these chunks are 64 octets long. Because Merkle-Damgård chaining is used, the internal state after processing the first 64 octet chunk depends only ...

A service that provides such numbers is called a random beacon. Since everyone has to agree on what a beacon's value is and peers may not have a complete view of the network, it is very difficult to construct a universally verifiable value using only internal network data. Since data only becomes canonical when it is included in a block (a block that is ...

I would assume that all the operations are to be done in the elliptic curve group (viewed as a module over $\mathbb Z/k\mathbb Z$, where $k$ is the order of the group), so that addition is the group operation and multiplication is elliptic curve point multiplication. That is to say, assume we have an elliptic curve $E$, equipped with the point addition ...

Bitcoin doesn't use RSA, it uses ECDSA. Every 256-bit value is a valid private key. (Though a very small fraction of them have to be folded.) But even if the numbers had to be special, it still wouldn't matter. You could use every 256-bit value as a seed to a pseudo-random number generator which you could use to deterministically generate numbers that had ...

About the best you can do is have a master public/private key pair where the public key is stored on your server and the private key is stored offline. When you generate a new private key, encrypt it with the master public key and store that in the database. That way, if a password is ever lost, you can recover the user's private key by using the master ...

At the core of your question is a concept called entropy, which is the amount of uncertainty or unpredictability in a set of data. In cryptography, entropy is related to probabilities, expressed in terms of powers of 2 (bits.) For example, a fair coin flip has one bit of entropy: it can be either heads (1) or tails (0). Flipping four coins gives you ...

A good hash doesn't give you any information about password length or anything else. The only attack against such a hash is guessing the password, and then using the hash to verify if it was correct. Depending on the hashing scheme, the cost per guess can vary widely. For example with plain MD5 a single graphics card can try several billion guesses per ...

I made a cool 5 word passphrase back then using the old Diceware method and use it as a master password. The question is as computing power increases will we need to add more and more words to our passphrases which we will eventually forget? I'm in my mid 30s, will passphrases be enough in my lifetime? :) So back then, Diceware suggested just 5 ...

This is a well-known problem from the secure multi-party computation literature, known as the coin-tossing problem. Several people want to get together and jointly generate an unbiased coin toss, where the security property is that no one can influence the bias of the coin. The problem is impossible if adversaries are allowed to be computationally ...