https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Adam3us&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T14:49:31ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Hashcash&diff=54506Hashcash2015-02-21T10:51:50Z<p>Adam3us: /* Work, difficulty & cryptographic security */</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by Microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256. There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage.<br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
===Future Hash===<br />
<br />
Once the NIST SHA3 contest has finalised, bitcoin might in the future consider adopting hashcash-SHA3 as a security upgrade (eg a single invocation of SHA3 vs a double invocation of SHA256). It seems clear from the SHA1 break, and SHA256 is a similar design, that there was previously a misunderstanding about the security of hash functions against birthday collisions, and SHA3 finalists all aim to fix that issue. One aspect of relevance for hashcash-SHA3 is that there is some debate within the NIST comments process on the proposal of weakening SHA3's resistance to pre-image attacks down to 128-bit (vs the full hash size as with previous hashes). The motivation is a small performance gain, with the rationale that some hash-pluggable algorithms do not rely on full-length pre-image resistance. The proposal has met with significant negative feedback due to it creating a non-standard security assumption (compared to all previous hashes), and therefore it creates risk and all hash-pluggable algorithms (like HMAC, RSA, DSA, hashcash etc) would need to be re-examined on a case by case basis to see if SHA3 is safe to use with them; from the balance of the feedback it seems probable that NIST will accept the feedback and SHA3 will retain the full 256-bit pre-image resistance. <br />
<br />
===Cryptanalytic Risks===<br />
<br />
A practical issue with switching to hashcash-SHA3 is that it would invalidate all existing ASIC mining hardware, and so is a change that would unlikely to be made except in the face of security risk; there is no indication that SHA1 or SHA256, or SHA256^2 are vulnerable to pre-image attack so the motivation is missing absent new cryptanalytic developments. In addition even if SHA256^2 became easier due to cryptanalytic attack, and miners started using whatever the new algorithmic approach was, it does not necessarily matter as difficulty would just adapt to it. One likely side-effect however would be that it would introduce more memory or pre-computation tradeoffs which could make ASICs unprofitable, or give advantages to people with large resources to do the pre-computations. Pre-computation advantages would perhaps be enough motivation to replace the hash with SHA3. Anyway this is all speculation if and until any pre-image affecting cryptanalytic attacks are found on SHA256.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but it's very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie, the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they don't know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targeted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of Nov 2013 hashrate is 4 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 62-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10 minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF0000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF0000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a petahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hours to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 62-bits (including +1 for double hash) every 10-minutes and is 537,000 times more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 9 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Scrypt proof-of-work===<br />
<br />
It is a misunderstanding to talk about the Scrypt proof-of-work.<br />
Scrypt is not intended as a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Hashcash with the internal hash function of Scrypt may be denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
This does not use the key-stretching feature of Scrypt so mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. This hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (usually 128kB).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. It's arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small Kickstarter project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Block_hashing_algorithm&diff=52557Block hashing algorithm2014-11-02T00:07:16Z<p>Adam3us: refer to hashcash page rather than duplicating a simplified partial explanation inline</p>
<hr />
<div>Bitcoin mining uses the [[hashcash]] proof of work function; the hashcash algorithm requires the following parameters: a service string, a nonce, and a counter. In bitcoin the service string is encoded in the block header data structure, and includes a version field, the hash of the previous block, the root hash of the merkle tree of all transactions in the block, the current time, and the difficulty. Bitcoin stores the nonce in the extraNonce field which is part of the coinbase transaction, which is stored as the left most leaf node in the merkle tree (the coinbase is the special first transaction in the block). The counter parameter is small at 32-bits so each time it wraps the extraNonce field must be incremented (or otherwise changed) to avoid repeating work.<br />
The basics of the hashcash algorithm are quite easy to understand and it is described in more detail [[hashcash|here]].<br />
When mining bitcoin, the hashcash algorithm repeatedly hashes the block header while incrementing the counter & extraNonce fields. Incrementing the extraNonce field entails recomputing the merkle tree, as the coinbase transaction is the left most leaf node. The block is also occasionally updated as you are working on it. <br />
<br />
A block header contains these fields:<br />
{| class="wikitable"<br />
|-<br />
! Field<br />
! Purpose<br />
! Updated when...<br />
! Size (Bytes)<br />
|-<br />
|Version<br />
|Block version number<br />
|You upgrade the software and it specifies a new version<br />
|4<br />
|-<br />
|hashPrevBlock<br />
|256-bit hash of the previous block header<br />
|A new block comes in<br />
|32<br />
|-d<br />
|hashMerkleRoot<br />
|256-bit hash based on all of the transactions in the block<br />
|A transaction is accepted<br />
|32<br />
|-<br />
|Time<br />
|Current timestamp as seconds since 1970-01-01T00:00 UTC<br />
|Every few seconds<br />
|4<br />
|-<br />
|Bits<br />
|Current [[target]] in compact format<br />
|The [[difficulty]] is adjusted<br />
|4<br />
|-<br />
|Nonce<br />
|32-bit number (starts at 0)<br />
|A hash is tried (increments)<br />
|4<br />
|}<br />
<br />
The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.<br />
<br />
The compact format of target is a special kind of floating-point encoding using 3 bytes mantissa, the leading byte as exponent (where only the 5 lowest bits are used) and its base is 256.<br />
Most of these fields will be the same for all users. There might be some minor variation in the timestamps. The nonce will usually be different, but it increases in a strictly linear way. "Nonce" starts at 0 and is incremented for each hash. Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root.<br />
<br />
The nonce parameter (extraNonce field in bitcoin) is designed to prevent different miners accidentally or maliciously generating the same hash. In addition it is extremely unlikely for two people However, it is (nearly) impossible for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of ''your'' unique Bitcoin addresses. Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network.<br />
<br />
Bitcoin uses: SHA256(SHA256(Block_Header)) but you have to be careful about byte-order.<br />
<br />
For example, this python code will calculate the hash of the block with the smallest hash as of June 2011, [http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d Block 125552]. The header is built from the six fields described above, concatenated together as little-endian values in hex notation:<br />
<br />
>>> import hashlib<br />
>>> header_hex = ("01000000" +<br />
"81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +<br />
"e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +<br />
"c7f5d74d" +<br />
"f2b9441a" +<br />
"42a14695")<br />
>>> header_bin = header_hex.decode('hex')<br />
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()<br />
>>> hash.encode('hex_codec')<br />
'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'<br />
>>> hash[::-1].encode('hex_codec')<br />
'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'<br />
<br />
Note that the actual hash, which is a 256-bit number, has lots of leading zero bits. When stored or printed as a big-endian hexadecimal constant, but it has leading zero bytes and if stored or printed as little-endian, these are the trailing zero bytes. E.g. if interpretation as a string -- lowest (or start of) string address keeps lowest significant byte, thus little-endian.<br />
The output of [http://blockexplorer.com blockexplorer] displays the hash values as big-endians numbers as notation for numbers is usual -- leading digits are the most significant digits read from left to right.<br />
<br />
For another example, [http://pastebin.com/bW3fQA2a here] is a version in plain C without any optimization, threading or error checking.<br />
<br />
Here is the same example in plain PHP without any optimization.<br />
<br />
<?<br />
//This reverses and then swaps every other char<br />
function SwapOrder($in){<br />
$Split = str_split(strrev($in));<br />
$x='';<br />
for ($i = 0; $i < count($Split); $i+=2) {<br />
$x .= $Split[$i+1].$Split[$i];<br />
} <br />
return $x;<br />
}<br />
<br />
//makes the littleEndian<br />
function littleEndian($value){<br />
return implode (unpack('H*',pack("V*",$value)));<br />
}<br />
<br />
$version = littleEndian(1);<br />
$prevBlockHash = SwapOrder('00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81');<br />
$rootHash = SwapOrder('2b12fcf1b09288fcaff797d71e950e71ae42b91e8bdb2304758dfcffc2b620e3');<br />
$time = littleEndian(1305998791);<br />
$bits =littleEndian( 440711666); <br />
$nonce = littleEndian(2504433986); <br />
<br />
//concat it all<br />
$header_hex = $version . $prevBlockHash . $rootHash . $time . $bits . $nonce;<br />
<br />
//convert from hex to binary <br />
$header_bin = hex2bin($header_hex);<br />
//hash it then convert from hex to binary <br />
$pass1 = hex2bin( hash('sha256', $header_bin ) );<br />
//Hash it for the seconded time<br />
$pass2 = hash('sha256', $pass1);<br />
//fix the order<br />
$FinalHash = SwapOrder($pass2);<br />
<br />
echo $FinalHash;<br />
?><br />
<br />
<br />
[[Category:Technical]]</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Proof_of_work&diff=45011Proof of work2014-03-15T00:22:09Z<p>Adam3us: /* Traditional proof of work */ correction it is based on cuckoo hash cycles, not cuckoo hash directly</p>
<hr />
<div>A '''proof of work''' is a piece of data which was difficult (costly, time-consuming) to produce so as to satisfy certain requirements. It must be trivial to check whether data satisfies said requirements. Producing a proof of work can be a random process with low probability, so that a lot of trial and error is required ''on average'' before a valid proof of work is generated. Bitcoin uses the [[Hashcash]] proof of work.<br />
<br />
One application of this idea is using [http://en.wikipedia.org/wiki/Hashcash hascash] as a method to preventing email spam, requiring a proof of work on the email's contents (including the To address), on every email. Legitimate emails will be able to do the work to generate the proof easily (not much work is required for a single email), but mass spam emailers will have difficulty generating the required proofs (which would require huge computational resources).<br />
<br />
Hashcash proofs of work are used in Bitcoin for block generation. Proofs of work that are tied to the data of each block are required for the blocks to be accepted. The [[difficulty]] of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes. Due to the very low probability of successful generation, this makes it unpredictable which worker computer in the network will be able to generate the next block.<br />
<br />
For a block to be valid it must hash to a value less than the current [[target]]; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceding block, thus each block has a [[block chain|chain]] of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.<br />
<br />
== Example ==<br />
<br />
Let's say the base string that we are going to do work on is "Hello, world!". Our target is to find a variation of it that SHA-256 hashes to a value beginning with '000'. We vary the string by adding an integer value to the end called a [[nonce]] and incrementing it each time. Finding a match for "Hello, world!" takes us 4251 tries (but happens to have zeroes in the first four digits):<br />
<br />
"Hello, world!0" => 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64<br />
"Hello, world!1" => e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8<br />
"Hello, world!2" => ae37343a357a8297591625e7134cbea22f5928be8ca2a32aa475cf05fd4266b7<br />
...<br />
"Hello, world!4248" => 6e110d98b388e77e9c6f042ac6b497cec46660deef75a55ebc7cfdf65cc0b965<br />
"Hello, world!4249" => c004190b822f1669cac8dc37e761cb73652e7832fb814565702245cf26ebb9e6<br />
"Hello, world!4250" => 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9<br />
<br />
4251 hashes on a modern computer is not very much work (most computers can achieve at least 4 million hashes per second). Bitcoin automatically varies the [[difficulty]] (and thus the amount of work required to generate a block) to keep a roughly constant rate of block generation. The probability of a single hash succeeding can be found [http://blockexplorer.com/q/probability here].<br />
<br />
In Bitcoin things are a bit more complex, especially since the header contains the [http://en.wikipedia.org/wiki/Merkle_tree Merkle tree] which depends on the included [[transactions]]. This includes the generation transaction, a transaction "out of nowhere" to our own address, which in addition to providing the miner with incentive to do the work, also ensures that every miner hashes a unique data set.<br />
<br />
== List of algorithms ==<br />
<br />
=== Traditional proof of work ===<br />
# hashcash with double iterated SHA256<br />
# hashcash with [[scrypt]] internal hash<br />
# [[Momentum]] birthday collision<br />
# Cuckoo cycle proof of work https://github.com/tromp/cuckoo <br />
# Various other proof of works functions (e.g. [[Ethereum]] had a few candidates)<br />
<br />
=== Proof of X ===<br />
# [[Proof of Stake]] (Used in [[Peercoin]], [[Nxt]])<br />
# [[Proof of Burn]] (Used for the [[Counterparty]] IPO)<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Proof_of_work&diff=44988Proof of work2014-03-13T18:01:39Z<p>Adam3us: /* Traditional proof of work */ clarify scrypt is hashcash, link to cuckoo</p>
<hr />
<div>A '''proof of work''' is a piece of data which was difficult (costly, time-consuming) to produce so as to satisfy certain requirements. It must be trivial to check whether data satisfies said requirements. Producing a proof of work can be a random process with low probability, so that a lot of trial and error is required ''on average'' before a valid proof of work is generated. Bitcoin uses the [[Hashcash]] proof of work.<br />
<br />
One application of this idea is using [http://en.wikipedia.org/wiki/Hashcash hascash] as a method to preventing email spam, requiring a proof of work on the email's contents (including the To address), on every email. Legitimate emails will be able to do the work to generate the proof easily (not much work is required for a single email), but mass spam emailers will have difficulty generating the required proofs (which would require huge computational resources).<br />
<br />
Hashcash proofs of work are used in Bitcoin for block generation. Proofs of work that are tied to the data of each block are required for the blocks to be accepted. The [[difficulty]] of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes. Due to the very low probability of successful generation, this makes it unpredictable which worker computer in the network will be able to generate the next block.<br />
<br />
For a block to be valid it must hash to a value less than the current [[target]]; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceding block, thus each block has a [[block chain|chain]] of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.<br />
<br />
== Example ==<br />
<br />
Let's say the base string that we are going to do work on is "Hello, world!". Our target is to find a variation of it that SHA-256 hashes to a value beginning with '000'. We vary the string by adding an integer value to the end called a [[nonce]] and incrementing it each time. Finding a match for "Hello, world!" takes us 4251 tries (but happens to have zeroes in the first four digits):<br />
<br />
"Hello, world!0" => 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64<br />
"Hello, world!1" => e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8<br />
"Hello, world!2" => ae37343a357a8297591625e7134cbea22f5928be8ca2a32aa475cf05fd4266b7<br />
...<br />
"Hello, world!4248" => 6e110d98b388e77e9c6f042ac6b497cec46660deef75a55ebc7cfdf65cc0b965<br />
"Hello, world!4249" => c004190b822f1669cac8dc37e761cb73652e7832fb814565702245cf26ebb9e6<br />
"Hello, world!4250" => 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9<br />
<br />
4251 hashes on a modern computer is not very much work (most computers can achieve at least 4 million hashes per second). Bitcoin automatically varies the [[difficulty]] (and thus the amount of work required to generate a block) to keep a roughly constant rate of block generation. The probability of a single hash succeeding can be found [http://blockexplorer.com/q/probability here].<br />
<br />
In Bitcoin things are a bit more complex, especially since the header contains the [http://en.wikipedia.org/wiki/Merkle_tree Merkle tree] which depends on the included [[transactions]]. This includes the generation transaction, a transaction "out of nowhere" to our own address, which in addition to providing the miner with incentive to do the work, also ensures that every miner hashes a unique data set.<br />
<br />
== List of algorithms ==<br />
<br />
=== Traditional proof of work ===<br />
# hashcash with double iterated SHA256<br />
# hashcash with [[scrypt]] internal hash<br />
# [[Momentum]] birthday collision<br />
# Cuckoo hash proof of work https://github.com/tromp/cuckoo <br />
# Various other proof of works functions (e.g. [[Ethereum]] had a few candidates)<br />
<br />
=== Proof of X ===<br />
# [[Proof of Stake]] (Used in [[Peercoin]], [[Nxt]])<br />
# [[Proof of Burn]] (Used for the [[Counterparty]] IPO)<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42160Hashcash2013-11-03T14:20:05Z<p>Adam3us: /* Work, difficulty & cryptographic security */ fix exa/peta confusion, previous was correct</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256. There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage.<br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
===Future Hash===<br />
<br />
Once the NIST SHA3 contest has finalised, bitcoin might in the future consider adopting hashcash-SHA3 as a security upgrade (eg a single invocation of SHA3 vs a double invocation of SHA256). It seems clear from the SHA1 break, and SHA256 is a similar design, that there was previously a misunderstanding about the security of hash functions against birthday collisions, and SHA3 finalists all aim to fix that issue. One aspect of relevance for hashcash-SHA3 is that there is some debate within the NIST comments process on the proposal of weakening SHA3's resistance to pre-image attacks down to 128-bit (vs the full hash size as with previous hashes). The motivation is a small performance gain, with the rationale that some hash-pluggable algorithms do not rely on full-length pre-image resistance. The proposal has met with significant negative feedback due to it creating a non-standard security assumption (compared to all previous hashes), and therefore it creates risk and all hash-pluggable algorithms (like HMAC, RSA, DSA, hashcash etc) would need to be re-examined on a case by case basis to see if SHA3 is safe to use with them; from the balance of the feedback it seems probable that NIST will accept the feedback and SHA3 will retain the full 256-bit pre-image resistance. <br />
<br />
===Cryptanalytic Risks===<br />
<br />
A practical issue with switching to hashcash-SHA3 is that it would invalidate all existing ASIC mining hardware, and so is a change that would unlikely to be made except in the face of security risk; there is no indication that SHA1 or SHA256, or SHA256^2 are vulnerable to pre-image attack so the motivation is missing absent new cryptanalytic developments. In addition even if SHA256^2 became easier due to cryptanalytic attack, and miners started using whatever the new algorithmic approach was, it does not necessarily matter as difficulty would just adapt to it. One likely side-effect however would be that it would introduce more memory or pre-computation tradeoffs which could make ASICs unprofitable, or give advantages to people with large resources to do the pre-computations. Pre-computation advantages would perhaps be enough motivation to replace the hash with SHA3. Anyway this is all speculation if and until any pre-image affecting cryptanalytic attacks are found on SHA256.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor ie the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of Nov 2013 hashrate is 4 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 62-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a petahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hours to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 62-bits (including +1 for double hash) every 10-minutes and is 537,000 times more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 9 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42159Hashcash2013-11-03T13:56:47Z<p>Adam3us: /* Work, difficulty & cryptographic security */</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256. There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage.<br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
===Future Hash===<br />
<br />
Once the NIST SHA3 contest has finalised, bitcoin might in the future consider adopting hashcash-SHA3 as a security upgrade (eg a single invocation of SHA3 vs a double invocation of SHA256). It seems clear from the SHA1 break, and SHA256 is a similar design, that there was previously a misunderstanding about the security of hash functions against birthday collisions, and SHA3 finalists all aim to fix that issue. One aspect of relevance for hashcash-SHA3 is that there is some debate within the NIST comments process on the proposal of weakening SHA3's resistance to pre-image attacks down to 128-bit (vs the full hash size as with previous hashes). The motivation is a small performance gain, with the rationale that some hash-pluggable algorithms do not rely on full-length pre-image resistance. The proposal has met with significant negative feedback due to it creating a non-standard security assumption (compared to all previous hashes), and therefore it creates risk and all hash-pluggable algorithms (like HMAC, RSA, DSA, hashcash etc) would need to be re-examined on a case by case basis to see if SHA3 is safe to use with them; from the balance of the feedback it seems probable that NIST will accept the feedback and SHA3 will retain the full 256-bit pre-image resistance. <br />
<br />
===Cryptanalytic Risks===<br />
<br />
A practical issue with switching to hashcash-SHA3 is that it would invalidate all existing ASIC mining hardware, and so is a change that would unlikely to be made except in the face of security risk; there is no indication that SHA1 or SHA256, or SHA256^2 are vulnerable to pre-image attack so the motivation is missing absent new cryptanalytic developments. In addition even if SHA256^2 became easier due to cryptanalytic attack, and miners started using whatever the new algorithmic approach was, it does not necessarily matter as difficulty would just adapt to it. One likely side-effect however would be that it would introduce more memory or pre-computation tradeoffs which could make ASICs unprofitable, or give advantages to people with large resources to do the pre-computations. Pre-computation advantages would perhaps be enough motivation to replace the hash with SHA3. Anyway this is all speculation if and until any pre-image affecting cryptanalytic attacks are found on SHA256.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor ie the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in TH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of Nov 2013 hashrate is 3.8 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 72-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a petahash/second is a 19 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hours to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 72-bits (including +1 for double hash) every 10-minutes and is 21 million times more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 9.4 ms (106 DES keys per second) to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42153Hashcash2013-11-03T11:32:35Z<p>Adam3us: /* Work, difficulty & cryptographic security */ fix power multiple</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256. There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage.<br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
===Future Hash===<br />
<br />
Once the NIST SHA3 contest has finalised, bitcoin might in the future consider adopting hashcash-SHA3 as a security upgrade (eg a single invocation of SHA3 vs a double invocation of SHA256). It seems clear from the SHA1 break, and SHA256 is a similar design, that there was previously a misunderstanding about the security of hash functions against birthday collisions, and SHA3 finalists all aim to fix that issue. One aspect of relevance for hashcash-SHA3 is that there is some debate within the NIST comments process on the proposal of weakening SHA3's resistance to pre-image attacks down to 128-bit (vs the full hash size as with previous hashes). The motivation is a small performance gain, with the rationale that some hash-pluggable algorithms do not rely on full-length pre-image resistance. The proposal has met with significant negative feedback due to it creating a non-standard security assumption (compared to all previous hashes), and therefore it creates risk and all hash-pluggable algorithms (like HMAC, RSA, DSA, hashcash etc) would need to be re-examined on a case by case basis to see if SHA3 is safe to use with them; from the balance of the feedback it seems probable that NIST will accept the feedback and SHA3 will retain the full 256-bit pre-image resistance. <br />
<br />
===Cryptanalytic Risks===<br />
<br />
A practical issue with switching to hashcash-SHA3 is that it would invalidate all existing ASIC mining hardware, and so is a change that would unlikely to be made except in the face of security risk; there is no indication that SHA1 or SHA256, or SHA256^2 are vulnerable to pre-image attack so the motivation is missing absent new cryptanalytic developments. In addition even if SHA256^2 became easier due to cryptanalytic attack, and miners started using whatever the new algorithmic approach was, it does not necessarily matter as difficulty would just adapt to it. One likely side-effect however would be that it would introduce more memory or pre-computation tradeoffs which could make ASICs unprofitable, or give advantages to people with large resources to do the pre-computations. Pre-computation advantages would perhaps be enough motivation to replace the hash with SHA3. Anyway this is all speculation if and until any pre-image affecting cryptanalytic attacks are found on SHA256.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor ie the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of Nov 2013 hashrate is 3.8 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 72-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a petahash/second is a 19 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hours to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 72-bits (including +1 for double hash) every 10-minutes and is 21 million times more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 9.4 ms (106 DES keys per second) to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42152Hashcash2013-11-03T11:27:51Z<p>Adam3us: /* Work, difficulty & cryptographic security */ more fixing peta vs exa confusion</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256. There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage.<br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
===Future Hash===<br />
<br />
Once the NIST SHA3 contest has finalised, bitcoin might in the future consider adopting hashcash-SHA3 as a security upgrade (eg a single invocation of SHA3 vs a double invocation of SHA256). It seems clear from the SHA1 break, and SHA256 is a similar design, that there was previously a misunderstanding about the security of hash functions against birthday collisions, and SHA3 finalists all aim to fix that issue. One aspect of relevance for hashcash-SHA3 is that there is some debate within the NIST comments process on the proposal of weakening SHA3's resistance to pre-image attacks down to 128-bit (vs the full hash size as with previous hashes). The motivation is a small performance gain, with the rationale that some hash-pluggable algorithms do not rely on full-length pre-image resistance. The proposal has met with significant negative feedback due to it creating a non-standard security assumption (compared to all previous hashes), and therefore it creates risk and all hash-pluggable algorithms (like HMAC, RSA, DSA, hashcash etc) would need to be re-examined on a case by case basis to see if SHA3 is safe to use with them; from the balance of the feedback it seems probable that NIST will accept the feedback and SHA3 will retain the full 256-bit pre-image resistance. <br />
<br />
===Cryptanalytic Risks===<br />
<br />
A practical issue with switching to hashcash-SHA3 is that it would invalidate all existing ASIC mining hardware, and so is a change that would unlikely to be made except in the face of security risk; there is no indication that SHA1 or SHA256, or SHA256^2 are vulnerable to pre-image attack so the motivation is missing absent new cryptanalytic developments. In addition even if SHA256^2 became easier due to cryptanalytic attack, and miners started using whatever the new algorithmic approach was, it does not necessarily matter as difficulty would just adapt to it. One likely side-effect however would be that it would introduce more memory or pre-computation tradeoffs which could make ASICs unprofitable, or give advantages to people with large resources to do the pre-computations. Pre-computation advantages would perhaps be enough motivation to replace the hash with SHA3. Anyway this is all speculation if and until any pre-image affecting cryptanalytic attacks are found on SHA256.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor ie the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of Nov 2013 hashrate is 3.8 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 72-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a petahash/second is a 19 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hours to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 72-bits (including +1 for double hash) every 10-minutes and is 35.7 million times more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 9.4 ms (106 DES keys per second) to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42148Hashcash2013-11-02T23:49:51Z<p>Adam3us: /* Work, difficulty & cryptographic security */ replace exa with peta, leftover mistake</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256. There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage.<br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
===Future Hash===<br />
<br />
Once the NIST SHA3 contest has finalised, bitcoin might in the future consider adopting hashcash-SHA3 as a security upgrade (eg a single invocation of SHA3 vs a double invocation of SHA256). It seems clear from the SHA1 break, and SHA256 is a similar design, that there was previously a misunderstanding about the security of hash functions against birthday collisions, and SHA3 finalists all aim to fix that issue. One aspect of relevance for hashcash-SHA3 is that there is some debate within the NIST comments process on the proposal of weakening SHA3's resistance to pre-image attacks down to 128-bit (vs the full hash size as with previous hashes). The motivation is a small performance gain, with the rationale that some hash-pluggable algorithms do not rely on full-length pre-image resistance. The proposal has met with significant negative feedback due to it creating a non-standard security assumption (compared to all previous hashes), and therefore it creates risk and all hash-pluggable algorithms (like HMAC, RSA, DSA, hashcash etc) would need to be re-examined on a case by case basis to see if SHA3 is safe to use with them; from the balance of the feedback it seems probable that NIST will accept the feedback and SHA3 will retain the full 256-bit pre-image resistance. <br />
<br />
===Cryptanalytic Risks===<br />
<br />
A practical issue with switching to hashcash-SHA3 is that it would invalidate all existing ASIC mining hardware, and so is a change that would unlikely to be made except in the face of security risk; there is no indication that SHA1 or SHA256, or SHA256^2 are vulnerable to pre-image attack so the motivation is missing absent new cryptanalytic developments. In addition even if SHA256^2 became easier due to cryptanalytic attack, and miners started using whatever the new algorithmic approach was, it does not necessarily matter as difficulty would just adapt to it. One likely side-effect however would be that it would introduce more memory or pre-computation tradeoffs which could make ASICs unprofitable, or give advantages to people with large resources to do the pre-computations. Pre-computation advantages would perhaps be enough motivation to replace the hash with SHA3. Anyway this is all speculation if and until any pre-image affecting cryptanalytic attacks are found on SHA256.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor ie the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a petahash/second is a 19 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42126Hashcash2013-11-01T12:36:16Z<p>Adam3us: /* Double Hash */ new section speculation about SHA3</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256. There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage.<br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
===Future Hash===<br />
<br />
Once the NIST SHA3 contest has finalised, bitcoin might in the future consider adopting hashcash-SHA3 as a security upgrade (eg a single invocation of SHA3 vs a double invocation of SHA256). It seems clear from the SHA1 break, and SHA256 is a similar design, that there was previously a misunderstanding about the security of hash functions against birthday collisions, and SHA3 finalists all aim to fix that issue. One aspect of relevance for hashcash-SHA3 is that there is some debate within the NIST comments process on the proposal of weakening SHA3's resistance to pre-image attacks down to 128-bit (vs the full hash size as with previous hashes). The motivation is a small performance gain, with the rationale that some hash-pluggable algorithms do not rely on full-length pre-image resistance. The proposal has met with significant negative feedback due to it creating a non-standard security assumption (compared to all previous hashes), and therefore it creates risk and all hash-pluggable algorithms (like HMAC, RSA, DSA, hashcash etc) would need to be re-examined on a case by case basis to see if SHA3 is safe to use with them; from the balance of the feedback it seems probable that NIST will accept the feedback and SHA3 will retain the full 256-bit pre-image resistance. <br />
<br />
===Cryptanalytic Risks===<br />
<br />
A practical issue with switching to hashcash-SHA3 is that it would invalidate all existing ASIC mining hardware, and so is a change that would unlikely to be made except in the face of security risk; there is no indication that SHA1 or SHA256, or SHA256^2 are vulnerable to pre-image attack so the motivation is missing absent new cryptanalytic developments. In addition even if SHA256^2 became easier due to cryptanalytic attack, and miners started using whatever the new algorithmic approach was, it does not necessarily matter as difficulty would just adapt to it. One likely side-effect however would be that it would introduce more memory or pre-computation tradeoffs which could make ASICs unprofitable, or give advantages to people with large resources to do the pre-computations. Pre-computation advantages would perhaps be enough motivation to replace the hash with SHA3. Anyway this is all speculation if and until any pre-image affecting cryptanalytic attacks are found on SHA256.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor ie the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42125Hashcash2013-11-01T12:17:08Z<p>Adam3us: /* Double Hash */ moved redundant text here</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256. There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage.<br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor ie the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42124Hashcash2013-11-01T12:15:15Z<p>Adam3us: /* Hash function choices */ remove redundant text</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256. There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage.<br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on preimage resistance and so is not vulnerable to birthday attacks, a generic method of defending SHA1 against this attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor ie the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42123Hashcash2013-11-01T12:12:30Z<p>Adam3us: /* Hashcash function */ fix math notation error should be / not mod</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on preimage resistance and so is not vulnerable to birthday attacks, a generic method of defending SHA1 against this attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor ie the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42122Hashcash2013-11-01T12:01:37Z<p>Adam3us: /* Hashcash function */ clearer label of preimage vs output</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on preimage resistance and so is not vulnerable to birthday attacks, a generic method of defending SHA1 against this attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(n-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(n-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(n-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42121Hashcash2013-11-01T11:57:38Z<p>Adam3us: /* Work, difficulty & cryptographic security */ correct units on hashrate</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on preimage resistance and so is not vulnerable to birthday attacks, a generic method of defending SHA1 against this attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(n-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(n-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(n-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42114Hashcash2013-10-31T15:43:36Z<p>Adam3us: /* Double Hash */ better explanation about double hash</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on preimage resistance and so is not vulnerable to birthday attacks, a generic method of defending SHA1 against this attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(n-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(n-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(n-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 exahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42113Hashcash2013-10-31T15:25:22Z<p>Adam3us: /* History */ formatting</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(n-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(n-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(n-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 exahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42112Hashcash2013-10-31T15:23:59Z<p>Adam3us: /* Hashcash */ link to more wikipedia</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(n-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(n-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(n-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 exahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42074Hashcash2013-10-30T00:52:20Z<p>Adam3us: /* Decentralization: hashcash-Scrypt vs hashcash-SHA256 */ minor text improvemens</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(n-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(n-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(n-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 exahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42073Hashcash2013-10-30T00:47:36Z<p>Adam3us: /* Decentralization & Scrypt(1) vs SHA256^2 */ no superscript simpify heading</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(n-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(n-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(n-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 exahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so that more internal rounds have their computations repeated to reduce memory. In theory therefore it would be possible to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware this would be optimized for to find he optimal mount of memory to use, and it is quite likely the optimal amount would likely be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42072Hashcash2013-10-30T00:46:28Z<p>Adam3us: /* Litecoin proof-of-work */ split section comparing scrypt / sha256</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(n-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(n-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(n-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 exahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
===Decentralization & Scrypt(1) vs SHA256^2===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so that more internal rounds have their computations repeated to reduce memory. In theory therefore it would be possible to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware this would be optimized for to find he optimal mount of memory to use, and it is quite likely the optimal amount would likely be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42071Hashcash2013-10-30T00:42:37Z<p>Adam3us: /* Hashcash function */ multiple small corrections</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(n-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(n-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(n-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 exahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so that more internal rounds have their computations repeated to reduce memory. In theory therefore it would be possible to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware this would be optimized for to find he optimal mount of memory to use, and it is quite likely the optimal amount would likely be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Help:FAQ&diff=42063Help:FAQ2013-10-29T18:14:50Z<p>Adam3us: /* How does the proof-of-work system help secure Bitcoin? */ add cross ref to new hashcash page</p>
<hr />
<div>Here you will find answers to the most commonly asked questions.<br />
<br />
== General ==<br />
=== What are bitcoins? ===<br />
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (eg: “100 BTC”).<br />
There are such things as [[physical bitcoins]], but ultimately, a bitcoin is just a number associated with a [[Address|Bitcoin Address]]. A physical bitcoin is simply an object, such as a coin, with the number carefully embedded inside. See also an [[Introduction|easy intro]] to bitcoin.<br />
<br />
=== How can I get bitcoins? ===<br />
<br />
There are a variety of ways to acquire bitcoins:<br />
<br />
* Accept bitcoins as payment for goods or services.<br />
* The most common way to buy bitcoins are the [[Buying bitcoins|Bitcoin Exchanges]]<br />
* There are several services where you can [[Buying_Bitcoins_(the_noob_version)|trade them]] for traditional currency.<br />
* Find someone to trade cash for bitcoins in-person through a [https://en.bitcoin.it/wiki/Category:Directories local directory].<br />
* Participate in a [[Pooled mining|mining pool]].<br />
* If you have a lot of mining hardware, you can solo mine and attempt to create a new [[block]] (currently yields 25 bitcoins plus transaction fees).<br />
* Visit sites that provide [[Trade#Free_Samples_and_Offers|free samples and offers]].<br />
<br />
===Does Bitcoin guarantee an influx of free money?===<br />
<br />
Since Bitcoin is a new technology, what it is and how it works may be initially unclear. Bitcoin is sometimes presented as being one of three things:<br />
<ol style="list-style-type: upper-alpha;"><br />
<li>Some sort of online 'get-rich-quick' scam.</li><br />
<li>A loophole in the market economy, the installation of which guarantees a steady influx of cash.</li><br />
<li>A sure investment that will almost certainly yield a profit.</li><br />
</ol><br />
In fact, none of the above are true. Let's look at them independently.<br />
<br />
;Is Bitcoin a 'get-rich-quick' scheme?<br />
:If you've spent much time on the Internet, you've probably seen ads for many 'get-rich-quick' schemes. These ads usually promise huge profits for a small amounts of easy work. Such schemes are usually pyramid/matrix-style schemes that make money from their own employees and offer nothing of any real value. Most convince one to buy packages that will make them earn hundreds a day, which in fact have the buyer distribute more such ads, and make minute profits.<br />
<br />
:Bitcoin is in no way similar to these schemes. Bitcoin doesn't promise windfall profits. There is no way for the developers to make money from your involvement or to take money from you. That bitcoins are nearly impossible to acquire without the owner's consent represents one of its greatest strengths. Bitcoin is an experimental, virtual currency that may succeed or may fail. None of its developers expect to get rich off of it. <br />
<br />
:A more detailed answer to this question can be found [http://bitcointalk.org/?topic=7815.0 here].<br />
<br />
;Will I make money by installing the client?<br />
:Most people who use Bitcoin don't earn anything by doing so, and the default client has no built-in way to earn Bitcoins. A small minority of people with dedicated, high-performance hardware do earn some Bitcoins by "''mining''" (generating new bitcoins, see [[#What is mining?|What is mining?]]) with special software, but joining Bitcoin shouldn't be construed as being the road to riches. Most Bitcoin users get involved because they find the project conceptually interesting and don't earn anything by doing so. This is also why you won't find much speculation about the political or economic repercussions of Bitcoin anywhere on this site: Bitcoin developers owe their dedication to the project's intellectual yieldings more than to those of a monetary nature. Bitcoin is still taking its first baby steps; it may go on to do great things but right now it only has something to offer those chasing conceptually interesting projects or bleeding edge technology.<br />
<br />
;As an investment, is Bitcoin a sure thing?<br />
:Bitcoin is a new and interesting electronic currency, the value of which is not backed by any single government or organization. Like other currencies, it is worth something partly because people are willing to trade it for goods and services. Its exchange rate fluctuates continuously, and sometimes wildly. It lacks wide acceptance and is vulnerable to manipulation by parties with modest funding. Security incidents such as website and account compromise may trigger major sell-offs. Other fluctuations can build into positive feedback loops and cause much larger exchange rate fluctuations. Anyone who puts money into Bitcoin should understand the risk they are taking and consider it a high-risk currency. Later, as Bitcoin becomes better known and more widely accepted, it may stabilize, but for the time being it is unpredictable. Any investment in Bitcoin should be done carefully and with a clear plan to manage the risk.<br />
<br />
=== Can I buy bitcoins with Paypal? ===<br />
<br />
It is possible to buy [[physical bitcoins]] with PayPal but it is otherwise difficult and/or expensive to do so for non-physical bitcoins, because of significant risk to the seller. <br />
<br />
While it is possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most exchanges do not allow funding through PayPal. This is due to repeated cases where someone pays for bitcoins with Paypal, receives their bitcoins, and then fraudulently complains to Paypal that they never received their purchase. PayPal often sides with the fraudulent buyer in this case, which means any seller needs to cover that risk with higher fees or refuse to accept PayPal altogether.<br />
<br />
Buying Bitcoins from individuals this way is still possible, but requires the seller to have some trust that the buyer will not file a claim with PayPal to reverse the payment.<br />
<br />
=== Where can I find a forum to discuss Bitcoin? ===<br />
<br />
Please visit the [[Bitcoin:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] for links to Bitcoin-related forums.<br />
<br />
=== How are new bitcoins created? ===<br />
<br />
[[File:total_bitcoins_over_time_graph.png|thumb|Number of bitcoins over time, assuming a perfect 10-minute interval.]]<br />
New bitcoins are generated by the network through the process of "[[#What is mining?|''mining'']]". In a process that is similar to a continuous raffle draw, mining nodes on the network are awarded bitcoins each time they find the solution to a certain mathematical problem (and thereby create a new [[block]]). Creating a block is a [[proof of work]] with a difficulty that varies with the overall strength of the network. The reward for solving a block is [[Controlled Currency Supply|automatically adjusted]] so that roughly every four years of operation of the Bitcoin network, half the amount of bitcoins created in the prior 4 years are created. {{formatnum:10500000}} bitcoins were created in the first 4 (approx.) years from January 2009 to November 2012. Every four years thereafter this amount halves, so it will be {{formatnum:5250000}} over years 4-8, {{formatnum:2625000}} over years 8-12, and so on. Thus the total number of bitcoins in existence will never exceed {{formatnum:21000000}}. See [[Controlled Currency Supply]].<br />
<br />
Blocks are [[Mining|mined]] every 10 minutes, on average and for the first four years ({{formatnum:210000}} blocks) each block included 50 new bitcoins. As the amount of processing power directed at mining changes, the difficulty of creating new bitcoins changes. This difficulty factor is calculated every 2016 blocks and is based upon the time taken to generate the previous 2016 blocks. See [[Mining]].<br />
<br />
=== What's the current total number of bitcoins in existence? ===<br />
<br />
[http://blockexplorer.com/q/totalbc Current count]. Also see [https://blockchain.info/charts/total-bitcoins Total bitcoins in circulation chart]<br />
<br />
The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first {{formatnum:210000}} blocks, 25 BTC for the next {{formatnum:210000}} blocks, then 12.5 BTC, 6.25 BTC and so on.<br />
<br />
=== How divisible are bitcoins? ===<br />
<br />
A bitcoin can be divided down to 8 decimal places. Therefore, 0.00000001 BTC is the smallest amount that can be handled in a transaction. If necessary, the protocol and related software can be modified to handle even smaller amounts.<br />
<br />
=== What do I call the various denominations of bitcoin? ===<br />
<br />
There is a lot of discussion about the naming of these fractions of bitcoins. The leading candidates are:<br />
<br />
* 1 BTC = 1 bitcoin<br />
* 0.01 BTC = 1 cBTC = 1 centibitcoin (also referred to as bitcent)<br />
* 0.001 BTC = 1 mBTC = 1 millibitcoin (also referred to as mbit (pronounced em-bit) or millibit or even bitmill)<br />
* 0.000 001 BTC = 1 μBTC = 1 microbitcoin (also referred to as ubit (pronounced yu-bit) or microbit)<br />
<br />
The above follows the accepted international SI prefixes for hundredths, thousandths, and millionths. There are many arguments against the special case of 0.01 BTC since it is unlikely to represent anything meaningful as the Bitcoin economy grows (it certainly won't be the equivalent of 0.01 USD, GBP or EUR). Equally, the inclusion of existing national currency denominations such as "cent", "nickel", "dime", "pence", "pound", "kopek" and so on are to be discouraged; this is a worldwide currency.<br />
<br />
One exception is the "satoshi" which is smallest denomination currently possible <br />
<br />
* 0.000 000 01 BTC = 1 satoshi (pronounced sa-toh-shee)<br />
which is so named in honour of Satoshi Nakamoto, the pseudonym of the inventor of Bitcoin.<br />
<br />
For an overview of all defined units of Bitcoin (including less common and niche units), see [[Units]].<br />
<br />
Further discussion on this topic can be found on the forums here:<br />
<br />
* [https://bitcointalk.org/index.php?topic=14438.msg195287#msg195287 We need names]<br />
* [https://bitcointalk.org/index.php?topic=8282.0 What to call 0.001 BTC]<br />
<br />
=== How does the halving work when the number gets really small? ===<br />
<br />
Eventually the reward will go from 0.00000001 BTC to zero and no more bitcoins will be created. <br />
<br />
The block reward calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by two and rounded down. The integer is equal to the value in BTC * 100,000,000 since internally in the reference client software, all Bitcoin balances and values are stored as unsigned integers.<br />
<br />
With an initial block reward of 50 BTC, it will take many 4-year periods for the block reward to reach zero.<br />
<br />
=== How long will it take to generate all the coins? ===<br />
<br />
The last block that will generate coins will be block #6,929,999 which should be generated at or near the year 2140. The total number of coins in circulation will then remain static at 20,999,999.9769 BTC.<br />
<br />
Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20,999,999.999999999496 BTC.<br />
<br />
=== If no more coins are going to be generated, will more blocks be created? ===<br />
<br />
Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, these fees will sustain the ability to use bitcoins and the Bitcoin network. There is no practical limit on the number of blocks that will be mined in the future.<br />
<br />
=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===<br />
<br />
Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will eventually increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").<br />
<br />
The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.<br />
<br />
=== If every transaction is broadcast via the network, does Bitcoin scale? ===<br />
The Bitcoin protocol allows lightweight clients that can use Bitcoin without downloading the entire transaction history. As traffic grows and this becomes more critical, implementations of the concept will be developed. Full network nodes will at some point become a more specialized service.<br />
<br />
With some modifications to the software, full Bitcoin nodes could easily keep up with both VISA and MasterCard combined, using only fairly modest hardware (a single high end server by todays standards). It is worth noting that the MasterCard network is structured somewhat like Bitcoin itself - as a peer to peer broadcast network.<br />
<br />
Learn more about [[Scalability]].<br />
<br />
==Economy==<br />
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===<br />
Bitcoins have value because they are useful and because they are [[Controlled Currency Supply|scarce]]. As they are accepted by more merchants, their value will [http://en.wikipedia.org/wiki/Sticky_%28economics%29 stabilize]. See the [[Trade|list of Bitcoin-accepting sites]].<br />
<br />
When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. Bitcoins, like dollars and euros, are not backed up by anything except the variety of merchants that accept them.<br />
<br />
It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.<br />
<br />
Alternatively it needs to be added that while the law of supply and demand applies it does not guarantee value of Bitcoins in the future. If confidence in Bitcoins is lost then it will not matter that the supply can no longer be increased, the demand will fall off with all holders trying to get rid of their coins. An example of this can be seen in cases of state currencies, in cases when the state in question dissolves and so no new supply of the currency is available (the central authority managing the supply is gone), however the demand for the currency falls sharply because confidence in its purchasing power disappears. Of-course Bitcoins do not have such central authority managing the supply of the coins, but it does not prevent confidence from eroding due to other situations that are not necessarily predictable.<br />
<br />
=== Is Bitcoin a bubble? ===<br />
Yes, in the same way as the euro and dollar are. They only have value in exchange and have no inherent value. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.<br />
<br />
=== Is Bitcoin a Ponzi scheme? ===<br />
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.<br />
<br />
A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters, and indeed, society as a whole, benefit from the usefulness of a stable, fast, inexpensive, and widely accepted p2p currency.<br />
<br />
The fact that early adopters benefit more doesn't alone make anything a Ponzi scheme. All good investments in successful companies have this quality.<br />
<br />
=== Doesn't Bitcoin unfairly benefit early adopters? ===<br />
Early adopters have a large number of bitcoins now because they took a risk and invested resources in an unproven technology. By so doing, they have helped Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.<br />
<br />
In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin.<br />
<br />
Since the pricing of Bitcoins has fallen greatly from its June 2011 peak, prices today are much more similar to those enjoyed by many early adopters. Those who are buying Bitcoins today likely believe that Bitcoin will grow significantly in the future. Setting aside the brief opportunity to have sold Bitcoins at the June 2011 peak enjoyed by few, the early-adopter window is arguably still open.<br />
<br />
===Won't loss of wallets and the finite amount of Bitcoins create excessive deflation, destroying Bitcoin? ===<br />
Worries about Bitcoin being destroyed by deflation are not entirely unfounded. Unlike most currencies, which experience inflation as their founding institutions create more and more units, Bitcoin will likely experience gradual deflation with the passage of time. Bitcoin is unique in that only a small amount of units will ever be produced (twenty-one million to be exact), this number has been known since the project's inception, and the units are created at a predictable rate.<br />
<br />
Also, Bitcoin users are faced with a danger that doesn't threaten users of any other currency: if a Bitcoin user loses his wallet, his money is gone forever, unless he finds it again. And not just to him; it's gone completely out of circulation, rendered utterly inaccessible to anyone. As people will lose their wallets, the total number of Bitcoins will slowly decrease.<br />
<br />
Therefore, Bitcoin seems to be faced with a unique problem. Whereas most currencies inflate over time, Bitcoin will mostly likely do just the opposite. Time will see the irretrievable loss of an ever-increasing number of Bitcoins. An already small number will be permanently whittled down further and further. And as there become fewer and fewer Bitcoins, the laws of supply and demand suggest that their value will probably continually rise.<br />
<br />
Thus Bitcoin is bound to once again stray into mysterious territory, because no one exactly knows what happens to a currency that grows continually more valuable. Many economists claim that a low level of inflation is a good thing for a currency, but nobody is quite sure about what might happens to one that continually deflates. Although deflation could hardly be called a rare phenomenon, steady, constant deflation is unheard of. There may be a lot of speculation, no one has any hard data to back up their claims.<br />
<br />
That being said, there is a mechanism in place to combat the obvious consequences. Extreme deflation would render most currencies highly impractical: if a single Canadian dollar could suddenly buy the holder a car, how would one go about buying bread or candy? Even pennies would fetch more than a person could carry. Bitcoin, however, offers a simple and stylish solution: infinite divisibility. Bitcoins can be divided up and trade into as small of pieces as one wants, so no matter how valuable Bitcoins become, one can trade them in practical quantities. <br />
<br />
In fact, infinite divisibility should allow Bitcoins to function in cases of extreme wallet loss. Even if, in the far future, so many people have lost their wallets that only a single Bitcoin, or a fraction of one, remains, Bitcoin should continue to function just fine. No one can claim to be sure what is going to happen, but deflation may prove to present a smaller threat than many expect.<br />
<br />
For more information, see the [[Deflationary spiral]] page.<br />
<br />
=== What if someone bought up all the existing Bitcoins? ===<br />
Bitcoin markets are competitive -- meaning the price of a bitcoin will rise or fall depending on supply and demand at certain price levels. Only a fraction of bitcoins issued to date are found on the exchange markets for sale. So even though technically a buyer with lots of money could buy all the bitcoins offered for sale, unless those holding the rest of the bitcoins offer them for sale as well, even the wealthiest, most determined buyer can't get at them.<br />
<br />
Additionally, new currency continues to be issued daily and will continue to do so for decades though over time the rate at which they are issued declines to insignificant levels. Those who are mining aren't obligated to sell their bitcoins so not all bitcoins will make it to the markets even.<br />
<br />
This situation doesn't suggest, however, that the markets aren't vulnerable to price manipulation. It doesn't take significant amounts of money to move the market price up or down and thus Bitcoin remains a volatile asset.<br />
<br />
===What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete?===<br />
<br />
That the block chain cannot be easily forked represents one of the central security mechanisms of Bitcoin. Given the choice between two block chains, a Bitcoin miner always chooses the longer one - that is to say, the one with the more complex hash. Thusly, it ensures that each user can only spend their bitcoins once, and that no user gets ripped off.<br />
<br />
As a consequence of the block chain structure, there may at any time be many different sub-branches, and the possibility always exists of a transaction being over-written by the longest branch, if it has been recorded in a shorter one. The older a transaction is though, the lower its chances of being over-written, and the higher of becoming permanent. Although the block chain prevents one from spending more Bitcoins than one has, it means that transactions can be accidentally nullified. <br />
<br />
A new block chain would leave the network vulnerable to [[double-spending|double-spend]] attacks. However, the creation of a viable new chain presents considerable difficulty, and the possibility does not present much of a risk.<br />
<br />
Bitcoin will always choose the longer Block Chain and determines the relative length of two branches by the complexities of their hashes. Since the hash of each new block is made from that of the block preceding it, to create a block with a more complex hash, one must be prepared to do more computation than has been done by the entire Bitcoin network from the fork point up to the newest of the blocks one is trying to supersede. Needless to say, such an undertaking would require a very large amount of processing power and since Bitcoin is continually growing and expanding, it will likely only require more with the passage of time.<br />
<br />
A much more distinct and real threat to the Bitcoin use is the development of other, superior virtual currencies, which could supplant Bitcoin and render it obsolete and valueless.<br />
<br />
A great deal of careful thought and ingenuity has gone into the development of Bitcoin, but it is the first of its breed, a prototype, and vulnerable to more highly-evolved competitors. At present, any threatening rivals have yet to rear their heads; Bitcoin remains the first and foremost private virtual currency, but we can offer no guarantees that it will retain that position. It would certainly be in keeping with internet history for a similar system built from the same principles to supersede and cast Bitcoin into obsolescence, after time had revealed its major shortcomings. Friendster and Myspace suffered similar fates at the hand of Facebook, Napster was ousted by Limeware, Bearshare and torrent applications, and Skype has all but crushed the last few disciples of the Microsoft Messenger army. <br />
<br />
This may sound rather foreboding, so bear in mind that the introduction of new and possibly better virtual currencies will not necessarily herald Bitcoin's demise. If Bitcoin establishes itself sufficiently firmly before the inception of the next generation of private, online currencies so as to gain widespread acceptance and general stability, future currencies may pose little threat even if they can claim superior design. This is known as the network effect.<br />
<br />
=== Is Bitcoin open to value manipulation? ===<br />
<br />
The current low market cap of Bitcoin means that any investor with deep enough pockets can significantly change/manipulate the rate. Is this a problem?<br />
<br />
This is only a problem if you are investing in Bitcoin for short period of time. A manipulator can't change the fundamentals, and over a period of 5-10 years they will win over any short term manipulations.<br />
<br />
==Sending and Receiving Payments==<br />
<br />
=== Why do I have to wait 10 minutes before I can spend money I received? ===<br />
<br />
10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case. <br />
<br />
[[Blocks]] (shown as "confirmations" in the GUI) are how the Bitcoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!<br />
<br />
Ten minutes was specifically chosen by [[Satoshi]] as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.<br />
<br />
As a thought experiment, what if the Bitcoin network grew to include Mars? From the farthest points in their orbits, it takes about 20 minutes for a signal to travel from Earth to Mars. With only 10 minutes between new blocks, miners on Mars would always be 2 blocks behind the miners on Earth. It would be almost impossible for them to contribute to the block chain. If we wanted collaborate with those kinds of delays, we would need at least a few hours between new blocks. <br />
<br />
[[File:TransactionConfirmationTimesExample.PNG]]<br />
<br />
=== Do you have to wait until my transactions are confirmed in order to buy or sell things with Bitcoin? ===<br />
<br />
YES, you do, IF the transaction is non-recourse. The Bitcoin reference software does not display transactions as confirmed until six blocks have passed (confirmations). As transactions are burred in the chain they become increasingly non-reversible but are very reversible before the first confirmation. Two to six confirmations are recommended for non-recourse situations depending on the value of the transactions involved.<br />
<br />
When people ask this question they are usually thinking about applications like supermarkets. This generally is a recourse situation: if somebody tries to double-spend on a face-to-face transaction it might work a few times, but probabalistically speaking eventually one of the double-spends will get noticed, and the penalty for shoplifting charges in most localities is calibrated to be several times worse than the proceeds of a single shoplifting event.<br />
<br />
Double-spends might be a concern for something like a snack machine in a low-traffic area with no nearby security cameras. Such a machine shouldn't honor 0-confirmation payments, and should instead use some other mechanism of clearing Bitcoin or validating transactions against reversal, see the wiki article [[Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation|here]] for alternatives.<br />
<br />
Applications that require immediate payment processing, like supermarkets or snack machines, need to manage the risks. Here is one way to reverse an unconfirmed payment:<br />
<br />
A [[Double-spending#Finney_attack|Finney attack]], in which an attacker mines a block containing a movement of some coins back to themselves. Once they find a block solution, they quickly go to a merchant and make a purchase, then broadcast the block, thus taking back the coins. This attack is a risk primarily for goods that are dispatched immediately, like song downloads or currency trades. Because the attacker can't choose the time of the attack, it isn't a risk for merchants such as supermarkets where you can't choose exactly when to pay (due to queues, etc). The attack can fail if somebody else finds a block containing the purchasing transaction before you release your own block, therefore, merchants can reduce but not eliminate the risk by making purchasers wait some length of time that's less than a confirm.<br />
<br />
Because pulling off this attack is not trivial, merchants who need to sell things automatically and instantly are most likely to just price the cost of reversal fraud in, or use insurance.<br />
<br />
=== I was sent some bitcoins and they haven't arrived yet! Where are they? ===<br />
<br />
Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them. <br />
<br />
The latest version of the Bitcoin-Qt client tells you how far it has yet to go in downloading the blockchain. Hover over the icon in the bottom right corner of the client to learn your client's status.<br />
<br />
If it has not caught up then it's possible that your transaction hasn't been included in a block yet. <br />
<br />
You can check pending transactions in the network by going [http://blockchain.info here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client. <br />
<br />
If the transaction is based on a coin that was in a recent transaction then it could be considered a low priority transaction. Transfers can take longer if the transaction fee paid was not high enough. If there is no fee at all the transfer can get a very low priority and take hours or even days to be included in a block.<br />
<br />
=== Why does my Bitcoin address keep changing? ===<br />
<br />
Whenever the address listed in "Your address" receives a transaction, Bitcoin replaces it with a new address. This is meant to encourage you to use a new address for every transaction, which enhances [[anonymity]]. All of your old addresses are still usable: you can see them in ''Settings -> Your Receiving Addresses''.<br />
<br />
===How much will the transaction fee be?===<br />
<br />
Some transactions might require a [[transaction fee]] for them to get confirmed in a timely manner. The transaction fee is processed by and received by the bitcoin miner. The most recent version of the Bitcoin client will estimate an appropriate fee when a fee might be required.<br />
<br />
The fee is added to the payment amount. For example, if you are sending a 1.234 BTC payment and the client requires a 0.0005 BTC fee, then 1.2345 BTC will be subtracted from the wallet balance for the entire transaction and the address for where the payment was sent will receive a payment of 1.234 BTC.<br />
<br />
A fee might be imposed because your transaction looks like a denial of service attack to the Bitcoin system. For example, it might be burdensome to transmit or it might recycle Bitcoins you recently received. The wallet software attempts to avoid generating burdensome transactions, but it isn't always able to do so: The funds in your wallet might be new or composed of many tiny payments. <br />
<br />
Because the fee is related to the amount of data that makes up the transaction and not to the amount of Bitcoins being sent, the fee may seem extremely low (0.0005 BTC for a 1,000 BTC transfer) or unfairly high (0.004 BTC for a 0.02 BTC payment, or about 20%). If you are receiving tiny amounts (''e.g.'' as small payments from a mining pool) then fees when sending will be higher than if your activity follows the pattern of conventional consumer or business transactions. <br />
<br />
As of Bitcoin 0.5.3 the required fee will not be higher than 0.05 BTC. For most users there is usually no required fee at all. If a fee is required it will most commonly be 0.0005 BTC.<br />
<br />
=== What happens when someone sends me a bitcoin but my computer is powered off? ===<br />
<br />
Bitcoins are not actually "sent" to your wallet; the software only uses that term so that we can use the currency without having to learn new concepts. Your wallet is only needed when you wish to spend coins that you've received.<br />
<br />
If you are sent coins when your wallet client program is not running, and you later launch the wallet client program, the coins will eventually appear as if they were just received in the wallet. That is to say, when the client program is started it must download blocks and catch up with any transactions it did not already know about.<br />
<br />
=== How long does "synchronizing" take when the Bitcoin client is first installed? What's it doing? ===<br />
<br />
The popular Bitcoin client software from bitcoin.org implements a "full" Bitcoin node: It can carry out all the duties of the Bitcoin P2P system, it isn't simply a "client". One of the principles behind the operation of full Bitcoin nodes is that they don't assume that the other participants have followed the rules of the Bitcoin system. During synchronization, the software is processing historical Bitcoin transactions and making sure for itself that all of the rules of the system have been correctly followed.<br />
<br />
In normal operation, after synchronizing, the software should use a hardly noticeable amount of your computer's resources.<br />
<br />
When the wallet client program is first installed, its initial validation requires a lot of work from your computer's hard disk, so the amount of time to synchronize depends on your disk speed and, to a lesser extent, your CPU speed. It can take anywhere from a few hours to a day or so. On a slow computer it could take more than 40 hours of continuous synchronization, so check your computer's power-saving settings to ensure that it does not turn its hard disk off when unattended for a few hours. You can use the Bitcoin software during synchronization, but you may not see recent payments to you until the client program has caught up to the point where those transactions happened.<br />
<br />
If you feel that this process takes too long, you can download a pre-synchronized blockchain from [http://eu2.bitcoincharts.com/blockchain/ http://eu2.bitcoincharts.com/blockchain/]. Alternatively, you can try an alternative "lite" client such as Multibit or a super-light client like electrum, though these clients have somewhat weaker security, are less mature, and don't contribute to the health of the P2P network.<br />
<br />
==Networking==<br />
=== Do I need to configure my firewall to run Bitcoin? ===<br />
<br />
Bitcoin will connect to other nodes, usually on TCP port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your Bitcoin client to connect to many nodes. [[Testnet]] uses TCP port 18333 instead of 8333.<br />
<br />
If you want to restrict your firewall rules to a few IPs, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]].<br />
<br />
=== How does the peer finding mechanism work? ===<br />
<br />
Bitcoin finds peers primarily by forwarding peer announcements within its own network and each node saves a database of peers that it's aware of, for future use. In order to bootstrap this process Bitcoin needs a list of initial peers, these can be provided manually but normally it obtains them by querying a set of DNS domain names which have automatically updated lists, if that doesn't work it falls back to a built-in list which is updated from time to time in new versions of the software. There is also an IRC based mechanism but it is disabled by default.<br />
<br />
==Mining==<br />
===What is mining?===<br />
[[Mining]] is the process of spending computation power to secure Bitcoin transactions against reversal and introducing new Bitcoins to the system.<br />
<br />
Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets the newly generated Bitcoins (25 per block at current levels). If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.<br />
<br />
===Is mining used for some useful computation?===<br />
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.<br />
<br />
===Is it not a waste of energy?===<br />
Spending energy on creating and securing a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.<br />
<br />
===Why don't we use calculations that are also useful for some other purpose?===<br />
To provide security for the Bitcoin network, the calculations involved need to have some [http://bitcoin.stackexchange.com/questions/5617/why-are-bitcoin-calculation-useless/5618#5618 very specific features]. These features are incompatible with leveraging the computation for other purposes.<br />
<br />
===How can we stop miners from creating zero transaction blocks?===<br />
The incentive for miners to include transactions is in the fees that come along with them. If we were to implement some minimum number of transactions per block it would be trivial for a miner to create and include transactions merely to surpass that threshold. As the network matures, the block reward drops, and miners become more dependent on transactions fees to pay their costs, the problem of zero transaction blocks should diminish over time.<br />
<br />
===How does the proof-of-work system help secure Bitcoin?===<br />
Bitcoin uses the [[Hashcash]] proof of work with a minor adaption. To give a general idea of the mining process, imagine this setup:<br />
<br />
payload = <some data related to things happening on the Bitcoin network><br />
nonce = 1<br />
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )<br />
<br />
The work performed by a miner consists of repeatedly increasing "nonce" until<br />
the hash function yields a value, that has the rare property of being below a certain<br />
target threshold. (In other words: The hash "starts with a certain number of zeroes",<br />
if you display it in the fixed-length representation, that is typically used.)<br />
<br />
As can be seen, the mining process doesn't compute anything special. It merely<br />
tries to find a number (also referred to as nonce) which - in combination with the payload -<br />
results in a hash with special properties.<br />
<br />
The advantage of using such a mechanism consists of the fact, that it is very easy to check a result: Given the payload and a specific nonce, only a single call of the hashing function is needed to verify that the hash has the required properties. Since there is no known way to find these hashes other than brute force, this can be used as a "proof of work" that someone invested a lot of computing power to find the correct nonce for this payload.<br />
<br />
This feature is then used in the Bitcoin network to secure various aspects. An attacker<br />
that wants to introduce malicious payload data into the network, will need to do the<br />
required proof of work before it will be accepted. And as long as honest miners have more<br />
computing power, they can always outpace an attacker.<br />
<br />
Also see [http://en.wikipedia.org/wiki/Hashcash Hashcash] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] and [http://en.wikipedia.org/wiki/SHA2 SHA2] and on Wikipedia.<br />
<br />
===Why was the "Generate coin" option of the client software removed?===<br />
<br />
In the early days of Bitcoin, it was easy for anyone to find new blocks using standard CPUs. As more and more people started mining, the [[difficulty]] of finding new blocks has greatly increased to the point where the average time for a CPU to find a single block can be many years. The only cost-effective method of [[Mining|mining]] is using a high-end graphics card with special software (see also [[Why a GPU mines faster than a CPU]]) and/or joining a [[Bitcoin Pool|mining pool]]. Since solo CPU mining is essentially useless, it was removed from the GUI of the Bitcoin software.<br />
<br />
==Security==<br />
<br />
===Could miners collude to give themselves money or to fundamentally change the nature of Bitcoin?===<br />
<br />
There are two questions in here. Let's look at them separately.<br />
<br />
;Could miners gang up and give themselves money?<br />
<br />
Mining itself is the process of creating new blocks in the block chain. Each block contains a list of all the transactions that have taken place across the entire Bitcoin network since the last block was created, as well as a hash of the previous block. New blocks are 'mined', or rather, generated, by Bitcoin clients correctly guessing sequences of characters in codes called 'hashes,' which are created using information from previous blocks. Bitcoin users may download specialized 'mining' software, which allows them to dedicate some amount of their processing power – however large or small – to guessing at strings within the hash of the previous block. Whoever makes the right guess first, thus creating a new block, receives a reward in Bitcoins.<br />
<br />
The block chain is one of the two structures that makes Bitcoin secure, the other being the public-key encryption system on which Bitcoin trade is based. The block chain assures that not only is every single transaction that ever takes place recorded, but that every single transaction is recorded on the computer of anyone who chooses to store the relevant information. Many, many users have complete records of every transaction in Bitcoins history readily available to them at any point, and anyone who wants in the information can obtain it with ease. These things make Bitcoin very hard to fool.<br />
<br />
The Bitcoin network takes considerable processing power to run, and since those with the most processing power can make the most guesses, those who put the most power toward to sustaining the network earn the most currency. Each correct guess yields, at present, twenty-five Bitcoins, and as Bitcoins are presently worth something (although the value still fluctuates) every miner who earns any number of Bitcoins makes money. Some miners pull in Bitcoins on their own; and some also join or form pools wherein all who contribute earn a share of the profits. <br />
<br />
Therefore, first answer is a vehement “yes” – not only can miners collude to get more money, Bitcoin is designed to encourage them to do so. Bitcoin pools are communal affairs, and there is nothing dishonest or underhanded about them.<br />
<br />
Of course, the real question is:<br />
<br />
;Can they do so in ways not sanctioned by Bitcoin developers? Is there any way to rip off the network and make loads of money dishonestly?<br />
<br />
Bitcoin isn't infallible. It can be cheated, but doing so is extremely difficult. Bitcoin was designed to evade some of the central problems with modern currencies – namely, that their trustworthiness hinges upon that of people who might not have users' best interests in mind. Every currency in the world (other than Bitcoin) is controlled by large institutions who keep track of what's done with it, and who can manipulate its value. And every other currency has value because people trust the institutions that control them.<br />
<br />
Bitcoin doesn't ask that its users trust any institution. Its security is based on the cryptography that is an integral part of its structure, and that is readily available for any and all to see. Instead of one entity keeping track of transactions, the entire network does, so Bitcoins are astoundingly difficult to steal, or double-spend. Bitcoins are created in a regular and predictable fashion, and by many different users, so no one can decide to make a whole lot more and lessen their value. In short, Bitcoin is designed to be inflation-proof, double-spend-proof and completely distributed.<br />
<br />
Nonetheless, there are a few ways that one can acquire Bitcoins dishonestly. Firstly, one can steal private keys. Key theft isn't something that Bitcoin security has been designed to prevent: it's up to users to keep theirs safe. But the cryptography is designed so that it is completely impossible to deduce someone's private key from their public one. As long as you keep your private key to yourself, you don't have much to worry about. Furthermore, one could theoretically create a new block chain, but due to the way in which the block chain is constructed, this would be extremely difficult and require massive amounts of processing power. A full explanation of the difficulties involved can be found in the [[block chain]] article.<br />
<br />
Bitcoin can be ripped off – but doing so would be extremely hard and require considerable expertise and a staggering amount of processing power. And it's only going to get harder with time. Bitcoin isn't impenetrable, but it's close enough to put any real worries in the peripherals.<br />
<br />
;Could miners fundamentally change the nature of Bitcoin?<br />
<br />
Once again, almost certainly not.<br />
<br />
Bitcoin is a distributed network, so any changes implemented to the system must be accepted by all users. Someone trying to change the way Bitcoins are generated would have to convince every user to download and use their software – so the only changes that would go through are those that would be equally benefit all users. <br />
<br />
And thus, it is more or less impossible for anyone to change the function of Bitcoin to their advantage. If users don't like the changes, they won't adopt them, whereas if users do like them, then these will help everyone equally. Of course, one can conceive of a situation where someone manages to get a change pushed through that provides them with an advantage that no one notices, but given that Bitcoin is structurally relatively simple, it is unlikely that any major changes will go through without someone noticing first.<br />
<br />
The fact that such changes are so difficult to make testifies to the fully distributed nature of Bitcoin. Any centrally controlled currency can be modified by its central agency without the consent of its adherents. Bitcoin has no central authority, so it changes only at the behest of the whole community. Bitcoins development represents a kind of collective evolution; the first of its kind among currencies.<br />
<br />
==Help==<br />
===I'd like to learn more. Where can I get help?===<br />
<br />
* Read the [[Introduction|introduction to bitcoin]] <br />
* See the videos, podcasts, and blog posts from the [[Press]]<br />
* Read and post on the [[:Bitcoin:Community_portal#Bitcoin_Community_Forums|forums]]<br />
* Chat on one of the [[:Bitcoin:Community_portal#IRC_Chat|Bitcoin IRC]] channels<br />
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works<br />
* Ask questions on the [http://bitcoin.stackexchange.com Bitcoin Stack Exchange]<br />
<br />
==See Also==<br />
<br />
* [[Man page]]<br />
* [[Introduction]]<br />
<br />
[[de:FAQ]]<br />
[[zh-cn:FAQ]]<br />
[[fr:FAQ]]<br />
[[ru:FAQ]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Proof_of_work&diff=42062Proof of work2013-10-29T18:05:03Z<p>Adam3us: cross ref to new hashcash page</p>
<hr />
<div>A '''proof of work''' is a piece of data which was difficult (costly, time-consuming) to produce so as to satisfy certain requirements. It must be trivial to check whether data satisfies said requirements. Producing a proof of work can be a random process with low probability, so that a lot of trial and error is required ''on average'' before a valid proof of work is generated. Bitcoin uses the [[Hashcash]] proof of work.<br />
<br />
One application of this idea is using [http://en.wikipedia.org/wiki/Hashcash hascash] as a method to preventing email spam, requiring a proof of work on the email's contents (including the To address), on every email. Legitimate emails will be able to do the work to generate the proof easily (not much work is required for a single email), but mass spam emailers will have difficulty generating the required proofs (which would require huge computational resources).<br />
<br />
Hashcash proofs of work are used in Bitcoin for block generation. Proofs of work that are tied to the data of each block are required for the blocks to be accepted. The [[difficulty]] of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes. Due to the very low probability of successful generation, this makes it unpredictable which worker computer in the network will be able to generate the next block.<br />
<br />
For a block to be valid it must hash to a value less than the current [[target]]; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceding block, thus each block has a [[block chain|chain]] of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.<br />
<br />
== Example ==<br />
<br />
Let's say the base string that we are going to do work on is "Hello, world!". Our target is to find a variation of it that SHA-256 hashes to a value beginning with '000'. We vary the string by adding an integer value to the end called a [[nonce]] and incrementing it each time. Finding a match for "Hello, world!" takes us 4251 tries (but happens to have zeroes in the first four digits):<br />
<br />
"Hello, world!0" => 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64<br />
"Hello, world!1" => e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8<br />
"Hello, world!2" => ae37343a357a8297591625e7134cbea22f5928be8ca2a32aa475cf05fd4266b7<br />
...<br />
"Hello, world!4248" => 6e110d98b388e77e9c6f042ac6b497cec46660deef75a55ebc7cfdf65cc0b965<br />
"Hello, world!4249" => c004190b822f1669cac8dc37e761cb73652e7832fb814565702245cf26ebb9e6<br />
"Hello, world!4250" => 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9<br />
<br />
4251 hashes on a modern computer is not very much work (most computers can achieve at least 4 million hashes per second). Bitcoin automatically varies the [[difficulty]] (and thus the amount of work required to generate a block) to keep a roughly constant rate of block generation. The probability of a single hash succeeding can be found [http://blockexplorer.com/q/probability here].<br />
<br />
In Bitcoin things are a bit more complex, especially since the header contains the [http://en.wikipedia.org/wiki/Merkle_tree Merkle tree] which depends on the included [[transactions]]. This includes the generation transaction, a transaction "out of nowhere" to our own address, which in addition to providing the miner with incentive to do the work, also ensures that every miner hashes a unique data set.<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42061Hashcash2013-10-29T18:01:31Z<p>Adam3us: /* Miner privacy */ typo fix</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(|n|-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(|n|-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(|n|-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 exahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 (approximately, technically minimum work is 0xFFFF000 hex expected iterations due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42060Hashcash2013-10-29T17:59:57Z<p>Adam3us: /* Work, difficulty & cryptographic security */ clarify +1</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(|n|-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(|n|-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(|n|-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 exahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 (approximately, technically minimum work is 0xFFFF000 hex expected iterations due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (including +1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42059Hashcash2013-10-29T17:58:30Z<p>Adam3us: /* Adding purpose */ about difficulty, target & separate secton on that</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(|n|-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(|n|-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(|n|-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targetted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic hardness terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of oct 2013 hashrate is 3.012 exahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 61.6-bits (+1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which the work required so that at current network hashrate a block is expected to be found every 10minutes. It is expressed relative to a minimum work unit of 2^32 (approximately, technically minimum work is 0xFFFF000 hex expected iterations due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000) = log2(difficulty)+log2(0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a exahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hous to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 61.6 bits (+1 for double hash) every 10-minutes and is 16,800x more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 12 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin).<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42056Hashcash2013-10-29T16:52:02Z<p>Adam3us: /* Hashcash */ split history into another section to make it easier for readers to skip!</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(|n|-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin), which makes Scrpt harder to implement in ASICs, as then you need memory in the ASIC, per mining core. <br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42055Hashcash2013-10-29T16:49:53Z<p>Adam3us: /* Hashcash */ more external and internal links</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
The hashcash proof-of-work function was invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256, reduces the reliance on SHA256 security properties and so makes hashcash still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(|n|-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin), which makes Scrpt harder to implement in ASICs, as then you need memory in the ASIC, per mining core. <br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42054Hashcash2013-10-29T16:43:51Z<p>Adam3us: /* Double Hash= */ typo</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the hashcash proof-of-work function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Hashcash is a proof-of-work function invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous mail severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[https://en.bitcoin.it/wiki/Bit_Gold_proposal] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
===Double Hash===<br />
<br />
Also bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256 that bitcoin uses as the hashcash hash, reduces the reliance on SHA256 security properties and so makes the algorithm still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(|n|-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin), which makes Scrpt harder to implement in ASICs, as then you need memory in the ASIC, per mining core. <br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42053Hashcash2013-10-29T16:43:31Z<p>Adam3us: /* Hashcash */ move double hash to new subsection, rewrite hmac explanation</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the hashcash proof-of-work function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Hashcash is a proof-of-work function invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous mail severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[https://en.bitcoin.it/wiki/Bit_Gold_proposal] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. <br />
<br />
==Double Hash===<br />
<br />
Also bitcoin is using two hash iterations (SHA256^2) somewhat similarly to how HMAC uses two hash iterations. The double invocation of SHA256 that bitcoin uses as the hashcash hash, reduces the reliance on SHA256 security properties and so makes the algorithm still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds. In the HMAC algorithm, which also uses a similar double hash construct, the double hash ensures that even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(|n|-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin), which makes Scrpt harder to implement in ASICs, as then you need memory in the ASIC, per mining core. <br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42052Hashcash2013-10-29T16:36:18Z<p>Adam3us: /* Hashcash */ give equal billing to bit-gold & cross ref</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the hashcash proof-of-work function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Hashcash is a proof-of-work function invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing anonymous remailer and mail2news remailer gateway abuse, namespace squatting on nymservers (pseudonymous mail severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster plugins and components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[https://en.bitcoin.it/wiki/Bit_Gold_proposal] bitcoin precursors, also use hashcash mining.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. Also bitcoin is using two hash iterations (SHA256^2) like HMAC. Even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure - because HMAC uses the underlying hash in a way that minimizes reliance on hash features. The double invocation of SHA256 that bitcoin uses as the hashcash hash, similar to HMAC, reduces the reliance on SHA256 security properties analogously and so makes the work still secure even if SHA256 is weakened in some ways by new cryptanalytic attacks. This usage pattern offers different protection beyond doubling the number of internal hash rounds.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(|n|-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin), which makes Scrpt harder to implement in ASICs, as then you need memory in the ASIC, per mining core. <br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42051Hashcash2013-10-29T16:29:28Z<p>Adam3us: /* Hashcash */ ref b-money, i2p, other uses</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the hashcash proof-of-work function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Hashcash is a proof-of-work function invented in 1997 by Adam Back, and proposed for anti-DoS uses including preventing anonymous remailer and mail2news remailer gateway abuse, namespace squatting on nymservers (pseudonymous mail severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster plugins and components and other systems. Hashcash was also used by Hal Finney's bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], another important bitcoin precursor, also uses hashcash mining.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. Also bitcoin is using two hash iterations (SHA256^2) like HMAC. Even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure - because HMAC uses the underlying hash in a way that minimizes reliance on hash features. The double invocation of SHA256 that bitcoin uses as the hashcash hash, reduces the reliance on SHA256 security properties analogously to the way HMAC uses a double hash, as it makes the hash still safe even if it is weakened in some ways by new cryptanalytic attacks.<br />
This usage pattern offers different protection beyond doubling the number of internal hash rounds.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(|n|-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin), which makes Scrpt harder to implement in ASICs, as then you need memory in the ASIC, per mining core. <br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42050Hashcash2013-10-29T16:10:55Z<p>Adam3us: /* Adding purpose */ tidy up</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the hashcash proof-of-work function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Hashcash is a proof-of-work function invented in 1997 by Adam Back. Like many cryptographic algorithms it uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. Also bitcoin is using two hash iterations (SHA256^2) like HMAC. Even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure - because HMAC uses the underlying hash in a way that minimizes reliance on hash features. The double invocation of SHA256 that bitcoin uses is a similar defense against SHA256 weakening to that used by HMAC as it makes the hash still safe even if it is weakened in some ways by new cryptanalytic attacks.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)=0 mod 2^(|n|-k). The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin), which makes Scrpt harder to implement in ASICs, as then you need memory in the ASIC, per mining core. <br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42049Hashcash2013-10-29T16:02:11Z<p>Adam3us: /* Hashcash function */ clarify a full hash inversion is computationally infeasible</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the hashcash proof-of-work function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Hashcash is a proof-of-work function invented in 1997 by Adam Back. Like many cryptographic algorithms it uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. Also bitcoin is using two hash iterations (SHA256^2) like HMAC. Even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure - because HMAC uses the underlying hash in a way that minimizes reliance on hash features. The double invocation of SHA256 that bitcoin uses is a similar defense against SHA256 weakening to that used by HMAC as it makes the hash still safe even if it is weakened in some ways by new cryptanalytic attacks.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If x from y=H(x) is random that is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash is of s, a service string so find H(s,c)=0 mod 2^(|n|-k). You will vary counter c until this is true. The service string could be a web server domain name, a recipients email address, or a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not trust a duplicated copy of the same work. To avoid risking wasting work in this way, there has to be a random starting point, and so the work is to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being incremented, an s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as a randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin), which makes Scrpt harder to implement in ASICs, as then you need memory in the ASIC, per mining core. <br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42048Hashcash2013-10-29T15:55:47Z<p>Adam3us: /* Hashcash */ put fpga, cpu in order</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the hashcash proof-of-work function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Hashcash is a proof-of-work function invented in 1997 by Adam Back. Like many cryptographic algorithms it uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. Also bitcoin is using two hash iterations (SHA256^2) like HMAC. Even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure - because HMAC uses the underlying hash in a way that minimizes reliance on hash features. The double invocation of SHA256 that bitcoin uses is a similar defense against SHA256 weakening to that used by HMAC as it makes the hash still safe even if it is weakened in some ways by new cryptanalytic attacks.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and yet once a pre-image is found anyone can very efficiently verify it by computing one hash so there is a huge asymmetry in full pre-image mining vs verification.<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If x from y=H(x) is random that is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash is of s, a service string so find H(s,c)=0 mod 2^(|n|-k). You will vary counter c until this is true. The service string could be a web server domain name, a recipients email address, or a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not trust a duplicated copy of the same work. To avoid risking wasting work in this way, there has to be a random starting point, and so the work is to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being incremented, an s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as a randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin), which makes Scrpt harder to implement in ASICs, as then you need memory in the ASIC, per mining core. <br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=42044Hashcash2013-10-29T14:45:13Z<p>Adam3us: new page on hashcash protcol, doesnt seem to be explained in full detail elsewhere</p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the hashcash proof-of-work function as the mining core. All the ASICs, GPUs are computing hashcash for mining reward and to validate the bitcoin blockchain transaction log. <br />
<br />
Hashcash is a proof-of-work function invented in 1997 by Adam Back. Like many cryptographic algorithms it uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256; and as bitcoin is a high assurance application for added security it actually uses SHA256 twice (denoted SHA256^2 ie "SHA256 function squared"). There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage. Also bitcoin is using two hash iterations (SHA256^2) like HMAC. Even though MD5 as bare hash is significantly weak now, HMAC-MD5 is still considered secure - because HMAC uses the underlying hash in a way that minimizes reliance on hash features. The double invocation of SHA256 that bitcoin uses is a similar defense against SHA256 weakening to that used by HMAC as it makes the hash still safe even if it is weakened in some ways by new cryptanalytic attacks.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but its very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and yet once a pre-image is found anyone can very efficiently verify it by computing one hash so there is a huge asymmetry in full pre-image mining vs verification.<br />
<br />
A second hash pre-image means given one-preimage x of y where y=H(x), the task is to find another pre-image of y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimization was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)=0 mod 2^(|n|-k) where n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie the first k bits of the hash output are 0. So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If x from y=H(x) is random that is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they dont know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash is of s, a service string so find H(s,c)=0 mod 2^(|n|-k). You will vary counter c until this is true. The service string could be a web server domain name, a recipients email address, or a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not trust a duplicated copy of the same work. To avoid risking wasting work in this way, there has to be a random starting point, and so the work is to find H(s,x,c)=0 mod 2^(|n|-k) where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being incremented, an s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as a randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if youhave a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce an extra-nonce. nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the work, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the miner send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use a deterministic address, with pulic derivation to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Litecoin proof-of-work===<br />
<br />
It is a misunderstanding to say litecoin uses the Scrypt proof-of-work. Scrypt is not a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Litecoin uses hashcash with the internal hash function of Scrypt: hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
Litecoin does not use the key-stretching feature of Scrypt so litecoin mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. The litecoin hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (128kB for litecoin), which makes Scrpt harder to implement in ASICs, as then you need memory in the ASIC, per mining core. <br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access or ownership of ASIC equipment by users. Its arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very very simple, so a skilled individual with his personal savings or a small kick-stater project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, when a well funded commercial entity corners the market by having 100x faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs. <br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes and may mid-term create a litecoin scaling problem.</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Mining&diff=42034Mining2013-10-29T10:38:59Z<p>Adam3us: /* Introduction */ link to new bitcoin it page for hashcash, and mention bitcoin uses hashcash rather than just describing hashcash line without naming it!</p>
<hr />
<div><!-- This page is designed to be short and simple! It should provide only a very brief explanation of things that have their own page and should link to other pages whenever possible. This page should serve as an entry point and a place to organize most of our mining articles. Thank You! (-Atheros) --><br />
[[File:Quick-and-dirty-4x5970-cooling.jpg|thumb|right|A quick and dirty mining rig]]<br />
== Introduction ==<br />
'''Mining''' is the process of adding transaction records to Bitcoin's public ledger of past transactions.<br />
This ledger of past transactions is called the [[block chain]] as it is a chain of [[block|blocks]].<br />
The block chain serves to [[Confirmation|confirm]] transactions to the rest of the network as having taken place.<br />
Bitcoin nodes use the block chain to distinguish legitimate Bitcoin transactions from attempts to re-spend coins that have already been spent elsewhere.<br />
<br />
Mining is intentionally designed to be resource-intensive and difficult so that the number of blocks found each day by miners remains steady. Individual [[blocks]] must contain a [[proof of work|proof of work]] to be considered valid. This proof of work is verified by other Bitcoin nodes each time they receive a block. Bitcoin uses the [[hashcash]] proof-of-work function.<br />
<br />
The primary purpose of mining is to allow Bitcoin nodes to reach a secure, tamper-resistant consensus.<br />
Mining is also the mechanism used to introduce Bitcoins into the system:<br />
Miners are paid any transaction fees as well as a "subsidy" of newly created coins.<br />
This both serves the purpose of disseminating new coins in a decentralized manner as well as motivating people to provide security for the system.<br />
<br />
Bitcoin mining is so called because it resembles the mining of other commodities:<br />
it requires exertion and it slowly makes new currency available at a rate that resembles the rate at which commodities like gold are mined from the ground.<br />
<br />
== Difficulty ==<br />
=== The Computationally-Difficult Problem ===<br />
Mining a block is difficult because the SHA-256 hash of a block's header must be lower than or equal to the [[Target|target]] in order for the block to be accepted by the network. This problem can be simplified for explanation purposes: The hash of a block must start with a certain number of zeros. The probability of calculating a hash that starts with many zeros is very low, therefore many attempts must be made. In order to generate a new hash each round, a [[Nonce|nonce]] is incremented. See [[Proof of work]] for more information.<br />
<br />
=== The Difficulty Metric ===<br />
The [[Difficulty|difficulty]] is the measure of how difficult it is to find a new block compared to the easiest it can ever be. It is recalculated every 2016 blocks to a value such that the previous 2016 blocks would have been generated in exactly two weeks had everyone been mining at this difficulty. This will yield, on average, one block every ten minutes. As more miners join, the rate of block creation will go up. As the rate of block generation goes up, the difficulty rises to compensate which will push the rate of block creation back down. Any blocks released by malicious miners that do not meet the required difficulty [[Target|target]] will simply be rejected by everyone on the network and thus will be worthless. <br />
<br />
=== Reward ===<br />
When a block is discovered, the discoverer may award themselves a certain number of bitcoins, which is agreed-upon by everyone in the network. Currently this bounty is 25 bitcoins; this value will halve every 210,000 blocks. See [[Controlled Currency Supply]].<br />
<br />
Additionally, the miner is awarded the fees paid by users sending transactions. The fee is an incentive for the miner to include the transaction in their block. In the future, as the number of new bitcoins miners are allowed to create in each block dwindles, the fees will make up a much more important percentage of mining income.<br />
<br />
== The mining ecosystem ==<br />
<br />
=== Hardware ===<br />
[[File:Usb-fpga module 1.15x-hs-800.jpg|thumb|right|FPGA Module]]<br />
Users have used various types of hardware over time to mine blocks. Hardware specifications and performance statistics are detailed on the [[Mining Hardware Comparison]] page.<br />
==== CPU Mining ==== <br />
Early Bitcoin client versions allowed users to use their CPUs to mine. As the network hashrate grew with more power efficient GPU miners the amount of Bitcoin's produced by CPU mining became lower than the cost of power to operate the CPUS. The option still exists in the reference Bitcoin client, but it is disabled by default.<br />
<br />
==== GPU Mining ====<br />
GPU Mining is drastically faster and more efficient than CPU mining. See the main article: [[Why a GPU mines faster than a CPU]]. A variety of popular [[Mining rig|mining rigs]] have been documented.<br />
==== FPGA Mining ====<br />
FPGA mining is a very efficient and fast way to mine, comparable to GPU mining and drastically outperforming CPU mining. FPGAs typically consume very small amounts of power with relatively high hash ratings, making them more viable and efficient than GPU mining. See [[Mining Hardware Comparison]] for FPGA hardware specifications and statistics.<br />
==== ASIC Mining ====<br />
An application-specific integrated circuit, or ''ASIC'', is a microchip designed and manufactured for a very specific purpose. ASICs designed for Bitcoin mining were first released in 2013. For the amount of power they consume, they are vastly faster than all previous technologies and already has made GPU mining financially unwise in some countries and setups.<br />
<br />
==== Mining services ====<br />
Mining contracts - provides mining services with performance specified by contract. An example would be where a specific level of mining capacity is rented out for a set price for a specific duration. Short list of mining contractors is [[Minerlease]].<br />
<br />
Mining shares - provides Mining as a Service (MaaS) model; break large-scale datacenter mining down to easily manageable pieces that are available in the form of shares of equipment. Mining shares are available from such companies as [[ASICMINER]] or [[Bit-miner.com]]<br />
<br />
Hosted mining services create some systemic risk for the Bitcoin system because they undermine the security assumption that the control of mining power is well distributed. If too much mining becomes consolidated in large hosting providers and an attacker is able to compromise some of these providers they could potentially disrupt the Bitcoin system or rip off people they transact with with reversals.<br />
<br />
=== Pools ===<br />
As more and more miners competed for the limited supply of blocks, individuals found that they were working for months without finding a block and receiving reward for their mining efforts. This made mining something of a gamble. To address the variance in their income miners started organizing themselves into [[Pooled mining|pools]] so that they could share rewards more evenly. See [[Pooled mining]] and [[Comparison of mining pools]].<br />
<br />
Similar to cloud mining traditional mining pools also create some potentially risky consolidation of control over hashing power. Although the individual miners are free to move to other pools if a pool misbehaves it can take days for them to notice misbehavior and react. Decentralized mining pools such as [[P2Pool]] exist to eliminate this risk but are more complicated to use.<br />
<br />
=== History ===<br />
Bitcoin's public ledger (the 'block chain') was started on January 3rd, 2009 at 18:15 UTC presumably by [[Satoshi Nakamoto]]. The first block is known as the [[genesis block]]. The first transaction recorded in the first block was a single transaction paying the reward of 50 new bitcoins to its creator.<br />
<br />
==See Also==<br />
<br />
* [http://codinginmysleep.com/bitcoin-mining-in-plain-english Bitcoin Mining in Plain English] by David Perry<br />
* [[Automatically mine when computer is locked|Tutorial to automatically start mining when you lock your computer]]. (Windows 7)<br />
* [http://www.reddit.com/r/Bitcoin/comments/18q2jx/eli5_bitcoin_mining_xpost_in_eli5/ Simplified Explanation of Bitcoin Mining] by reddit user [http://www.reddit.com/user/azotic azotic]<br />
<br />
[[ru:Mining]]<br />
[[Category:Mining]][[Category:Vocabulary]]</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Help:FAQ&diff=41861Help:FAQ2013-10-21T17:34:01Z<p>Adam3us: /* How does the proof-of-work system help secure Bitcoin? */ cross reference to hashcash</p>
<hr />
<div>Here you will find answers to the most commonly asked questions.<br />
<br />
== General ==<br />
=== What are bitcoins? ===<br />
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (eg: “100 BTC”).<br />
There are such things as [[physical bitcoins]], but ultimately, a bitcoin is just a number associated with a [[Address|Bitcoin Address]]. A physical bitcoin is simply an object, such as a coin, with the number carefully embedded inside. See also an [[Introduction|easy intro]] to bitcoin.<br />
<br />
=== How can I get bitcoins? ===<br />
<br />
There are a variety of ways to acquire bitcoins:<br />
<br />
* Accept bitcoins as payment for goods or services.<br />
* The most common way to buy bitcoins are the [[Buying bitcoins|Bitcoin Exchanges]]<br />
* There are several services where you can [[Buying_Bitcoins_(the_noob_version)|trade them]] for traditional currency.<br />
* Find someone to trade cash for bitcoins in-person through a [https://en.bitcoin.it/wiki/Category:Directories local directory].<br />
* Participate in a [[Pooled mining|mining pool]].<br />
* If you have a lot of mining hardware, you can solo mine and attempt to create a new [[block]] (currently yields 25 bitcoins plus transaction fees).<br />
* Visit sites that provide [[Trade#Free_Samples_and_Offers|free samples and offers]].<br />
<br />
===Does Bitcoin guarantee an influx of free money?===<br />
<br />
Since Bitcoin is a new technology, what it is and how it works may be initially unclear. Bitcoin is sometimes presented as being one of three things:<br />
<ol style="list-style-type: upper-alpha;"><br />
<li>Some sort of online 'get-rich-quick' scam.</li><br />
<li>A loophole in the market economy, the installation of which guarantees a steady influx of cash.</li><br />
<li>A sure investment that will almost certainly yield a profit.</li><br />
</ol><br />
In fact, none of the above are true. Let's look at them independently.<br />
<br />
;Is Bitcoin a 'get-rich-quick' scheme?<br />
:If you've spent much time on the Internet, you've probably seen ads for many 'get-rich-quick' schemes. These ads usually promise huge profits for a small amounts of easy work. Such schemes are usually pyramid/matrix-style schemes that make money from their own employees and offer nothing of any real value. Most convince one to buy packages that will make them earn hundreds a day, which in fact have the buyer distribute more such ads, and make minute profits.<br />
<br />
:Bitcoin is in no way similar to these schemes. Bitcoin doesn't promise windfall profits. There is no way for the developers to make money from your involvement or to take money from you. That bitcoins are nearly impossible to acquire without the owner's consent represents one of its greatest strengths. Bitcoin is an experimental, virtual currency that may succeed or may fail. None of its developers expect to get rich off of it. <br />
<br />
:A more detailed answer to this question can be found [http://bitcointalk.org/?topic=7815.0 here].<br />
<br />
;Will I make money by installing the client?<br />
:Most people who use Bitcoin don't earn anything by doing so, and the default client has no built-in way to earn Bitcoins. A small minority of people with dedicated, high-performance hardware do earn some Bitcoins by "''mining''" (generating new bitcoins, see [[#What is mining?|What is mining?]]) with special software, but joining Bitcoin shouldn't be construed as being the road to riches. Most Bitcoin users get involved because they find the project conceptually interesting and don't earn anything by doing so. This is also why you won't find much speculation about the political or economic repercussions of Bitcoin anywhere on this site: Bitcoin developers owe their dedication to the project's intellectual yieldings more than to those of a monetary nature. Bitcoin is still taking its first baby steps; it may go on to do great things but right now it only has something to offer those chasing conceptually interesting projects or bleeding edge technology.<br />
<br />
;As an investment, is Bitcoin a sure thing?<br />
:Bitcoin is a new and interesting electronic currency, the value of which is not backed by any single government or organization. Like other currencies, it is worth something partly because people are willing to trade it for goods and services. Its exchange rate fluctuates continuously, and sometimes wildly. It lacks wide acceptance and is vulnerable to manipulation by parties with modest funding. Security incidents such as website and account compromise may trigger major sell-offs. Other fluctuations can build into positive feedback loops and cause much larger exchange rate fluctuations. Anyone who puts money into Bitcoin should understand the risk they are taking and consider it a high-risk currency. Later, as Bitcoin becomes better known and more widely accepted, it may stabilize, but for the time being it is unpredictable. Any investment in Bitcoin should be done carefully and with a clear plan to manage the risk.<br />
<br />
=== Can I buy bitcoins with Paypal? ===<br />
<br />
It is possible to buy [[physical bitcoins]] with PayPal but it is otherwise difficult and/or expensive to do so for non-physical bitcoins, because of significant risk to the seller. <br />
<br />
While it is possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most exchanges do not allow funding through PayPal. This is due to repeated cases where someone pays for bitcoins with Paypal, receives their bitcoins, and then fraudulently complains to Paypal that they never received their purchase. PayPal often sides with the fraudulent buyer in this case, which means any seller needs to cover that risk with higher fees or refuse to accept PayPal altogether.<br />
<br />
Buying Bitcoins from individuals this way is still possible, but requires the seller to have some trust that the buyer will not file a claim with PayPal to reverse the payment.<br />
<br />
=== Where can I find a forum to discuss Bitcoin? ===<br />
<br />
Please visit the [[Bitcoin:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] for links to Bitcoin-related forums.<br />
<br />
=== How are new bitcoins created? ===<br />
<br />
[[File:total_bitcoins_over_time_graph.png|thumb|Number of bitcoins over time, assuming a perfect 10-minute interval.]]<br />
New bitcoins are generated by the network through the process of "[[#What is mining?|''mining'']]". In a process that is similar to a continuous raffle draw, mining nodes on the network are awarded bitcoins each time they find the solution to a certain mathematical problem (and thereby create a new [[block]]). Creating a block is a [[proof of work]] with a difficulty that varies with the overall strength of the network. The reward for solving a block is [[Controlled Currency Supply|automatically adjusted]] so that roughly every four years of operation of the Bitcoin network, half the amount of bitcoins created in the prior 4 years are created. {{formatnum:10500000}} bitcoins were created in the first 4 (approx.) years from January 2009 to November 2012. Every four years thereafter this amount halves, so it will be {{formatnum:5250000}} over years 4-8, {{formatnum:2625000}} over years 8-12, and so on. Thus the total number of bitcoins in existence will never exceed {{formatnum:21000000}}. See [[Controlled Currency Supply]].<br />
<br />
Blocks are [[Mining|mined]] every 10 minutes, on average and for the first four years ({{formatnum:210000}} blocks) each block included 50 new bitcoins. As the amount of processing power directed at mining changes, the difficulty of creating new bitcoins changes. This difficulty factor is calculated every 2016 blocks and is based upon the time taken to generate the previous 2016 blocks. See [[Mining]].<br />
<br />
=== What's the current total number of bitcoins in existence? ===<br />
<br />
[http://blockexplorer.com/q/totalbc Current count]. Also see [https://blockchain.info/charts/total-bitcoins Total bitcoins in circulation chart]<br />
<br />
The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first {{formatnum:210000}} blocks, 25 BTC for the next {{formatnum:210000}} blocks, then 12.5 BTC, 6.25 BTC and so on.<br />
<br />
=== How divisible are bitcoins? ===<br />
<br />
A bitcoin can be divided down to 8 decimal places. Therefore, 0.00000001 BTC is the smallest amount that can be handled in a transaction. If necessary, the protocol and related software can be modified to handle even smaller amounts.<br />
<br />
=== What do I call the various denominations of bitcoin? ===<br />
<br />
There is a lot of discussion about the naming of these fractions of bitcoins. The leading candidates are:<br />
<br />
* 1 BTC = 1 bitcoin<br />
* 0.01 BTC = 1 cBTC = 1 centibitcoin (also referred to as bitcent)<br />
* 0.001 BTC = 1 mBTC = 1 millibitcoin (also referred to as mbit (pronounced em-bit) or millibit or even bitmill)<br />
* 0.000 001 BTC = 1 μBTC = 1 microbitcoin (also referred to as ubit (pronounced yu-bit) or microbit)<br />
<br />
The above follows the accepted international SI prefixes for hundredths, thousandths, and millionths. There are many arguments against the special case of 0.01 BTC since it is unlikely to represent anything meaningful as the Bitcoin economy grows (it certainly won't be the equivalent of 0.01 USD, GBP or EUR). Equally, the inclusion of existing national currency denominations such as "cent", "nickel", "dime", "pence", "pound", "kopek" and so on are to be discouraged; this is a worldwide currency.<br />
<br />
One exception is the "satoshi" which is smallest denomination currently possible <br />
<br />
* 0.000 000 01 BTC = 1 satoshi (pronounced sa-toh-shee)<br />
which is so named in honour of Satoshi Nakamoto, the pseudonym of the inventor of Bitcoin.<br />
<br />
For an overview of all defined units of Bitcoin (including less common and niche units), see [[Units]].<br />
<br />
Further discussion on this topic can be found on the forums here:<br />
<br />
* [https://bitcointalk.org/index.php?topic=14438.msg195287#msg195287 We need names]<br />
* [https://bitcointalk.org/index.php?topic=8282.0 What to call 0.001 BTC]<br />
<br />
=== How does the halving work when the number gets really small? ===<br />
<br />
Eventually the reward will go from 0.00000001 BTC to zero and no more bitcoins will be created. <br />
<br />
The block reward calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by two and rounded down. The integer is equal to the value in BTC * 100,000,000 since internally in the reference client software, all Bitcoin balances and values are stored as unsigned integers.<br />
<br />
With an initial block reward of 50 BTC, it will take many 4-year periods for the block reward to reach zero.<br />
<br />
=== How long will it take to generate all the coins? ===<br />
<br />
The last block that will generate coins will be block #6,929,999 which should be generated at or near the year 2140. The total number of coins in circulation will then remain static at 20,999,999.9769 BTC.<br />
<br />
Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20,999,999.999999999496 BTC.<br />
<br />
=== If no more coins are going to be generated, will more blocks be created? ===<br />
<br />
Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, these fees will sustain the ability to use bitcoins and the Bitcoin network. There is no practical limit on the number of blocks that will be mined in the future.<br />
<br />
=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===<br />
<br />
Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will eventually increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").<br />
<br />
The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.<br />
<br />
=== If every transaction is broadcast via the network, does Bitcoin scale? ===<br />
The Bitcoin protocol allows lightweight clients that can use Bitcoin without downloading the entire transaction history. As traffic grows and this becomes more critical, implementations of the concept will be developed. Full network nodes will at some point become a more specialized service.<br />
<br />
With some modifications to the software, full Bitcoin nodes could easily keep up with both VISA and MasterCard combined, using only fairly modest hardware (a single high end server by todays standards). It is worth noting that the MasterCard network is structured somewhat like Bitcoin itself - as a peer to peer broadcast network.<br />
<br />
Learn more about [[Scalability]].<br />
<br />
==Economy==<br />
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===<br />
Bitcoins have value because they are useful and because they are [[Controlled Currency Supply|scarce]]. As they are accepted by more merchants, their value will [http://en.wikipedia.org/wiki/Sticky_%28economics%29 stabilize]. See the [[Trade|list of Bitcoin-accepting sites]].<br />
<br />
When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. Bitcoins, like dollars and euros, are not backed up by anything except the variety of merchants that accept them.<br />
<br />
It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.<br />
<br />
Alternatively it needs to be added that while the law of supply and demand applies it does not guarantee value of Bitcoins in the future. If confidence in Bitcoins is lost then it will not matter that the supply can no longer be increased, the demand will fall off with all holders trying to get rid of their coins. An example of this can be seen in cases of state currencies, in cases when the state in question dissolves and so no new supply of the currency is available (the central authority managing the supply is gone), however the demand for the currency falls sharply because confidence in its purchasing power disappears. Of-course Bitcoins do not have such central authority managing the supply of the coins, but it does not prevent confidence from eroding due to other situations that are not necessarily predictable.<br />
<br />
=== Is Bitcoin a bubble? ===<br />
Yes, in the same way as the euro and dollar are. They only have value in exchange and have no inherent value. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.<br />
<br />
=== Is Bitcoin a Ponzi scheme? ===<br />
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.<br />
<br />
A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters, and indeed, society as a whole, benefit from the usefulness of a stable, fast, inexpensive, and widely accepted p2p currency.<br />
<br />
The fact that early adopters benefit more doesn't alone make anything a Ponzi scheme. All good investments in successful companies have this quality.<br />
<br />
=== Doesn't Bitcoin unfairly benefit early adopters? ===<br />
Early adopters have a large number of bitcoins now because they took a risk and invested resources in an unproven technology. By so doing, they have helped Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.<br />
<br />
In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin.<br />
<br />
Since the pricing of Bitcoins has fallen greatly from its June 2011 peak, prices today are much more similar to those enjoyed by many early adopters. Those who are buying Bitcoins today likely believe that Bitcoin will grow significantly in the future. Setting aside the brief opportunity to have sold Bitcoins at the June 2011 peak enjoyed by few, the early-adopter window is arguably still open.<br />
<br />
===Won't loss of wallets and the finite amount of Bitcoins create excessive deflation, destroying Bitcoin? ===<br />
Worries about Bitcoin being destroyed by deflation are not entirely unfounded. Unlike most currencies, which experience inflation as their founding institutions create more and more units, Bitcoin will likely experience gradual deflation with the passage of time. Bitcoin is unique in that only a small amount of units will ever be produced (twenty-one million to be exact), this number has been known since the project's inception, and the units are created at a predictable rate.<br />
<br />
Also, Bitcoin users are faced with a danger that doesn't threaten users of any other currency: if a Bitcoin user loses his wallet, his money is gone forever, unless he finds it again. And not just to him; it's gone completely out of circulation, rendered utterly inaccessible to anyone. As people will lose their wallets, the total number of Bitcoins will slowly decrease.<br />
<br />
Therefore, Bitcoin seems to be faced with a unique problem. Whereas most currencies inflate over time, Bitcoin will mostly likely do just the opposite. Time will see the irretrievable loss of an ever-increasing number of Bitcoins. An already small number will be permanently whittled down further and further. And as there become fewer and fewer Bitcoins, the laws of supply and demand suggest that their value will probably continually rise.<br />
<br />
Thus Bitcoin is bound to once again stray into mysterious territory, because no one exactly knows what happens to a currency that grows continually more valuable. Many economists claim that a low level of inflation is a good thing for a currency, but nobody is quite sure about what might happens to one that continually deflates. Although deflation could hardly be called a rare phenomenon, steady, constant deflation is unheard of. There may be a lot of speculation, no one has any hard data to back up their claims.<br />
<br />
That being said, there is a mechanism in place to combat the obvious consequences. Extreme deflation would render most currencies highly impractical: if a single Canadian dollar could suddenly buy the holder a car, how would one go about buying bread or candy? Even pennies would fetch more than a person could carry. Bitcoin, however, offers a simple and stylish solution: infinite divisibility. Bitcoins can be divided up and trade into as small of pieces as one wants, so no matter how valuable Bitcoins become, one can trade them in practical quantities. <br />
<br />
In fact, infinite divisibility should allow Bitcoins to function in cases of extreme wallet loss. Even if, in the far future, so many people have lost their wallets that only a single Bitcoin, or a fraction of one, remains, Bitcoin should continue to function just fine. No one can claim to be sure what is going to happen, but deflation may prove to present a smaller threat than many expect.<br />
<br />
For more information, see the [[Deflationary spiral]] page.<br />
<br />
=== What if someone bought up all the existing Bitcoins? ===<br />
Bitcoin markets are competitive -- meaning the price of a bitcoin will rise or fall depending on supply and demand at certain price levels. Only a fraction of bitcoins issued to date are found on the exchange markets for sale. So even though technically a buyer with lots of money could buy all the bitcoins offered for sale, unless those holding the rest of the bitcoins offer them for sale as well, even the wealthiest, most determined buyer can't get at them.<br />
<br />
Additionally, new currency continues to be issued daily and will continue to do so for decades though over time the rate at which they are issued declines to insignificant levels. Those who are mining aren't obligated to sell their bitcoins so not all bitcoins will make it to the markets even.<br />
<br />
This situation doesn't suggest, however, that the markets aren't vulnerable to price manipulation. It doesn't take significant amounts of money to move the market price up or down and thus Bitcoin remains a volatile asset.<br />
<br />
===What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete?===<br />
<br />
That the block chain cannot be easily forked represents one of the central security mechanisms of Bitcoin. Given the choice between two block chains, a Bitcoin miner always chooses the longer one - that is to say, the one with the more complex hash. Thusly, it ensures that each user can only spend their bitcoins once, and that no user gets ripped off.<br />
<br />
As a consequence of the block chain structure, there may at any time be many different sub-branches, and the possibility always exists of a transaction being over-written by the longest branch, if it has been recorded in a shorter one. The older a transaction is though, the lower its chances of being over-written, and the higher of becoming permanent. Although the block chain prevents one from spending more Bitcoins than one has, it means that transactions can be accidentally nullified. <br />
<br />
A new block chain would leave the network vulnerable to [[double-spending|double-spend]] attacks. However, the creation of a viable new chain presents considerable difficulty, and the possibility does not present much of a risk.<br />
<br />
Bitcoin will always choose the longer Block Chain and determines the relative length of two branches by the complexities of their hashes. Since the hash of each new block is made from that of the block preceding it, to create a block with a more complex hash, one must be prepared to do more computation than has been done by the entire Bitcoin network from the fork point up to the newest of the blocks one is trying to supersede. Needless to say, such an undertaking would require a very large amount of processing power and since Bitcoin is continually growing and expanding, it will likely only require more with the passage of time.<br />
<br />
A much more distinct and real threat to the Bitcoin use is the development of other, superior virtual currencies, which could supplant Bitcoin and render it obsolete and valueless.<br />
<br />
A great deal of careful thought and ingenuity has gone into the development of Bitcoin, but it is the first of its breed, a prototype, and vulnerable to more highly-evolved competitors. At present, any threatening rivals have yet to rear their heads; Bitcoin remains the first and foremost private virtual currency, but we can offer no guarantees that it will retain that position. It would certainly be in keeping with internet history for a similar system built from the same principles to supersede and cast Bitcoin into obsolescence, after time had revealed its major shortcomings. Friendster and Myspace suffered similar fates at the hand of Facebook, Napster was ousted by Limeware, Bearshare and torrent applications, and Skype has all but crushed the last few disciples of the Microsoft Messenger army. <br />
<br />
This may sound rather foreboding, so bear in mind that the introduction of new and possibly better virtual currencies will not necessarily herald Bitcoin's demise. If Bitcoin establishes itself sufficiently firmly before the inception of the next generation of private, online currencies so as to gain widespread acceptance and general stability, future currencies may pose little threat even if they can claim superior design. This is known as the network effect.<br />
<br />
=== Is Bitcoin open to value manipulation? ===<br />
<br />
The current low market cap of Bitcoin means that any investor with deep enough pockets can significantly change/manipulate the rate. Is this a problem?<br />
<br />
This is only a problem if you are investing in Bitcoin for short period of time. A manipulator can't change the fundamentals, and over a period of 5-10 years they will win over any short term manipulations.<br />
<br />
==Sending and Receiving Payments==<br />
<br />
=== Why do I have to wait 10 minutes before I can spend money I received? ===<br />
<br />
10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case. <br />
<br />
[[Blocks]] (shown as "confirmations" in the GUI) are how the Bitcoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!<br />
<br />
Ten minutes was specifically chosen by [[Satoshi]] as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.<br />
<br />
As a thought experiment, what if the Bitcoin network grew to include Mars? From the farthest points in their orbits, it takes about 20 minutes for a signal to travel from Earth to Mars. With only 10 minutes between new blocks, miners on Mars would always be 2 blocks behind the miners on Earth. It would be almost impossible for them to contribute to the block chain. If we wanted collaborate with those kinds of delays, we would need at least a few hours between new blocks. <br />
<br />
[[File:TransactionConfirmationTimesExample.PNG]]<br />
<br />
=== Do you have to wait until my transactions are confirmed in order to buy or sell things with Bitcoin? ===<br />
<br />
YES, you do, IF the transaction is non-recourse. The Bitcoin reference software does not display transactions as confirmed until six blocks have passed (confirmations). As transactions are burred in the chain they become increasingly non-reversible but are very reversible before the first confirmation. Two to six confirmations are recommended for non-recourse situations depending on the value of the transactions involved.<br />
<br />
When people ask this question they are usually thinking about applications like supermarkets. This generally is a recourse situation: if somebody tries to double-spend on a face-to-face transaction it might work a few times, but probabalistically speaking eventually one of the double-spends will get noticed, and the penalty for shoplifting charges in most localities is calibrated to be several times worse than the proceeds of a single shoplifting event.<br />
<br />
Double-spends might be a concern for something like a snack machine in a low-traffic area with no nearby security cameras. Such a machine shouldn't honor 0-confirmation payments, and should instead use some other mechanism of clearing Bitcoin or validating transactions against reversal, see the wiki article [[Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation|here]] for alternatives.<br />
<br />
Applications that require immediate payment processing, like supermarkets or snack machines, need to manage the risks. Here is one way to reverse an unconfirmed payment:<br />
<br />
A [[Double-spending#Finney_attack|Finney attack]], in which an attacker mines a block containing a movement of some coins back to themselves. Once they find a block solution, they quickly go to a merchant and make a purchase, then broadcast the block, thus taking back the coins. This attack is a risk primarily for goods that are dispatched immediately, like song downloads or currency trades. Because the attacker can't choose the time of the attack, it isn't a risk for merchants such as supermarkets where you can't choose exactly when to pay (due to queues, etc). The attack can fail if somebody else finds a block containing the purchasing transaction before you release your own block, therefore, merchants can reduce but not eliminate the risk by making purchasers wait some length of time that's less than a confirm.<br />
<br />
Because pulling off this attack is not trivial, merchants who need to sell things automatically and instantly are most likely to just price the cost of reversal fraud in, or use insurance.<br />
<br />
=== I was sent some bitcoins and they haven't arrived yet! Where are they? ===<br />
<br />
Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them. <br />
<br />
The latest version of the Bitcoin-Qt client tells you how far it has yet to go in downloading the blockchain. Hover over the icon in the bottom right corner of the client to learn your client's status.<br />
<br />
If it has not caught up then it's possible that your transaction hasn't been included in a block yet. <br />
<br />
You can check pending transactions in the network by going [http://blockchain.info here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client. <br />
<br />
If the transaction is based on a coin that was in a recent transaction then it could be considered a low priority transaction. Transfers can take longer if the transaction fee paid was not high enough. If there is no fee at all the transfer can get a very low priority and take hours or even days to be included in a block.<br />
<br />
=== Why does my Bitcoin address keep changing? ===<br />
<br />
Whenever the address listed in "Your address" receives a transaction, Bitcoin replaces it with a new address. This is meant to encourage you to use a new address for every transaction, which enhances [[anonymity]]. All of your old addresses are still usable: you can see them in ''Settings -> Your Receiving Addresses''.<br />
<br />
===How much will the transaction fee be?===<br />
<br />
Some transactions might require a [[transaction fee]] for them to get confirmed in a timely manner. The transaction fee is processed by and received by the bitcoin miner. The most recent version of the Bitcoin client will estimate an appropriate fee when a fee might be required.<br />
<br />
The fee is added to the payment amount. For example, if you are sending a 1.234 BTC payment and the client requires a 0.0005 BTC fee, then 1.2345 BTC will be subtracted from the wallet balance for the entire transaction and the address for where the payment was sent will receive a payment of 1.234 BTC.<br />
<br />
A fee might be imposed because your transaction looks like a denial of service attack to the Bitcoin system. For example, it might be burdensome to transmit or it might recycle Bitcoins you recently received. The wallet software attempts to avoid generating burdensome transactions, but it isn't always able to do so: The funds in your wallet might be new or composed of many tiny payments. <br />
<br />
Because the fee is related to the amount of data that makes up the transaction and not to the amount of Bitcoins being sent, the fee may seem extremely low (0.0005 BTC for a 1,000 BTC transfer) or unfairly high (0.004 BTC for a 0.02 BTC payment, or about 20%). If you are receiving tiny amounts (''e.g.'' as small payments from a mining pool) then fees when sending will be higher than if your activity follows the pattern of conventional consumer or business transactions. <br />
<br />
As of Bitcoin 0.5.3 the required fee will not be higher than 0.05 BTC. For most users there is usually no required fee at all. If a fee is required it will most commonly be 0.0005 BTC.<br />
<br />
=== What happens when someone sends me a bitcoin but my computer is powered off? ===<br />
<br />
Bitcoins are not actually "sent" to your wallet; the software only uses that term so that we can use the currency without having to learn new concepts. Your wallet is only needed when you wish to spend coins that you've received.<br />
<br />
If you are sent coins when your wallet client program is not running, and you later launch the wallet client program, the coins will eventually appear as if they were just received in the wallet. That is to say, when the client program is started it must download blocks and catch up with any transactions it did not already know about.<br />
<br />
=== How long does "synchronizing" take when the Bitcoin client is first installed? What's it doing? ===<br />
<br />
The popular Bitcoin client software from bitcoin.org implements a "full" Bitcoin node: It can carry out all the duties of the Bitcoin P2P system, it isn't simply a "client". One of the principles behind the operation of full Bitcoin nodes is that they don't assume that the other participants have followed the rules of the Bitcoin system. During synchronization, the software is processing historical Bitcoin transactions and making sure for itself that all of the rules of the system have been correctly followed.<br />
<br />
In normal operation, after synchronizing, the software should use a hardly noticeable amount of your computer's resources.<br />
<br />
When the wallet client program is first installed, its initial validation requires a lot of work from your computer's hard disk, so the amount of time to synchronize depends on your disk speed and, to a lesser extent, your CPU speed. It can take anywhere from a few hours to a day or so. On a slow computer it could take more than 40 hours of continuous synchronization, so check your computer's power-saving settings to ensure that it does not turn its hard disk off when unattended for a few hours. You can use the Bitcoin software during synchronization, but you may not see recent payments to you until the client program has caught up to the point where those transactions happened.<br />
<br />
If you feel that this process takes too long, you can download a pre-synchronized blockchain from [http://eu2.bitcoincharts.com/blockchain/ http://eu2.bitcoincharts.com/blockchain/]. Alternatively, you can try an alternative "lite" client such as Multibit or a super-light client like electrum, though these clients have somewhat weaker security, are less mature, and don't contribute to the health of the P2P network.<br />
<br />
==Networking==<br />
=== Do I need to configure my firewall to run Bitcoin? ===<br />
<br />
Bitcoin will connect to other nodes, usually on TCP port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your Bitcoin client to connect to many nodes. [[Testnet]] uses TCP port 18333 instead of 8333.<br />
<br />
If you want to restrict your firewall rules to a few IPs, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]].<br />
<br />
=== How does the peer finding mechanism work? ===<br />
<br />
Bitcoin finds peers primarily by forwarding peer announcements within its own network and each node saves a database of peers that it's aware of, for future use. In order to bootstrap this process Bitcoin needs a list of initial peers, these can be provided manually but normally it obtains them by querying a set of DNS domain names which have automatically updated lists, if that doesn't work it falls back to a built-in list which is updated from time to time in new versions of the software. There is also an IRC based mechanism but it is disabled by default.<br />
<br />
==Mining==<br />
===What is mining?===<br />
[[Mining]] is the process of spending computation power to secure Bitcoin transactions against reversal and introducing new Bitcoins to the system.<br />
<br />
Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets the newly generated Bitcoins (25 per block at current levels). If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.<br />
<br />
===Is mining used for some useful computation?===<br />
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.<br />
<br />
===Is it not a waste of energy?===<br />
Spending energy on creating and securing a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.<br />
<br />
===Why don't we use calculations that are also useful for some other purpose?===<br />
To provide security for the Bitcoin network, the calculations involved need to have some [http://bitcoin.stackexchange.com/questions/5617/why-are-bitcoin-calculation-useless/5618#5618 very specific features]. These features are incompatible with leveraging the computation for other purposes.<br />
<br />
===How can we stop miners from creating zero transaction blocks?===<br />
The incentive for miners to include transactions is in the fees that come along with them. If we were to implement some minimum number of transactions per block it would be trivial for a miner to create and include transactions merely to surpass that threshold. As the network matures, the block reward drops, and miners become more dependent on transactions fees to pay their costs, the problem of zero transaction blocks should diminish over time.<br />
<br />
===How does the proof-of-work system help secure Bitcoin?===<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] proof of work with a minor adaption. To give a general idea of the mining process, imagine this setup:<br />
<br />
payload = <some data related to things happening on the Bitcoin network><br />
nonce = 1<br />
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )<br />
<br />
The work performed by a miner consists of repeatedly increasing "nonce" until<br />
the hash function yields a value, that has the rare property of being below a certain<br />
target threshold. (In other words: The hash "starts with a certain number of zeroes",<br />
if you display it in the fixed-length representation, that is typically used.)<br />
<br />
As can be seen, the mining process doesn't compute anything special. It merely<br />
tries to find a number (also referred to as nonce) which - in combination with the payload -<br />
results in a hash with special properties.<br />
<br />
The advantage of using such a mechanism consists of the fact, that it is very easy to check a result: Given the payload and a specific nonce, only a single call of the hashing function is needed to verify that the hash has the required properties. Since there is no known way to find these hashes other than brute force, this can be used as a "proof of work" that someone invested a lot of computing power to find the correct nonce for this payload.<br />
<br />
This feature is then used in the Bitcoin network to secure various aspects. An attacker<br />
that wants to introduce malicious payload data into the network, will need to do the<br />
required proof of work before it will be accepted. And as long as honest miners have more<br />
computing power, they can always outpace an attacker.<br />
<br />
Also see [http://en.wikipedia.org/wiki/Hashcash Hashcash] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] and [http://en.wikipedia.org/wiki/SHA2 SHA2] and on Wikipedia.<br />
<br />
===Why was the "Generate coin" option of the client software removed?===<br />
<br />
In the early days of Bitcoin, it was easy for anyone to find new blocks using standard CPUs. As more and more people started mining, the [[difficulty]] of finding new blocks has greatly increased to the point where the average time for a CPU to find a single block can be many years. The only cost-effective method of [[Mining|mining]] is using a high-end graphics card with special software (see also [[Why a GPU mines faster than a CPU]]) and/or joining a [[Bitcoin Pool|mining pool]]. Since solo CPU mining is essentially useless, it was removed from the GUI of the Bitcoin software.<br />
<br />
==Security==<br />
<br />
===Could miners collude to give themselves money or to fundamentally change the nature of Bitcoin?===<br />
<br />
There are two questions in here. Let's look at them separately.<br />
<br />
;Could miners gang up and give themselves money?<br />
<br />
Mining itself is the process of creating new blocks in the block chain. Each block contains a list of all the transactions that have taken place across the entire Bitcoin network since the last block was created, as well as a hash of the previous block. New blocks are 'mined', or rather, generated, by Bitcoin clients correctly guessing sequences of characters in codes called 'hashes,' which are created using information from previous blocks. Bitcoin users may download specialized 'mining' software, which allows them to dedicate some amount of their processing power – however large or small – to guessing at strings within the hash of the previous block. Whoever makes the right guess first, thus creating a new block, receives a reward in Bitcoins.<br />
<br />
The block chain is one of the two structures that makes Bitcoin secure, the other being the public-key encryption system on which Bitcoin trade is based. The block chain assures that not only is every single transaction that ever takes place recorded, but that every single transaction is recorded on the computer of anyone who chooses to store the relevant information. Many, many users have complete records of every transaction in Bitcoins history readily available to them at any point, and anyone who wants in the information can obtain it with ease. These things make Bitcoin very hard to fool.<br />
<br />
The Bitcoin network takes considerable processing power to run, and since those with the most processing power can make the most guesses, those who put the most power toward to sustaining the network earn the most currency. Each correct guess yields, at present, twenty-five Bitcoins, and as Bitcoins are presently worth something (although the value still fluctuates) every miner who earns any number of Bitcoins makes money. Some miners pull in Bitcoins on their own; and some also join or form pools wherein all who contribute earn a share of the profits. <br />
<br />
Therefore, first answer is a vehement “yes” – not only can miners collude to get more money, Bitcoin is designed to encourage them to do so. Bitcoin pools are communal affairs, and there is nothing dishonest or underhanded about them.<br />
<br />
Of course, the real question is:<br />
<br />
;Can they do so in ways not sanctioned by Bitcoin developers? Is there any way to rip off the network and make loads of money dishonestly?<br />
<br />
Bitcoin isn't infallible. It can be cheated, but doing so is extremely difficult. Bitcoin was designed to evade some of the central problems with modern currencies – namely, that their trustworthiness hinges upon that of people who might not have users' best interests in mind. Every currency in the world (other than Bitcoin) is controlled by large institutions who keep track of what's done with it, and who can manipulate its value. And every other currency has value because people trust the institutions that control them.<br />
<br />
Bitcoin doesn't ask that its users trust any institution. Its security is based on the cryptography that is an integral part of its structure, and that is readily available for any and all to see. Instead of one entity keeping track of transactions, the entire network does, so Bitcoins are astoundingly difficult to steal, or double-spend. Bitcoins are created in a regular and predictable fashion, and by many different users, so no one can decide to make a whole lot more and lessen their value. In short, Bitcoin is designed to be inflation-proof, double-spend-proof and completely distributed.<br />
<br />
Nonetheless, there are a few ways that one can acquire Bitcoins dishonestly. Firstly, one can steal private keys. Key theft isn't something that Bitcoin security has been designed to prevent: it's up to users to keep theirs safe. But the cryptography is designed so that it is completely impossible to deduce someone's private key from their public one. As long as you keep your private key to yourself, you don't have much to worry about. Furthermore, one could theoretically create a new block chain, but due to the way in which the block chain is constructed, this would be extremely difficult and require massive amounts of processing power. A full explanation of the difficulties involved can be found in the [[block chain]] article.<br />
<br />
Bitcoin can be ripped off – but doing so would be extremely hard and require considerable expertise and a staggering amount of processing power. And it's only going to get harder with time. Bitcoin isn't impenetrable, but it's close enough to put any real worries in the peripherals.<br />
<br />
;Could miners fundamentally change the nature of Bitcoin?<br />
<br />
Once again, almost certainly not.<br />
<br />
Bitcoin is a distributed network, so any changes implemented to the system must be accepted by all users. Someone trying to change the way Bitcoins are generated would have to convince every user to download and use their software – so the only changes that would go through are those that would be equally benefit all users. <br />
<br />
And thus, it is more or less impossible for anyone to change the function of Bitcoin to their advantage. If users don't like the changes, they won't adopt them, whereas if users do like them, then these will help everyone equally. Of course, one can conceive of a situation where someone manages to get a change pushed through that provides them with an advantage that no one notices, but given that Bitcoin is structurally relatively simple, it is unlikely that any major changes will go through without someone noticing first.<br />
<br />
The fact that such changes are so difficult to make testifies to the fully distributed nature of Bitcoin. Any centrally controlled currency can be modified by its central agency without the consent of its adherents. Bitcoin has no central authority, so it changes only at the behest of the whole community. Bitcoins development represents a kind of collective evolution; the first of its kind among currencies.<br />
<br />
==Help==<br />
===I'd like to learn more. Where can I get help?===<br />
<br />
* Read the [[Introduction|introduction to bitcoin]] <br />
* See the videos, podcasts, and blog posts from the [[Press]]<br />
* Read and post on the [[:Bitcoin:Community_portal#Bitcoin_Community_Forums|forums]]<br />
* Chat on one of the [[:Bitcoin:Community_portal#IRC_Chat|Bitcoin IRC]] channels<br />
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works<br />
* Ask questions on the [http://bitcoin.stackexchange.com Bitcoin Stack Exchange]<br />
<br />
==See Also==<br />
<br />
* [[Man page]]<br />
* [[Introduction]]<br />
<br />
[[de:FAQ]]<br />
[[zh-cn:FAQ]]<br />
[[fr:FAQ]]<br />
[[ru:FAQ]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Complete_detail_of_how_Bitcoin_works&diff=41860Complete detail of how Bitcoin works2013-10-21T17:23:08Z<p>Adam3us: /* Factual Inaccuracies */ very minor: spacing typo in previous</p>
<hr />
<div>===[http://www.youtube.com/watch?v=mrlgw5KpkXM Steve Gibson's Explanation of Bitcoin]===<br />
<br />
====Out-of-Date Information====<br />
* Project is not on SourceForge anymore. It's on GitHub. <ref name="bitcoin">[http://github.com/bitcoin/bitcoin bitcoin on Github], The primary Bitcoin project page on Github</ref><br />
* We no longer go to an IRC chat room to find peers. We use DNS-based host seeding.<br />
* We have gone through a reward halving already. So his 50-bitcoin-reward is now out-of-date.<br />
* He references the EFF bitcoin donation page, which is no longer available.<br />
* He says coin creation rate is 300 coins per hour within the entire system. Since the block halving, this is no longer the case.<br />
* The network is no longer 186GH/s. It is as of this writing 36TH/s.<ref name="sipa hashrate">[http://bitcoin.sipa.be Excellent hashrate graphs], sipa built a regularly-updated set of hashrate graphs</ref><br />
* The UI no longer works in only two decimal digits of precision.<br />
* One can no longer use bitcoind to directly generate coins, nor is CPU mining of basically any worth.<br />
<br />
====Factual Inaccuracies====<br />
* Asserts Satoshi is Japanese. We don't know that.<br />
* He asserts that currencies are "synthetic", but people use objects with instrinsic value all the time as currency, so this is incorrect unless you accept the narrow definition of "currency" as a "modern money system issued by a government." <ref name="currency definition">[http://www.investopedia.com/terms/c/currency.asp Investopedia "Currency" Definition], A definition of the term as per an online reference</ref><br />
* Humans didn't just choose gold just because it was scarce. We chose gold for a whole host of other properties.<ref name="why gold">[http://www.npr.org/blogs/money/2011/02/15/131430755/a-chemist-explains-why-gold-beat-out-lithium-osmium-einsteinium Why Gold for Currency], Reasons why gold was the best (and perhaps only) choice for currency on Earth</ref><br />
* Satoshi's paper doesn't fully explain how bitcoin works, or else we'd all be able to just point to that paper and let newbies read it.<ref name="bitcoin paper">[http://bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System], The seminal paper by Satoshi Nakamoto himself</ref><br />
* It was incorrectly claimed that Adam Back invented the concept of proof of work. Bitcoin does use Back's hashcash proof-of-work because bitcoin needs specific properties and hashcash is the simplest (and so far only) proof of work with these required properties (primecoin maybe the new exception). But the PoW concept is older, and due to Dwork & Naor in their crypto 1992 paper.<br />
* Explanation of hashing is wrong: To get 20 bits of 0 at the beginning of a hash, you still don't get a '''guarantee''' that after 2<sup>20</sup> hashes, you have all zeroes, and that half that number on average are what's necessary to find a 20-zero solution. Basically this whole explanation is just plain wrong.<br />
* Hashcash didn't fail because legitimate mailing lists are indistinguishable from spammers. He states that there are no measures that could be taken to allow legit mass-mailing lists while denying spamming. This is factually incorrect.<br />
* The public key of the signer of a transaction is NOT included in the transaction itself.<ref name="bitcoin paper" /><br />
* He says multiple times that all nodes on the network are busy mining. This is not the case at all, nor was it for months prior to the video's creation date, which was February, 2011.<br />
* The blockchain is not the chain "up to the most recent block that anyone has created." It is the chain of most-work-done. Counter-examples include the possibility of multiple competing sibling blocks, and stale blocks arriving too late.<br />
* He equates the '''number of zeroes in front''' of the difficulty target directly with the integer-sounding difficulty.<br />
* Gibson says multiple times it is completely anonymous currency. '''False'''.<br />
* He says when you first fire up bitcoin it creates "a keypair." It's actually a whole bunch of them.<br />
* Since bitcoin is not anonymous, when he says there's no way of knowing who is behind addresses, this is misleading.<br />
* There '''are''' ways in fact to track bitcoin users, even if you create all the pubkeys you want. Staying relatively anonymous doesn't require you to just create a bunch of pubkeys. It is quite a bit harder than that.<ref name="bitcoin analysis1">[http://www.youtube.com/watch?v=-FaQNPCqG58 Bitcoin - An Analysis], A 28c3 talk describing in depth some possible methods for de-anonymizing users, amongst quite a number of other topics studied</ref><ref name="bitcoin analyis2">[http://www.youtube.com/watch?v=gQoykhNoBbY Black OPs of TCP/IP], Dan Kaminsky rambling about Bitcoin security</ref><br />
* CPU mining is basically no point anymore. Nor was there a point even back then.<br />
* 21,000,000 is not the real number. The real number of bitcoins ever created in the far future will be 20999999.97690000 - 0.00000001 bitcoins, assuming nobody ever again does what midnightmagic did<ref name="underpay">[https://bitcointalk.org/index.php?topic=7253.msg184414#msg184414 (in his case, as a tribute)], midnightmagic claims to have underpaid himself by 1x10<sup>-8</sup>, but he accidentally threw away a bunch of fees too</ref><ref name="blockexplorer underpay">[http://blockexplorer.com/b/124724 124724], the full blockexplorer decode of the underpay block</ref>, and pays themselves less.<br />
<br />
====Imprecise Wording====<br />
* A block is more than just a collection of transactions.<br />
* He says bitcoind addresses are "public keys converted into ascii" which is somewhat misleading. It's a special form of base-58.<br />
* Steve says the same thing twice without linking the two concepts: He says each four years X bitcoins are created (divided by two each four years,) but then then describes 210,000 blocks afterwards as the same thing without really linking the two facts together.<br />
* Is not using the terminology for "double-spend" or explaining why it's even a consideration for cryptocurrency, which prevents people from looking terminology up later. (Too dumbed-down.)<br />
* The term "anchored" is wrong. Bitcoin is not anchored to other currencies.<br />
<br />
===References===<br />
<references /></div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Complete_detail_of_how_Bitcoin_works&diff=41859Complete detail of how Bitcoin works2013-10-21T17:21:30Z<p>Adam3us: /* Factual Inaccuracies */ prefix with clearer statement about the factual inaccuracy (pow invention attribution), delete extraneous text in same point</p>
<hr />
<div>===[http://www.youtube.com/watch?v=mrlgw5KpkXM Steve Gibson's Explanation of Bitcoin]===<br />
<br />
====Out-of-Date Information====<br />
* Project is not on SourceForge anymore. It's on GitHub. <ref name="bitcoin">[http://github.com/bitcoin/bitcoin bitcoin on Github], The primary Bitcoin project page on Github</ref><br />
* We no longer go to an IRC chat room to find peers. We use DNS-based host seeding.<br />
* We have gone through a reward halving already. So his 50-bitcoin-reward is now out-of-date.<br />
* He references the EFF bitcoin donation page, which is no longer available.<br />
* He says coin creation rate is 300 coins per hour within the entire system. Since the block halving, this is no longer the case.<br />
* The network is no longer 186GH/s. It is as of this writing 36TH/s.<ref name="sipa hashrate">[http://bitcoin.sipa.be Excellent hashrate graphs], sipa built a regularly-updated set of hashrate graphs</ref><br />
* The UI no longer works in only two decimal digits of precision.<br />
* One can no longer use bitcoind to directly generate coins, nor is CPU mining of basically any worth.<br />
<br />
====Factual Inaccuracies====<br />
* Asserts Satoshi is Japanese. We don't know that.<br />
* He asserts that currencies are "synthetic", but people use objects with instrinsic value all the time as currency, so this is incorrect unless you accept the narrow definition of "currency" as a "modern money system issued by a government." <ref name="currency definition">[http://www.investopedia.com/terms/c/currency.asp Investopedia "Currency" Definition], A definition of the term as per an online reference</ref><br />
* Humans didn't just choose gold just because it was scarce. We chose gold for a whole host of other properties.<ref name="why gold">[http://www.npr.org/blogs/money/2011/02/15/131430755/a-chemist-explains-why-gold-beat-out-lithium-osmium-einsteinium Why Gold for Currency], Reasons why gold was the best (and perhaps only) choice for currency on Earth</ref><br />
* Satoshi's paper doesn't fully explain how bitcoin works, or else we'd all be able to just point to that paper and let newbies read it.<ref name="bitcoin paper">[http://bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System], The seminal paper by Satoshi Nakamoto himself</ref><br />
* It was incorrectly claimed that Adam Back invented the concept of proof of work. Bitcoin does useBack's hashcash proof-of-work because bitcoin needs specific properties and hashcash is the simplest (and so far only) proof of work with these required properties (primecoin maybe the new exception). But the PoW concept is older, and due to Dwork & Naor in their crypto 1992 paper.<br />
* Explanation of hashing is wrong: To get 20 bits of 0 at the beginning of a hash, you still don't get a '''guarantee''' that after 2<sup>20</sup> hashes, you have all zeroes, and that half that number on average are what's necessary to find a 20-zero solution. Basically this whole explanation is just plain wrong.<br />
* Hashcash didn't fail because legitimate mailing lists are indistinguishable from spammers. He states that there are no measures that could be taken to allow legit mass-mailing lists while denying spamming. This is factually incorrect.<br />
* The public key of the signer of a transaction is NOT included in the transaction itself.<ref name="bitcoin paper" /><br />
* He says multiple times that all nodes on the network are busy mining. This is not the case at all, nor was it for months prior to the video's creation date, which was February, 2011.<br />
* The blockchain is not the chain "up to the most recent block that anyone has created." It is the chain of most-work-done. Counter-examples include the possibility of multiple competing sibling blocks, and stale blocks arriving too late.<br />
* He equates the '''number of zeroes in front''' of the difficulty target directly with the integer-sounding difficulty.<br />
* Gibson says multiple times it is completely anonymous currency. '''False'''.<br />
* He says when you first fire up bitcoin it creates "a keypair." It's actually a whole bunch of them.<br />
* Since bitcoin is not anonymous, when he says there's no way of knowing who is behind addresses, this is misleading.<br />
* There '''are''' ways in fact to track bitcoin users, even if you create all the pubkeys you want. Staying relatively anonymous doesn't require you to just create a bunch of pubkeys. It is quite a bit harder than that.<ref name="bitcoin analysis1">[http://www.youtube.com/watch?v=-FaQNPCqG58 Bitcoin - An Analysis], A 28c3 talk describing in depth some possible methods for de-anonymizing users, amongst quite a number of other topics studied</ref><ref name="bitcoin analyis2">[http://www.youtube.com/watch?v=gQoykhNoBbY Black OPs of TCP/IP], Dan Kaminsky rambling about Bitcoin security</ref><br />
* CPU mining is basically no point anymore. Nor was there a point even back then.<br />
* 21,000,000 is not the real number. The real number of bitcoins ever created in the far future will be 20999999.97690000 - 0.00000001 bitcoins, assuming nobody ever again does what midnightmagic did<ref name="underpay">[https://bitcointalk.org/index.php?topic=7253.msg184414#msg184414 (in his case, as a tribute)], midnightmagic claims to have underpaid himself by 1x10<sup>-8</sup>, but he accidentally threw away a bunch of fees too</ref><ref name="blockexplorer underpay">[http://blockexplorer.com/b/124724 124724], the full blockexplorer decode of the underpay block</ref>, and pays themselves less.<br />
<br />
====Imprecise Wording====<br />
* A block is more than just a collection of transactions.<br />
* He says bitcoind addresses are "public keys converted into ascii" which is somewhat misleading. It's a special form of base-58.<br />
* Steve says the same thing twice without linking the two concepts: He says each four years X bitcoins are created (divided by two each four years,) but then then describes 210,000 blocks afterwards as the same thing without really linking the two facts together.<br />
* Is not using the terminology for "double-spend" or explaining why it's even a consideration for cryptocurrency, which prevents people from looking terminology up later. (Too dumbed-down.)<br />
* The term "anchored" is wrong. Bitcoin is not anchored to other currencies.<br />
<br />
===References===<br />
<references /></div>Adam3ushttps://tests.bitcoin.it/w/index.php?title=Complete_detail_of_how_Bitcoin_works&diff=41840Complete detail of how Bitcoin works2013-10-20T13:38:42Z<p>Adam3us: /* Factual Inaccuracies */ simplify explanation of innacuracy about who invented proof-of-work</p>
<hr />
<div>===[http://www.youtube.com/watch?v=mrlgw5KpkXM Steve Gibson's Explanation of Bitcoin]===<br />
<br />
====Out-of-Date Information====<br />
* Project is not on SourceForge anymore. It's on GitHub. <ref name="bitcoin">[http://github.com/bitcoin/bitcoin bitcoin on Github], The primary Bitcoin project page on Github</ref><br />
* We no longer go to an IRC chat room to find peers. We use DNS-based host seeding.<br />
* We have gone through a reward halving already. So his 50-bitcoin-reward is now out-of-date.<br />
* He references the EFF bitcoin donation page, which is no longer available.<br />
* He says coin creation rate is 300 coins per hour within the entire system. Since the block halving, this is no longer the case.<br />
* The network is no longer 186GH/s. It is as of this writing 36TH/s.<ref name="sipa hashrate">[http://bitcoin.sipa.be Excellent hashrate graphs], sipa built a regularly-updated set of hashrate graphs</ref><br />
* The UI no longer works in only two decimal digits of precision.<br />
* One can no longer use bitcoind to directly generate coins, nor is CPU mining of basically any worth.<br />
<br />
====Factual Inaccuracies====<br />
* Asserts Satoshi is Japanese. We don't know that.<br />
* He asserts that currencies are "synthetic", but people use objects with instrinsic value all the time as currency, so this is incorrect unless you accept the narrow definition of "currency" as a "modern money system issued by a government." <ref name="currency definition">[http://www.investopedia.com/terms/c/currency.asp Investopedia "Currency" Definition], A definition of the term as per an online reference</ref><br />
* Humans didn't just choose gold just because it was scarce. We chose gold for a whole host of other properties.<ref name="why gold">[http://www.npr.org/blogs/money/2011/02/15/131430755/a-chemist-explains-why-gold-beat-out-lithium-osmium-einsteinium Why Gold for Currency], Reasons why gold was the best (and perhaps only) choice for currency on Earth</ref><br />
* Satoshi's paper doesn't fully explain how bitcoin works, or else we'd all be able to just point to that paper and let newbies read it.<ref name="bitcoin paper">[http://bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System], The seminal paper by Satoshi Nakamoto himself</ref><br />
* Bitcoin uses Adam Back's hashcash proof-of-work because bitcoin needs specific properties and hashcash is the simplest (and so far only) proof of work with these required properties (primecoin maybe the new exception). But the PoW concept is older, and due to Dwork & Naor in their crypto 1992 paper. Satoshi cited Back's hashcash paper in the Bitcoin paper. <br />
* Explanation of hashing is wrong: To get 20 bits of 0 at the beginning of a hash, you still don't get a '''guarantee''' that after 2<sup>20</sup> hashes, you have all zeroes, and that half that number on average are what's necessary to find a 20-zero solution. Basically this whole explanation is just plain wrong.<br />
* Hashcash didn't fail because legitimate mailing lists are indistinguishable from spammers. He states that there are no measures that could be taken to allow legit mass-mailing lists while denying spamming. This is factually incorrect.<br />
* The public key of the signer of a transaction is NOT included in the transaction itself.<ref name="bitcoin paper" /><br />
* He says multiple times that all nodes on the network are busy mining. This is not the case at all, nor was it for months prior to the video's creation date, which was February, 2011.<br />
* The blockchain is not the chain "up to the most recent block that anyone has created." It is the chain of most-work-done. Counter-examples include the possibility of multiple competing sibling blocks, and stale blocks arriving too late.<br />
* He equates the '''number of zeroes in front''' of the difficulty target directly with the integer-sounding difficulty.<br />
* Gibson says multiple times it is completely anonymous currency. '''False'''.<br />
* He says when you first fire up bitcoin it creates "a keypair." It's actually a whole bunch of them.<br />
* Since bitcoin is not anonymous, when he says there's no way of knowing who is behind addresses, this is misleading.<br />
* There '''are''' ways in fact to track bitcoin users, even if you create all the pubkeys you want. Staying relatively anonymous doesn't require you to just create a bunch of pubkeys. It is quite a bit harder than that.<ref name="bitcoin analysis1">[http://www.youtube.com/watch?v=-FaQNPCqG58 Bitcoin - An Analysis], A 28c3 talk describing in depth some possible methods for de-anonymizing users, amongst quite a number of other topics studied</ref><ref name="bitcoin analyis2">[http://www.youtube.com/watch?v=gQoykhNoBbY Black OPs of TCP/IP], Dan Kaminsky rambling about Bitcoin security</ref><br />
* CPU mining is basically no point anymore. Nor was there a point even back then.<br />
* 21,000,000 is not the real number. The real number of bitcoins ever created in the far future will be 20999999.97690000 - 0.00000001 bitcoins, assuming nobody ever again does what midnightmagic did<ref name="underpay">[https://bitcointalk.org/index.php?topic=7253.msg184414#msg184414 (in his case, as a tribute)], midnightmagic claims to have underpaid himself by 1x10<sup>-8</sup>, but he accidentally threw away a bunch of fees too</ref><ref name="blockexplorer underpay">[http://blockexplorer.com/b/124724 124724], the full blockexplorer decode of the underpay block</ref>, and pays themselves less.<br />
<br />
====Imprecise Wording====<br />
* A block is more than just a collection of transactions.<br />
* He says bitcoind addresses are "public keys converted into ascii" which is somewhat misleading. It's a special form of base-58.<br />
* Steve says the same thing twice without linking the two concepts: He says each four years X bitcoins are created (divided by two each four years,) but then then describes 210,000 blocks afterwards as the same thing without really linking the two facts together.<br />
* Is not using the terminology for "double-spend" or explaining why it's even a consideration for cryptocurrency, which prevents people from looking terminology up later. (Too dumbed-down.)<br />
* The term "anchored" is wrong. Bitcoin is not anchored to other currencies.<br />
<br />
===References===<br />
<references /></div>Adam3us