JP2024042037A - Methods and systems for directing exchanges associated with tokens held anonymously on a blockchain - Google Patents

Abstract

A method and system for controlling the generation of blockchain transactions and/or recipients of transaction outputs is provided. The method identifies at least one transaction (Tx) on a blockchain, the Tx using unspent Tx outputs (UTXOs) associated with a tokenized asset associated with an asset controller and an output from a previous Tx locked by a Redeem script hash, and for each identified Tx, creates an unfinished blockchain Tx, which is communicated to the controller of the asset. The unfinished blockchain Tx is unfinished in that it lacks a required cryptographic signature, and revenue payments associated with the asset are redirected by the controller to a destination of their choice.Selected Figure: Figure 1

Description

TECHNICAL FIELD The present invention relates generally to distributed ledger and blockchain technology, and more particularly to the use of blockchain technology to implement a system for automatic control of computer-implemented processes. The invention also relates to electronic communication and notification technology. One embodiment of the present invention provides for recording and controlling ownership or control of electronic assets via a blockchain, and for generating and accomplishing blockchain transactions in response to current ownership data. Provide solutions. The present invention also provides a new and advantageous solution for controlling and enabling the transmission of electronic communications to recipients. The present invention utilizes blockchain technology to realize storage of recipient addresses or identifiers, allowing privacy and/or security to be extended, and allowing recipients to specify notification addresses stored on the blockchain. and/or allow changes. The invention is suitable for, but not limited to, use with the Bitcoin blockchain.

This specification is intended to encompass all forms of electronic, computer-based distributed ledgers, including, but not limited to, blockchain and transaction chain technologies, permissioned and unauthorized ledgers, shared ledgers, and variations thereof. , we use the term “blockchain”. Although the most widely known use of blockchain technology is the Bitcoin ledger, other blockchain implementations have been proposed and developed. Although Bitcoin is referred to herein for convenience and explanation purposes, the invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the invention. It should be noted that

A blockchain is a consensus-based electronic ledger implemented as a decentralized, computer-based, distributed system composed of blocks. Furthermore, a block is composed of transactions. Each transaction includes at least one input and at least one output. Each block contains a hash of the previous block, and the blocks chain together to create a permanent, immutable record of every transaction written to the blockchain since its inception. A transaction contains small programs known as scripts embedded in its inputs and outputs. A script specifies how and by whom the output of a transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

In order for a transaction to be written to the blockchain, it must be "verified." Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. The software client installed on the node performs this validation task on unused transactions (UTXOs) by executing its own lock and unlock scripts. If the lock and unlock script execution evaluates to true, the transaction is valid and the transaction is written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, the transaction must be i) verified by the first node that received the transaction, and if the transaction is verified, the node relays the transaction to other nodes in the network; ii) added to new blocks constructed by miners; and iii) mined, i.e. added to the public ledger of past transactions.

Blockchain technology is most widely known for its use in cryptocurrency implementation, but digital entrepreneurs are increasingly using it to implement new systems, such as Bitcoin-based cryptocurrency security systems, and data storage that can be stored on blockchains. I'm starting to explore the use of both. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not limited to the realm of cryptocurrencies. Such solutions can take advantage of the benefits of blockchain (e.g., permanent, tamper-resistant records of events, distributed processes, etc.) while being more diverse in their applications.

One area of current research is the use of blockchain for the implementation of "smart contracts." These are machine-readable computer programs designed to automate the execution of the terms of a transaction or agreement. Unlike traditional transactions, which can be described in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce results, and that can cause actions to be performed depending on those results. .

Another area of interest related to blockchain is the use of "tokens" (or "colored coins") for the representation and transfer of real-world entities via blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Thus, tokens serve as identifiers that allow real-world items to be referenced from the blockchain.

Data regarding smart contracts needs to be registered, tracked and recorded. For example, there is a need to record data related to the ownership of assets managed by smart contracts. This is particularly important with respect to smart contracts relating to assets owned by multiple entities, where ownership is divided into shares. In such cases, the transfer of ownership needs to be recorded in a secure manner. It is also important that the associated costs are earned on the asset and/or the income generated and paid therefrom. Another important consideration is that it is often desirable to protect the identities of the real-world parties involved.

Typically, holding a tokenized asset on a blockchain results in an unspent transaction output (UTXO) that is allocated to the current asset holder and determines the scale of that asset holder's current holdings. means that exists. This is encapsulated within the Redeem script needed to transfer the asset and can typically be in the following format:

XOP_CHECKMULTISIG(Metadata-A Metadata-B PublicK-A)Y
However, the information held in the blockchain is not this script, but rather a hash of the script, which means that critical public key information is not available for public viewing.

