After Segwit has been active, has become the door opener for development is far ahead, either with a Lightning Network, Atomic, Atomic Swap Multipath Payment, and one of them is the Schnorr Signature again. And of course there are many other things else can developed thereafter.
Then what's a Schnorr Signature for that matter? What are the functions and benefits of Schnorr Signature in the bitcoin? How can it be done? In the bitcoin, essentially a discourse about the implementation of Schnorr Signature has long been discussed. To be precise, in January 2016, Schnorr Signature has many began seizing attention, along with the potential and development of the Bitcoin Segwit it was still done.
Function Of Digital Signature
Of course, if you want to learn more about what that Schnorr Signature, we need to refer back and understand in advance about Digital Signatures. And Yes, of course, Digital Signature, using Bitcoin in it.
Literally, a Digital Signature is a mathematical scheme that is required as evidence incontrovertible that an authentic message or document is actually derived from the owners absolutely.
In the Bitcoin, a Digital Signature is required as a condition of absolute so that a number of the person's property be bitcoin used or spent. Bitcoin, indeed many use branches of the science of cryptography as a Foundation, including a pair of key in the cryptographic branch of science known as Public Key and Private Key.
In order for a number of bitcoin can be used, the owner must be able to provide proof that he is the owner of a number of authentic bitcoin it. Then there is the role of a Digital Signature which served in the authentic evidence, giving a digital signature of the owner,
Between the Public Key and Private Key, in effect interlinked with each other, the way it works ever worked together. The difference, to generate or produce Public Key from a Private Key is fairly easy to do. However, it could probably produce the Private Key from the Public Key. The reason? Obviously, because the Private Key that is only works in one direction only.
Digital Signature, can be used for proof of ownership (proof of ownership) of the Private Key that correlates on the Public Key. That is to say, evidence of ownership, can be served without having to reveal the Private Key belonging to the person. He can only do that with the function of Digital Signature.
A digital signature or Digital Signature is, basically consists of three algorithms in the way it works:
Hashing AlgorithmSignature generation AlgoritmA Signature Verifying Algorithm
Bitcoin transactions, a Digital Signature can be done with a calculation (read: hashing) data transaction along with the Private Key it is. Well, in the Bitcoin, method for calculation that can produce such a Digital Signature created using the Elliptic Curve Digital Signing Algorithm (ECDSA). So the owner of the Private Key of a valid that need not worry that their absolute access over a number of the bitcoin can be stolen by others.
What's a Schnorr Signature?
Schnorr Signature is discovered by a mathematician and a kriptograper origin of bermana Germany Claus-Peter Schnorr. The name Schnorr in digital signatures (Scnorr Signature) is named after it.
Unlike the ECDSA are used currently, Bitcoin Schnorr Signature is one of the other forms of the Digital version of the Signature. Another variant of the version of a Digital Signature in addition to the existing Schnorr e.g. ElGamal Digital Signature Scheme.
We are not going to be a lot of talk about the other variants. But so far the Schnorr Signature, be talked about because it is considered quite suitable to be implemented in the Bitcoin. Although, there are some things that need to be scrutinized in the end. Most of all, is because the implementation of Schnorr later likely can be run through hard fork.
Schnorr Signature is considered quite suitable for Bitcoin, because it could serve just as well as ECDSA. In addition, Schnorr can also help in terms of scalability Bitcoin. It is not because with Schnorr, algorithms for digital signature becomes more efficient.
Schnorr, can be useful in summarizing the digital signature for multisig transaction, was replaced with a digital signature only. So that it will automatically be much more concise and efficient, because of the size of the previous transaction may be there are many digital signature being only one digital signature only.
If the transaction digitally can be more effective with just one digital signature only, then by Schnorr, bitcoin transactions are able to measure smaller up to 25%. In the end, it will be quite helpful to save the size of the bitcoin network bandwidth. Not only minimize transaction size, Schnorr is also potentially to add transaction privacy bitcoin.
Schnorr Signature relation with Segwit
If the beginning of yesteryear had in mind that the magnitude of the likely implementation of Schnorr will be able to walk only with Hard Fork, then Segwit have active development has opened the door to it.
One of the functions of the Segwit (a Segregated Witness), have removed the digital signature in the transaction bitcoin became part of which served as witnesses. A Digital Signature, it is no longer included in the transaction using Segwit. So the implementation of Schnorr became wide open.
Benefits Of Schnorr Signature
Some things about the benefits of Schnorr Signature already mentioned above. However, for more detail, here are the benefits in more detail:
Bitcoin transactions size occurs on-chain can be smaller. Bitcoin transactions are executed on-chain it given the current Bitcoin can already use Lightning Network. And the Network's Lightning deals, basically running off-chain though still need transactions on-chain while opening/closing channel transactions.Validation of the transaction becomes faster and more efficient.Increase the user's privacy while using the wallet multisig.Help resolve scalability bitcoin, due to the size of the transaction can be suppressed.Helps mining climate became milder, and miners are also more efficient because the cost of komputasinya can be further suppressed.
The Workings Of The Schnorr Signature
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. O3the 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 O2In 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.