Method for data sharing and privacy protection in digital currency transaction

Abstract

The invention discloses a method for data sharing and privacy protection in digital currency transaction, which comprises the following steps that: a digital currency transaction participant registers and registers in a trust mechanism to obtain a secure communication parameter; the sharing initiator requests an encryption token from a trust mechanism; the trust mechanism checks the transaction request, registers and sends an encryption token; the shared transaction content is encrypted through the encryption token and recorded to a distributed account book; the sharing responder requests a query token to the trust agency, and the supervision agency, the auditing agency or other transaction participants authorized to access all request the query token in this way; the trust mechanism checks the query request from the sharing responder and sends a query token; the shared responder decrypts the shared transaction content by querying the token; and the supervision mechanism or the auditing mechanism obtains the batch query token through the trust mechanism. According to the method, data security protection is provided on the premise that transaction contents are not contacted by using the lowest coupling degree and the most simplified interaction process.

Description

Technical Field

[0001] The present invention relates to a method for data sharing and privacy protection in digital currency transactions. Background Art

[0002] Central bank digital currencies are issued and managed by central banks in various countries based on distributed ledger technology (DLT), such as Brazil, Sweden, and the United Arab Emirates. Commercial banks and / or non-bank financial institutions in the country participate in digital currency transactions and / or provide consensus algorithms. Due to the technical characteristics of distributed ledgers, all institutions involved in transactions and consensus calculations can obtain transaction data in their ledgers, such as Figure 9 If privacy protection measures are not taken, sensitive data including but not limited to end-user information, transaction details, and programmable fields in contracts can be easily intercepted, resulting in a leak.

[0003] To address these privacy issues, central banks and regulatory agencies in different countries have adopted varying measures and technical implementations: 1) setting complex distributed ledger access permissions; 2) having the initiator grant one-time access permissions and expiration dates to the responder; 3) having the initiator assign specific access permissions to each transaction; and 4) having each participant independently develop their own access control and permission management subsystems. This, in the long term, creates a significant workload and high project costs. Once a project has already been developed or deployed on a large scale, it becomes extremely difficult to coordinate functional adaptation and business adjustments among participating parties. Furthermore, these solutions make it difficult for regulators to achieve real-time monitoring.

[0004] Therefore, in response to the above problems, a method for data sharing and privacy protection in digital currency transactions is provided. Summary of the Invention

[0005] The purpose of this invention is to overcome the existing defects and provide a method for data sharing and privacy protection in digital currency transactions. By using the lowest coupling degree and the most simplified interaction process, without accessing the transaction content, it provides reliable data security protection and a customizable privacy protection solution.

[0006] The technical solution to achieve the above purpose is:

[0007] A method for data sharing and privacy protection in digital currency transactions, comprising:

[0008] Step S1: The digital currency transaction participants register with the trust institution and obtain secure communication parameters;

[0009] Step S2: The sharing initiator requests an encryption token from the trust institution;

[0010] Step S3: The trusted institution verifies the transaction request, registers it, and issues an encrypted token;

[0011] Step S4: Encrypt the shared transaction content using an encryption token and record it in a distributed ledger;

[0012] Step S5: The shared responder requests a query token from the trust institution. The regulatory agency, auditing agency, or other authorized transaction participants all request a query token in this way.

[0013] Step S6: The trust authority verifies the query request from the shared responder and issues a query token;

[0014] Step S7: The sharing responder decrypts the shared transaction content using the query token;

[0015] In step S8, the regulatory agency or auditing agency obtains a batch query token through a trusted agency.

[0016] Preferably, in step S1, the digital currency transaction participants register with the trust institution, register, and obtain secure communication parameters, including:

[0017] Step S11: The participant sends the preset parameters to the trusted institution to register or update the institution information;

[0018] Step S12: After receiving the data, the trust institution verifies the validity of the data and saves it to the database after verification.

[0019] Step S13: The trust authority confirms that the request is valid, and the server generates secure communication parameters;

[0020] In step S11, the preset parameters include but are not limited to the organization name, organization registration number, organization access IP address library, server security certificate library, trusted server environment information and signed service agreement electronic document;

[0021] In step S12, only registered participating institutions can share designated transaction content with other institutions, or have specific shared transaction content shared by other institutions;