In some cases, income distributions are paid via the same tokenized instrument as the original asset, for example as a dividend when additional shares within the company are issued. In such cases, public key unavailability is not an issue since the revenue share can simply be paid to the same Redeem script hash as the original issuance transaction.

However, in the more common scenario where income distributions are paid as alternative assets (e.g. BTC dividends for shares), this flaw in public key information means that, according to the current state of technology, the public This means that a separate off-chain database of keys must be maintained. While such a solution is clearly viable, it means that there are two systems (the blockchain and an off-chain database) maintaining the asset register. This injects complexity into the solution and can potentially cause the two databases to become out of sync with each other. This also requires additional storage resources.

Therefore, it is desirable to provide a solution that does at least the following:
- Enabling or enabling the control, influence, or direction of secure transfers to anonymous parties via blockchain;
- removing the requirement for said second database, and thus the risk it poses, by allowing automatic determination of where transfers should be made (e.g. where income should be paid);
- be able to disburse income in a way that ensures that only current asset holders are in a position to claim their funds;
Providing a generic mechanism for generating actions and technical responses (e.g. in response to income generation) in proportion to the current ownership of assets represented and/or referenced via the blockchain ,
Using blockchain transactions to enable secure automatic transfer of assets and recording of such transfers and payments on the blockchain, thus providing benefits such as tamper-resistant records of events and data;
Enables protection of “real world” identities such as asset owners, and the solution enables or should provide anonymity;
- Provide solutions to enable and control electronic communications that need to be sent to "unknown" parties.

Such improved solutions have been devised. The present invention provides at least the above technical effects discussed above.

The invention is defined in the appended claims. According to the invention, therefore, a control method and a corresponding system may be provided.

The method may be a method of controlling the transfer of an entity or item or part thereof. This may be transferred electronically, preferably via a blockchain. An entity or item may, for convenience, be referred to herein as an asset or part of an asset, and may be represented, tokenized, and/or referenced on or via a blockchain. Additionally or alternatively, the invention may be a method of controlling the generation of blockchain transactions. The invention may provide an automatic solution that does not require human intervention for operation.

Additionally or alternatively, the invention may be described as a method of controlling and/or specifying recipients of blockchain transaction output. The invention may be described as a method of controlling, directing, and/or influencing transfers via a blockchain. The transfer may relate to an asset or part of a cryptocurrency or fund and/or some other resource via a blockchain. This may be the transfer of control, such as an item, from the output of one transaction to the input of another transaction. This may be a method of redirecting such transfers.

Blockchain transactions may relate to or be associated with assets represented on the blockchain. The asset may be a tokenized asset. Assets may be associated with (smart) contracts.

The method includes the steps of identifying at least one transaction (Tx) on a blockchain, the transaction comprising an unspent transaction output (UTXO) associated with a tokenized asset associated with an asset controller and a Redeem script. and input using output from a previous transaction locked by a hash.

The method includes the steps of: generating an incomplete blockchain transaction for each identified transaction (Tx), the incomplete blockchain transaction comprising:
a first output containing a copy of the Redeem script hash;
a second output, the second output being modifiable such that only the asset controller can specify recipients of the second output.

The controller of an asset may be the owner or some other entity associated with the asset. An asset controller may be a real-world controller or a computational resource representing an owner. Computational resources may be automated agents. Assets may be represented on the blockchain as tokens (or "colored coins") provided in the metadata of transaction scripts.

Recipients may be designated using cryptographic keys.

The blockchain may be the Bitcoin blockchain or an alternative implementation of an electronic distributed ledger.

The method may further include sending the incomplete blockchain transaction to a controller of the asset.

An incomplete blockchain transaction may be incomplete in that it lacks the required cryptographic signature.

Unfinished transactions are
inputs that use unused transaction outputs (UTXOs); and/or
an input that uses the output of another transaction to transfer an amount of value or currency to an asset controller;
may further include.

The method may further include modifying the second output of the incomplete transaction to include the cryptographic signature. The modifying step may be performed by the asset controller.

Identifying at least one transaction (Tx) may involve or include traversing the blockchain until reaching a blockchain transaction that includes an unused output (UTXO) associated with the asset.

At least one step of the method may be performed by an autonomous computing agent.

The method may further include completing and/or modifying the outstanding transaction by specifying a recipient of the second output. Additionally or alternatively, the method may include submitting the incomplete transaction to the blockchain.

Incomplete transactions may be configured such that their outputs may be changed. An incomplete transaction may include a signature type that requires all inputs to be signed but no outputs to be signed. The signature type may be the Bitcoin SIGHASH_NONE signature type, or a substantially functionally equivalent signature type in another blockchain protocol, allowing the signature type to effectuate or enable modification of transaction output.

The method may further include using unused transaction output (UTXO) to transfer the tokenized asset to the recipient address.

