Greetings to all! Please explain how the Diffie-Hellman protocol works in Bitcoin?

That is, in Blockchain Transactions, there is also a total number of "K" recipient and sender? "K" the recipient and the sender are the same as in the photo scheme?

Maybe I'm confusing something, but I heard "K" is the secret number of the transaction.

If "X" is a private number. You can define "K" by the formula:

$$K = ((Z + (X \cdot R)) / S) \mod N$$

Suppose there is a transaction:


1MJT3tqXwzko6ACGYFdRmJbxosLC4VKD7w - sends BTC

18VGa5mEJyu5XrYD2MG8Xm6J1eJYrrShWW - receives BTC

Question what is their shared secret key ???




This is the Shared Secret Key for the address https://www.blockchain.com/btc/address/1MJT3tqXwzko6ACGYFdRmJbxosLC4VKD7w

So this Diffie-Hellman protocol turns out this Shared Secret Key is also for an address? https://www.blockchain.com/btc/address/18VGa5mEJyu5XrYD2MG8Xm6J1eJYrrShWW

But the question is how the owner of the address learns: 18VGa5mEJyu5XrYD2MG8Xm6J1eJYrrShWW about the existence of the Shared Secret Key ????

  • $\begingroup$ And in Bitcoin, where exactly is the key agreement between the sender and receiver? $\endgroup$
    – Izi Tors
    Commented Jan 12, 2019 at 15:13
  • $\begingroup$ The question is how can the recipient see this? $\endgroup$
    – Izi Tors
    Commented Jan 12, 2019 at 15:14
  • $\begingroup$ I am worried about my BTC. In 2018, I sent bitcoins to addresses that have already been hacked. Can scammers find out my private key knowing the shared secret transaction key that was sent in 2018 ??? $\endgroup$
    – Izi Tors
    Commented Jan 12, 2019 at 15:39

1 Answer 1


Bitcoin does not use ECDH, or any DH, at all. It does use ECDSA (on secp256k1). The formula you posted is a wrongly-cased rearrangement of part of DSA, which with notational change is also used for ECDSA. In (EC)DSA k is a secret nonce known only to the signer, and not shared in any way; it could be computed from the formula if you know the privatekey, but only the signer knows the privatekey and the signer never needs to compute k, making that formulation useless. OTOH if the signer defectively uses same k for multiple signatures, an attacker can use a different formula to recover privatekey.

There is no shared secret key. In fact there is no encryption at all. The fundamental principle of blockchain is the exact opposite of confidentiality; it is that the information should be replicated and known widely enough that no 'damage' -- including a governmental prohibition -- can cause it to be lost. The security goal is only integrity/authenticity: that unauthorized parties can't forge or alter a transaction.

It appears your actual question is: does an outgoing transaction expose information about your key? Variants of this question have been asked and answered many times on bitcoin.SX, and there is no single answer because it can depend on transaction type. The specific transaction you linked to, fcd0ddf5c96d160acc520a6e014e070c293eaf04a8b5145f9c705bb2a36c08b0, appears to be standard P2KH (pay to key hash) on both sides, and a P2KH input exposes your publickey (as opposed to just your key hash, equivalent to your address, which was exposed on the output of the earlier incoming transaction). This does not endanger you in any way; the entire point of public key cryptography is that the publickey can be publicly known, distributed and even published because it is infeasible (in the current universe) to use it to obtain the privatekey.

Unless, as noted above, your system defectively used the same k to sign more than one transaction. In that case, everyone who sees the blockchain, which is pretty much everybody in the world, not just the hackers (or other people) who control the specific address(es) you sent to, can immediately determine your privatekey. See:

  • $\begingroup$ Please explain how the secret value "k" is generated in the program code Bitcoin Wallets. And why, until 2014, in Blokchain, there was a lot of the same "k" value? How was this connected and is it dangerous to use wallets where RFC 6979 is not used? Could the lack of RFC 6979 lead to the same problem with the same "k"? $\endgroup$
    – Izi Tors
    Commented Feb 4, 2019 at 22:21
  • $\begingroup$ There are thousands of bitcoin wallets, all of which can be different and many of which I couldn't look at even if I had months to waste, plus that's a different question than you asked and StackExchange is designed to NOT be a discussion forum. Assuming you mean the bitcoin blockchain, what makes you think there were "a lot of the same k"? You can only detect duplicate k (and it only matters) when it's for the same key, in which case you get a duplicate r in the signature, and AFAIK there have been only a handful of those, but bitcoin.SX would be the place for that. $\endgroup$ Commented Feb 5, 2019 at 6:49
  • $\begingroup$ Yes, that's right, such duplicates of "k". Repeated to create a digital signature between Bitcoin cryptocurrencies. But on the Bitcoin forum, the developers did not give me an exact answer why did the Bitcoin algorithm create identical duplicates of "k" and "r"? "r" is the public key value of "k". I need to study how the "k" appears, I think it is not a random number. $\endgroup$
    – Izi Tors
    Commented Feb 5, 2019 at 14:17
  • $\begingroup$ In the Bitcoin Developers forum, I just found out that the developers applied "RFC 6979" to eliminate this error according to the document: tools.ietf.org/html/rfc6979 But still I did not get an answer on the Bitcoin developers forum. I would like to study this in depth and ask the answer from professional cryptographers! Is there a mathematical explanation for the appearance of such duplicates of "k"? $\endgroup$
    – Izi Tors
    Commented Feb 5, 2019 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.