33 releases

0.10.0 Apr 26, 2023
0.10.0-alpha.1 Mar 24, 2023
0.9.1 Apr 11, 2023
0.9.0-rc.1 Dec 25, 2022
0.5.0 Nov 23, 2021

#165 in #wallet

Download history 134/week @ 2023-12-18 68/week @ 2023-12-25 18/week @ 2024-01-01 97/week @ 2024-01-08 162/week @ 2024-01-15 81/week @ 2024-01-22 30/week @ 2024-01-29 63/week @ 2024-02-05 76/week @ 2024-02-12 151/week @ 2024-02-19 171/week @ 2024-02-26 136/week @ 2024-03-04 301/week @ 2024-03-11 435/week @ 2024-03-18 182/week @ 2024-03-25 579/week @ 2024-04-01

1,530 downloads per month
Used in 42 crates (13 directly)


2.5K SLoC

Bitcoin Protocol Foundation Library

A collection of Bitcoin crates implementing the foundations of the Bitcoin protocol.

These are alternatives to the bitcoin crate or experiments with vision to be integrated into the bitcoin crate.


Bitcoin script types

Bitcoin doesn't make a distinction between Bitcoin script coming from different sources, like scriptPubKey in transaction output or witness and scriptSig in transaction input. There are many other possible script containers for Bitcoin script: redeem script, witness script, taproot leaf bitcoin_scripts of different versions. In fact, any "script" of bitcoin::Script type can be used for inputs and outputs. What is a valid script for in one context will not be a valid script for some other. That would mean that in principle with existing bitcoin::Script type every input script can be used as an output script, leading to potentially harmful code coming from an unaware developer.

While all bitcoin::Scripts have the same parsing rules converting byte string into a set of instructions (i.e. the same syntax), there are multiple ways how the consensus meaning of these instructions will be interpreted under different contexts (different semantics). Moreover, the bitcoin_scripts may be nested - or to be committed into some other Bitcoin script – in a nested structures like in several layers, like redeemScript inside of scriptSig used for P2SH, or tapScript within witnessScript coming from witness field for Taproot. These nested layers do distinguish on the information they contain, since some of them only commit to the hashes of the nested bitcoin_scripts (bitcoin::ScriptHash, WitnessProgram) or public keys (bitcoin::PubkeyHash, bitcoin::WPubkeyHash), while other contain the full source of the script.

The present type system represents a solution to the problem: it distinguish different logical types by introducing Script wrapper types. It defines LockScript as bottom layer of a script, containing no other script commitments (in form of their hashes). It also defines types above on it: PubkeyScript (for whatever is there in scriptPubkey field of a bitcoin::TxOut), SigScript (for whatever comes from scriptSig field of bitcoin::TxIn), RedeemScript and WitnessScript. For taproot, we define LeafScript as a top level of specific script branch (see bitcoin::util::psbt::TapTree) and crate::TapScript as a type specific for the current 0xC0 tapleaf version semantics, defined in BIP-342.

There are conversion functions, which, for instance, can analyse PubkeyScript and if it is a custom script or P2PK return a LockScript type - or otherwise fail with error. These conversions functions reside in convert module. So with this type system one is always sure which semantic information it does contain.

Type conversion

LockScript -+-> (PubkeyScript + RedeemScript) -+-> SigScript
            |                                  +-> WitnessScript
            +-> PubkeyScript
TapScript ----> LeafScript

PubkeyScript --?--> LockScript


~155K SLoC