[0022] In step S13, the secure communication parameters include but are not limited to the organization identification information, the server security certificate, the designated communication IP address and port, and the enabled service type;

[0023] In step S13, the enabled service types include but are not limited to requesting an encryption token, requesting a query token, and requesting a batch query token;

[0024] In step S13, the trust institution and the participants perform network configuration and call requests according to the secure communication parameters to achieve point-to-point secure encrypted communication between servers;

[0025] In step S2, the sharing initiator sends its own organization identification information, the unique identification information shared in the transaction, and the list of designated organizations authorized to access the shared transaction information to the designated gateway of the trusted organization. If the sharing initiator shares a content or field with multiple participating organizations in a transaction, it applies for an encryption token and specifies the list of authorized access organizations. If multiple shared contents or fields are shared with different designated organizations, it provides the shared unique identification information one by one and obtains multiple encryption tokens.

[0026] Preferably, the step S3, wherein the trust institution verifies the transaction request, registers and issues an encrypted token, includes:

[0027] In step S31, the trust institution will query whether the institution has applied for an encrypted token using the shared unique identification information in the transaction;

[0028] Step S32: If it has been used, the shared unique identification information of the organization is fed back and cannot be used again. If it has not been used, the trust organization generates a key pair using an asymmetric encryption algorithm agreed upon with all parties according to data security standards;

[0029] Step S33: The trusted institution verifies the list of designated institutions that can view the shared transaction information, associates it with the shared unique identification information in the transaction, and registers it in the database;

[0030] In step S34, the trust authority generates and returns an encrypted token to the sharing initiator, which only provides access rights to the sharing initiator's server and the designated IP address whitelist within the specified validity period;

[0031] In step S32, the asymmetric encryption algorithm includes but is not limited to the RSA encryption algorithm, the elliptic curve encryption algorithm, the national secret elliptic curve public key encryption algorithm and the ElGamal algorithm, and generates and saves an asymmetric key pair;

[0032] In step S32, a set of asymmetric key pairs is generated for each transaction;

[0033] In step S32, the trust authority generates an encrypted token in the following manner: for a group of shared initiators and shared responders, a group of asymmetric key pairs is generated within a period, and is reused between designated transaction parties within a valid period;

[0034] In step S34, the content of the generated encrypted token always keeps changing and can be quickly identified through the algorithm, including but not limited to the business type and timestamp.

[0035] Preferably, in step S4, an encryption token is used to obtain the encryption private key of the transaction at a designated gateway, and the sharing initiator uses the encryption private key to algorithmically encrypt the shared transaction content and record it in the domain value of the distributed ledger.

[0036] Preferably, in step S4, the encrypted shared transaction content, encryption token, and organization information are sent to a designated gateway address, and the server encrypts and returns the ciphertext. The sharing initiator records the ciphertext in the domain value of the distributed ledger.

[0037] Preferably, the step S5, wherein the shared response direction requests the trust institution to query the token, includes:

[0038] Step S51, obtaining shared unique identification information of the transaction from the distributed ledger, including but not limited to the transaction identification number and transaction hash value;

[0039] Step S52: The shared responder collects its own organization identification information and random number information parameters to form a token query request message;

[0040] Step S53, sending the query request to the trust institution through the specified server security certificate and the IP address in the whitelist;

[0041] In step S6, the trust authority verifies the query request from the shared responder and issues a query token, including:

[0042] Step S61: The trust institution verifies whether the institution identification number in the request message is consistent with the IP address and server security certificate of the query request;

[0043] Step S62: If not, the returned request information is inconsistent with the parameters reserved by the institution. If so, the trust institution checks the shared unique identification information with the shared response institution to see if it is one of the authorized access institutions.

[0044] In step S63, if not, the return institution is not authorized to access the specified transaction. If so, the trust institution generates and returns a query token to the shared responder, providing access rights only to the shared responder's server, a specified IP address whitelist, and within the specified validity period.

[0045] Preferably, in step S7, the query token is used to obtain the decryption public key of the transaction at the designated gateway, and the shared responder uses the decryption public key to obtain the original shared transaction content.

[0046] Preferably, in step S7, the shared transaction ciphertext to be decrypted, the decryption token, and the organization information are sent to a designated gateway address, and the server returns the shared transaction content after decryption.

[0047] Preferably, in step S8, the regulatory agency or auditing agency obtains a batch query token through a trusted institution, including:

