Crate bitcoin_policy

source ·

Constants

Functions

  • | Check for standard transaction types | | ———– | @param[in] mapInputs | | Map of previous transactions that have | outputs we’re spending | ––––– | @param[in] taproot_active | | Whether or taproot consensus rules | are active (used to decide whether spends | of them are permitted) | | ———– | @return | | True if all inputs (scriptSigs) use | only standard transaction forms | | ———– | Check transaction inputs to mitigate two | potential denial-of-service attacks: | | 1. scriptSigs with extra data stuffed into them, | not consumed by scriptPubKey (or P2SH script) | | 2. P2SH scripts with a crazy number of expensive | CHECKSIG/CHECKMULTISIG operations | | Why bother? To avoid denial-of-service attacks; | an attacker can submit a standard | HASH… OP_EQUAL transaction, which will get | accepted into blocks. | | | The redemption script can be anything; an | attacker could use a very | expensive-to-check-upon-redemption script like: | | DUP CHECKSIG DROP … repeated 100 times… OP_1 | | Note that only the non-witness portion of the | transaction is checked here.
  • | @note | | This file is intended to be customised | by the end user, and includes only local | node policy logic |
  • | Compute the virtual transaction size | (weight reinterpreted as bytes). |
  • | Check for standard transaction types | | ———– | @return | | True if all outputs (scriptPubKeys) | use only standard transaction forms |
  • | Check if the transaction is over standard | P2WSH resources limit: 3600bytes witnessScript | size, 80bytes per witness stack element, | 100 witness stack elements | | These limits are adequate for multisignatures | up to n-of-100 using OP_CHECKSIG, OP_ADD, | and OP_EQUAL. | | Also enforce a maximum stack item size | limit and no annexes for tapscript spends. |