比特币Scriptless Scripts(via Schnorr signatures)

来源及Blockchain Capital Blog
Scriptless Scripts are a way to execute smart contracts off-chain using Schnorr Signatures.

一、背景知识

1. Smart contracts: Currently, smart contracts are used to process Bitcoin transactions. These include standard transactions that only require a single signature as well as more complex transactions such as time-locked or multi-signature transactions.
2. Script: These smart contracts are currently processed on-chain using Bitcoin Script.
3. On-chain vs. off-chain: Bitcoin smart contracts are currently processed “on-chain” which has negative effects on user transaction costs, network participation resource requirements, and privacy . The potential power of Scriptless Scripts is that they address these issues by using Schnorr signatures to move smart contract processing off-chain.

The concept of Scriptless Scripts was born from Mimblewimble, which is a blockchain design that with the exception of kernels and their signatures, does not store permanent data
Fundamental properties of Mimblewimble include both privacy and scaling, both of which require the implementation of Scriptless Scripts.

二、Scriptless Scripts的优势

1. functionality功能性优势：Scriptless Scripts could increase the range and complexity of smart contracts that are possible with Bitcoin today. Currently, Bitcoin smart contracts are executed within Bitcoin Script which is limited in the types of contracts that can be executed. This limitation stems from the number of “opcodes” that have been enabled by the network (remember, anything done at the network level requires network-wide consensus, which is hard to achieve).
   Scriptless scripts move the specification and execution of these smart contracts from a network-wide decision — as is currently the case for smart contracts that execute within Bitcoin Script — to a decision that only involves the participants of the smart contract. As a result, the range of smart contracts that a Bitcoin user could potentially deploy should increase drastically.
2. Privacy隐私性优势：When the smart contracts themselves are on-chain, many details are divulged（透露） to the entire network including the number and addresses of participants as well as the amount of capital involved — that’s not ideal as it’s very far afield from typical user expectations regarding contracts and money transfers. Instead, Scriptless Scripts use Schnorr signatures to move these contracts off-chain. This means that instead of the entire network verifying the actual terms of a contract, the network and its participants simply verify that there is a valid outcome — That is, that the parties to the contract agree that the terms have been satisfied and the resulting transaction is valid.换句话说，全网并不需要知道Alice和Bob之间的合约执行细节，全网只需要知道Alice和Bob对他们合约的执行结果满意且认可所生成的交易transaction为valid（通过Scriptless Scripts来实现）。
3. efficiency效率性优势：By moving smart contracts off-chain, Scriptless Scripts minimize the amount of data that needs to be verified and stored on the network level. That means less overhead for network participants (e.g. full nodes) and lower transaction fees for users (a win-win).

三、 Schnorr Signatures在Scritpless Scripts中的作用

3.1 Schnorr Signatures

The signer has a private key x and random private nonce r. G is the generator of a discrete log hard group, R=rG is the public nonce and P=xG is the public key
he signature, s, for message m, can then be computed as a simple linear transaction：

s=r+e⋅x

where:

e=H(P||R||m), P=xG

The position on the line chosen is taken as the hash of all the data that one needs to commit to, the digital signature. The verification equation involves the multiplication of each of the terms in the equation by G and takes into account the cryptographic assumption (discrete log) where G can be multiplied in but not divided out, thus preventing deciphering.

sG=rG+e⋅xG=R+e⋅P

Elliptic Curve Digital Signature Algorithm (ECDSA) signatures (used in Bitcoin) are not linear in xx and rr, and are thus less useful.来源

3.2 Schnorr Multi-signatures

A multi-signature (mulitsig) has multiple participants that produce a signature. Every participant might produce a separate signature and concatenate them, forming a mulitsig.
具体细节见博客第二节内容。
Mulitsig can therefore be seen that these signatures are essentially Scriptless Scripts. Independent public keys of several participants are joint to form a single key and signature, which, when published, do not divulge details of the number of participants involved or the original public keys.

3.3 Adaptor Signatures

根据Schnorr Multi-signatures调整，Adaptor Signatures是所有Scriptless Scripts工作的基石。
If two parties are considered, rather than providing their nonce R in the mulitsig protocol, a blinding factor, taken as an elliptic curve point T, is conceived and sent in addition to R (i.e. R+T). It can therefore be seen that R is not blinded; it has instead been offset by the secret value T.

以2方签名为例：

1. Here, the Schnorr mulitsig construction is modified such that the first party generates：

T=tG,R=rG

where t is the shared secret, G is the generator of discrete log hard group and r is the random nonce.

2. Using this information, the second party generates：

H(P||R+T||m)x

where the coins to be swapped are contained within message m.

3. The first party can now calculate the complete signature s such that:

s=r+t+H(P||R+T||m)x