[0048] Step S81: The regulatory agency or auditing agency signs an access agreement with the sharing initiator and the sharing responder, and provides it to the trust agency;

[0049] Step S82: The regulatory agency or auditing agency provides a query period and specifies query conditions for a list of transaction shared unique identification numbers;

[0050] In step S83, the trust institution generates associated query tokens in batches according to the query conditions.

[0051] The beneficial effects of the present invention are: the present invention provides encrypted tokens and query tokens to both parties of the central bank digital currency transaction through a trusted institution, so that the shared content is only viewed by the two parties of the transaction; at the same time, it provides extremely high privacy protection without changing the structure of the existing system and without reading the original data. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 is a flow chart of a method for data sharing and privacy protection in digital currency transactions according to the present invention;

[0053] Figure 2 This is a specific flow chart of the registration of institutions participating in central bank digital currency transactions with trust institutions in the present invention;

[0054] Figure 3 This is a specific flow chart of the trust institution in the present invention verifying the transaction request, registering and issuing the encrypted token;

[0055] Figure 4 This is a specific flow chart of the shared response direction requesting a query token from a trusted institution in the present invention;

[0056] Figure 5 This is a specific flow chart of the trust authority in the present invention verifying the query request from the shared responder and issuing the query token;

[0057] Figure 6 This is a specific flow chart of the regulatory agency or auditing agency obtaining batch query tokens through a trust agency in the present invention;

[0058] Figure 7 This is a schematic diagram of data sharing and privacy protection during the central bank digital currency transaction process in the present invention;

[0059] Figure 8 This is a schematic diagram of adding a trust institution to achieve transaction data sharing and privacy protection in the present invention;

[0060] Figure 9 Schematic diagram of existing transaction data sharing and privacy challenges. DETAILED DESCRIPTION

[0061] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. In the description of the present invention, it should be noted that the terms "center", "up", "down", "left", "right", "vertical", "horizontal", "inside", "outside" and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance.

[0062] The present invention will be further described below with reference to the accompanying drawings.

[0063] like Figure 7 、 8 As shown, the present invention uses a trusted institution to provide an encrypted token to the sharing initiator and a query token to the sharing responder during the central bank digital currency transaction process, thereby protecting the privacy of the shared data portion of the transaction data and making it invisible to non-counterparty institutions. Regulators can also obtain query tokens in batches by signing agreements with the transaction parties (sharing initiators and / or sharing responders) to achieve supervision purposes. The specific steps are as follows.

[0064] like Figure 1 As shown, a method for data sharing and privacy protection in digital currency transactions includes:

[0065] In step S1, digital currency transaction participants register with a trusted institution and obtain secure communication parameters. The digital currency transaction participants are participants in the central bank's digital currency transaction.

[0066] In the embodiment, participating institutions include but are not limited to regulators, transaction service providers, consensus parties and other institutions. Regulators are responsible for monitoring whether the real-time flow of digital currency complies with laws and regulations such as anti-money laundering and anti-terrorist financing, such as the Central Bank of Brazil (BCB) and the Brazilian Financial Intelligence Unit (COAF); transaction service providers provide a software and hardware environment that facilitates end users to use digital currency, such as local commercial banks and (or) electronic payment institutions (EMI); consensus parties confirm transactions or parameter changes in the distributed network through algorithms, such as interbank banks, interbank associations, non-bank financial institutions, etc.; other roles can register according to the needs of collecting, analyzing and processing data on the distributed ledger.

[0067] Among them, transaction service providers can be divided into shared initiators and shared responders according to the order in which transactions are initiated.

[0068] Trust institutions can act as independent service gateways or neutral distributed ledgers, providing encryption and query token services for all registered institutions regarding cross-institutional shared transactions within the ledger. They are characterized by not directly participating in transactions, not obtaining raw transaction data, and not relying on existing system modules.

[0069] like Figure 2 As shown, in step S1, digital currency transaction participants register with a trusted institution and obtain secure communication parameters, including:

[0070] In step S11, the participant sends the preset parameters to the trusted institution to register or update the institution information.

[0071] In an embodiment, the preset parameters include but are not limited to the organization name, organization registration number (for example: Brazilian legal person unique identification code CNPJ), organization access IP address library, (optional) server security certificate library, (optional) trusted server environment information and (optional) signed service agreement electronic document.

