LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • Abstract
  • Motivation
  • Specification
  • Implementations
  • Commentary
  • References

Was this helpful?

Edit on GitHub
Export as PDF
  1. Scripts

Push TX

Abstract

Push TX is a technique that enables users to enforce and access transactional states and conditions within Bitcoin script using ECDSA signature messages. It allows for the enforcement of several transaction elements, such as the number of inputs, nSequence values, input and output values, and script conditions, as well as the ability to specify the script into which tokens will be spent. The Push TX algorithm works by pushing the transaction pre-image message that generates the signature onto the stack as part of the input's unlocking script. This message can be pushed as a single contiguous blob, multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's locking script. The signature is then computed on-chain within the script and checked against the public key using OP_CHECKSIG to ensure the current transaction is valid. This standard outlines the motivation and specifications for implementing the Push TX technique within Bitcoin script.

Motivation

The Push TX technique offers several benefits to Bitcoin users and developers. Firstly, it allows for the enforcement of complex transactional states and conditions at the consensus layer, making it easier to create Turing complete machines within the Bitcoin ecosystem. This is achieved by enabling users to specify the script into which tokens will be spent, which can be used to enforce next state conditions. Additionally, it enables users to specify and enforce various transaction elements, such as input and output values, nSequence values, and the nLocktime condition. This improves the security and efficiency of Bitcoin transactions by ensuring that all transactional conditions are met and enforced at the consensus layer.

Specification

The Push TX algorithm works as follows:

  1. The user or process that is using the UTXO pushes the transaction pre-image message that generates the signature onto the stack as part of the unlocking script. This message can be pushed as a single contiguous blob, multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's locking script.

  2. The algorithm pushes the current transaction onto the stack.

  3. The algorithm pushes a dummy private key onto the stack.

  4. Using the transaction and private key pushed in steps 2 and 3, the algorithm generates an ECDSA signature on-chain within the script.

  5. The algorithm pushes the public key derived from the private key onto the stack.

  6. The algorithm uses OP_CHECKSIG to check the signature against the public key, ensuring that the current transaction is valid.

The Push TX algorithm can be used to enforce several elements of the transaction, including but not limited to the number of inputs, nSequence values, input and output values, and script conditions, as well as the ability to specify the script into which tokens will be spent.

Implementations

Commentary

Bitcoin script is often misunderstood as being limited to the data provided in the locking and unlocking scripts. However, the Push TX technique allows for the inspection of the entire transaction within a contract itself, including all inputs and outputs. This opens up boundless possibilities for smart contracts on Bitcoin.

The ability to place arbitrary constraints on inputs and outputs within a contract means that a wide range of use cases can be implemented on Bitcoin. For example, contracts that enforce multi-signature transactions or time-based restrictions can be easily created using Push TX. Additionally, the technique enables the creation of more complex contracts that can enforce next state conditions, making it possible to create Turing complete machines within the Bitcoin ecosystem.

The high-level functionality of Push TX is relatively simple: it allows for the inspection and enforcement of transactional states and conditions within Bitcoin script. However, the implications of this functionality are far-reaching, as it enables the creation of a wide range of smart contracts and decentralized applications on the Bitcoin blockchain. This is important for Bitcoin because it expands its use cases and makes it a more versatile platform for developers and businesses looking to leverage blockchain technology.

References

PreviousPay to True ReturnNextBare Multi-Signature

Last updated 1 year ago

Was this helpful?

This has been .

implemented in the sCrypt ecosystem
nChain WP-1605
Xiaohui Liu Article