The method may further include using the output of the previous transaction to transfer or reissue ownership of the asset.

The cryptocurrency amount associated with the second output may be calculated by computational resources according to rules provided within the smart contract.

The second output of the incomplete transaction, when used, may transfer an amount of currency or value to the recipient. This currency or value may be any type of resource. This may be, for example, an amount of cryptocurrency or some tokenized fund or other product.

The invention also provides a corresponding system. The system may be configured to carry out the steps of any preceding claims.

the system,
blockchain and
at least one autonomous computational agent,
traverse the blockchain, and/or
generate an incomplete transaction, and/or
Send incomplete transactions to recipients,
and at least one autonomous computing agent configured to.

Additionally or alternatively, the invention may include one or more steps configured to control, direct, or influence the transmission of electronic communications. Accordingly, the method of the present invention may be described as a method of establishing an electronic communication channel between two or more parties.

Additionally or alternatively, the present invention may be configured to effectuate and/or enable completion of incomplete blockchain transactions. Accordingly, the invention may be described as a method of controlling or influencing the validity and/or propagation of blockchain transactions on a blockchain network.

Accordingly, the terms "communication," "notification," and "alert" may be used interchangeably.

Accordingly, the present invention may provide a method of controlling and/or generating electronic communications. Additionally or alternatively, the present invention may provide a solution for determining the destination or recipient of an electronic communication/transmission. This can be a blockchain implemented solution. The invention may be a method/system configured to enable (electronic, off-blockchain) communication with anonymous or semi-anonymous recipients. This recipient may for example be an asset owner or a controller, although the invention is not limited in this respect. Communications may be sent using information stored or “embedded” within the sequence of blockchain transactions. The invention may be described as a method of addressing and/or determining the destination of electronic communications via a blockchain.

The method may include sending a signal to the address. The address may be a notification address. The signal may be called or serve the function of an (electronic) notification or communication.

The invention is not limited with respect to the context, purpose, or content of the notification.

The doctor may be provided as metadata within the unlock script associated with the input of the transaction (Tx ₁ ) on the blockchain. The term "identifier" may be used synonymously with "address." This sending step may be triggered by an event. Events may be specified, determined, or influenced by smart contracts. Sending the notification may be performed by a computer-based resource. This may be performed at least as part of an automated process.

Notifications may serve as requests and/or triggers for completion of outstanding transactions. The method may include completing incomplete transactions. Completion may include providing a cryptographic signature.

An unlock script may be provided to use the output from further transactions (Tx ₂ ) on the blockchain. (This may be a "preceding" transaction on the blockchain in the sense that the input of transaction Tx ₁ may use the output of transaction Tx _2. )
Accordingly, the invention may include the step of requiring provision of a notification address within the unlock script in order to unlock the lock script. This step may be repeated. Accordingly, a sequence of notification addresses may be requested and provided. A notification address may be required to use each output in a chain of blockchain transactions. This allows provision of different addresses over time. Thus, the present invention enables and enables modification of recipient addresses for notifications.

The input of the transaction (Tx ₁ ) and/or the output of the further transaction (Tx ₂ ) may be associated with a tokenized asset represented on or referenced via the blockchain. This token may be referred to as a "colored coin".

The electronic notification may include incomplete or completed blockchain transactions and/or information related to incomplete or completed blockchain transactions.

This may be incomplete in that the requested piece of data is missing.

This may include information regarding the location of completed/incomplete transactions or how to access them.

The notification address may be associated with an asset or resource represented on the blockchain or a controller of an asset or resource represented on the blockchain. The controller may be the same or a different entity than the actual ("real world") owner of the asset.

The method may further include traversing the blockchain to identify the transaction Tx ₁ or a further transaction Tx _2. Those skilled in the art will understand how this traversal can be performed as known techniques.

The method includes the steps of submitting a transaction to a blockchain, wherein the transaction (Tx ₁ ) is a Redeem script that requests provision of a notification address in metadata of the unlock script to use the output (UTXO). including an unused output (UTXO) containing a UTXO.

Unspent Outputs (UTXOs) may transfer ownership of or otherwise relate to tokenized assets represented on or referenced via a blockchain.

The notification address may be provided as a parameter in the unlock script of the transaction (Tx ₁ ). This may be provided as a second parameter.

The method may include using a Redeem script to ensure that the notification address is provided in the unlock script. The Redeem script may include a value indicating how many notification addresses must be provided by the unlock script.

Multiple notification addresses may be provided within the unlock script.

The notification address may be a network address, a cryptographic key, a uniform resource locator (URI), an email address, or any other address or identifier that is represented within the script's metadata and that can be used as a destination for electronic communications. . Thus, the notification address may serve as an identifier for the recipient of the notification/communication.

