Computer implemented method and system for transferring access to a digital asset

Abstract

A method of transferring access to a digital asset is disclosed. The method comprises receiving a first blockchain transaction (4) from a first participant (6) by each of a plurality of second participants (8), (10). The first participant (6) has a first private key of a first private-public key pair of a cryptography system, and each participant (6), (8), (10) has a respective first share of a second private key of a second private-public key pair of the cryptography system, and the first blockchain transaction is signed with the first private key. Signature of the first blockchain transaction with the first private key is verified by each second participant (8), (10). A respective first share is applied to the first blockchain transaction to generate a respective second share of a second blockchain transaction signed with the second private key. Signature with the second private key is possible by means of a first threshold number of second shares and is inaccessible to less than the first threshold number of second shares. The first threshold number of second shares is combined from the first participant (6) and a plurality of the second participants (8), (10) generate the signature.

Claims

1. A method of transferring access to a digital asset, the method comprising: receiving a first blockchain transaction from a first participant by each of a plurality of second participants, wherein the first participant has a first private key of a first private-public key pair of a cryptography system, and each the participant has a respective share of a second private key of a second private-public key pair of the cryptography system, wherein the first blockchain transaction is signed with the first private key; verifying, by a plurality of the second participants, that the first blockchain transaction has been signed with the first private key; applying a respective the share of the second private key to the first blockchain transaction to generate a respective share of a first secret value, wherein the first secret value is a second blockchain transaction signed with the second private key, wherein the first secret value is accessible to a first threshold number of the shares of the first secret value and is inaccessible to less than the first threshold number of shares of the first secret value; combining at least the first threshold number of the shares of the first secret value from the first participant and a plurality of the second participants to generate the first secret value; and transferring access to the digital asset to a third private key of the cryptography system in the event of one or more of the plurality of second participants becoming unresponsive.

2. A method according to claim 1, wherein each of a plurality of the second participants has a respective private key of the cryptography system.

3. A method according to claim 1, further comprising distributing shares of the share of the second private key in possession of the first participant among the first participant and at least one second participant.

4. A method according to claim 1, wherein the digital asset remains under control of the third private key fora predetermined time.

5. A method according to claim 1, further comprising distributing the shares of the second private key among a plurality of the participants.

6. A method of transferring access to a digital asset, the method comprising: sending a first blockchain transaction from a first participant to a plurality of second participants, wherein the first participant has a first private key of a first private-public key pair of a cryptography system, and each the participant has a respective share of a second private key of a second private-public key pair of the cryptography system, wherein the first blockchain transaction is signed with the first private key; receiving, from a plurality of the second participants, a respective share of a first secret value, wherein the first secret value is a second blockchain transaction signed with the second private key, wherein the first secret value is accessible to a first threshold number of the shares of the first secret value and is inaccessible to less than the first threshold number of shares of the first secret value, wherein each the share of the second private key is applied to the second blockchain transaction after verification, by the corresponding the second participants, that the first blockchain transaction has been signed with the first private key; combining at least the first threshold number of the shares of the first secret value from the first participant and a plurality of the second participants to generate the first secret value; and transferring access to the digital asset to a third private key of the cryptography system in the event of one or more of the plurality of second participants becoming unresponsive.

7. A method according to claim 6, wherein each of a plurality of the second participants has a respective private key of the cryptography system.

8. A method according to claim 6, further comprising distributing shares of the share of the second private key in possession of the first participant among the first participant and at least one the second participant.

9. A method according to claim 6, wherein the digital asset remains under control of the third private key for a predetermined time.

10. A method according to claim 6, further comprising distributing the shares of the second private key among a plurality of the participants.

11. A method according to claim 1, wherein the cryptography system is an elliptic curve cryptography system, wherein the public key of each the public-private key pair is related to the corresponding private key by multiplication of an elliptic curve generator point by the private key.

12. A computer implemented system comprising: a processor; and nontransitory memory coupled with the processor and storing a set of instructions that, when executed by the processor, causes the processor to execute the method according to claim 1.

13. A method according to claim 6, wherein the cryptography system is an elliptic curve cryptography system, wherein the public key of each the public-private key pair is related to the corresponding private key by multiplication of an elliptic curve generator point by the private key.

14. A computer implemented system comprising: a processor; and nontransitory memory coupled with the processor and storing a set of instructions that, when executed by the processor, causes the processor to execute the method according to claim 6.

Description

(1) An embodiment of the present invention will now be described, by way of example only and not in any limitative sense, with reference to the accompanying drawings, in which:—

