user89827: I am confused by the public key cryptography versions that I've read so far. Are the steps optional, dependable on the types of blockchain or they are referring to different methods?
Version 1 =========
Alice to Bob
Step 1. Content > Hash > Digest > Encrypt with Alice's private key > Digital Signature
Step 2. Digital Signature > Encrypt with Alice's private key + Bob's public key > Digest
Step 3. Send digest to Bob
In the above steps, Alice uses private key TWICE. First to encrypt the content's digest. Second time encrypt together with Bob's public key. 
Is hashing optional? 
Is the hash generated automatically once it is encrypted with Alice's private key? 
Or encrypting with Alice's private key step is optional?
Is step 2 optional too? or are all the above steps automated? 
Bob received
Step 1. Digest > Alice's public key > Content
Step 2. Digest > Bob's private key > Content
=
=
Version 2 =========
Alice to Bob
Step1. Alice generates the keys pair
Step2. Alice gives Bob her public key
Step3. Alice encrypts content with her own private key
In the above steps, Alice didn't hash the content first. 
Bob received
Step1. Bob decrypts with Alice's public key
What if someone else has Alice's public key, aren't they able to decrypt it too? 
=
=
Version 3 =========
Alice to Bob
Step1. Alice encrypts with Bob's public key
Bob received
Step1. Bob decrypts with his own private key
=
=

user208: Questions like this cannot be answered without specifying the digital signature scheme you're using.
In general
In general, a digital signature scheme consists of 3 algorithms:

KeyGen() -> (PrivKey, PubKey): generates a private key and a corresponding public key.
Sign(PrivKey,Message) -> Signature: signs a message with a given private key.
Verify(PubKey,Message,Signature) -> Bool: verifies a signature against a public key and a message.

What the data types involved are depends on the specific scheme.
ECDSA
In ECDSA, the digital signature scheme used in Bitcoin, the private key is a number, the public key is a point on an elliptic curve, the message is a byte array, and the signature is a pair of two numbers.
ECDSA does require a hashing step. In fact, without the hashing step, it is completely broken.
However, nowhere is there any encryption involved. There is simply a signing algorithm, and a verifying algorithm.
RSA
The mistake you're making, calling signing "encrypting with the private key" is a very common one, because it is often how digital signature schemes are explained.
It is true for some specific signature schemes, but not all. Most notably it is true for RSA. The private and public keys are interchangeable there, so indeed, by swapping them, the encryption scheme turns into a signature scheme.

89827: <p>I am confused by the public key cryptography versions that I've read so far. Are the steps optional, dependable on the types of blockchain or they are referring to different methods?</p>

<p>Version 1 =========</p>

<p><strong>Alice to Bob</strong></p>

<p>Step 1. Content > Hash > Digest > Encrypt with Alice's private key > Digital Signature</p>

<p>Step 2. Digital Signature > Encrypt with Alice's private key + Bob's public key > Digest</p>

<p>Step 3. Send digest to Bob</p>

<p>In the above steps, Alice uses private key TWICE. First to encrypt the content's digest. Second time encrypt together with Bob's public key. </p>

<p>Is hashing optional? </p>

<p>Is the hash generated automatically once it is encrypted with Alice's private key? </p>

<p>Or encrypting with Alice's private key step is optional?</p>

<p>Is step 2 optional too? or are all the above steps automated? </p>

<p><strong>Bob received</strong></p>

<p>Step 1. Digest > Alice's public key > Content</p>

<p>Step 2. Digest > Bob's private key > Content</p>

<p>=</p>

<p>=</p>

<p>Version 2 =========</p>

<p><strong>Alice to Bob</strong></p>

<p>Step1. Alice generates the keys pair</p>

<p>Step2. Alice gives Bob her public key</p>

<p>Step3. Alice encrypts content with her own private key</p>

<p>In the above steps, Alice didn't hash the content first. </p>

<p><strong>Bob received</strong></p>

<p>Step1. Bob decrypts with Alice's public key</p>

<p>What if someone else has Alice's public key, aren't they able to decrypt it too? </p>

<p>=</p>

<p>=</p>

<p>Version 3 =========</p>

<p><strong>Alice to Bob</strong></p>

<p>Step1. Alice encrypts with Bob's public key</p>

<p><strong>Bob received</strong></p>

<p>Step1. Bob decrypts with his own private key</p>

<p>=</p>

<p>=</p>
 208: <p>Questions like this cannot be answered without specifying the digital signature scheme you're using.</p>

<p><strong>In general</strong></p>

<p>In general, a digital signature scheme consists of 3 algorithms:</p>

<ul>
<li>KeyGen() -> (PrivKey, PubKey): generates a private key and a corresponding public key.</li>
<li>Sign(PrivKey,Message) -> Signature: signs a message with a given private key.</li>
<li>Verify(PubKey,Message,Signature) -> Bool: verifies a signature against a public key and a message.</li>
</ul>

<p>What the data types involved are depends on the specific scheme.</p>

<p><strong>ECDSA</strong></p>

<p>In ECDSA, the digital signature scheme used in Bitcoin, the private key is a number, the public key is a point on an elliptic curve, the message is a byte array, and the signature is a pair of two numbers.</p>

<p>ECDSA does require a hashing step. In fact, without the hashing step, it is completely broken.</p>

<p>However, nowhere is there <em>any encryption</em> involved. There is simply a signing algorithm, and a verifying algorithm.</p>

<p><strong>RSA</strong></p>

<p>The mistake you're making, calling signing "encrypting with the private key" is a very common one, because it is often how digital signature schemes are explained.</p>

<p>It is true for some specific signature schemes, but not all. Most notably it is true for RSA. The private and public keys are interchangeable there, so indeed, by swapping them, the encryption scheme turns into a signature scheme.</p>