At least one step of the method may be performed by an automated computing resource or agent. This may be called a "bot" or "oracle."

The method and/or system may be substantially as described below in the section entitled "Notification Addresses Embedded within the Blockchain."

The invention may further provide a computer-implemented system arranged and configured to perform the steps of any embodiment of the method described herein.

the system,
blockchain and
at least one autonomous computational agent,
traverse the blockchain, and/or
generate and/or send electronic notices;
and at least one autonomous computing agent configured to.

Any features described in relation to the method may also be applicable to the system, and vice versa. Any feature described above with respect to one embodiment or aspect may be present in any other embodiment or aspect of the invention.

The invention may be substantially as described in the illustrative embodiments set forth in the following Examples, Description, and Figures. The above-mentioned and other aspects of the invention are apparent from and taught with reference to the embodiments described herein.

Embodiments of the invention will be described below, by way of example only, with reference to the accompanying drawings, in which: FIG.

1 provides a summary of illustrative embodiments of the invention. Provides a description of the traversal logic utilized when iterating on the blockchain to determine the current ownership of an asset. 3 provides a description of the transaction outputs required according to one embodiment of the present invention. Provides a description of the construction of an initial incomplete blockchain transaction. 4 provides an illustration of the outstanding transaction of FIG. 4 after it has been modified and completed by the asset controller. Provides a description of one embodiment of the present invention in which a notification is sent to an asset controller to notify the asset controller that there are outstanding transactions that require attention and modification. 3 illustrates an illustration of a usage example model according to an embodiment of the invention. Provides a blockchain transaction number 100.10 related to the example provided below that may be used to generate shares among assets represented on the blockchain. Provides a blockchain transaction number 100.120 related to the example provided below that may be used to issue shares of an asset to a recipient. Note that the notification address is specified as a requirement in ScriptSig. This allows the recipient (i.e., asset owner or controller) to provide the notification address as metadata in the unlock script when "claiming" the share via input in a later transaction. Provides a blockchain transaction number 150.10 that can be used to transfer ownership of a portion of an asset to a recipient. In this case, the current asset controller retains some parts of the asset and assigns or transfers other parts to other parties. Provides an incomplete blockchain transaction number 400.1 that may be generated in connection with the example provided below. When modified by the asset controller, it provides blockchain transaction number 400.10, which is the completed version of the incomplete transaction shown in FIG.

The present invention provides a versatile solution that enables control of secure transfer of digital entities via inputs and outputs of blockchain transactions. In the example provided herein, the present invention provides a method for controlling assets registered on a blockchain according to the terms of the underlying investment contract, e.g. in direct proportion to how ownership of the asset is divided. Discussed for illustrative purposes only in the context of paying revenue or accrued costs. For example, if an asset is divided into 100 shares, the income payable may be calculated for each share.

However, it is important to note that the present invention is not limited to such use case scenarios, but rather provides a more general transport control and notification solution that can be utilized to advantage in a variety of applications and situations.

<Main terms>
This technical specification uses the following terminology to define key concepts and components throughout.

As shown herein, the present invention provides an automatic, secure and robust mechanism that allows at least the following:
- the ability to determine the current ownership of an asset from a blockchain (such as the Bitcoin blockchain);
- the ability to control the transmission of electronic communications to unknown parties related to assets;
• the ability to pay the income generated by the asset in proportion to the current ownership of the asset;

In the latter two, this process can be used to advantage if assets maintain a separate ownership database or if ownership is hidden by the blockchain through the use of (payment) addresses.

The present invention provides at least two advantageous aspects.
1) The ability to make payments to owners of assets via the blockchain, where the owners are unknown and anonymous to the assets;
2) The ability to notify anonymous owners using information stored in a sequence of blockchain transactions.

<Determination of current ownership of assets represented on blockchain>
In order to allocate costs/income for an asset represented on a blockchain, it is necessary to be able to determine the current ownership of the asset. There are two mechanisms by which this can be achieved.
- Ownership may be maintained in a separate register that is maintained off-chain by the asset (and updated by having transfers countersigned by the asset). This mechanism is ideal for regulated assets where formal "Know Your Customer" rules apply.
- Ownership can be determined by scanning transactions on the blockchain to dynamically generate a current ownership list. Note that this approach does not determine ownership itself, but identifies the Bitcoin address responsible for the asset. This may be referred to as an "asset controller" which may or may not be the actual owner. This blockchain traversal technique is used by the present invention.

<Generation of actions related to ownership, e.g. calculation and payment of income>
to pay the income from the asset in proportion to the current ownership of the asset;
・The asset must have the ability to determine current ownership;
-The asset must be capable of recording total income for a given period;
Assets must be income divisible between current ownership;
-The asset must be able to offset costs from income;
-The asset must be able to retain income if previous costs have not been paid;
- The asset must be capable of triggering the payment of income to the current asset holder.