(2) FIG. 1 is a digital signature system embodying the present invention;

(3) FIG. 2 is a process for generating shares of a digital signature for use in the process of FIG. 1;

(4) FIG. 3 is a process of generating a digital signature from the shares generated in the process of FIG. 2;

(5) FIG. 4 shows a process for splitting a share of a private key; and

(6) FIG. 5 shows a process for executing digital signature in the case of an unresponsive or malicious participant.

SYSTEM OVERVIEW

(7) Referring to FIG. 1, a system 2 embodying the present invention for carrying out rapid signature of blockchain transactions 4 has four parties in a threshold signature scheme, the parties being a client 6, an exchange 8, a trusted third party (TTP) 10 and an escrow 12. Each party has a respective elliptic curve public/private key pair (y.sub.C,x.sub.C), (y.sub.Ex,x.sub.Ex), (y.sub.T,x.sub.T), (y.sub.Es,x.sub.Es) respectively. Compared to the typical ‘2 of 3’ escrow arrangement of the prior art, the present invention features an additional party, the TTP 10. As explained in greater detail below, the TTP 10 is required to participate in the generation of every signature that does not involve the Escrow 12 (in case of fault resolution).

(8) The TTP 10 is required to have a fast (low latency) and reliable connection with the Exchange 8, and the TTP 10 should be physically separate from all other parties.

(9) Secure communication channels enabling both encryption and authentication are then established between the client 6 and exchange 8, the exchange 8 and TTP 10, the client 6 and TTP 10, and the exchange 8 and escrow 12. These communication channels establish shared secrets that can that can be periodically updated without additional communication using the method described in International Patent Application WO 2017/145016.

(10) The parties hold secret key shares x.sub.n; n=1, 2, 3, 4 in a threshold private key x; the shares are generated distributively (i.e. without a trusted dealer), according to a method described in greater detail below so that the full private key never exists in a single place. These shares (along with the signature initialisation) may be used to generate a partial signature (or signature share) sig.sub.n; n=1, 2, 3, 4 on a message m (a Bitcoin transaction hash). The TTP will provide a partial signature on any transaction in response to an authenticated request from the Exchange 8. It follows that, the ‘3 of 4’ threshold scheme effectively emulates a ‘2 of 3’ multi-signature. One further possibility is for there to be restrictions on the types of transaction that TTP 10 will partially sign. For example, the TTP 10 should only sign transactions sending to certain addresses. This arrangement has the advantage that TTP 10 would not need to know anything about the transaction and could therefore ‘sign it blind’. Also, this scheme mimics the ‘2 of 3’ structure of BitGo most closely.

(11) Parties 2, 3 and 4 are assumed to employ trusted hardware, such that their share in the threshold private key is generated within a protected ‘enclave’. Messages can be sent into the enclave and a (partial) signature on the message may be output if certain conditions are met, but the private key share never leaves the enclave. In this scheme, the threshold private key can be reconstructed given two private key shares. However, with the use of trusted hardware, such an attack would require prolonged physical access to two sets of hardware at a time when both pieces of hardware contain key shares of the same generation. Therefore, such an attack would be very difficult to realise in practice.

(12) Basic Operation of the Exchange

(13) Referring to FIG. 1, the high-level function of the threshold wallet in relation to exchange operations is as follows: 1. Client 6 deposits some Bitcoin B in to an account associated with the (dealer-less) public key produced by the threshold scheme. 2. Various trades are executed, leaving a proportion f of B belonging to the Client 6. 3. Settlement is requested (either by the Client 6 or by the Exchange 8). Let us say that it is the Exchange 8 requesting settlement, and that the correct distribution of funds is encoded in transaction T. 4. T and Sig (T,x.sub.Ex) are sent, by the Exchange 8, to TTP 10. 5. If Sig (T,x.sub.Ex) verifies, TTP 10 sends their partial signature on T (denoted sig.sub.3) to the Exchange 8. TTP 10 does not need to know the information contained in T, and in fact, it would be better from a security point of view if they did not. This could be achieved via a partial blind signature operation. 6. Meanwhile, if the request is deemed authentic (Sig (T,x.sub.E) verifies), and they agree with the content of T, the Client 6 sends Sig (T,x.sub.C), sig.sub.1, Sig (sig.sub.1,x.sub.C) to the Exchange 8. 7. If the signatures verify, the Exchange 8 combines sig.sub.2, sig.sub.1, sig.sub.3, and checks that the signature Sig (T,x) verifies; if so, T,Sig(T,x) are broadcast to the blockchain network.
Secure Wallet Protocol

