Today I came across Luke Dashjr's patch and decided to apply it to my Bitcoin Core node. I integrated the patching process in the script with which I compile my Bitcoin
Core:
#!/bin/bash if [[ "$UID" -ne 0 ]]; then echo "Run me as root."; exit 1; fi s_code_dir=/usr/local/src script_d=$(dirname "$0") apply_patch_of_lukedj() { file_to_be_patched=${s_code_dir}/bitcoin-${rls}/src/script/interpreter.cpp backup_of_the_original=${script_d}/interpreter.cpp.${rls}.b patch_file=${script_d}/filter-ordinals.patch if [[ ! -f "$backup_of_the_original" ]]; then cp "$file_to_be_patched" "$backup_of_the_original" && echo "$file_to_be_patched backed up." fi patch "$file_to_be_patched" <"$patch_file" } dpnds_debian_bookworm=( automake cmake curl g++-multilib libtool libboost-all-dev binutils bsdmainutils pkg-config patch bison ) for d in "${dpnds_debian_bookworm[@]}"; do apt install -y "$d"; done echo "Go to https://github.com/bitcoin/bitcoin/releases/latest and give me the version, e.g. 26.0"; read rls rls_fl="v${rls}.tar.gz" cd "$s_code_dir" wget -q "https://github.com/bitcoin/bitcoin/archive/refs/tags/${rls_fl}" tar -xzf "${rls_fl}" && rm "${rls_fl}" cd "bitcoin-${rls}" && echo "Applying the patch of LukeDJ?[Y/any_other_key]";read ch if [[ "$ch" == y ]]; then apply_patch_of_lukedj fi ./autogen.sh && echo "autogen.sh finished. Press C to continue or any other key to cancel.[C/any_other_key]"; read ch if [[ "$ch" != 'c' ]]; then exit; fi ./configure --disable-tests --disable-bench --enable-util-cli --with-utils=no half_of_my_cores=$(echo "$(nproc) / 2"|bc) make -j "$half_of_my_cores" >make_log 2>&1 make install >make_i_log 2>&1
Apologies to the reader - It is my first time with patch.
If your setup is different than mine feel free to tweak
s_code_dir and patch_file in my script.
The most important tweak that I made to Luke's patch is getting rid of the first two lines, so that it looks like so:@@ -504,6 +504,14 @@ bool EvalScript(std::vector<std::vector<unsigned char> >& stack, const CScript& return set_error(serror, SCRIPT_ERR_MINIMALDATA); } stack.push_back(vchPushValue); + if ((flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) && opcode == OP_FALSE) { + auto pc_tmp = pc; + opcodetype next_opcode; + valtype dummy_data; + if (script.GetOp(pc_tmp, next_opcode, dummy_data) && next_opcode == OP_IF) { + return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS); + } + } } else if (fExec || (OP_IF <= opcode && opcode <= OP_ENDIF)) switch (opcode) {
I was explicit in specifying in my script the file to be patched, hence no need for those two lines. The script builds Bitcoin Core on the latest Debian stable, if you are on another distribution you may need to rewrite the
dpnds_debian_bookworm array and the for loop that iterates through it.
When running the script at the moment of applying the patch you should get the output like that:patching file /usr/local/src/bitcoin-26.0/src/script/interpreter.cpp Hunk #1 succeeded at 479 (offset -25 lines).
where:
"Hunk #1"refers to the first section of the patch file that contains changes to be applied to the target file,interpreter.cpp."succeeded"indicates that the patching process for this hunk was successful,"at 479"specifies the line number in the target file where the patch has been successfully applied"(offset -25 lines)"indicates that there was an offset of 25 lines between the location where the patch was expected to be applied and where it was actually applied. My guess is that offset occurs due to differences between the originalinterpreter.cppfor which Luke published his patch in February of 2023 and the most recent version ofinterpreter.cpp, published in December of 2023. Despite that the patching was successful.
Bearing in mind the possibility of the inscription/ordinal convention changing faster than Bitcoin Core's release cadence mempool filtering such as this seems to be a sensible solution as Luke reassures that the spam filters can be updated very fast.