This income may arrive at the end of a time period (eg, every six months) or as it is generated (eg, immediately). Depending on the characteristics of the contract, the same terms may enable the proportional payment of income by some contracts and only enable payments to current holders for a certain period of time.

<Technical solutions>
The technical solution provided by the present invention provides a mechanism by which an investment or asset controller, through an agent or smart contract, can generate a set of payment transactions to both recover its costs or pay out its revenues. The solution relies on an automated oracle (or multiple oracles depending on the structure of the underlying contract) that is triggered by an off-chain condition. For example, this condition can be the date on which a reward is to be paid. When this trigger condition is activated, the oracle:
Calculate the total payment for the assets as a whole,
Calculate individual payments across the current ownership shares of the asset based on a payment rule (e.g., pro rata);
Generate payment transactions for each individual asset holder.

Figure 1 shows the basic flow of how the technical solution determines the individual payments to generate.

The steps in the flowchart of FIG. 1 are defined in more detail in the following sections.

<Traversing the blockchain from issuing transactions>
To determine the current position (ownership) of a share within an asset, the associated oracle can traverse the blockchain from the initial issuance transaction to determine where the current share of the asset currently resides. There is a need. The issue transaction is referred to as the "anchor transaction" in FIG. FIG. 2 shows an example transaction chain that may be used during such a traversal. Essentially, this process involves following the trail from transaction to transaction on the blockchain until the oracle finds the UTXO associated with the asset. When this output is not used, this indicates that the asset controller that uses the last input in the asset should still be the controller. Therefore, traversal processing may stop at this transaction.

Each individual issue or transfer transaction output has an associated Redeem script. The fact that the transaction output is unused makes it difficult for Oracle to determine which Redeem script was used to consume the output from the previous transaction and therefore what proportion of the asset it "owns" at any given time. can be determined.

<Generate distribution payment>
Knowing the Redeem script, the revenue sharing transaction can take advantage of the SIGHASH_NONE ability to redirect output only in ways that the Redeem script's controller can change. For this purpose, a distribution transaction needs to be constructed as shown in FIG.

A distribution transaction has two outputs.
1) the output to be sent back (reissued) to the current controller so that the next time the traversal process is performed, the same controller is determined to be the current controller;
2) Output of transferring several electronic funds to the controller.

A reissue output can be constructed because it can simply reproduce (or copy) the Redeem script hash from the previous issue/transfer transaction.

However, based on the number of signatures required and because the lock script for the income payment to A cannot be constructed at the time of construction, it is not possible to construct the distribution transaction in one step.

To solve this, a distribution transaction is first constructed and broadcast in the format shown in FIG.