(14) This section describes the protocol for the creation of the secure wallet and then the threshold signing operation. The protocol is described in terms of the high-level primitives that are described in detail in R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin. Robust threshold DSS signatures. In International Conference on the Theory and Applications of Cryptographic Techniques, 354-371 (1996).

(15) Dealer-Free Key Generation

(16) The creation of the secure wallet is initiated with a re-initialisation of the secure communication channels between the 4 participants in the scheme (as described in International Patent Application WO 2017/145016).

(17) The Exchange 8 then coordinates the dealer-free generation of a shared elliptic curve public key, where each of the 4 participants will hold shares in the corresponding secret key (on a degree 1 polynomial). Two of these four shares are sufficient to reconstruct the private key, but this operation is impossible, even with the collusion of two of the participants if the key shares are protected in trusted execution environments. The only possible way to authorise a transaction is via the generation of a threshold signature involving three of the four parties.

(18) The key generation involves running the Joint Verifiable Random Secret Sharing (JVRSS) protocol to create the shared polynomial, and the corresponding shared public key y via the Exp-Interpolate procedure with each party having a share (x.sub.i) on the polynomial. The Exp-Interpolate procedure is the recovery of the shared secret, multiplied by the elliptic curve generator point, from at least a threshold number of shares, multiplied by the elliptic curve generator point, i.e. using a similar technique (i.e. Lagrange interpolation) which would be used to recover the shared secret from the threshold number of shares. Unconditionally secure verification of the secret shares is ensured by performing the protocol of Pedersen [Pedersen 1991]. This process is illustrated in FIG. 2. Once the key generation has been verifiably performed, the client (or exchange) pays funds to the shared public key (the corresponding Bitcoin address for y), which is then confirmed by the exchange (or Client). It should be noted that the parameter r is calculated from the x-coordinate of w.sub.0.

(19) Ephemeral Key Sharing

(20) To enable rapid and non-interactive signature generation on a given transaction, the ephemeral key (k) shares and secret share multiplication necessary to construct the signature can be generated in advance of the signing procedure. This means that once a signature is required, each party only needs to calculate their signature share (given a particular transaction hash m) which can then be broadcast and interpolated by anyone to generate the full signature.

(21) FIG. 2 shows this ‘pre-signing’ procedure in terms of Joint Random Secret Sharing (JRSS) protocols (sharing an unknown random value), and Joint Zero Secret Sharing (JZSS) protocols (sharing zero with random shares—used for masking). The operations shown in FIG. 2 are performed to jointly compute the value of r from the ephemeral key shares without any party learning the full ephemeral key.

(22) The shared key generation and the ‘pre-signing’ arrangement described here can be performed in parallel at the same time, saving significantly on communication latency.

(23) Signature Generation

(24) As shown in FIG. 3, the generation of a valid signature (for the shared public key y) requires the consent of 3 parties (the signature will be interpolated from 3 points on the degree 2 (t=2) signature share polynomial). In normal operation, the shares will be produced by the Client 6, the Exchange 8 and the TTP 10. The full signature interpolation (Lagrange) can performed by any party, but in the present embodiment is performed by the exchange 8 (or client 6), who will compile the final transaction and broadcast it to the network. FIG. 3 shows each party computing the signature share and then broadcasting it. This share can be public—it contains no information about the private or ephemeral key shares, or any other identifying information due to the masking shares (of zero) c.sub.i. A more detailed explanation of the key share scheme used to distribute the key and signature shares shown in FIG. 2 is described in Appendix 1.

(25) Client Key Management

(26) In addition to the security benefits from a dealer free shared key for the secured funds, the security for the client can be further enhanced by splitting the client key share. This process is shown in FIG. 4. Once established from the Joint Verifiable Random Secret Sharing (JVRSS) protocol, the client key share (x.sub.1) can itself be split into two or three sub-shares. The splitting is performed according to the protocol described in International Patent Application WO 2017/145010. Once the key share has been split, it is securely deleted. The sub-key shares are then sent to different devices to enable two-factor authentication (2FA) in order to authorise transaction signing. A further security enhancement can be achieved by the exchange storing one of the client sub-key shares—therefore both the client (via 2FA) and the exchange is required to consent the providing the client partial signature.

(27) Resolution in case of malicious/unresponsive parties

(28) Unresponsive Client

