Please describe the feature you’d like to see added.
As a miner operating within a sanctions regime, I need to be able to reject transactions and maybe even blocks that contain sanctioned hashes.
Powerful sanctions regimes provide lists of sanctioned hashes for all major blockchains, including Bitcoin. These hashes end up being incorporated into output script templates that reside on the Bitcoin blockchain, and when these hashes are included, transactions need to be rejected.
Is your feature related to a problem, if so please describe it.
Yes, the problem to be fixed is described in Issue #29137
Describe the solution you’d like
Sanctions File
Sanctions regimes list their sanctioned hashes in standard address formats.
These hashes can be extracted from official sanctions files into a simple text file of one address per line. (To avoid semantical arguments, this file SHOULD NOT be seen as containing a list of sanctioned addresses; rather, it contains a list of sanctioned hashes that may later on be incorporated into standard output script templates.)
An example sanctions file extracted from OFAC’s sdn_advanced.xml file is available in @0xB10C’s ofac-sanctioned-digital-currency-addresses repository: https://github.com/0xB10C/ofac-sanctioned-digital-currency-addresses/blob/lists/sanctioned_addresses_XBT.txt
Command Line Arguments / Configuration File Options
Proposed command line options:
-checksanctions=filename: Enforce sanctions during transaction validation by loading the sanctions search tree from a specified text file (Default filename: sanctions.txt)-sanctionblocks: Enforce sanctions by rejecting new blocks that contain sanctioned transactions
Runtime Operation
If I am subject to a sanctions regime, I need to be able to optionally turn on sanctions enforcement. Sanctions need to be enforced when transactions are validated, such as during mempool acceptance, package relay, and possibly block validation (but not initial block download).
Load sanctions file & populate search tree
On startup, the sanctions text file is read and the encoded script template hashes are decoded into their byte arrays in accordance with addresstype.{h,cpp} and/or script/solver.{h,cpp}.
As each sanctioned hash is decoded into its std::vector<unsigned char>, it is added to a trie data structure for efficient matching during transaction validation.
A ternary search tree that can take std::basic_strings backed by std::vector<unsigned char> is available to the Bitcoin source code via its dependency on Boost: https://www.boost.org/doc/libs/1_84_0/libs/spirit/doc/html/spirit/qi/reference/string/symbols.html
Reject transactions containing sanctioned hashes
Any time a sanctions-enforcing node takes in a new transaction or a new inventory of transactions, that node needs to check txin output scripts and txout output scripts for sanctioned hashes.
Optionally reject sanctioned blocks
If a particular sanctions regime encompasses enough hash power, then sanctions-enforcing miners can safely orphan blocks containing sanctioned transactions.
Describe any alternatives you’ve considered
The exact trie data structure to use for acceptable performance could be evaluated further.
Please leave any additional context
Several miners have implemented their own sanctions enforcement mechanisms, with private or unpublished patches going back to as early as 2014. These implementations are neither efficient not economical to maintain. A standard implementation that can be optionally relied upon by miners in sanctions regimes is becoming a necessity.
