<blockquote>
  <p>Private Key (SK) -> Public Key (PK) -> Address (A). Some say that SK -> PK == A. Which one is correct?</p>
</blockquote>

<p>The first one. An address is not a public key. It is some encoding (Base 58 Check encoding or Bech32, depending on the address type) of the RIPEMD160 hash of the SHA256 hash of the public key. The address comes from the public key, but it is not the public key itself. A public key can have multiple addresses.</p>

<blockquote>
  <ol start="2">
  <li>Now, in a transaction when X to Y of "n" bitcoins happens this: X signs (digitally) the transaction "t" with its SK and this the part that I don't get it. How "Y" does to open and verify that the transaction was send from X? or besides that X signs the transaction he encrypts? the transaction again with the PK/A of Y for Y can open it? There's something that I missing?</li>
  </ol>
</blockquote>

<p>Signing is not the same thing as encrypting. Transactions are not encrypted, no data in a transaction is secret. It can all be read by everyone.</p>

<p>A digital signature can be verified by knowing the message that was signed and the public key corresponding to the private key that signed the message. In the case of Bitcoin, the message is defined by the consensus rules (it is the hash of certain parts of the transaction), and the public key is provided in the transaction itself. Those three things (the public key, signature, and message) can then be used to verify that the signature is valid.</p>

CC BY-SA 4.0
2019-05-13T00:35:59.960Z
First part clear, if that's the case some sites are showing wrong info. Despite that, the second part it's not clear still. So, generally a transaction is composed of 3 parts: Proof of X ownership of the "n" bitcoins to transfer called inputs, then the amount "n" to transfer, and finally the address of Y called output. But this 3 things is a transaction itself (right?) so, this transaction or message is digitally sign using a type of ECDSA this sign is composed of SK of A and the transaction and this is broadcasted to the network for further validation right?
Kevin
CC BY-SA 4.0
2019-05-13T00:37:22.870Z
So, the validation uses the ECDSA validation part of the algorithm right? o How that works?
Kevin
CC BY-SA 4.0
2019-05-13T01:58:04.460Z
A transaction is largely composed of two parts: a list of inputs, and a list of outputs. Each input provides a proof that that input is allowed to spend the output they reference. Each output provides the value of that output, and the conditions required to be allowed to spend that output.
Ava Chow
CC BY-SA 4.0
2019-05-13T02:00:24.920Z
A typical output has a condition that it can only be spent if the inputs provides the public key that hashes to the hash provided in the output, and a valid signature for that public key that signs the spending transaction. Both that pubkey and the signature then go into the corresponding input in the spending transaction. When that spending transaction is validated, the validator will check that the signature is valid for that pubkey and transaction (among other things). They check the signature validity using ECDSA's validation algorithm.
Ava Chow
CC BY-SA 4.0
2019-05-12T22:10:35.117Z
2019-05-12T22:10:35.117Z
Ava Chow
<p>I need some claryfication about the things, here it goes:
1. For what I've read, for generate a bitcoin address is following this flow:(General speaking) Private Key (SK) -> Public Key (PK) -> Address (A). Some say that SK -> PK == A. Which one is correct?
2. Now, in a transaction when X to Y of "n" bitcoins happens this: X signs (digitally) the transaction "t" with its SK and this the part that I don't get it. How "Y" does to open and verify that the transaction was send from X? or besides that X signs the transaction he encrypts? the transaction again with the PK/A of Y for Y can open it? There's something that I missing?</p>

<p>Note that my native language it's not english and it's hard for me to understand this complex topic.</p>

<p>Thanks in advance</p>

<transactions>
Understanding private keys, public keys, adresses and transactions
Kevin
# Understanding private keys, public keys, adresses and transactions

(Asked by: username_0 on 2019-05-12)

I need some claryfication about the things, here it goes:
1. For what I've read, for generate a bitcoin address is following this flow:(General speaking) Private Key (SK) -> Public Key (PK) -> Address (A). Some say that SK -> PK == A. Which one is correct?
2. Now, in a transaction when X to Y of "n" bitcoins happens this: X signs (digitally) the transaction "t" with its SK and this the part that I don't get it. How "Y" does to open and verify that the transaction was send from X? or besides that X signs the transaction he encrypts? the transaction again with the PK/A of Y for Y can open it? There's something that I missing?

Note that my native language it's not english and it's hard for me to understand this complex topic.

Thanks in advance

**Tags:** transactions


---

## 1 answers

### Answer by username_1 on 2019-05-12. Score: 1 | Accepted answer

> Private Key (SK) -> Public Key (PK) -> Address (A). Some say that SK -> PK == A. Which one is correct?

The first one. An address is not a public key. It is some encoding (Base 58 Check encoding or Bech32, depending on the address type) of the RIPEMD160 hash of the SHA256 hash of the public key. The address comes from the public key, but it is not the public key itself. A public key can have multiple addresses.

> 2. Now, in a transaction when X to Y of "n" bitcoins happens this: X signs (digitally) the transaction "t" with its SK and this the part that I don't get it. How "Y" does to open and verify that the transaction was send from X? or besides that X signs the transaction he encrypts? the transaction again with the PK/A of Y for Y can open it? There's something that I missing?

Signing is not the same thing as encrypting. Transactions are not encrypted, no data in a transaction is secret. It can all be read by everyone.

A digital signature can be verified by knowing the message that was signed and the public key corresponding to the private key that signed the message. In the case of Bitcoin, the message is defined by the consensus rules (it is the hash of certain parts of the transaction), and the public key is provided in the transaction itself. Those three things (the public key, signature, and message) can then be used to verify that the signature is valid.

> **Comments:**
> **username_0**: First part clear, if that's the case some sites are showing wrong info. Despite that, the second part it's not clear still. So, generally a transaction is composed of 3 parts: Proof of X ownership of the "n" bitcoins to transfer called inputs, then the amount "n" to transfer, and finally the address of Y called output. But this 3 things is a transaction itself (right?) so, this transaction or message is digitally sign using a type of ECDSA this sign is composed of SK of A and the transaction and this is broadcasted to the network for further validation right?  
> **username_0**: So, the validation uses the ECDSA validation part of the algorithm right? o How that works?  
> **username_1**: A transaction is largely composed of two parts: a list of inputs, and a list of outputs. Each input provides a proof that that input is allowed to spend the output they reference. Each output provides the value of that output, and the conditions required to be allowed to spend that output.  
> **username_1**: A typical output has a condition that it can only be spent if the inputs provides the public key that hashes to the hash provided in the output, and a valid signature for that public key that signs the spending transaction. Both that pubkey and the signature then go into the corresponding input in the spending transaction. When that spending transaction is validated, the validator will check that the signature is valid for that pubkey and transaction (among other things). They check the signature validity using ECDSA's validation algorithm.  

---