(29) Referring to FIG. 5, in this case, the Exchange 8 must involve the Escrow 12 in order to construct the threshold signature on T. The situation is the same as would arise for BitGo. The procedure for convincing the Escrow 12 to participate can be relatively slow and involve multiple checks (for example, to guard against the possibility that security of the Exchange 8 has been compromised). For additional security, the Escrow 12 could be configured to (initially) only provide a partial signature on a transaction which moves the funds to a special ‘holding account’ (recovery address: rec), also secured under a threshold signature, where they must remain for a period of time. The significance of this account may be known only to the parties of the threshold scheme. This precaution would give the Client 6 time to intervene, for example, if they had been wrongly deemed unresponsive.

(30) Malicious Client

(31) Also with reference to FIG. 5, a malicious client 6 acts to prevent the generation of a valid threshold signature (and therefore the transfer of funds) by providing a signature share (i.e. s.sub.1) that is invalid. When the 3 signature shares are combined to form the full signature, it will be immediately apparent that the signature is incorrect (by failed validation with the shared public key). The initial step in this case is to identify which of the three signature shares (s.sub.1, s.sub.2 or s.sub.3) is invalid. This can be done iteratively: the exchange 8, TTP 10 and Escrow 12 can attempt to sign a transaction to the recovery address, and if this fails a signature can be generated shares from the client 6, TTP 10 and Escrow 12 (i.e. the exchange 8 share is malicious). Alternatively, a signature share verification scheme can be employed.

(32) The present invention enables a secure wallet service system employed by Bitcoin exchanges, which employ the ‘2 of 3’ multi-signature technology, to be effectively replaced (and improved) by a scheme based on threshold signatures employing polynomial secret sharing. The present invention is also compatible with trading via payment channels since it allows for signing at high frequency (in contrast to S. Goldfeder, R. Gennaro, H. Kalodner, J. Bonneau, J. A. Kroll, E. W. Felten, and A. Narayanan. Securing Bitcoin wallets via a new DSA/ECDSA threshold signature scheme (2015) and R. Gennaro et al. Threshold-optimal DSA/ECDSA signatures and an application to Bitcoin wallet security (2016). International Conference on Applied Cryptography and Network Security. ACNS 2016: Applied Cryptography and Network Security pp 156-174, for example).

(33) The present invention can also be made robust against the possibility of an unresponsive exchange. Because the TTP sees (and provides partial signature on) every commitment transaction, TTP always knows current channel state; this means TTP can collaborate with Escrow and Client to provide an orderly sequence of soft resolutions in event that exchange is rendered unresponsive, thus avoiding ‘failure mode’ described above.

(34) The present invention also avoids the need for Segregated Witness, by exchanging the first commitment transactions by embedding them in an on-chain transaction. The Escrow monitors the blockchain for these transactions, and collaborates with the appropriate parties to provide refunds if the relevant transactions are not observed before timeout.

(35) It should be noted that the availability and security of any of the parties (and therefore the system as a whole) may be enhanced by further sharing their private key and/or share in the threshold private key between members of a (private) ‘Congress’. For example, the Escrow may initiate a refund if the required ECTs are not observed on the blockchain. In this case, the difficulty of the blocks can be checked inside TEEs belonging to members of the Congress, and a Ghostchain may be instantiated to construct the (partial) signature on the refund transaction if and only if commitment transactions are not observed within a certain number of blocks after the channel is funded.

(36) It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word “comprising” and “comprises”, and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of” and “comprising” means “including or consisting of”. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

APPENDIX 1—DETAILED DESCRIPTION OF KEY SHARE AND SIGNATURE SHARE GENERATION

(37) Algorithm 1—Key Generation

(38) Domain Parameters (CURVE, Cardinality n, Generator G)

(39) Input: NA

(40) Output: Public Key Q.sub.A

(41) Private Key Shares d.sub.A(1), d.sub.A(2), . . . , d.sub.A(j)

(42) For a threshold of k slices from (j) participants, a constructed key segment d.sub.A(i) is constructed which is associated with participant (i) and (j−1) participants nominated as participant (h) that are the other parties that participant (i)exchanges secrets with to sign a key (and hence a Bitcoin transaction). In the scheme, j is the total number of participants where k≤j and hence h=j−1 Hence, there is a (k,j)—threshold sharing scheme.

(43) The method for algorithm 1 follows: 1) Each participant p.sub.(i) of (j) where 1≤i≤j exchanges an ECC public key with all other participants. This address is the Group identity address and does not need to be used for any other purpose. 2) Each participant p.sub.(i) selects a polynomial ƒ.sub.i(x) of degree (k−1) with random coefficients in a manner that is secret from all other parties.

