Blockchain Transaction Processing with Shared-Secret Linked Keys
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Non-custodial hosted wallets in blockchain transactions face security vulnerabilities due to the storage of extended public keys (xpubs) on beneficiary servers, allowing potential access to derive all associated public keys and link transactions, compromising privacy and security.
Innovation Solution
Implementing a method that uses linked keys derived from secrets shared between devices, rather than storing xpubs on servers, and performing verification on the beneficiary device to pre-authorize or reject transactions, ensuring privacy and security by preventing linkage of transactions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Extent of automation
If extended public keys (xpubs) are stored on the beneficiary server, then transaction verification can be performed automatically, but security and privacy are compromised as third parties can link all transactions
Solution Approach 1:
The patent extracts the verification capability from the server by removing xpub storage. Instead of storing xpubs on the beneficiary server, the system uses linked keys that are derived from shared secrets stored only on devices. This extraction eliminates the server's ability to link transactions while maintaining verification functionality through device-based secret sharing.
Solution Approach 2:
The patent introduces shared secrets as an intermediary between the originator and beneficiary. These secrets enable transaction verification without requiring direct exposure of public keys or transaction linkage capabilities on the server. The shared secrets act as a mediator that allows automatic verification while preserving privacy by preventing third-party transaction linking.
2Adaptability or versatility
If xpubs are stored on the beneficiary server, then all associated public keys can be derived for transaction linking, but this creates security vulnerabilities and compromises integrity
Solution Approach 1:
The patent segments the key system into multiple shared secrets, each associated with specific transactions or transaction groups. Instead of having a single xpub that can derive all keys, the system uses multiple segmented secrets that can only derive keys for their associated transactions. This segmentation prevents comprehensive transaction linkage while maintaining the ability to derive necessary keys for verification.
Solution Approach 2:
The patent applies local quality by making each shared secret transaction-specific or context-specific rather than universal. Each secret has a defined scope and can only be used for verifying transactions within that scope. This localizes the key derivation capability to specific transactions, preventing broad linkage while maintaining verification integrity for individual transactions.
3Object-affected harmful factors
If a secret is shared between originator and beneficiary devices, then transaction linkage is prevented, but verification complexity increases
Solution Approach 1:
The patent applies preliminary action by pre-establishing shared secrets between originator and beneficiary devices before transactions occur. These secrets are generated and stored in advance through secure key exchange protocols. This preliminary setup simplifies the verification process during actual transactions, as the secrets are already in place and ready for use, reducing real-time complexity despite the initial setup effort.
Data Source
Figure 1
Figure 2
Figure 3A~3B
AI summary
The present disclosure relates to a computer-implemented method of processing a blockchain transaction over a peer-to-peer network including an originator device, an originator server, a beneficiary device, a beneficiary server, and a non-custodial wallet hosted on the beneficiary server. The method comprises: sending a linked key associated with the blockchain transaction and blockchain transaction information from the originator device to the non-custodial wallet on the beneficiary server via the originator server, the linked key derived from a secret shared between the originator device and the beneficiary device; performing verification of the linked key, by the beneficiary device, using the secret and the blockchain transaction information; and performing one of pre-authorising the blockchain transaction and rejecting the blockchain transaction at the non-custodial wallet in response to performing the verification by the beneficiary device