Episode #125 of the Stack Overflow podcast is here. We talk Tilde Club and mechanical keyboards. Listen now
65

I'm afraid you won't like the answer. These curves - including the secp256k1 curve, y2 = x3 + 7` - 'look' nice when evaluated in typical number fields (integers, reals, ...), but secp256k1 is defined over the field Z2256-232-977, which means the X and Y coordinates are 256-bit integers modulo a large number. Curves using such coordinates do not have nice ...


61

A compressed key is just a way of storing a public key in fewer bytes (33 instead of 65). There are no compatibility or security issues because they are precisely the same keys, just stored in a different way. The original Bitcoin software didn't use compressed keys only because their use was poorly documented in OpenSSL. They have no disadvantages other ...


39

"It looks good to me" tends to make for a pretty boring paper. Security expert Dan Kaminsky has given talks and written articles about the Bitcoin system. His two main points are that it cannot scale to the number of transactions a payment processing system needs and that it is not as anonymous as many people think. He also wrote, "As a note, I have a ...


28

Brian Warner is a security expert and he has studied the source code. His presentation about Bitcoin is by far the best deep technical explanation I've seen: http://vimeo.com/27177893 There is a brief mention about the security of the source code, embedded in two hours of brilliant explication of the security of the overall system design. Also, the ...


28

This has nothing to do with RFC6979, but with ECDSA signing and public key recovery. The (r, s) is the normal output of an ECDSA signature, where r is computed as the X coordinate of a point R, modulo the curve order n. In Bitcoin, for message signatures, we use a trick called public key recovery. The fact is that if you have the full R point (not just its ...


26

Because of the Birthday paradox, you only need 280 addresses (despite there existing 2160 different address combinations) before a collision becomes probable. Thankfully, that is still an enormous number. At 90 million addresses per 4 hours, it will take about 445 times the age of the universe to reach that number. It's also irrelevant. Even if anyone - or ...


25

TLDR; forget about it. The ASICs are optimized for bitcoin mining. Not just Sha256(Sha256(x)) hashing, but very specifically bitcoin mining. You can't even use them for the Sha256(Sha256(x)) hashing in the rest of the bitcoin system, like hashing transactions. The ASICs are made for hashing 80 bytes, where you give them the midstate from hashing the first ...


20

Short answer: no. Long answer: Blocks are exactly 80 bytes long. When have you ever seen an 80 character password? Blocks start with a bunch of null bytes in the version field. Again, when have you seen that in a password? Each miner is mining a different block. You don't know the merkle root of what they're mining because that contains a hash of a secret ...


19

you can check the Bitcoin doc https://en.bitcoin.it/wiki/Secp256k1 , there you will find some technical details about the secp256k1 used in bitcoin. Below an illustration of the secp256k1's elliptic curve y2 = x3 + 7 over the real numbers (plot using www.desmos.com/calculator/ialhd71we3) in the context of a finite field Zp, which greatly changes the ECC ...


17

Based on the time-frame and my impression of the capabilities of the various groups developing wallet software during that period my initial guess was that the Bitpay copay software might be the source of these signatures. Copay is a multi-signature wallet which was initially released around that time. As I'm not a javascript developer it took me a bit of ...


16

Format (private keys): uncompressed: 0x80 + [32-byte secret] + [4 bytes of Hash() of previous 33 bytes], base58 encoded compressed: 0x80 + [32-byte secret] + 0x01 + [4 bytes of Hash() previous 34 bytes], base58 encoded case 1: secret (hex): 1111111111111111111111111111111111111111111111111111111111111111 uncompressed: secret (base58): ...


12

BitLotto was likely the first blockchain-based "provably fair". It uses the transaction ID as the "ticket", and the results of a large government-run lottery to determine the winning numbers. http://www.BitLotto.com SatoshiDICE became a blockbuster (pun intended) method for online gambling. It uses the transaction ID to determine the "lucky number" (...


11

ECDSA can be thought of as a special form of mathematics where division is, for all practical purposes, impossible. Public keys are formed from private keys by multiplication -- the public key is multiplied by the generator G. Because of the properties of multiplication, new public keys can be generated by an entity that doesn't know the corresponding ...


10

Short answer: no. Longer answer: to 'forward' coins one needs to spend them out of the first receiving address, and to the next one. in order to spend them, one needs to sign a transaction using the private key associated with the first receiving address.


9

All of Bitcoin's public-key cryptography is done with secp256k1. Every sane transaction has at least one secp256k1 signature and at least one secp256k1 public key or public key hash (address). A complete overnight failure of ECDSA/secp256k1 is the only technical failure I can think of which could destroy Bitcoin. This is very unlikely, though. Bitcoin is ...


9

Not any serious efficiency concerns. Signing is done fairly infrequently for any particular client (only a few signatures per transaction usually). While possible that the signing might take slightly longer to generate the k value, it would not be noticeable, especially considering how infrequently it is used by any one particular client. It's the ...


9

F29E9187 are indeed the first four bytes of the double sha256 of the bytes: 802CF24DBA5FB0A30E26E83B2AC5B9E29E1B161E5C1FA7425E73043362938B982401 In order to check this, you need to compute the double sha256 of this array of bytes. However, as already discussed, passing the string 802CF2... to the hash function will not yield the right answer, as this ...


8

A very relevant answer can be found here: Is Each Bitcoin Address Unique? This is a question of the birthday attack on the hashes. Bitcoin addresses (assuming the "normal" style starting with a 1) encode 160 bit hashes, so the output space has a possible 2^160 hashes. Because its a hash function, we assume all outputs have equal probability of being output. ...


8

Let me rewrite your question in a different notation, where all lowercase values are integers and uppercase values are points. The group generator is G (a known constant). The private key is q, its corresponding public key is Q = qG. The nonce is n, its corresponding point is R = nG. The X coordinate of R is r. The hash function is h(x). A signature is (r,s)...


7

Here's something you can copy-paste in. byteArray = new Uint8Array([181,143,16,173,231,56,63,149,181,185,224,124,84,230,123,36]); function toHexString(byteArray) { return Array.prototype.map.call(byteArray, function(byte) { return ('0' + (byte & 0xFF).toString(16)).slice(-2); }).join(''); } function toByteArray(hexString) { var result = []; ...


7

The size of secp256k1's coordinate field is 2256 - 232 - 977. That means there are only 232 + 977 (about 4 billion) possible 32-byte combinations that are not a valid coordinate. Only slightly less than half (around 2255 - 1.17 * 2127) of those are the X coordinate of a point on the curve (in fact, for every valid X coordinate, there are either exactly 0 ...


7

You're right, there is no strict requirement that the private key is strictly less than the group order. However, it is required that the resulting public key is uniform, which implies that (x % n) must be uniformly distributed between 1 and n-1 inclusive (or at least indistinguishably close to uniform). The easiest way to accomplish this is by saying that ...


7

Let's disect this function call: void sha256(struct sha256 *sha, const void *p, size_t size) First we realize that the return value is void which means the function does not return the sha256 of the data. However we see that the first argument struct sha256 *sha is a pointer to a sha256 struct with the name sha. This suggests that the pointer that we pass ...


6

It is currently not implemented by any client that I know of, but it is possible to create a signature for a transaction that doesn't include the outputs. The trick is using the SIGHASH_NONE signature type. This would allow you to fill in the output later on, and still send it. Another possible solution that has been suggested (but again not implemented) is ...


6

Bitcoin uses SHA256 followed by RIPEMD-160, which I'll collectively call HASH160. Good hashes have 4 properties: it is easy to compute the hash value for any given message it is infeasible to generate a message that has a given hash it is infeasible to modify a message without changing the hash it is infeasible to find two different messages with the ...


6

It may help to break the fields apart. 04 4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa 385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1 03 [could be 02] 4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa [discarded value can be computed from above value] There is more detail omitted above. The 03 can be 02 ...


6

In fact, it is done over the whole block, but indirectly. One of the members in the block header is the Merkle root hash of the transaction hashes. Effectively, that is a hash of all the transactions. Because that field is included in the block header, the hash of the block header is effectively a hash of all transactions as well. If a transaction would ...


6

Is there a specific attack or bug which asymmetric cryptography prevents during bitcoin transactions? asymmetric cryptography is not really something that was added on top of Bitcoin in order to prevent some specific attack or fix some specific bug. asymmetric cryptography is one of two fundamental foundation stones, one of the two primary building blocks ...


5

ASICs for BTC mining are optimized for one calculation: SHA256(SHA256(x)). They can not be used to calculate MD5(x) or even SHA256(x), so unless you use double-SHA256 to hash your passwords, you should not be worried.


5

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


Only top voted, non community-wiki answers of a minimum length are eligible