(44) This function is subject to a first secret value in the form of the participant's secret a.sub.0.sup.(i) that is selected as the polynomial free term. This value is not shared.

(45) ƒ.sub.i(h) is defined to be the result of the function, ƒ.sub.(x) that was selected by participant p.sub.(i) for the value at point (x=h), and the base equation for participant p.sub.(i) is defined as the function:
ƒ.sub.(x)=Σ.sub.p=0.sup.(k-1)a.sub.px.sup.p mod n

(46) In this equation, a.sub.0 is the secret for each participant p.sub.(i) and is not shared.

(47) Hence, each participant p.sub.(i) has a secretly kept function ƒ.sub.i(x) that is expressed as the degree (k−1) polynomial with a free term a.sub.0.sup.(i) being defined as that participant's secret such that:
ƒ.sub.i.sub.(x)=Σ.sub.γ=0.sup.(k-1)a.sub.γx.sup.γ mod n 3) Each participant p.sub.(i) encrypts first shares ƒ.sub.i(h) to participant P.sub.(h) ∀h={1, . . . , (i−1), (i+1), . . . , j} using P.sub.(h)'s public key as noted above and exchanges the value for P.sub.(h) to decrypt. Each participant P.sub.i sets up a respective secure encrypted communication channel with each other participant P.sub.j, for example by means of a method disclosed in international patent application WO 2017/145010. 4) Each participant P.sub.(i) broadcasts the values below to all participants.
a.sub.κ.sup.(i)G∀κ={0, . . . ,(k−1)}  a)
ƒ.sub.i(h)G∀h={1, . . . ,j}  b) 5) Each participant P.sub.(h≠1) verifies the consistency of the received shares with those received from each other participant.

(48) That is: Σh.sup.κa.sub.κ.sup.(i)G=f.sub.i(h)G

(49) And that ƒ.sub.i(h)G is consistent with the participant's share. 6) Each participant P.sub.(h≠i) validates that the share owned by that participant (P.sub.(h≠i)) and which was received is consistent with the other received shares:
a.sub.0.sup.(i)G=Σ.sub.hϵBb.sub.hƒ.sub.i(h)G∀P.sub.(h≠i)

(50) In effect, this step consists of carrying out, on the elliptic curve encrypted versions of the shares f.sub.i(h) (i.e. f.sub.i(h)G), the operation which, if carried out on the unencrypted versions of f.sub.i(h), would recover the secret value a.sub.0.sup.(i), to recover G a.sub.0.sup.(i). In the case of a Shamir secret sharing scheme, therefore, the coefficients b.sub.h represent the Lagrange interpolation coefficients necessary to recover the secret from its corresponding shares.

(51) If this is not consistent, the participant rejects the protocol and starts again. In addition, because each participant P.sub.j communicates with participant P.sub.1 by means of its own encrypted communication channel, it is possible to identify which participant Pj is associated with any inconsistent shares. 7) Participant p.sub.(i) now either calculates their share d.sub.A(i) as:
SHARE(p.sub.(i))=d.sub.A(i)=Σ.sub.h=J.sup.jƒ.sub.h(i)mod n Where Σ.sub.h=l.sup.Jƒ.sub.h(i)mod n are second shares in respective second secret values a.sub.0 received from each participant P.sub.(h≠i) And where: SHARE (p.sub.(i))ϵZ.sub.n and d.sub.A(j) Where: Q.sub.A=Exp−Interpolate(ƒ.sub.1, . . . , ƒ.sub.J)[=G×d.sub.A]

(52) And where the operation Exp-Interpolate( ) is defined as the operation which recovers the elliptic curve encrypted secret from the elliptic curve encrypted shares. Return (d.sub.A(i),Q.sub.A)

(53) Participant p.sub.(i) now uses the share in calculating signatures. This role can be conducted by any participant or by a party p.sub.(c) that acts as a coordinator in the process of collecting a signature. The participant p.sub.(c) can vary and does not need to be the same party on each attempt to collect enough shares to sign a transaction.

(54) Hence private key shares d.sub.A(i)←Z.sub.n* have been created without knowledge of the other participant's shares.

(55) Algorithm 2—Updating the Private Key

(56) Input: Participant P.sub.i's share of private key d.sub.A denoted as d.sub.A(i).

(57) Output: Participant P.sub.i's new private key share d.sub.A(i).