Any one of the outputs can be changed by setting the signature hash to the input to SIGHASH_NONE. (Note: one or more embodiments of the invention may be implemented on protocols other than the Bitcoin protocol. It is important that the outputs are configured such that they are modifiable.) However, the last By locking it inside the issuance transaction, the rightful owner of the asset is required to sign the input (and clearly won't do so unless they are interested), so only they can make changes. can. Note that there is no need for a signature to be provided at the final asset issuance/transfer to the transaction. As shown in Figure 4, assuming the asset issuer is a countersigner of any transfer transaction, if they were not present, this transaction would simply be a signature on the proceeds for distribution to achieve the same effect. are combined using

<Redirect distribution payments>
When the current asset owner receives an incomplete template transaction, they decide that it is of most interest to them and add the last asset to the transaction after modifying the income payment transaction to pay the income to themselves. Complete the transaction by signing the issue/transfer input. This modified completed transaction is shown in FIG. The transaction is completed here, so it can be mined.

Thus, the outcome is achieved without the requirement to know about the underlying ownership of an asset other than the ownership share of the asset contained in the blockchain record itself.

<Need for notification>
As mentioned above, a payment distribution transaction is initially generated in an incomplete format. This then needs to be communicated in some way to the asset controller so that the asset controller becomes aware of the existence of the transaction, makes the necessary changes to complete the transaction, and submits it to the blockchain. do.

However, incomplete transactions cannot be broadcast via the blockchain itself. This is because, by default, blockchain propagation nodes do not propagate incomplete transactions across the network. Since the original version of the distribution transaction is incomplete (missing the signature), there is no hope that the controller/owner will be able to receive the incomplete transaction and apply the signature before it is dropped by the network. This does not affect the ownership of the asset, but it does mean that the associated parties are not paid the income they receive.

Therefore, there are technical issues that need to be overcome, namely how to communicate an incomplete blockchain transaction (Tx) (or its existence) to a recipient when the recipient's identity and/or other information is unknown. There is a question of whether to do so. To solve this technical problem, there needs to be a channel available to broadcast this incomplete transaction to interested parties or at least make interested parties aware of the existence and/or location of the incomplete transaction.

There are various possible ways to solve this, including:
- A contract may expose a "broadcast" channel as part of the contract. On the broadcast channel, all outstanding transactions are broadcast by asset owners who listen to the channel and react to them to determine transactions of interest. This publish/subscribe mechanism is a standard IT feature.
- Sale or other transfer of an asset causes the new asset owner/controller to lock the notification address to the sale transaction. This allows the communication channel to be set up without any other information about the asset owner/controller being known. The asset then uses this private channel to send the unfinished transaction to the current owner or to notify them that the transaction is available for download and later completion from an accessible location. Notice.

None of these solutions affect or impact the first aspect of the invention described above in that the asset still knows no ownership of the asset itself other than the information held on the blockchain itself. In the example below, the transaction utilizes the second option for transaction notification. This notification technique forms a second novel aspect of the invention and provides privacy or anonymity of transaction information.

<Notification address embedded in blockchain>
This aspect of the invention provides a solution to the propagation problem identified above by enabling the ability to embed notification addresses within blockchain transactions. The notification address is therefore available for later notification. This chapter explains how this model works.

Notifications may take any suitable form, such as e-mail. In such a case, an email may be sent to the email address that was embedded in the previous transaction. However, other forms of electronic communication known in the art are also encompassed within the scope of the present invention. Essentially, the identifier captured in the initial transaction serves as the address or location to which notifications are sent.

Note that this notification technique can be used to advantage as a solution to the problem, both on its own and with respect to a wide range of situations and applications, independently of the first aspect of the invention described above. .

In our example, however, the role of the notification address is that when the author of a given target transaction has no other information about the relevant interested parties, the relevant interested parties may send their signature to the target transaction. It is to ensure that transactions can be notified to apply (and to make other changes).

This solution means that the communication can be sent to the recipient without any further information having to be provided or known. The present invention thus provides enhanced alert, notification, or communication techniques that protect or enhance privacy and security. No additional information about the recipient is required other than the address provided within the transaction script and then extracted from the transaction script. This itself lends itself to being carried out by automated processes such as bots.

Sending a notification to a specified address may be triggered by an event. Events may be specified within or affected by a smart contract.

A notification may simply be a signal sent to an address and/or may include predetermined content. Therefore, the desired information message can be transmitted. Additionally or alternatively, receipt of the notification may serve as a signal to an automated process, thus triggering a predetermined or programmed response, such as providing a signature for a transaction or performing some other action. .

The invention is not limited as to the content of notification messages sent to embedded addresses. The notification may include a copy of the outstanding transaction in some cases. In our example, however, the role of the notification address is that when the author of a given target transaction has no other information about the associated interested entity (human or computer-based resource), (which may be) can be notified or alerted of the need to apply their signature (and make other changes) to the target transaction. In fact, the invention therefore enables future blockchain transactions to be fulfilled and completed. By providing the necessary signatures, a partially invalid transaction is converted into a valid, executable transaction that can be accepted by the blockchain. The invention therefore solves the problem of how to control, realize and/or enable the validity of a blockchain transaction and its propagation on a blockchain network.

For this purpose, a "seed" transaction needs to be generated that forces the capture of the notification address in all subsequent transactions. This may typically be before the issuance transaction (for standard tokenization transactions). This issue or "source" transaction requires additional attributes to be provided on the unlock script, including the notification address. The complete flow of this process is shown in FIG.

<Notification Redeem script>
The main format of the unlock script is as follows.

As you can see from the structure above, the elements shown in boxes represent standard scripts, but with new prefixes. This prefix takes the form shown here.

This particular example means that <Count of notification addresses> can range from 1 to 4, but the structure can be extended to support different maximum values if required. do. This script prefix effectively drops the associated notification address from the stack and then checks to ensure that the number of notification addresses matches the number that should be present.

<Usage example model>
The model provided in Figure 7 illustrates the primary use cases that fall within the scope of the non-debt lending model.

<[100] Issuing shares>
The asset issues shares among itself to the appropriate asset holders and ensures that the entity's notification address is captured during the issuance. Here, the primary entity is the asset.

<Main success scenarios>
This step is only necessary if the current holder notification details are kept on the blockchain itself.

The share generation transaction is shown in FIG. 8 as transaction 100.10.

The complete Redeem script for output 1 of transaction 100.10 is shown below.

OP_DROP OP_CHECKSIG
The share issue transaction is shown in FIG. 9 as transaction 100.20.

The complete Redeem script for output 1 of transaction 100.20 is shown below.

This example Redeem script allows a subsequent sale to transfer ownership to up to four buyers, which may require multiple transactions if the purchase involves more than four buyers. Note that it is clearly possible to extend (or limit) the possible number of new purchases by repeating (or reducing) the "if" blocks in the above script.

＜[150] Selling shares＞
An asset owner must sell a percentage of its equity to another interested party, where the primary entity is the asset owner.

Key success scenarios:

This produces a number of key features that are essential to support the underlying income distribution.
- Sales are only possible to a maximum of 4 new holders (eg 4 output transactions, but could be any number from 1 to 4).
- If the sale involves the withholding of a portion of the shares, only three new holders can be supported as only the slots are returned to the current holders for reallocation.

<Transaction 150.10>
In the example transaction 150.10 provided in FIG. 10, the transaction implements a partial sale by the current asset holder holding one stake and selling one other stake to a new holder. do. Note that in real-world scenarios, additional inputs may be required to cover mining fees. This is ignored in the template of Figure 10, and transaction 150.10 improves readability.

The output Redeem script of transaction 150.10 (Figure 10) is the same as that of transaction 100.20 (Figure 9), except that the public key is:

<PubK-SecondaryAssetHolder> and <PubK-Asset>
This Redeem script for output 2 of transaction 150.10 (FIG. 10) is completely identical to that of transaction 100.20 (FIG. 9).

<[200] Determination of ownership>
The asset needs to determine how to allocate the proceeds of the payment to the current asset holders, even if the asset is not aware of the current asset holders. The primary subject of this action is the asset.

Key success scenarios:

<[300] Calculate payment>
Here, the asset wishes to calculate the amount of income owed to its current owner. The primary subject of this action is the asset.

Key success scenarios:

<[400] Payment of income>
Here, assets wish to pay income to their owners in proportion to their ownership. The primary entity is the asset.

Key success scenarios:

Transaction 400.10 - Interim (incomplete) transaction is shown in FIG. Transaction 400.10 - Final (Complete Transaction) is shown in FIG. In FIG. 12, changes are shown in bold for clarity.

<Illustrative scenario: Asset equity capital>
The main type of scenario supported by this model is traditional equity capital for assets such as companies. A company (NewCo plc) issues a fixed amount of freely tradable shares (1000) from which income is paid periodically (annually). When revenue distribution represents a company's profits, there is no requirement to support the collection of costs from the asset holder base (profits have already offset costs from them).

<Main advantages of the present invention include>
The present invention enables autonomous activity on the blockchain, allowing income/cost payable entities to be created without the need to maintain a separate off-chain ownership database (except for legal reasons). enable.

The present invention allows a notification address or identifier to be embedded within a transaction, specifically within the script of the transaction.

The present invention thus provides enhanced privacy, security, and communication, which is particularly advantageous in applications related to controlling and recording transfers of assets and/or funds over a blockchain.

It should be noted that the embodiments described above do not limit the invention, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word ``comprising'' or ``comprises'' does not exclude the presence of elements or steps other than those listed in a claim or in the specification as a whole. As used herein, "comprises" means "includes or consists of", and "comprising" means "including" or "consists of". ” means. A singular reference to an element does not exclude the presence of a plurality of that element, and vice versa. The invention may be implemented in hardware having a plurality of separate elements or by a suitably programmed computer. In the device claim enumerating several means, several of these means can be embodied by one and the same item of hardware. The mere fact that certain quantities are recited in mutually different dependent claims does not indicate that a combination of these quantities cannot be used to advantage.

In addition to the above, the following notes are also disclosed:
(Appendix 1)
1. A method of controlling transfers over a blockchain, the method comprising:
Identifying at least one transaction (Tx) on the blockchain, said transaction comprising:
Unspent Transaction Outputs (UTXOs) related to tokenized assets associated with the asset controller; and
An input using an output from a previous transaction locked by the Redeem script hash; and
and
For each identified transaction (Tx), generating an uncompleted blockchain transaction, the uncompleted blockchain transaction comprising:
a first output including a copy of the Redeem script hash; and
a second output, the second output being modifiable so that only the asset controller can specify a recipient of the second output;
and
The method includes:
(Appendix 2)
sending the uncompleted blockchain transaction to the controller of the asset;
2. The method of claim 1, further comprising:
(Appendix 3)
3. The method of claim 1 or 2, wherein the incomplete blockchain transaction is incomplete in that it lacks a required cryptographic signature.
(Appendix 4)
The incomplete transaction is
inputs using said unspent transaction outputs (UTXOs); and/or
an input that uses the output of another transaction to transfer an amount of value or currency to the asset controller;
4. The method of any one of claims 1 to 3, further comprising:
(Appendix 5)
modifying the second output of the pending transaction to include a cryptographic signature;
5. The method of any one of claims 1 to 4, further comprising:
(Appendix 6)
and identifying at least one transaction (Tx) comprises traversing the blockchain until reaching a blockchain transaction that includes an unspent output (UTXO) associated with the asset.
6. The method according to any one of claims 1 to 5.
(Appendix 7)
7. The method of any one of claims 1 to 6, wherein at least one step of the method of any one of claims 1 to 6 is performed by an autonomous computing agent.
(Appendix 8)
completing the outstanding transaction by designating a recipient of the second output;
submitting the completed transaction to the blockchain;
8. The method of any one of claims 1 to 7, further comprising:
(Appendix 9)
9. The method of claim 8, wherein the recipient is specified using an encryption key.
(Appendix 10)
10. The method of any one of claims 1 to 9, wherein the assets are represented on the blockchain as tokens provided in metadata in a script.
(Appendix 11)
11. The method of any one of claims 1 to 10, wherein the pending transaction includes a signature type that requires all inputs to be signed but none of the outputs to be signed, preferably the signature type is the Bitcoin SIGHASH_NONE signature type or a signature type functionally equivalent to an alternative blockchain protocol.
(Appendix 12)
using the unspent transaction output (UTXO) to transfer the tokenized assets to a recipient address;
12. The method of any one of claims 1 to 11, further comprising:
(Appendix 13)
using the output of the previous transaction to transfer ownership of or reissue the asset;
13. The method of any one of claims 1 to 12, further comprising:
(Appendix 14)
14. The method of any one of claims 1 to 13, wherein the cryptocurrency amount associated with the second output is calculated by computational resources according to one or more rules provided in a smart contract.
(Appendix 15)
15. The method of any one of claims 1 to 14, wherein the second output of the uncompleted transaction, when spent, transfers an amount of currency or value, such as cryptocurrency or tokenized funds, to a recipient.
(Appendix 16)
sending a signal and/or an electronic notification to a notification address provided as metadata in an unlock script of an input of a transaction (Tx ₁ ) on a blockchain;
16. The method of any one of claims 1 to 15, further comprising:
(Appendix 17)
17. The method of claim 16, wherein the signal or notification provides a prompt, trigger, or warning to a recipient associated with the uncompleted transaction.
(Appendix 18)
in response to said signal or notification, modifying said pending blockchain transaction, preferably including providing at least one cryptographic signature;
18. The method of claim 16 or 17, comprising:
(Appendix 19)
The signal or electronic notification may:
the incomplete blockchain transaction; and/or
Information relating to the location of, or means of accessing, the pending blockchain transaction; and/or
Information relating to the uncompleted blockchain transaction;
19. The method of any one of claims 16 to 18, comprising:
(Appendix 20)
20. A computer-implemented system arranged and configured to perform the steps of any one of claims 1 to 19.
(Appendix 21)
The system comprises:
Blockchain and
at least one autonomous computational agent,
traversing the blockchain; and/or
Creating the uncompleted transaction; and/or
Sending the pending transaction to a recipient;
At least one autonomous computational agent configured to:
21. The system of claim 20, comprising:

Claims (11)

A method for controlling transfer via a blockchain, the method comprising:
finding an anchor transaction;
traversing transaction history to determine a current set of unused transaction outputs (UTXOs);
generating a distribution transaction related to the asset for the determined UTXO;
broadcasting the distribution transaction;
redirecting distribution transactions by an asset owner to a selected key of the asset owner;
publishing the distribution transaction on the blockchain;
method including. Traversing the transaction history includes searching all uses of the asset starting from the time of issuance to determine the current unused output (UTXO) that determines the current location/ownership of the asset. 2. The method of claim 1, comprising the step of: The method of claim 1, wherein the step of generating a distribution transaction includes the step of generating and broadcasting an incomplete transaction. The method of claim 3, wherein the transaction in an incomplete state is missing a primary transaction signature. 2. The method of claim 1, wherein a broadcast channel broadcasts all outstanding transactions to be broadcast, and owners of the assets listen to the broadcast channel to determine transactions of their interest. 2. The method of claim 1, further comprising: upon sale or other transfer of the asset, a new asset owner locks a notification address to the sale transaction. 7. The method of claim 6, wherein sending a notification to the notification address is triggered by an event. 8. The method of claim 7, wherein the event is specified in a smart contra. The method of claim 7, wherein the notification includes a copy of the incomplete transaction. a step of selling a proportion of assets,
capturing the buyer's notification address;
generating a resale transaction template;
countersigning the distribution transaction with the asset;
publishing the distribution transaction on the blockchain;
2. The method of claim 1, further comprising the step of: A system,
blockchain and
at least one autonomous computational agent,
traversing the blockchain, and/or
generate an incomplete transaction, and/or
transmitting the incomplete transaction to a recipient;
at least one autonomous computing agent arranged and configured to
system containing.

Images