In understanding the workings of the Schnorr Signature, we need to understand how the transaction pattern of scrypt bitcoin in General. Above, we have learned that Bitcoin using ECDSA as a method to present proof of ownership of the bitcoin someone to generate a digital signature. While on any digital signatures with this ECDSA, length reaches 65 bytes.

in the model of this transaction, generally using Bitcoin Unspent Transaction Output or commonly abbreviated with UTXO. As the definition of the name UTXO, meaning that UTXO is the Output transactions that still haven't spent (not to be used for another transaction).

So any output transaction in the bitcoin, both already spent or not, in the end can serve as an input in the next transaction. More details we can see from the image below:

From the pictures, we can know that the digital signature in the UTXO of it, can be used as an input transaction, replacing scriptPubKey. If you are confused with scriptPubKey, a script that is essentially a merger of new transactions, the input script with the script output on previous transactions.

The question is, why is the "Transaction 2" in figure above uses scriptPubKey as its input? Obviously, as a number of bitcoin transactions transacted 2 were obtained from the previous transaction (transaction 1). Then on the 2nd Transaction, there are some combined input that had previously come from the output transactions 1.

ScriptPubKey in UTXO bitcoin, essentially using the script for Locking transaction, until at least a number of bitcoin on those deals, used back in the next transaction. If a transaction UTXO bitcoin has been used/spent, then it means that UTXO has gone missing, it becomes UTXO in the second transaction, as well as beyond, remaining is just partial evidence of the transaction that's ever done it.

Bitcoin transactions a second pattern, is when using a Multisignature Address. Generally, this is using multisig schema patterns M-of-N. This means that any combination of valid signatures in N, will be able to open UTXO only by the number of valid signatures threshold M.

If at the input transaction multisig last consists of 3 UTXO output correlations before, then it means the transaction input 3 x from the ECDSA signature of length size 65 bytes. This became the opportunity of use of Schnorr Signature to be quite useful.

On Schnorr Signature, generate the signature obtained in this way:

Signature creation:
(R, s) = (r*G, r + H(X, R, m) * x)

Description

m = Message

x = Private key

G = Generator point

X = Public key (X = x*G, public key = private key * generator point)(R, s) = Signature (R is the x co-ordinate of a random value after multiplying by the generator point, s is the signature)H(x, y, z..) = Cryptographic Hashing function

R = random nonce * generator point (becomes a point on the Elliptic Curve)s = random nonce + Hash function(Users Public Key, Random point on Elliptic Curve, the message (transaction)) * Private Key

Whereas verification of signaturenya as follows:

Signature verification:

s * G = R + H (X, R, m) * X

If we see from the above verification process is essentially linear equations. Both sides of the equation must be equal in order for it to be worth a valid signature.

A simple implementation of the use of Schnorr Signature that has been there for it to be used in the Bitcoin, are as follows:

Signature creation:
X = the summation of each Public Key Point

• X = (Xi + (Xi+1) + (Xi+2)…)R = the summation of each participants random nonce
• R = (Ri + (Ri+1) + (Ri+2)…)s = the summation of each participants signature
• si = ri + H(X,R,m) * X
• s = (si + (si+1) + (si+2)…)(R, s) = is the signature with s being the summation of all signaturesSignature verification:
  s*G = R + H(X,R,m) * X * X represents the summation of all participants Public Keys

Potential weaknesses and address them

Unfortunately, at a simple implementation above, are seen to have potential security issues, called Rogue Key Attacks. Picture of how a pattern of attacks that can be performed as follows:

•      Alice has two outputs, namely, O1 and O2.
  

•      While Bob had Output i.e. O3
  

•      the M1 is a message authorizing use of O1, and so on ...
  

•      Alice would like to spend your output from O1 to Bob through the multi party protocols, but not for the O2
  

•      In this case, Bob had the opportunity to be able to claim that he had the same key belongs to Alice, using message m2 (even though the message is correctly Bob m3).
  

Bob uses this pattern:

s * G = R + H (L, X, A, m1 | m2) * XA + H (L, XA, R, m1 | m2) * XA

So with that pattern, basically Bob duplicate messages in m2 to O2 can steal from Alice.

Bellare-Neven Signatures As One Solution

The potential weakness of security issues on a Schnorr Signature is, of course, presents an alternative solution so that the schematic the Schnorr can be developed further. It does since it first appeared, Schnorr is still no eligibility standards that can be used.

Nevertheless, it remains still invites a lot of things over the possibility of more implementations could allow it to be done. One such Bellare-Neven is by Signature. Basically, Bellare-Neven Signature is specifically to address security issues related to a Rogue Key Attack.

Bellare-Neven, become an alternative solution that is good enough, and was presented by Peter Wuile on 24-26 January 2018 and then housed at Stanford University on the event Blockchain Protocol Analysis and Security Engineering (2018 BPASE18 ).

Compared with the simple implementation of schemes over Schnorr, Bellare-Neven Signature adds a hash from the total amount of all existing public key in input. More details in the following pattern: Neven-Bellare

Signature creation:
L = H(Xi + (Xi+1)…)

• L is the hash of the summation of all Public KeysR = (ri * G) + ((ri+1) * G)…
• R is the summation of each participants Random Point
• They share their Random Nonce Points with other signerssi = ri + H(L, Xi, R, m) * xi
• si is the signature generated for each participant
• si = random nonce + Hash(Hash of all Public Keys, Participants Public Key, Sum of all Random Points, message (transaction)) * Participants Private Keys = (si) + (si+1) + (si+2)…
• s is the summation of each participants signature* (R, s) is the final signatureSignature verification:
  s*G = R + H(L,X1,R,m) * X1 + H(L,X2,R,m) * X2 +…

So even though the transaction is using multisig, however will need the public key of each participant in the transaction input.