(58) Algorithm 2 can be used to both update the private key as well as to add randomness into the protocol. 1) Each participant selects a random polynomial of degree (k−1) subject to zero as its free term. This is analogous to Algorithm 1 but that the participants must validate that the selected secret of all other participants is zero.

(59) Generate the zero share: z.sub.i←Z.sub.n* 2) d.sub.A(i)′=d.sub.A(i)+z.sub.i 3) Return: d.sub.A(i)′

(60) The result of this algorithm is a new key share that is associated with the original private key. A variation of this algorithm makes the ability to both increase the randomness of the first algorithm or to engage in a re-sharing exercise that results in new key slices without the need to change the bitcoin address possible. In this way, the invention allows a group to additively mask a private key share without altering the underlying private key. This process can be used to minimise any potential key leakage associated with the continued use and deployment of the individual key shares without changing the underlying bitcoin address and private key.

(61) Algorithm 3—Signature Generation

(62) Domain Parameters: CURVE, Cardinality n, Generator G

(63) Input: Message to be signed e=H(m) Private Key Share d.sub.A(i)ϵZ.sub.n*

(64) Output: Signature (r,s)ϵZ.sub.n* for e=H(m)
A) Distributed Key Generation 1) Generate the ephemeral key shares using Algorithm 1:
D.sub.k(i)←Z.sub.n* 2) Generate Mask shares using Algorithm 1:
α.sub.i←Z.sub.n 3) Generate Mask shares with Algorithm 2:
b.sub.i,c.sub.i←Z.sub.n.sup.2

(65) The shares of b and c are then kept secret by the participants.

(66) B) Signature Generation

(67) 4) e=H(m) Validate the hash of the message m 5) Broadcast
ϑ.sub.i=D.sub.k(i)α.sub.i+β.sub.i mod n
And
ω.sub.i=G×α.sub.i 6) μ=Interpolate(ϑ.sub.i, . . . , ϑ.sub.n) mod n
[[=D.sub.kα mod n]

(68) Where the operation μ=Interpolate (υ.sub.1, . . . , υ.sub.j)mod n is defined as the operation which recovers the secret from the shares. 7) θ=Exp−Interpolate (ω.sub.1, . . . , ω.sub.n)
[=G×α] 8) Calculate (R.sub.x,R.sub.y) where r.sub.x,y=(R.sub.x,R.sub.y)=θ×μ.sup.−1
[=G×D.sub.k.sup.−1]] 9) r=r.sub.x=R.sub.x mod n If r=0, start again (i.e. from the initial distribution) 10) Broadcast S.sub.i=D.sub.k(i)(e+D.sub.A(i)r)+C.sub.i mod n 11) S=Interpolate(s.sub.i, . . . , s.sub.n)mod n If s=0 redo Algorithm 3 from the start (A.1). 12) Return (r,s) 13) In Bitcoin, reconstruct the transaction with the (r,s) pair to form a standard transaction.

REFERENCES

(69) TABLE-US-00001 Reference Author, date, name & location [Lightning 2016] J Poon; T Dryja; The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments (2016). [Gennaro 1996] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin. Robust threshold DSS signatures. In International Conference on the Theory and Applications of Cryptographic Techniques, 354-371 (1996). [Goldfeder 2015] S. Goldfeder, R. Gennaro, H. Kalodner, J. Bonneau, J. A. Kroll, E. W. Felten, and A. Narayanan. Securing Bitcoin wallets via a new DSA/ECDSA threshold signature scheme (2015). [Gennaro 2016] R. Gennaro et al.. Threshold-optimal DSA/ECDSA signatures and an application to Bitcoin wallet security (2016). International Conference on Applied Cryptography and Network Security. ACNS 2016: Applied Cryptography and Network Security pp 156-174. [Boneh 2016] Boneh, Dan, Rosario Gennaro, and Steven Goldfeder. “Using Level-1 Homomorphic Encryption To Improve Threshold DSA Signatures For Bitcoin Wallet Security.” [Wright 2016] Wright, C. & Savanah, S. (2016) “Determining a common secret for two Blockchain nodes for the secure exchange of information” “International Patent Application Number: WO 2017/145010”. 2016 [Bogos 2016] Bogos, Sonia, John Gaspoz, and Serge Vaudenay. “Cryptanalysis of a homomorphic encryption scheme.” ArcticCrypt 2016. No. EPFL-CONF- 220692. 2016. [Yupu 2012] Hu, Yupu, and Fenghe Wang. “An Attack on a Fully Homomorphic Encryption Scheme.” IACR Cryptology ePrint Archive 2012 (2012): 561.