81

I'm afraid you won't like the answer. These curves - including the secp256k1 curve, y2 = x3 + 7 - 'look' nice when evaluated in typical fields (like the real numbers), but secp256k1 is defined over the finite 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 any ...


44

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 ...


24

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 ...


17

No, it is not safe. Never share your 12 word phrase. It is a backup of your private key and allows people to spend your money. They only need your public key or Bitcoin address to give you money, not your private key.


10

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 ...


10

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 = []; ...


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

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 ...


7

For a curve with for instance the equation: y^2 = x^3 + a * x + b The generator point G, or a ECDSA public key, is a pair of coordinates x and y, for which the above equation holds. To reduce the storage size for a curve point, one can also store a sign and the x coordinate, this is what is known as point-compression. You can then reconstruct the y by ...


7

No, there is no explicit, publicly-disclosed plan for this situation. However, there is an implicit plan: when it becomes know that practical quantum computers are on the near-term horizion, the programmers responsible for maintaining Bitcoin at that point will create a hard fork or soft fork to introduce a new signature type, likely something based on ...


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

The reasons for the 3 numbers: Bitcoin uses 256-bit ECDSA signatures. These require in the order of 2128 steps to find a private key from the public key is known. This is Bitcoin's security level: we aim to always require an attacker to perform 2128 steps. If the seed has less than 128 bits of entropy, this inevitably leads to a faster algorithm, where an ...


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

You can think of the generator G as the first point after infinity on the curve. Begin with infinity and add G; the result is G. Add G to this and you get 2G. Add G to this and you get 3G. And so on. If you add G a total of n times (where n is the order of the curve) you will be back at infinity, where you started; the whole curve is a never-ending loop. ...


6

The value of G(compressed) = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 and G(uncompressed) = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8 source: https://en.bitcoin.it/wiki/Secp256k1


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

We start out with the exchange having two things. It has a set of Bitcoin addresses that it owns, each of which has some balance. It also has a set of accounts, each of which it owes some number of Bitcoin to. The objective is to prove that the exchange controls each Bitcoin address on that list and that the total of all account debts is less than the total ...


5

There's a reason cryptographic hash functions, like the double SHA256 used for proof-of-work in Bitcoin, are not usually described using these complexity classes that classify asymptotic behavior. In fact, there are several. A technical reason is that hash functions often do not scale. For example, it is not defined how one would extend the proof-of-work to ...


5

I believe Satoshi was once asked this question, and answered that it was just some curve that existed and was presumed to be efficiently implemented. I'll try to find a reference.


5

Bitcoin public key cryptography is not based on RSA, but on Elliptic Curves, so the key is not a huge coprime (in fact ECC manages to achive a similar level of security with much smaller keys). About why blocks are hashed, the reason is not to slow down anything, quite the contrary: it's to speed up verification that a block "follows" the other blocks in ...


5

It is specified in BIP32 (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). The SHA512-HMAC function is reused because it is already part of the standard elsewhere, but it takes a key in addition to the data being hashed. As the key can be arbitrary, we opted to use to make sure the key derivation was Bitcoin-specific.


5

It's not possible to directly compute the ed25519 public key from the private key. Instead, use the deterministic private key to create a seed, then use the seed to re-create the private key with its corresponding public key. The following code snippet assumes ed25519_skpk is already initialized: char hex_ed_pk[65]; ...


5

If people in general would more often pick lower integers as private keys than larger integers, then it would be a good strategy for an attacker to start with lower integers. However, the opposite also holds. If people would more often pick larger numbers, then atackers would ideally start at the end and work their way backwards. In practice, no such bias ...


5

bpub appears to be the extended private key prefix for the Blockcypher testnet. Bitcoin addresses and private keys usually have a prefix to help differentiate the network/type of key. The original xpub notation comes from BIP32, meaning extended public key. This expanded into ypub with BIP49, and finally zpub with BIP49+ (used in BIP84). Various coins can ...


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