Skip to content

Latest commit

 

History

History
47 lines (35 loc) · 2.02 KB

FAQs.bitcoin-script.md

File metadata and controls

47 lines (35 loc) · 2.02 KB

This Miniscript expression

or_b(pk(key_1),s:pk(key_2))

Bitcoin Script

<key_1>
OP_CHECKSIG
OP_SWAP 
<key_2>
OP_CHECKSIG
OP_BOOLOR

Bitcoin Script as ASCII ART

<key_1> OP_CHECKSIG OP_SWAP <key_2> OP_CHECKSIG OP_BOOLOR
\_________________/   \     \________________/          /
 \       X             \            X       /          /
  \                     \__________________/          /
   \                             Y=s:X               /
    \_______________________________________________/
                         or_b(X,Y)

Explanation

This expression as ASCII ART is a script template commonly used in Bitcoin-like blockchain scripts for multi-signature transactions. Let's break it down:

<key_1> OP_CHECKSIG: This checks if the signature provided matches <key_1>. If it does, it pushes TRUE to the stack. <key_2> OP_CHECKSIG: Similarly, this checks if the signature matches <key_2>, pushing TRUE to the stack if it does. OP_SWAP: This operation swaps the top two items on the stack. Here, it would swap the result of the second OP_CHECKSIG with whatever was on the stack before (likely FALSE if no match, or TRUE if matched). OP_BOOLOR: This operation checks if either of the two boolean values on the stack is TRUE. If at least one is TRUE, it results in TRUE.

The diagram you've drawn illustrates this:

X: Represents the result of OP_CHECKSIG for <key_1>. Y: Represents the result of OP_CHECKSIG for <key_2> after the OP_SWAP.

The final operation or_b(X,Y) (represented by OP_BOOLOR) will be TRUE if either X or Y or both are TRUE.

In simpler terms, this script allows spending from an output if there's a valid signature for either <key_1> or <key_2>. It's essentially an OR condition between the two keys for unlocking the funds.

This setup is often used for scenarios where you might want to give one of two parties the ability to spend funds (like a backup key in case one key is lost), or for more complex smart contract scenarios in blockchain where flexibility in transaction authorization is needed.