Multi-Criteria Blockchain Protocol for Threshold Transaction Unlocking
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing blockchain protocols are limited in their ability to apply threshold restrictions beyond digital signature checks, failing to accommodate scenarios requiring other criteria for transaction unlocking.
Innovation Solution
A binary threshold protocol (BTP) and spectrum threshold protocol (STP) are introduced, allowing multiple criteria to be satisfied, with a counter incrementing each time a criterion is met, and unlocking the transaction only when a predetermined number of criteria are satisfied, enabling flexible and proportional digital asset transfer based on the number of criteria satisfied.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If m-of-n signature checks are used in blockchain protocols, then transaction security is improved, but the protocol cannot accommodate other types of criteria for transaction unlocking
Solution Approach 1:
The output script is designed to perform multiple functions: it can check digital signatures (traditional m-of-n functionality) and simultaneously evaluate other criteria types such as hash pre-images, timestamps, or custom conditions. This universal script structure allows the same blockchain protocol to handle diverse unlocking requirements without sacrificing security.
Solution Approach 2:
The protocol changes the parameters of the verification process by accepting different types of input data (signatures, hash pre-images, timestamps, etc.) and applying appropriate verification methods for each. The output script dynamically adjusts its verification approach based on the criterion type, enabling flexible criteria evaluation while maintaining consistent security standards.
2Device complexity
If traditional blockchain transaction protocols are used, then protocol simplicity is maintained, but complex transaction unlocking conditions cannot be implemented
Solution Approach 1:
The complex transaction unlocking conditions are segmented into multiple independent criterion components, each verified separately by the output script. The script evaluates each criterion (signature verification, hash pre-image validation, timestamp checks, etc.) as an independent unit and aggregates the results. This segmentation allows complex conditions to be implemented while maintaining clear, modular protocol structure.
Solution Approach 2:
The output script acts as an intermediary between the transaction input data and the unlocking logic. It receives various types of input data, performs appropriate verification for each criterion type, and determines whether the overall unlocking condition is met. This intermediary layer handles the complexity internally while presenting a unified interface to the blockchain protocol.
3Adaptability or versatility
If multiple criterion components are added to enable flexible transaction unlocking, then adaptability is improved, but script complexity increases
Solution Approach 1:
The output script is segmented into distinct verification sections, each handling a specific criterion type (signature verification, hash pre-image checking, timestamp validation, etc.). Each section is independently structured and can be evaluated separately. This modular segmentation reduces script complexity by organizing multiple criterion components into clear, manageable sections rather than a monolithic verification block.
Data Source
AI summary
A computer-implemented method of generating a transaction for a blockchain, the transaction being for transferring an amount of a digital asset from a first party to a second party. The method comprises generating a first transaction comprising an output locking the amount of the digital asset, the output comprising an output script comprising a plurality of criterion components each requiring a respective input data item, and a plurality of counter script components. Each criterion component is associated with one of the counter script components. The output script is configured so as to, when executed alongside an input script of a second transaction, i) increment a counter each time a respective criterion component is satisfied by a respective input data item of the input script, and ii) to require the counter to increment to at least a predetermined number in order to be unlocked by the input script.