From 840808136b269fc0c82494921e05e27e6c5f1778 Mon Sep 17 00:00:00 2001 From: Alex Chepurnoy Date: Mon, 18 May 2020 17:59:32 +0300 Subject: [PATCH 01/12] eip11 alpha with no serialization --- eip11.md | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 eip11.md diff --git a/eip11.md b/eip11.md new file mode 100644 index 00000000..a0b1071c --- /dev/null +++ b/eip11.md @@ -0,0 +1,63 @@ +EIP-11: Distributed Signatures +----------------------------- + +This EIP defines how to implement distributed signatures on top of the Ergo Platform. + + +Motivating Examples: +==================== + +Alice, Bob and Carol are doing joint business and want to have joint control over funds as well. They decide that 2-out-of-3 quorum is enough to spend the joint funds, so there is no problem if one of them can not sign because of an illness or a vacation. Thus they do store funds in boxes protected by 2-out-of-3 threshold signature. + +Please note that unlike multi-signatures in Bitcoin, threshold signatures in Ergo preserve zero-knowledge. This leads to interesting applications where actual signers must be hidden but the signing ring is not. For example, it could be desirable to show that union paid to a lawyer, but it is better to hide who approved that spending. + +Sigma Protocols: +================== + +A Sigma-protocol is three-step protocol between a prover and a verifier. First, prover is generating (secret) randomness and sends a commitment to it *a* to a verifier. The verifier is storing the commitment and sends a random challenge *e* to the prover. Prover is generating a response *z* based on the randomness and the challenge and sends it to the verifier. Verifier checks the tuple *(a,e,z)* and accepts it if it is valid. + +A Sigma-protocol can be converted to a signature scheme by using Fiat-Shamir transformation. Basically, using message *m*, prover can get challenge as *hash(m)* (note that this is about so-called Wek Fiat Shamir, while Ergo is using Strong Fiat-Shamir, where *e = hash(pk || m)*, and $pk$ is a statement (public key) the prover is proving). + +Sigma protocol also allows for simulation of proofs, AND / OR / threshold conjectures. Good introductions can be found in the Chapter 6 of the "Efficient Secure Two-Party Protocols: Techniques and Constructions" book by Lindell and Hazay, and also in the tutorial by Ivan Damgard: https://cs.au.dk/~ivan/Sigma.pdf. + +For details on how proving and verification of arbitrary statements is done in ErgoTree (after reduction), see Appendix A in the ErgoScript whitepaper: https://ergoplatform.org/docs/ErgoScript.pdf . + +Signing Procedure: +================== + +First, signing quorum should be decided. For example, Alice and Bob may decide to sign a transaction. Other parties (Carol in this case) will be simulated. + +Then every real signer needs to generate commitments in the first place. In our example that means that e.g. Alice sends her commitment to Bob. +On getting the Alice's commitment, Bob is produced a threshold signature where his tuple (a_B, e_B, z_B) is proper, Carol's tuple (a_C, e_C, z_C) is properly simulated as well, but for Alice's +(a_A, e_A', z_A') only the commitment is real, while other parts are simulated, thus the whole threshold signature is invalid. Bob needs for Alice to complete the signature. + +Thus the Bob is sending (a_B, z_B, a_C, z_C) to Alice, and now she can provide a valid signature. + +In general case, signing procedure is as following: + +* First, needed quorum of real participants to be decided. Please note that in case of 2-out-3 signature, there are just 2 and only 2 signers needed (a third one will be simulated anyway by the prover). +* Second, real participants generate commitments. In the simplest case, they can be sent to one of the signers. +* One signer is producing an invalid signature and sends simulated commitments and his commitment and response to others. +* Others produce proper responses and send them to the chosen signer (or broadcast) +* Now the signer can assemble a valid signature. + +The most complex example at the moment of writing this document is 4-out-of-8 signature and it can be found in DistributedSigSpecification.scala of https://github.com/ScorexFoundation/sigmastate-interpreter/pull/412 . + + +Data Packets: +============= + +JSON documents are used for exchanging . + + + +Implementation: +=============== + + + +Limitations +=========== + +Please note that while threshold signatures preserve zero-knowledge (e.g. in case of 2-out-of-3 threshold signature it is +known that two parties of out three at least signed an input, but not known who are these parties exactly) for a blockchain observer, participants of the signing group know who was involved in the signing process. Secrecy within the group can be achieved via MPC protocols. From bc5e2e2881e2323231586c2f2c340bd7e4e7e315 Mon Sep 17 00:00:00 2001 From: Alex Chepurnoy Date: Mon, 18 May 2020 20:24:07 +0300 Subject: [PATCH 02/12] restructuring --- eip11.md => eip-0011.md | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-) rename eip11.md => eip-0011.md (83%) diff --git a/eip11.md b/eip-0011.md similarity index 83% rename from eip11.md rename to eip-0011.md index a0b1071c..81a3d3b4 100644 --- a/eip11.md +++ b/eip-0011.md @@ -1,18 +1,18 @@ EIP-11: Distributed Signatures ------------------------------ +------------------------------ This EIP defines how to implement distributed signatures on top of the Ergo Platform. -Motivating Examples: -==================== +Motivating Examples +=================== Alice, Bob and Carol are doing joint business and want to have joint control over funds as well. They decide that 2-out-of-3 quorum is enough to spend the joint funds, so there is no problem if one of them can not sign because of an illness or a vacation. Thus they do store funds in boxes protected by 2-out-of-3 threshold signature. Please note that unlike multi-signatures in Bitcoin, threshold signatures in Ergo preserve zero-knowledge. This leads to interesting applications where actual signers must be hidden but the signing ring is not. For example, it could be desirable to show that union paid to a lawyer, but it is better to hide who approved that spending. -Sigma Protocols: -================== +Sigma Protocols +=============== A Sigma-protocol is three-step protocol between a prover and a verifier. First, prover is generating (secret) randomness and sends a commitment to it *a* to a verifier. The verifier is storing the commitment and sends a random challenge *e* to the prover. Prover is generating a response *z* based on the randomness and the challenge and sends it to the verifier. Verifier checks the tuple *(a,e,z)* and accepts it if it is valid. @@ -22,8 +22,8 @@ Sigma protocol also allows for simulation of proofs, AND / OR / threshold conjec For details on how proving and verification of arbitrary statements is done in ErgoTree (after reduction), see Appendix A in the ErgoScript whitepaper: https://ergoplatform.org/docs/ErgoScript.pdf . -Signing Procedure: -================== +Signing Procedure +================= First, signing quorum should be decided. For example, Alice and Bob may decide to sign a transaction. Other parties (Carol in this case) will be simulated. @@ -44,18 +44,27 @@ In general case, signing procedure is as following: The most complex example at the moment of writing this document is 4-out-of-8 signature and it can be found in DistributedSigSpecification.scala of https://github.com/ScorexFoundation/sigmastate-interpreter/pull/412 . -Data Packets: -============= +Data Packets +============ -JSON documents are used for exchanging . +JSON documents are used for exchanging data needed for distributed signature generation. +JSON encoding transaction is already done in Ergo Platform reference client API, please check "UnsignedErgoTransaction" +in [openapi.yaml](https://github.com/ergoplatform/ergo/blob/master/src/main/resources/api/openapi.yaml). -Implementation: -=============== +Prover Implementation +===================== + +Implementation of the prover supporting hints from outside allowing for distributed signatures done +[in this PR in the sigmastate-interpreter repository](https://github.com/ScorexFoundation/sigmastate-interpreter/pull/412). + +Support in the Reference Protocol Client +======================================== + Limitations =========== From 784d1db1045b25a92ef05e3541150bb8e2c11a67 Mon Sep 17 00:00:00 2001 From: Alex Chepurnoy Date: Mon, 18 May 2020 21:07:10 +0300 Subject: [PATCH 03/12] a, e, z format --- eip-0011.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/eip-0011.md b/eip-0011.md index 81a3d3b4..845b5a33 100644 --- a/eip-0011.md +++ b/eip-0011.md @@ -52,8 +52,13 @@ JSON documents are used for exchanging data needed for distributed signature gen JSON encoding transaction is already done in Ergo Platform reference client API, please check "UnsignedErgoTransaction" in [openapi.yaml](https://github.com/ergoplatform/ergo/blob/master/src/main/resources/api/openapi.yaml). +A commitment (a) is about one secp256k1 element in case of prove-dlog (Schnorr signature) protocol, and two elements in +case of prove-Diffie-Hellman-tuple protocol. Element encoded as Base16-encoded x-coordinate with a sign byte prepended, +see ASN.1 for details (the only difference is that INF point encoded as 33 zero bytes). +A challenge (e) is encoded as Base-16 encoded 256-bits (32-bytes) array. +Response (z) is 256-bits number encoded with Base16. Prover Implementation From 0b7a9fae1e0c7d7ced94396a806063807f68f990 Mon Sep 17 00:00:00 2001 From: Alex Chepurnoy Date: Tue, 19 May 2020 16:26:29 +0300 Subject: [PATCH 04/12] proper subheadings --- eip-0011.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/eip-0011.md b/eip-0011.md index 845b5a33..3658abef 100644 --- a/eip-0011.md +++ b/eip-0011.md @@ -1,18 +1,18 @@ EIP-11: Distributed Signatures ------------------------------- +============================== This EIP defines how to implement distributed signatures on top of the Ergo Platform. Motivating Examples -=================== +------------------- Alice, Bob and Carol are doing joint business and want to have joint control over funds as well. They decide that 2-out-of-3 quorum is enough to spend the joint funds, so there is no problem if one of them can not sign because of an illness or a vacation. Thus they do store funds in boxes protected by 2-out-of-3 threshold signature. Please note that unlike multi-signatures in Bitcoin, threshold signatures in Ergo preserve zero-knowledge. This leads to interesting applications where actual signers must be hidden but the signing ring is not. For example, it could be desirable to show that union paid to a lawyer, but it is better to hide who approved that spending. Sigma Protocols -=============== +--------------- A Sigma-protocol is three-step protocol between a prover and a verifier. First, prover is generating (secret) randomness and sends a commitment to it *a* to a verifier. The verifier is storing the commitment and sends a random challenge *e* to the prover. Prover is generating a response *z* based on the randomness and the challenge and sends it to the verifier. Verifier checks the tuple *(a,e,z)* and accepts it if it is valid. @@ -23,7 +23,7 @@ Sigma protocol also allows for simulation of proofs, AND / OR / threshold conjec For details on how proving and verification of arbitrary statements is done in ErgoTree (after reduction), see Appendix A in the ErgoScript whitepaper: https://ergoplatform.org/docs/ErgoScript.pdf . Signing Procedure -================= +----------------- First, signing quorum should be decided. For example, Alice and Bob may decide to sign a transaction. Other parties (Carol in this case) will be simulated. @@ -31,7 +31,7 @@ Then every real signer needs to generate commitments in the first place. In our On getting the Alice's commitment, Bob is produced a threshold signature where his tuple (a_B, e_B, z_B) is proper, Carol's tuple (a_C, e_C, z_C) is properly simulated as well, but for Alice's (a_A, e_A', z_A') only the commitment is real, while other parts are simulated, thus the whole threshold signature is invalid. Bob needs for Alice to complete the signature. -Thus the Bob is sending (a_B, z_B, a_C, z_C) to Alice, and now she can provide a valid signature. +Thus the Bob is sending (a_B, e_B, z_B, a_C, e_C, z_C) to Alice, and now she can provide a valid signature. In general case, signing procedure is as following: @@ -45,7 +45,7 @@ The most complex example at the moment of writing this document is 4-out-of-8 si Data Packets -============ +------------ JSON documents are used for exchanging data needed for distributed signature generation. @@ -62,16 +62,16 @@ Response (z) is 256-bits number encoded with Base16. Prover Implementation -===================== +--------------------- Implementation of the prover supporting hints from outside allowing for distributed signatures done [in this PR in the sigmastate-interpreter repository](https://github.com/ScorexFoundation/sigmastate-interpreter/pull/412). Support in the Reference Protocol Client -======================================== +---------------------------------------- Limitations -=========== +----------- Please note that while threshold signatures preserve zero-knowledge (e.g. in case of 2-out-of-3 threshold signature it is known that two parties of out three at least signed an input, but not known who are these parties exactly) for a blockchain observer, participants of the signing group know who was involved in the signing process. Secrecy within the group can be achieved via MPC protocols. From 6dfa1a9cd1046f407d33c8d3d9d70b99890741d2 Mon Sep 17 00:00:00 2001 From: Alex Chepurnoy Date: Tue, 19 May 2020 17:20:11 +0300 Subject: [PATCH 05/12] commitment json --- eip-0011.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/eip-0011.md b/eip-0011.md index 3658abef..60be020f 100644 --- a/eip-0011.md +++ b/eip-0011.md @@ -53,13 +53,22 @@ JSON encoding transaction is already done in Ergo Platform reference client API, in [openapi.yaml](https://github.com/ergoplatform/ergo/blob/master/src/main/resources/api/openapi.yaml). A commitment (a) is about one secp256k1 element in case of prove-dlog (Schnorr signature) protocol, and two elements in -case of prove-Diffie-Hellman-tuple protocol. Element encoded as Base16-encoded x-coordinate with a sign byte prepended, -see ASN.1 for details (the only difference is that INF point encoded as 33 zero bytes). +case of prove-Diffie-Hellman-tuple protocol. Element encoded as Base16-encoded x-coordinate with a sign byte +(of the y-coordinate) prepended, see ASN.1 for details (the only difference is that INF point encoded as 33 zero bytes). A challenge (e) is encoded as Base-16 encoded 256-bits (32-bytes) array. Response (z) is 256-bits number encoded with Base16. +A public key is encoded as one secp256k1 element in case of prove-dlog, four elements in case of +prove-diffie-hellman-tuple: + + { + "hint": "commitment", + "type": "dlog", + "pk": "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", + "commitment": "0253db866791af521ba4ab009509b6db89d272d9461636ee65eaa3e316884b21a4" + } Prover Implementation --------------------- @@ -70,6 +79,8 @@ Implementation of the prover supporting hints from outside allowing for distribu Support in the Reference Protocol Client ---------------------------------------- +[This PR](https://github.com/ergoplatform/ergo/pull/1118). + Limitations ----------- From ba6c8485c6364d020dcf99fe8752ca758247b27f Mon Sep 17 00:00:00 2001 From: Alex Chepurnoy Date: Tue, 19 May 2020 17:58:47 +0300 Subject: [PATCH 06/12] initial draft --- eip-0011.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/eip-0011.md b/eip-0011.md index 60be020f..e76941e9 100644 --- a/eip-0011.md +++ b/eip-0011.md @@ -65,11 +65,51 @@ prove-diffie-hellman-tuple: { "hint": "commitment", + "index": 0, "type": "dlog", + "real": true, "pk": "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", "commitment": "0253db866791af521ba4ab009509b6db89d272d9461636ee65eaa3e316884b21a4" } +or + + { + "hint": "commitment", + "type": "dht", + "real": false, + "pk": [ + "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", + "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", + "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", + "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c" + ], + "commitment": "0253db866791af521ba4ab009509b6db89d272d9461636ee65eaa3e316884b21a4" + } + +, where "index" is input index a hint is provided for. A partial signature can be encoded then as + + { + "hint": "partial-sig", + "index": 0, + "type": "dlog", + "real": true, + "pk": "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", + "commitment": "0253db866791af521ba4ab009509b6db89d272d9461636ee65eaa3e316884b21a4", + "challenge": "0253db866791af521ba4ab009509b6db89d272d9461636ee65eaa3e316884b21a4", + "response": "0253db866791af521ba4ab009509b6db89d272d9461636ee65eaa3e316884b21a4" + } + +and similarly for dht. + +Then we have two possible clients, stateful, which do store locally unsigned transactions and so can use transaction id +in messages, and stateless, which do not store any information. Then in the stateless setting +(reference protocol client will likely support only initially) signing request would be like current +signing request for "/wallet/transaction/sign" API method. A signature and so transaction generated could be invalid +(see "Signing Procedure" section). It is up to external utilities (or manual efforts) to gather needed hints for the +prover. + + Prover Implementation --------------------- @@ -81,6 +121,16 @@ Support in the Reference Protocol Client [This PR](https://github.com/ergoplatform/ergo/pull/1118). +Further Work +------------ + +[TODO] + +Optimizations +------------- + +[TODO] + Limitations ----------- From 859f944e9b39c986e713c37ee984495b3b43be0e Mon Sep 17 00:00:00 2001 From: Alex Chepurnoy Date: Tue, 19 May 2020 20:11:39 +0300 Subject: [PATCH 07/12] fixed json for dht case --- eip-0011.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/eip-0011.md b/eip-0011.md index e76941e9..a0ad217e 100644 --- a/eip-0011.md +++ b/eip-0011.md @@ -79,12 +79,15 @@ or "type": "dht", "real": false, "pk": [ - "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", - "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", - "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", - "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c" - ], - "commitment": "0253db866791af521ba4ab009509b6db89d272d9461636ee65eaa3e316884b21a4" + "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", + "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", + "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c", + "03a73c66970f14fc6450c6ab1a167cb4ba3baa64b20f731e22ec6840c70d27ef1c" + ], + "commitment": [ + "0253db866791af521ba4ab009509b6db89d272d9461636ee65eaa3e316884b21a4", + "0253db866791af521ba4ab009509b6db89d272d9461636ee65eaa3e316884b21a4" + ] } , where "index" is input index a hint is provided for. A partial signature can be encoded then as @@ -124,7 +127,7 @@ Support in the Reference Protocol Client Further Work ------------ -[TODO] +Please note that in addition to Optimizations ------------- From 675f99d65bc4063f5856b6296ea2b337bd461eb5 Mon Sep 17 00:00:00 2001 From: ScalaHub <23208922+scalahub@users.noreply.github.com> Date: Thu, 21 May 2020 11:26:13 +0530 Subject: [PATCH 08/12] Update eip-0011.md --- eip-0011.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/eip-0011.md b/eip-0011.md index a0ad217e..367d77f1 100644 --- a/eip-0011.md +++ b/eip-0011.md @@ -7,16 +7,16 @@ This EIP defines how to implement distributed signatures on top of the Ergo Plat Motivating Examples ------------------- -Alice, Bob and Carol are doing joint business and want to have joint control over funds as well. They decide that 2-out-of-3 quorum is enough to spend the joint funds, so there is no problem if one of them can not sign because of an illness or a vacation. Thus they do store funds in boxes protected by 2-out-of-3 threshold signature. +Alice, Bob and Carol are doing a joint business and want to have joint control over funds as well. They decide that 2-out-of-3 quorum is enough to spend the joint funds, so there is no problem if one of them can not sign because of an illness or a vacation. Thus they store funds in boxes protected by 2-out-of-3 threshold signature. Please note that unlike multi-signatures in Bitcoin, threshold signatures in Ergo preserve zero-knowledge. This leads to interesting applications where actual signers must be hidden but the signing ring is not. For example, it could be desirable to show that union paid to a lawyer, but it is better to hide who approved that spending. Sigma Protocols --------------- -A Sigma-protocol is three-step protocol between a prover and a verifier. First, prover is generating (secret) randomness and sends a commitment to it *a* to a verifier. The verifier is storing the commitment and sends a random challenge *e* to the prover. Prover is generating a response *z* based on the randomness and the challenge and sends it to the verifier. Verifier checks the tuple *(a,e,z)* and accepts it if it is valid. +A Sigma-protocol is three-step protocol between a prover and a verifier. First, prover is generates (secret) randomness and sends a commitment to it *a* to a verifier. The verifier stores the commitment and sends a random challenge *e* to the prover. Prover generates a response *z* based on the randomness and the challenge and sends it to the verifier. Verifier checks the tuple *(a,e,z)* and accepts it if it is valid. -A Sigma-protocol can be converted to a signature scheme by using Fiat-Shamir transformation. Basically, using message *m*, prover can get challenge as *hash(m)* (note that this is about so-called Wek Fiat Shamir, while Ergo is using Strong Fiat-Shamir, where *e = hash(pk || m)*, and $pk$ is a statement (public key) the prover is proving). +A Sigma-protocol can be converted to a signature scheme by using Fiat-Shamir transformation. Basically, using message *m*, prover can get challenge as *hash(m)* (note that this is the so-called "Weak" Fiat Shamir transform, while Ergo uses the Strong Fiat-Shamir transform, where *e = hash(pk || m)*, and $pk$ is a statement (public key) that the prover is proving). Sigma protocol also allows for simulation of proofs, AND / OR / threshold conjectures. Good introductions can be found in the Chapter 6 of the "Efficient Secure Two-Party Protocols: Techniques and Constructions" book by Lindell and Hazay, and also in the tutorial by Ivan Damgard: https://cs.au.dk/~ivan/Sigma.pdf. @@ -27,15 +27,15 @@ Signing Procedure First, signing quorum should be decided. For example, Alice and Bob may decide to sign a transaction. Other parties (Carol in this case) will be simulated. -Then every real signer needs to generate commitments in the first place. In our example that means that e.g. Alice sends her commitment to Bob. -On getting the Alice's commitment, Bob is produced a threshold signature where his tuple (a_B, e_B, z_B) is proper, Carol's tuple (a_C, e_C, z_C) is properly simulated as well, but for Alice's -(a_A, e_A', z_A') only the commitment is real, while other parts are simulated, thus the whole threshold signature is invalid. Bob needs for Alice to complete the signature. +Then every real signer needs to generate commitments. In our example that means that e.g. Alice sends her commitment to Bob. +On getting Alice's commitment, Bob produces a threshold signature where his tuple (a_B, e_B, z_B) is proper, Carol's tuple (a_C, e_C, z_C) is properly simulated as well, but for Alice's tuple +(a_A, e_A', z_A') only the commitment is real, while other parts are simulated, thus the whole threshold signature is invalid. Bob needs Alice to complete the signature. -Thus the Bob is sending (a_B, e_B, z_B, a_C, e_C, z_C) to Alice, and now she can provide a valid signature. +Bob sends (a_B, e_B, z_B, a_C, e_C, z_C) to Alice, using which she can now provide a valid signature. -In general case, signing procedure is as following: +In the general case, signing procedure is as follows: -* First, needed quorum of real participants to be decided. Please note that in case of 2-out-3 signature, there are just 2 and only 2 signers needed (a third one will be simulated anyway by the prover). +* First, the needed quorum of real participants is to be decided. Please note that in case of 2-out-3 signature, there are just 2 and only 2 signers needed (a third one will be simulated anyway by the prover). * Second, real participants generate commitments. In the simplest case, they can be sent to one of the signers. * One signer is producing an invalid signature and sends simulated commitments and his commitment and response to others. * Others produce proper responses and send them to the chosen signer (or broadcast) From 3ac3c22c6fb950f8891cc3118dad2919d59b64a7 Mon Sep 17 00:00:00 2001 From: ScalaHub <23208922+scalahub@users.noreply.github.com> Date: Thu, 21 May 2020 14:58:22 +0530 Subject: [PATCH 09/12] Update eip-0011.md --- eip-0011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eip-0011.md b/eip-0011.md index 367d77f1..363dd095 100644 --- a/eip-0011.md +++ b/eip-0011.md @@ -14,7 +14,7 @@ Please note that unlike multi-signatures in Bitcoin, threshold signatures in Erg Sigma Protocols --------------- -A Sigma-protocol is three-step protocol between a prover and a verifier. First, prover is generates (secret) randomness and sends a commitment to it *a* to a verifier. The verifier stores the commitment and sends a random challenge *e* to the prover. Prover generates a response *z* based on the randomness and the challenge and sends it to the verifier. Verifier checks the tuple *(a,e,z)* and accepts it if it is valid. +A Sigma-protocol is three-step protocol between a prover and a verifier. First, the prover generates (secret) randomness and sends a commitment to it *a* to a verifier. The verifier stores the commitment and sends a random challenge *e* to the prover. The prover generates a response *z* based on the randomness plus the challenge and sends it to the verifier. The verifier checks the tuple *(a,e,z)* and accepts it if it is valid. A Sigma-protocol can be converted to a signature scheme by using Fiat-Shamir transformation. Basically, using message *m*, prover can get challenge as *hash(m)* (note that this is the so-called "Weak" Fiat Shamir transform, while Ergo uses the Strong Fiat-Shamir transform, where *e = hash(pk || m)*, and $pk$ is a statement (public key) that the prover is proving). From ff886a3d6604b8b3a4819a5409821df3d9848ca0 Mon Sep 17 00:00:00 2001 From: ScalaHub <23208922+scalahub@users.noreply.github.com> Date: Tue, 9 Jun 2020 03:03:35 +0530 Subject: [PATCH 10/12] Update eip-0011.md --- eip-0011.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/eip-0011.md b/eip-0011.md index 363dd095..27ff4687 100644 --- a/eip-0011.md +++ b/eip-0011.md @@ -7,31 +7,34 @@ This EIP defines how to implement distributed signatures on top of the Ergo Plat Motivating Examples ------------------- -Alice, Bob and Carol are doing a joint business and want to have joint control over funds as well. They decide that 2-out-of-3 quorum is enough to spend the joint funds, so there is no problem if one of them can not sign because of an illness or a vacation. Thus they store funds in boxes protected by 2-out-of-3 threshold signature. +Alice, Bob and Carol have a joint business and need joint control over business funds. They decide that a 2-out-of-3 quorum is enough to spend the joint funds, so that there is no problem if one of them can not sign because of an illness or a vacation. Thus, they store such funds in boxes protected by 2-out-of-3 threshold signature. Please note that unlike multi-signatures in Bitcoin, threshold signatures in Ergo preserve zero-knowledge. This leads to interesting applications where actual signers must be hidden but the signing ring is not. For example, it could be desirable to show that union paid to a lawyer, but it is better to hide who approved that spending. Sigma Protocols --------------- -A Sigma-protocol is three-step protocol between a prover and a verifier. First, the prover generates (secret) randomness and sends a commitment to it *a* to a verifier. The verifier stores the commitment and sends a random challenge *e* to the prover. The prover generates a response *z* based on the randomness plus the challenge and sends it to the verifier. The verifier checks the tuple *(a,e,z)* and accepts it if it is valid. +A Sigma-protocol is three-step protocol between a prover and a verifier with common "statement" *y*, where the prover wants to prove knowledge of some secret *x* such that *(x, y)* form some relation, such as being a (public, private) keypair. We call this "proving the statement" *y*. First, the prover generates (secret) randomness and sends to the verifier, a commitment *a* to the secret. The verifier stores the commitment and sends a random challenge *e* to the prover. The prover generates a response *z* based on the randomness plus the challenge and sends it to the verifier. The verifier checks the tuple *(a,e,z)* and accepts it if it is valid. -A Sigma-protocol can be converted to a signature scheme by using Fiat-Shamir transformation. Basically, using message *m*, prover can get challenge as *hash(m)* (note that this is the so-called "Weak" Fiat Shamir transform, while Ergo uses the Strong Fiat-Shamir transform, where *e = hash(pk || m)*, and $pk$ is a statement (public key) that the prover is proving). +A Sigma-protocol can be converted to a signature scheme by using Fiat-Shamir transformation. Basically, using commitment *a*, prover can get challenge as *hash(a)* (note that this is the so-called "Weak" Fiat Shamir transform, while Ergo uses the Strong Fiat-Shamir transform, where *e = hash(y || a)*, and *y* is the statement (public key) that the prover is proving. -Sigma protocol also allows for simulation of proofs, AND / OR / threshold conjectures. Good introductions can be found in the Chapter 6 of the "Efficient Secure Two-Party Protocols: Techniques and Constructions" book by Lindell and Hazay, and also in the tutorial by Ivan Damgard: https://cs.au.dk/~ivan/Sigma.pdf. +Sigma protocols also allow simulation of proofs, AND / OR / threshold conjectures. Good introductions can be found in Chapter 6 of the "Efficient Secure Two-Party Protocols: Techniques and Constructions" book by Lindell and Hazay, and also in the tutorial by Ivan Damgard: https://cs.au.dk/~ivan/Sigma.pdf. + +For details on how proving and verification of arbitrary statements is done in ErgoTree (after reduction), see Appendix A in the ErgoScript whitepaper: https://ergoplatform.org/docs/ErgoScript.pdf. + +For instance, a 2-out-of-3 Sigma proof consists of 3 arbitary statements (*y_1*, *y_2*, *y_3*), and the prover proves any 2 of them without revealing which. Let *i, j, k* be in {1, 2, 3} such that prover knows secrets of *y_i, y_j* but not of *y_k*. +The prover simulates a proof of *y_k* to generate an accepting transcript *(a_k, e_k, z_k)*. He then generates *a_i, a_j* as a proper prover and sends (*a_1, a_2, a_3*) to the verifier. The verifer chooses a challenge *s* and sends back to the prover. +The prover then computes *e_i, e_j* such that *(e_1, e_2, e_3)* form consistent 2-out-of-3 shares of *s* in an ideal secret sharing scheme. Finally the prover computes *z_i, z_j* using the proper procedure. The tuple *(e_1, e_2, e_3, z_1, z_2, z_3)* is sent to the verifier. The verifier accepts if *(a_1, e_1, z_1), (a_2, e_2, z_2), (a_3, e_3, z_3)* are accepting transcripts and *(e_1, e_2, e_3)* form consistent 2-out-of-3 shares of *s*. For details refer to the paper [CDS94]( https://www.win.tue.nl/~berry/papers/crypto94.pdf). The non-interactive variant computes *s = hash(y_1 || y_2 || y_3 || a_1 || a_2 || a_3)*. -For details on how proving and verification of arbitrary statements is done in ErgoTree (after reduction), see Appendix A in the ErgoScript whitepaper: https://ergoplatform.org/docs/ErgoScript.pdf . Signing Procedure ----------------- -First, signing quorum should be decided. For example, Alice and Bob may decide to sign a transaction. Other parties (Carol in this case) will be simulated. +First, signing quorum should be decided. For example, Alice and Bob may decide to sign a transaction. Other parties (Carol in this case) will be simulated. The procedure requires an offchain interaction between Alice and Bob but they don't have to share secrets. -Then every real signer needs to generate commitments. In our example that means that e.g. Alice sends her commitment to Bob. -On getting Alice's commitment, Bob produces a threshold signature where his tuple (a_B, e_B, z_B) is proper, Carol's tuple (a_C, e_C, z_C) is properly simulated as well, but for Alice's tuple -(a_A, e_A', z_A') only the commitment is real, while other parts are simulated, thus the whole threshold signature is invalid. Bob needs Alice to complete the signature. +Then every real signer needs to generate commitments. In our scenario this means that Alice, for example, will send her commitment *a_A* to Bob. On getting Alice's commitment, Bob produces a partial threshold signature as follows. First he simulates Carol to get tuples *(a_C, e_c, z_C)* and generates his commitment *a_B* properly. Then he uses *(a_A, a_B, a_C)* to compute *s* as described above. In the final partial signature, his tuple *(a_B, e_B, z_B)* is proper, Carol's tuple *(a_C, e_C, z_C)* is properly simulated as well, but for Alice's part nothing is computed. Thus, the whole threshold signature is invalid. Bob needs Alice to complete the signature. -Bob sends (a_B, e_B, z_B, a_C, e_C, z_C) to Alice, using which she can now provide a valid signature. +Bob sends *(a_B, e_B, z_B, a_C, e_C, z_C)* to Alice, using which she can now provide a valid signature. In the general case, signing procedure is as follows: From d052c0e0b3deabb4bd9d2e6df08cbc754199b811 Mon Sep 17 00:00:00 2001 From: ScalaHub <23208922+scalahub@users.noreply.github.com> Date: Tue, 9 Jun 2020 03:06:57 +0530 Subject: [PATCH 11/12] Update eip-0011.md --- eip-0011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eip-0011.md b/eip-0011.md index 27ff4687..3ea6ccb0 100644 --- a/eip-0011.md +++ b/eip-0011.md @@ -32,7 +32,7 @@ Signing Procedure First, signing quorum should be decided. For example, Alice and Bob may decide to sign a transaction. Other parties (Carol in this case) will be simulated. The procedure requires an offchain interaction between Alice and Bob but they don't have to share secrets. -Then every real signer needs to generate commitments. In our scenario this means that Alice, for example, will send her commitment *a_A* to Bob. On getting Alice's commitment, Bob produces a partial threshold signature as follows. First he simulates Carol to get tuples *(a_C, e_c, z_C)* and generates his commitment *a_B* properly. Then he uses *(a_A, a_B, a_C)* to compute *s* as described above. In the final partial signature, his tuple *(a_B, e_B, z_B)* is proper, Carol's tuple *(a_C, e_C, z_C)* is properly simulated as well, but for Alice's part nothing is computed. Thus, the whole threshold signature is invalid. Bob needs Alice to complete the signature. +Then every real signer needs to generate commitments. In our scenario this means that Alice, for example, will send her commitment *a_A* to Bob. On getting Alice's commitment, Bob produces a partial threshold signature as follows. First he simulates Carol to get tuples *(a_C, e_C, z_C)* and generates his commitment *a_B* properly. Then he uses *(a_A, a_B, a_C)* to compute *s* as described above. In the final partial signature, his tuple *(a_B, e_B, z_B)* is proper, Carol's tuple *(a_C, e_C, z_C)* is properly simulated as well, but for Alice's part nothing is computed. Thus, the whole threshold signature is invalid. Bob needs Alice to complete the signature. Bob sends *(a_B, e_B, z_B, a_C, e_C, z_C)* to Alice, using which she can now provide a valid signature. From 9906f403f61d8592ab955494cc4310563f4067c6 Mon Sep 17 00:00:00 2001 From: Alex Chepurnoy Date: Wed, 5 Aug 2020 14:44:49 +0300 Subject: [PATCH 12/12] eip11 polishing --- eip-0011.md | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git a/eip-0011.md b/eip-0011.md index 3ea6ccb0..52f49e86 100644 --- a/eip-0011.md +++ b/eip-0011.md @@ -1,6 +1,12 @@ EIP-11: Distributed Signatures ============================== +* Author: kushti, scalahub +* Status: Proposed +* Created: 07-Oct-2019 +* License: CC0 +* Forking: not needed + This EIP defines how to implement distributed signatures on top of the Ergo Platform. @@ -14,15 +20,15 @@ Please note that unlike multi-signatures in Bitcoin, threshold signatures in Erg Sigma Protocols --------------- -A Sigma-protocol is three-step protocol between a prover and a verifier with common "statement" *y*, where the prover wants to prove knowledge of some secret *x* such that *(x, y)* form some relation, such as being a (public, private) keypair. We call this "proving the statement" *y*. First, the prover generates (secret) randomness and sends to the verifier, a commitment *a* to the secret. The verifier stores the commitment and sends a random challenge *e* to the prover. The prover generates a response *z* based on the randomness plus the challenge and sends it to the verifier. The verifier checks the tuple *(a,e,z)* and accepts it if it is valid. +A Sigma-protocol is a three-step protocol between a prover and a verifier jointly sharing a public "statement" *y*, where the prover wants to prove knowledge of some secret *x* such that *(x, y)* form some relation, such as being a (private, public) keypair. We call this "proving the statement" *y*. First, the prover generates (secret) randomness and sends to the verifier, a commitment *a* to the secret. The verifier stores the commitment and sends a random challenge *e* to the prover. The prover generates a response *z* based on the randomness plus the challenge and sends it to the verifier. The verifier checks the tuple *(a,e,z)* and accepts if it is valid. -A Sigma-protocol can be converted to a signature scheme by using Fiat-Shamir transformation. Basically, using commitment *a*, prover can get challenge as *hash(a)* (note that this is the so-called "Weak" Fiat Shamir transform, while Ergo uses the Strong Fiat-Shamir transform, where *e = hash(y || a)*, and *y* is the statement (public key) that the prover is proving. +A Sigma-protocol can be converted to a signature scheme by using Fiat-Shamir transformation. Basically, using commitment *a*, prover can get challenge as *e = hash(a)* (note that this is the so-called "Weak" Fiat Shamir transform, while Ergo uses the Strong Fiat-Shamir transform, where *e = hash(y || a)*, and *y* is the statement (public key) that the prover is proving. Sigma protocols also allow simulation of proofs, AND / OR / threshold conjectures. Good introductions can be found in Chapter 6 of the "Efficient Secure Two-Party Protocols: Techniques and Constructions" book by Lindell and Hazay, and also in the tutorial by Ivan Damgard: https://cs.au.dk/~ivan/Sigma.pdf. For details on how proving and verification of arbitrary statements is done in ErgoTree (after reduction), see Appendix A in the ErgoScript whitepaper: https://ergoplatform.org/docs/ErgoScript.pdf. -For instance, a 2-out-of-3 Sigma proof consists of 3 arbitary statements (*y_1*, *y_2*, *y_3*), and the prover proves any 2 of them without revealing which. Let *i, j, k* be in {1, 2, 3} such that prover knows secrets of *y_i, y_j* but not of *y_k*. +For instance, a 2-out-of-3 Sigma proof consists of 3 arbitrary statements (*y_1*, *y_2*, *y_3*), and the prover proves any 2 of them without revealing which ones are actually proven. Let *i, j, k* be in {1, 2, 3} such that prover knows secrets of *y_i, y_j* but not of *y_k*. The prover simulates a proof of *y_k* to generate an accepting transcript *(a_k, e_k, z_k)*. He then generates *a_i, a_j* as a proper prover and sends (*a_1, a_2, a_3*) to the verifier. The verifer chooses a challenge *s* and sends back to the prover. The prover then computes *e_i, e_j* such that *(e_1, e_2, e_3)* form consistent 2-out-of-3 shares of *s* in an ideal secret sharing scheme. Finally the prover computes *z_i, z_j* using the proper procedure. The tuple *(e_1, e_2, e_3, z_1, z_2, z_3)* is sent to the verifier. The verifier accepts if *(a_1, e_1, z_1), (a_2, e_2, z_2), (a_3, e_3, z_3)* are accepting transcripts and *(e_1, e_2, e_3)* form consistent 2-out-of-3 shares of *s*. For details refer to the paper [CDS94]( https://www.win.tue.nl/~berry/papers/crypto94.pdf). The non-interactive variant computes *s = hash(y_1 || y_2 || y_3 || a_1 || a_2 || a_3)*. @@ -30,7 +36,7 @@ The prover then computes *e_i, e_j* such that *(e_1, e_2, e_3)* form consistent Signing Procedure ----------------- -First, signing quorum should be decided. For example, Alice and Bob may decide to sign a transaction. Other parties (Carol in this case) will be simulated. The procedure requires an offchain interaction between Alice and Bob but they don't have to share secrets. +First, signing quorum should be decided. For example, Alice and Bob may decide to sign a transaction. Other parties (Carol in this case) will be simulated. The procedure requires an off-chain interaction between Alice and Bob but they don't have to share secrets. Then every real signer needs to generate commitments. In our scenario this means that Alice, for example, will send her commitment *a_A* to Bob. On getting Alice's commitment, Bob produces a partial threshold signature as follows. First he simulates Carol to get tuples *(a_C, e_C, z_C)* and generates his commitment *a_B* properly. Then he uses *(a_A, a_B, a_C)* to compute *s* as described above. In the final partial signature, his tuple *(a_B, e_B, z_B)* is proper, Carol's tuple *(a_C, e_C, z_C)* is properly simulated as well, but for Alice's part nothing is computed. Thus, the whole threshold signature is invalid. Bob needs Alice to complete the signature. @@ -127,16 +133,6 @@ Support in the Reference Protocol Client [This PR](https://github.com/ergoplatform/ergo/pull/1118). -Further Work ------------- - -Please note that in addition to - -Optimizations -------------- - -[TODO] - Limitations -----------