Patent Application
20250061458
This application is based upon and claims priority to Chinese Patent Application No. 202311029127.1, filed on Aug. 16, 2023, the entire contents of which are incorporated herein by reference.
The present invention pertains to the field of blockchain technology and specifically focuses on a remarkably resilient method that supports receiver confirmation on asset transfer.
In recent years, blockchain technology has garnered increasing attention in the fields of supply chain, high-performance computing, and search engines, with Bitcoin, Ether, and Hyperledger Fabric serving as notable representatives. Blockchain, a distributed ledger technology, ensures the high security and reliability of historical data in distributed systems. It enables interactions between multiple untrusted participants without the need for a centralized authority.
The academic and industrial communities have shown significant interest in blockchain technology due to its ability to provide untrusted parties with a distributed ledger that guarantees data transparency, integrity, and immutability. This versatility allows blockchain technology to be applied to anonymous online payments, cost-effective remittances, and a wide range of decentralized applications.
The volume and total market capitalization of blockchain technology have experienced explosive growth in recent years, primarily driven by its vital role in the financial sector, where it aids in fraud prevention and misinformation detection. According to PwC's market study, the global blockchain market is projected to reach a value of US $1,431.54 billion by 2030, with a compound annual growth rate (CAGR) of approximately 85.9% between 2022 and 2030.
It is worth noting that an increasing number of crypto assets are gaining tangible value in the real world, which has resulted in an augmented demand for secure, scalable, and efficient blockchain interoperability. Thus, Bitcoin Improvement Proposal (BIP) 70 was proposed to handle the payment issues.
In addition, in all financial fields, it is not uncommon for “fat-finger”-type errors to occur when purchasing, selling, or transferring cryptocurrencies. Such errors refer to the situation where traders unintentionally input incorrect transaction details due to the size of their fingers or inaccurate key sensitivity. This can lead to trading errors, such as inputting the wrong transaction quantity or price, which may result in price fluctuations. Particularly in high-frequency trading, these errors can cause market instability. Incorrect trades can also expose traders and companies to potential trading risks, such as financial losses or legal liabilities. Furthermore, “fat-finger”-type errors can lead to market malfunction, such as incomplete trades or erroneous trading data, affecting the market's efficiency and fairness. This can potentially damage the reputation of traders and financial institutions, especially if such errors occur frequently or result in significant losses. For instance, the significant, rapid, and unexpected drop of US stock indexes in 2010 was caused by an incorrect order in the billions rather than the millions. In 2021, a crypto asset trading platform called DeversiFi erroneously paid out a $24 million fee, and in 2023, an OpenSea collector mistakenly input a 100 ETH bid for a Non-Fungible Token (NFT). Due to the instantaneous and anonymous nature of blockchain transactions, recouping the erroneous funds often relies on the recipient's goodwill. While some blockchains like Ethereum provide a receipt to confirm transaction completion, it cannot prevent the occurrence of “fat finger” by the payer. Therefore, including the recipient's independent confirmation in transactions would be valuable for reducing human errors.
In order to reduce the “fat finger” errors on the touch screen, Microsoft Research produced a prototype device called nanoTouch with a rear-mounted touch interface according to the report by Colin Barras. Kong et al. regard a touch as a time series of ovals and offer 15 target-agnostic touch metrics to measure human performance for touch-based systems so as to help touch accuracy investigation. Holz et al. Propose to increase the touch accuracy based on the perceived input point model. In addition, U.S. Pat. No. 11,619,983B2 detects a touch screen touch event a vibro-acoustic event so as to resolve near touch ambiguities. Although the prior art can reduce “fat finger” errors on touch screen, they cannot handle the after-fact errors.
In order to reduce the loss caused by “fat finger”, financial institutions usually take measures such as enhanced trader training, the use of trading system limitations and security measures, and the implementation of transaction review and monitoring.
The probability of a single user making a “fat finger” error is small, so a simple and effective solution would be to have transactions confirmed not only by the sender, but also by the receiver, so that the probability of the same error occurring by both users at the same time is greatly reduced. Therefore, a highly fault-tolerant asset transfer method and system that supports receiver confirmation is needed to solve the aforementioned problem.
Asset transfer protocols are essential for the secure exchange of digital assets distributed over blockchains. Currently, there are some asset exchange problems that need to be solved. Particularly, as the blockchain payment mechanism does not require confirmation from the receiver to accept the payment, it cannot avoid human errors caused by honest “fat finger”, which may lead to irreversible loss of assets. Therefore, it is necessary to design a highly fault-tolerant asset transfer method so as to achieve a safe and efficient asset transfer.
The main purpose of the present invention is to overcome the drawbacks and deficiencies of the prior art, and to propose a highly fault-tolerant asset transfer method. To this end, the present method includes receiver's confirmation in the asset transfer transaction, which effectively avoids the generation of erroneous transactions in the event that the transaction content is erroneous due to human error by an honest participant, and further realizes safe and efficient asset transfer in blockchain systems.
Bitcoin transactions have a 32-bit HashType field, which changes the way the signature hash is generated and uses only 8 LSBs (Least Significant Bits) in the Hash Type and the MSBs (Most Significant Bits) are 0. In such a system, the transaction parameter such as HashType can be redefined and the recipient is asked to confirm the transaction if the value of the 31st bit of its HashType is 1, then the transaction has the additional feature of recipient confirmation, otherwise it is a regular transaction. In addition, Bitcoin transactions can have multiple inputs and multiple outputs.
According to a first aspect of the present invention, there is disclosed a method of highly fault-tolerant asset transfer transactions on a blockchain supporting confirmation by a receiver, wherein the method comprises:
According to a second aspect of the present invention, there is disclosed a highly fault-tolerant asset transfer system for transactions on a blockchain to support confirmation by a receiver, wherein the system comprises:
Embodiments of the invention are described hereinafter in detail with reference to the drawings, in which:
The following discloses the need for embodiments of the present invention for building components of an asset transfer protocol: a highly fault-tolerant asset-transfer system supporting receiver confirmation.
The current blockchain payment mechanism does not require the payee to confirm acceptance of the payment, and therefore cannot tolerate errors caused by “fat finger” of careless players. Assuming that each person independently and identically has a “fat-finger” error rate p<1.0, the joint probability of error caused by the payer and payee will be p2. Therefore, if the transaction must include a payee's confirmation, the number of errors in the transfer of assets will be greatly reduced.
The embodiments described below are intended to improve fault tolerance in the transfer mechanism with respect to erroneous inputs by the payer, avoiding loss of funds due to human error due to the payer.
The present invention presents an asset transfer protocol that can be used to tolerate accidental errors by honest but careless players, and is applicable to any blockchain.
Bitcoin transactions have a 32-bit HashType field that uses only 8 LSBs (Least Significant Bits) and the MSB (Most Significant Bit) are 0. Additionally, Bitcoin transactions can have multiple inputs and multiple outputs. The present invention may redefine HashType as an indicator to add recipient confirmation. If the value of the unused indicator (e.g., the 31st bit of its HashType) is 1, the transaction has the additional feature of recipient confirmation, otherwise it is a regular transaction.
Embodiments will be described in detail below with reference to
According to an embodiment of the present invention,
Upon receiving a new payment transaction, the blockchain node will check the signature of the payer as usual. The flow of the two-input-one-output transaction confirmation step according to the embodiment of the present invention is shown in
HASH<PubKHashA>VerifySig
where HASH(PubK) is a one-way function that converts the public key PubK to a blockchain address, and VerifySig(σ, PubK, m) is a check to see if σ is the signature of the message m with respect to the public key PubK. in step 240, the miner checks for the equality between HASH(PubKA) and PubKHashA, as well as in step 250, by means of VerifySig(σA, PubKA, out) to verify the first input, i.e., the sender's signature. If any verification is negative, the transaction TXn is discarded at the corresponding steps 241 and 251. Otherwise, in step 260, the miner checks whether an indicator such as the MSB of the HashType is 1. If it is not 1, the transaction is a regular transaction, and the transaction is packaged into the block via step 280. If it is 1, the verification of the receiver's signature continues through VerifySig(σB, PubKB, out) in step 270. If the verification is negative, the transaction TXn is discarded at step 271, otherwise, the transaction is packed to the block at step 280.
Each payment transaction contains the signature of the payee for confirmation, and the asset transfer protocol is intended to enable participants from different blockchains to exchange digital assets. A block diagram of a blockchain system according to an embodiment of the present invention is shown in
The participants in an asset transfer according to an embodiment of the present invention are shown in
Take as an example the asset transfer between user Alice and user Bob on the blockchain. Both parties to the transaction comply with the transfer protocol, but may make errors on the inputs. A transfer step according to an embodiment of the present invention is shown in
S1: determine the transaction content, the two players negotiate an agreement on the transaction content and determine the conditions and rules of the transaction, specifically:
Alice and Bob negotiate and agree on the transfer data such as asset type and quantity, transaction price, transaction conditions and transaction fees, etc., determine the conditions and rules of the exchange, and generate transaction content m, 510;
Wherein, in step 510, m contains the asset type, quantity, transaction parameter HashType, and exchange rule of the asset that Alice is prepared to transfer to Bob; in step 511; furthermore, m contains some public information, such as the signer's public key. The transaction content m is represented as follows:
m={HashType,scriptPubKey,α,auxiliary data}
Where α is the amount transferred from Alice to Bob on the blockchain; the MSB (Most Significant Bits) of HashType marks indicates whether the receiver confirms that the transaction amount or not. If it is set to “1”
“The receiver's signature on confirmation must be included in the transaction.”
S2: key pair generation, signing the transaction content according to the key pairs generated on the blockchain by the two parties to the transaction; specifically:
In step 520, Alice owning the key pair (skA, pkA) on the blockchain, signs m to obtain signatures σA;
In step 521, Bob owning the key pair (skB, pkB) on the blockchain too, signs m to obtain signature σB.
S3: The two parties exchange signatures and verify each other's signatures. If any verification fails, the transaction is terminated, specifically:
In step 530, Alice sends signature σA to Bob for verifying the transaction contents and consistency. If fails, the transaction is terminated. So does Bob.
S4: Either party constructs the transaction and broadcasts it to the blockchain network, specifically:
In step 540 Bob constructs transaction Tx=<σA,σB,m> and broadcasts the transaction Tx to the blockchain for the fund transferring;
S5: The blockchain validation nodes or miners check the transaction. If the verification is successful, the transaction is packed into the block and recorded on the blockchain, specifically:
In step 550, for transaction Tx, the blockchain node verifies the signature σA of the sender. if the verification fails, transaction Tx is discarded; otherwise, it checks whether the indicator such as the MSB of the HashType field in transaction m is “1”. If positive, further verifies the signature σB of the receiver. If the signature σB of the receiver is successfully verified, the blockchain node packs the transaction Tx into a block such that the transaction Tx will be recorded in the blockchain;
Note that for a multiple-input transaction Tx, if and only if its parent transaction is NULL, the signature is produced by the receiver. The steps depicted in
| Number | Date | Country | Kind |
|---|---|---|---|
| 202311029127.1 | Aug 2023 | CN | national |