The first party then calculates and publishes the adaptor signature s′ to the second party (and anyone else listening)

s′=s−t

4. The second party can verify the adaptor signature s′ by asserting s′G

s′G=?R+H(P||R+T||m)P

However, this is not a valid signature, as the hashed nonce point is R+T and not R.

The second party cannot retrieve a valid signature from this and requires ECDLP solving to recover s′+t, which is virtually impossible.

After the first party broadcasts ss to claim the coins within message m, the second party can calculate the secret t from

t=s−s′

The above is very general. However, by attaching auxiliary proofs too, an adaptor signature can be derived that will allow the translation of correct movement of the auxiliary protocol into a valid signature.

四、 常用的Scriptless Scripts

常用的Scriptless Scripts有：

1. Simultaneous Scriptless Scripts
2. Atomic (Cross-chain Swaps) Example with Adaptor Signatures
3. Zero Knowledge Contingent Payments
4. Mimblewimble’s Core Scriptless Script

4.1 Simultaneous Scriptless Scripts

The execution of separate transactions in an atomic fashion is achieved through preimages. If two transactions require the preimage to the same hash, once one is executed, the preimage is exposed so that the other one can be as well. Atomic swaps and Lightning channels use this construction.
考虑两个Schnorr Signatures的差值：(Mimblewimble中的关键特性)

d=s−s′=k−k′+e⋅x−e′⋅x′

The above equation can be verified in a similar manner to that of a single Schnorr signature, by multiplying each term by G and confirming algebraic correctness:

dG=kG−k′G+e⋅xG−e′⋅x′G

It must be noted that the difference d is being verified, and not the Schnorr signature itself. d functions as the translating key between two separate independent Schnorr signatures. Given d and either s or s′, the other can be computed. So possession of d makes these two signatures atomic. This scheme does not link the two signatures or compromise their security.

For an atomic transaction, during the setup stage, someone provides the opposing party with the value d, and asserts it as the correct value. Once the transaction is signed, it can be adjusted to complete the other transaction. Atomicity is achieved, but can only be used by the person who possesses this d value. Generally, the party that stands to lose money requires the d value.

The d value provides an interesting property with regard to atomicity. It is shared before signatures are public, which in turn allows the two transactions to be atomic once the transactions are published. By taking the difference of any two Schnorr signatures, one is able to construct transcripts, such as an atomic swap multisig contract.

This is a critical feature for Mimblewimble, which was previously thought to be unable to support atomic swaps or Lightning channels.

4.2 Atomic (Cross-chain Swaps) Example with Adaptor Signatures

Alice has a certain number of coins on a particular blockchain; Bob also has a certain number of coins on another blockchain. Alice and Bob want to engage in an atomic exchange. However, neither blockchain is aware of the other, nor are they able to verify each other’s transactions.

The classical way of achieving this involves the use of the blockchain’s script system to put a hash preimage challenge and then reveal the same preimage on both sides. Once Alice knows the preimage, she reveals it to take her coins. Bob then copies it off one chain to the other chain to take his coins.

Using adaptor signatures, the same result can be achieved through simpler means. In this case, both Alice and Bob put up their coins on two of two outputs on each blockchain. They sign the mulitsig protocols in parallel, where Bob then gives Alice the adaptor signatures for each side using the same value T . This means that for Bob to take his coins, he needs to reveal t; and for Alice to take her coins, she needs to reveal T. Bob then replaces one of the signatures and publishes t, taking his coins. Alice computes t from the final signature, visible on the blockchain, and uses that to reveal another signature, giving Alice her coins.
Thus it can be seen that atomicity is achieved. One is still able to exchange information, but now there are no explicit hashes or preimages on the blockchain. No script properties are necessary and privacy is achieved.

4.3 Zero Knowledge Contingent Payments

Zero Knowledge Contingent Payments (ZKCP) is a transaction protocol. This protocol allows a buyer to purchase information from a seller using coins in a manner that is private, scalable, secure and, importantly, in a trustless environment. The expected information is transferred only when payment is made. The buyer and seller do not need to trust each other or depend on arbitration by a third party.

4.4 Mimblewimble’s Core Scriptless Script

As previously stated, Mimblewimble is a blockchain design. Built similarly to Bitcoin, every transaction has inputs and outputs. Each input and output has a confidential transaction commitment. Confidential commitments have an interesting property where, in a valid balanced transaction, one can subtract the input from the output commitments, ensuring that all of the values of the Pedersen values balance out. Taking the difference of these inputs and outputs results in the mulitsig key of the owners of every output and every input in the transaction. This is referred to as the kernel.Mimblewimble blocks will only have a list of new inputs, new outputs and signatures that are created from the aforementioned excess value.
Since the values are homomorphically encrypted, nodes can verify that no coins are being created or destroyed.