[0072] Step S12: After receiving the data, the trust institution verifies the validity of the data and saves it to the database after completing the verification.

[0073] In the embodiment, only registered participating institutions can share designated transaction content with other institutions, or have specific shared transaction content shared by other institutions.

[0074] In step S13, the trust institution confirms that its request is valid and feeds back the institution identification information (institution unique identification number IIN) generated by the server, the server security certificate (or asymmetric key pair), the designated communication IP address and port, and the permitted business scope to the participant.

[0075] In the embodiment, the secure communication parameters include, but are not limited to, organization identification information, server security certificate, designated communication IP address and port, and enabled service types.

[0076] In the embodiment, the enabled service types include, but are not limited to, requesting an encryption token, requesting a query token, and requesting a batch query token.

[0077] In the embodiment, the communication between the trust institution and the participants is carried out according to the secure communication parameters to perform network configuration and call request, thereby realizing point-to-point secure encrypted communication between servers.

[0078] Step S2: The sharing initiator requests an encryption token from the trust institution.

[0079] In an embodiment, the sharing initiator sends its own institution identification information, the shared unique identification information in the transaction, and the list of designated institutions authorized to access the shared transaction information to the designated gateway of the trusted institution. If the sharing initiator shares a content or field with multiple participating institutions in a transaction, it applies for an encryption token and specifies the list of authorized access institutions. If multiple shared contents or fields are shared with different designated institutions, the shared unique identification information is provided one by one and multiple encryption tokens are obtained to achieve privacy protection between different institutions in the same transaction.

[0080] In step S3, the trusted institution verifies the transaction request, registers it, and issues an encrypted token.

[0081] like Figure 3 As shown, in step S3, the trust institution verifies the transaction request, registers and issues an encrypted token, including:

[0082] In step S31, the trust institution will query whether the institution has applied for an encrypted token using the shared unique identification information in the transaction.

