bitcoin-dev

Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)

Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)

Original Postby David A. Harding

Posted on: May 6, 2024 07:39 UTC

Dave's inquiry to Andrew Poelstra revolves around the concept of covenants in Bitcoin scripting and their execution mechanics, particularly focusing on the utilization of Lamport signatures in tandem with ECDSA signatures for creating a covenant-like behavior.

Dave is puzzled about how Lamport signatures, which are designed to commit to the size of an ECDSA signature (notwithstanding its variable nature), can facilitate covenant functionality given that ECDSA signatures themselves are committed to spending transactions. This relationship seemingly introduces a circular dependency, as the ECDSA signature is contingent upon the transaction that spends it, which in turn depends on the previous transaction's txid and script.

Andrew Poelstra previously outlined that a crucial component for establishing covenants within Bitcoin's scripting environment is the ability for scripts to introspect - to assess and impose restrictions on future transactions based on the current transaction's details. However, Dave points out a potential limitation in achieving this introspection through Lamport signatures since these signatures are inherently designed to pre-commit to ECDSA signatures' sizes rather than their specific content. This pre-commitment does not naturally accommodate the dynamic and unknown aspects of a transaction that would be necessary for a script to effectively restrict future spending conditions (the scriptPubKey of the transaction that spends it).

The conversation highlights a technical challenge in implementing covenants through the existing capabilities of Bitcoin's scripting language, particularly regarding the use of Lamport and ECDSA signatures. The issue at hand involves developing a method that allows for effective transaction introspection without falling into a circular dependency trap, where the commitment to a future transaction's specifics cannot be known at the time of creating the script due to the inherent sequential dependency of transactions within the blockchain.

For further reading on Andrew's preliminary description of the mechanism required for covenants and the role of OP_CHECKSIGFROMSTACK, interested parties can refer to the provided link. This source may offer additional insights into the theoretical underpinnings and proposed implementations of such scripting capabilities within the Bitcoin ecosystem, shedding light on ongoing discussions and development efforts aimed at enhancing the flexibility and security of Bitcoin transactions through advanced scripting mechanisms.