[0083] In step S32, if it has been used, the shared unique identification information of the organization is fed back and cannot be used again. If it has not been used, the trust organization agrees on an asymmetric encryption algorithm with all parties according to data security standards (for example, Brazil's General Data Protection Law LGPD).

[0084] In the embodiment, the asymmetric encryption algorithm includes but is not limited to the RSA encryption algorithm, the elliptic curve encryption algorithm (ECC), the national secret elliptic curve public key cryptography algorithm (SM2) and the ElGamal algorithm, which generates and saves an asymmetric key pair.

[0085] In an embodiment, an asymmetric key pair is generated for each transaction.

[0086] In another embodiment, the encryption token generated by the trust authority is as follows: for a group of shared initiators and shared responders, such as an initiator and one (or more) responders, a group of asymmetric key pairs are generated within a period and reused between designated transaction parties within the validity period.

[0087] In step S33, the trusted institution checks the list of designated institutions that can view the shared transaction information, associates it with the shared unique identification information in the transaction, and registers it in the database.

[0088] In step S34, the trust authority generates and returns an encrypted token to the sharing initiator, providing access rights only to the sharing initiator's server, a specified IP address whitelist, and within a specified validity period.

[0089] In the embodiment, the content of the generated encrypted token always keeps changing and can be quickly identified through an algorithm, including but not limited to business type, timestamp, etc.

[0090] Step S4: Encrypt the shared transaction content through the encryption token and record it in the distributed ledger.

[0091] In the embodiment, an encryption token is used to obtain the encryption private key of the transaction at a designated gateway, and the sharing initiator uses the encryption private key to algorithmically encrypt the shared transaction content and record it in the domain value of the distributed ledger.

[0092] In another embodiment, the encrypted shared transaction content, encryption token, and organization information are sent to a designated gateway address. The server encrypts and returns the ciphertext. The sharing initiator records the ciphertext in the domain value of the distributed ledger.

[0093] In step S5, the shared responder requests the trust institution to query the token, wherein the regulatory agency, auditing agency or other transaction participants with authorized access all request the query token in this way.

[0094] like Figure 4 As shown, in step S5, the shared response direction requests the trust authority to query the token, including:

[0095] Step S51: Obtain shared unique identification information of the transaction from the distributed ledger, including but not limited to the transaction identification number and transaction hash value.

[0096] In step S52, the shared responder collects its own organization identification information, random number information and other parameters to form a token query request message.

[0097] Step S53: Send the query request to the trust organization through the designated server security certificate and the IP address in the whitelist.

[0098] In step S6, the trust authority verifies the query request from the shared responder and issues a query token.

[0099] like Figure 5 As shown, in step S6, the trust authority verifies the query request from the shared responder and issues a query token, including:

[0100] In step S61, the trust organization checks whether the organization identification number in the request message is consistent with the IP address and server security certificate of the query request.

[0101] Step S62: If not, the returned request information is inconsistent with the parameters reserved by the institution. If so, the trust institution checks the shared unique identification information and whether the shared response institution is one of the authorized access institutions.

[0102] In step S63, if not, the return institution is not authorized to access the specified transaction. If so, the trust institution generates and returns a query token to the shared responder, providing access rights only to the shared responder's server, a specified IP address whitelist, and within the specified validity period.

[0103] Step S7: The sharing responder decrypts the shared transaction content by querying the token.

[0104] In an embodiment, a query token is used to obtain a decryption public key for the transaction at a designated gateway, and the shared responder uses the decryption public key to obtain the original shared transaction content.

[0105] In another embodiment, the shared transaction ciphertext to be decrypted, the decryption token, and the organization information are sent to a designated gateway address, and the server returns the shared transaction content after decryption.

[0106] In step S8, the regulatory agency or auditing agency obtains a batch query token through a trusted agency.

[0107] like Figure 6 As shown, in step S8, the regulatory agency or auditing agency obtains a batch query token through a trusted institution, including:

[0108] In step S81, the regulatory agency or auditing agency signs an access agreement with the sharing initiator and / or sharing responder, and provides it to the trust agency.

[0109] In step S82, the regulatory agency or auditing agency provides a query period and specifies query conditions for a list of transaction shared unique identification numbers.

[0110] In step S83, the trust institution generates associated query tokens in batches according to the query conditions.

[0111] In summary, by providing encrypted tokens and query tokens to designated participants in each transaction, the trusted institution ensures that shared transaction data is accessible only to authorized participants, while other institutions are denied access. Furthermore, the trusted institution does not need to access or store the distributed ledger, enabling it to provide services independently of the data.

[0112] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for data sharing and privacy protection in digital currency transactions, characterized in that: include: Step S1: The digital currency transaction participants register with the trust institution and obtain secure communication parameters; Step S2: The sharing initiator requests an encryption token from the trust institution; Step S3: The trusted institution verifies the transaction request, registers it, and issues an encrypted token; Step S4: Encrypt the shared transaction content using an encryption token and record it in a distributed ledger; Step S5: The shared responder requests a query token from the trust institution. The regulatory agency, auditing agency, or other authorized transaction participants all request a query token in this way. Step S6: The trust authority verifies the query request from the shared responder and issues a query token; Step S7: The sharing responder decrypts the shared transaction content using the query token; In step S8, the regulatory agency or auditing agency obtains a batch query token through a trusted agency.

2. A method for data sharing and privacy protection in digital currency transactions according to claim 1, characterized in that: In step S1, digital currency transaction participants register with a trusted institution and obtain secure communication parameters, including: Step S11: The participant sends the preset parameters to the trusted institution to register or update the institution information; Step S12: After receiving the data, the trust institution verifies the validity of the data and saves it to the database after verification. Step S13: The trust authority confirms that the request is valid, and the server generates secure communication parameters; In step S11, the preset parameters include but are not limited to the organization name, organization registration number, organization access IP address library, server security certificate library, trusted server environment information and signed service agreement electronic document; In step S12, only registered participating institutions can share designated transaction content with other institutions, or have specific shared transaction content shared by other institutions; In step S13, the secure communication parameters include but are not limited to the organization identification information, the server security certificate, the designated communication IP address and port, and the enabled service type; In step S13, the enabled service types include but are not limited to requesting an encryption token, requesting a query token, and requesting a batch query token; In step S13, the trust institution and the participants perform network configuration and call requests according to the secure communication parameters to achieve point-to-point secure encrypted communication between servers; In step S2, the sharing initiator sends its own organization identification information, the unique identification information shared in the transaction, and the list of designated organizations authorized to access the shared transaction information to the designated gateway of the trusted organization. If the sharing initiator shares a content or field with multiple participating organizations in a transaction, it applies for an encryption token and specifies the list of authorized access organizations. If multiple shared contents or fields are shared with different designated organizations, it provides the shared unique identification information one by one and obtains multiple encryption tokens.

3. A method for data sharing and privacy protection in digital currency transactions according to claim 1, characterized in that: In step S3, the trusted institution verifies the transaction request, registers it, and issues an encrypted token, including: In step S31, the trust institution will query whether the institution has applied for an encrypted token using the shared unique identification information in the transaction; Step S32: If it has been used, the shared unique identification information of the organization is fed back and cannot be used again. If it has not been used, the trust organization generates a key pair using an asymmetric encryption algorithm agreed upon with all parties according to data security standards; Step S33: The trusted institution verifies the list of designated institutions that can view the shared transaction information, associates it with the shared unique identification information in the transaction, and registers it in the database; In step S34, the trust authority generates and returns an encrypted token to the sharing initiator, which only provides access rights to the sharing initiator's server and the designated IP address whitelist within the specified validity period; In step S32, the asymmetric encryption algorithm includes but is not limited to the RSA encryption algorithm, the elliptic curve encryption algorithm, the national secret elliptic curve public key encryption algorithm and the ElGamal algorithm, and generates and saves an asymmetric key pair; In step S32, a set of asymmetric key pairs is generated for each transaction; In step S32, the trust authority generates an encrypted token in the following manner: for a group of shared initiators and shared responders, a group of asymmetric key pairs is generated within a period, and is reused between designated transaction parties within a valid period; In step S34, the content of the generated encrypted token always keeps changing and can be quickly identified through the algorithm, including but not limited to the business type and timestamp.

4. A method for data sharing and privacy protection in digital currency transactions according to claim 1, characterized in that: In step S4, the encryption token is used to obtain the encryption private key of the transaction at the designated gateway. The sharing initiator uses the encryption private key to algorithmically encrypt the shared transaction content and record it in the domain value of the distributed ledger.

5. A method for data sharing and privacy protection in digital currency transactions according to claim 1, characterized in that: In step S4, the encrypted shared transaction content, encryption token, and organization information are sent to the designated gateway address. The server encrypts and returns the ciphertext. The sharing initiator records the ciphertext in the domain value of the distributed ledger.

6. A method for data sharing and privacy protection in digital currency transactions according to claim 1, characterized in that: The step S5, in which the shared response direction requests the trust institution to query the token, includes: Step S51, obtaining shared unique identification information of the transaction from the distributed ledger, including but not limited to the transaction identification number and transaction hash value; Step S52: The shared responder collects its own organization identification information and random number information parameters to form a token query request message; Step S53, sending the query request to the trust institution through the specified server security certificate and the IP address in the whitelist; In step S6, the trust authority verifies the query request from the shared responder and issues a query token, including: Step S61: The trust institution verifies whether the institution identification number in the request message is consistent with the IP address and server security certificate of the query request; Step S62: If not, the returned request information is inconsistent with the parameters reserved by the institution. If so, the trust institution checks the shared unique identification information with the shared response institution to see if it is one of the authorized access institutions. In step S63, if not, the return institution is not authorized to access the specified transaction. If so, the trust institution generates and returns a query token to the shared responder, providing access rights only to the shared responder's server, a specified IP address whitelist, and within the specified validity period.

7. A method for data sharing and privacy protection in digital currency transactions according to claim 1, characterized in that: In step S7, the query token is used to obtain the decryption public key of the transaction at the designated gateway, and the shared responder uses the decryption public key to obtain the original shared transaction content.

8. A method for data sharing and privacy protection in digital currency transactions according to claim 1, characterized in that: In step S7, the shared transaction ciphertext to be decrypted, the decryption token, and the organization information are sent to the designated gateway address, and the server returns the shared transaction content after decryption.

9. A method for data sharing and privacy protection in digital currency transactions according to claim 1, characterized in that: In step S8, the regulatory agency or auditing agency obtains a batch query token from a trusted institution, including: Step S81: The regulatory agency or auditing agency signs an access agreement with the sharing initiator and the sharing responder, and provides it to the trust agency; Step S82: The regulatory agency or auditing agency provides a query period and specifies query conditions for a list of transaction shared unique identification numbers; In step S83, the trust institution generates associated query tokens in batches according to the query conditions.

Images