Skip to content

Block Signature Overflow and Moving CHECKTEMPLATEVERIFY as an OP_SUCCESS #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ariard wants to merge 1 commit into from
Closed

Block Signature Overflow and Moving CHECKTEMPLATEVERIFY as an OP_SUCCESS #3

ariard wants to merge 1 commit into from

Conversation

@ariard
Copy link

@ariard ariard commented Jun 29, 2025 •
edited
Loading

In its current version, CHECKTEMPLATEVERIFY proposes to refurbish OP_NOP4 (0xb3)
with newer template commitment semantics. In my understanding, this soft fork
proposed changes allows to build pre-committed chain of transactions that are
committed by hash, and therefore immutable in some layout as soon as the root
of the chain of the transactions hits the chain.

The refurbished opcode is expected to behave in the following fashion:

  • There is at least one element on the stack (stack.size() < 1), fail otherwise
  • The element on the stack is 32 bytes long, NOP otherwise (stack.back().size())
  • The DefaultCheckTemplateVerifyHash of the transaction at the current input index is equal to the element on the stack (checker.CheckTemplateVerifyHash(hash))

The DefaultCheckTemplateVerifyHash commits to the serialized version, locktime,
scriptSigs hash (if any non-null scriptSigs), number of inputs, sequences hash,
number of outputs, outputs hash, and currently executing input index
(GetDefaultCheckTemplateVerifyHashEmptyScript() and GetDefaultCheckTemplateVerifyHashWithScript()).

Block Signatures Overflow Attacks

Per-block signature operation limit were introduced by Satoshi with commit
f1e1fb4bde, see GetSigOpCount() > MAX_BLOCK_SIGOPS in the main.cpp.
This limit has been activated with block 79400 and made a consensus rule
by Satoshi with commit 172f0060.

This per-block signature operation limit was originally set to MAX_BLOCK_SIZE / 50,
i.e 20_000 signatures operations per-block. BIP141 bumped this size limit to
80_000 signatures which was implemented in core by commit 2b1f6f9 and this
new consensus rule limit became activated with block 481,824.

This per-block consensus limit opens the door to some cross-layer attacks to
target off-chain protocols with competing interests (e.g alice_sig OR bob_sig+timelock)
where one of the counterparty fulfills the blocks with junk signatures until
some timelock is reached. This has been tested and it's feasible, especially
if you use empty CHECKMULTISIGs for reaching the MAX_BLOCK_SIGOPS_COST.

This limit applies to all the spends of a SegWit V0 scriptpubkey (WitnessSigOps).

See ariard@b85a426

This attack comes with a significative advantage, as if a lamba block construction
algorithm is picked up, the blocks can be busied up to prevent a counterparty
transaction to be included in the chain, as such paralyzing the semantics of
the off-chain protocols. By targetting multiple off-chain protocols instances
at the same time, an adversary can gain an economic advantage on the targetted
counterparties. Indeed the block is a public structure, while each targeted
off-chain protocol is private, and with no easy means for the counterparties
to coordinate themselves for reaction.

The Problem for Signature Ops Consuming Scripts

While this is not a problem with the core design of CHECKTEMPLATEVERIFY, it
is a problem affecting any future CTV scripts using at the same time a CTV
lock and a signature lock (e.g CHECKSIGVERIFY) in the same script path
(i.e a redeemscript or in a witness script). Indeed, by refurbishing OP_NOP4
as a CHECKTEMPLATEVERIFY opcode, this makes implicitly the usage of CTV in
a redeem script subject to the signature ops accounting limit (GetTransactionSigOpCost)
and lead to exposure by block signature exhaustion attack for a subset of
use cases.

The subset of use cases that would be affected would be of the following form,
as one layout example:

   OP_IF 
       <vault_hash> OP_CHECKTEMPLATEVERIFY 
   OP_ELSE 
       <alice_bob_aggregated_pubkey> OP_CHECKSIG 
   OP_ENDIF

The Fix : Deploying CHECKTEMPLATEVERIFY as an OP_SUCCESS

The fix is pretty straightforward to reduce the exposure of future CTV
use-cases, by migrating CTV in another upgradable path, e.g as a tapscript.

One simple way is just to move CTV as an OP_SUCCESS refurbishing the available
slot for the opcode of value 254 (OP_CHECKTEMPLATEVERIFY = 254) that this pull
request is proposing.

@ariard ariard changed the title Block Signature Exhaustion and Moving CHECKTEMPLATEVERIFY as an OP_SUCCESS Block Signature Overflow and Moving CHECKTEMPLATEVERIFY as an OP_SUCCESS Jun 29, 2025
@ariard ariard mentioned this pull request Jun 29, 2025
Open
@average-gary
Copy link

average-gary commented Jun 30, 2025

If I am understanding this correctly, the assertion is that future CTV upgrades, via the case OP_CHECKTEMPLATEVERIFY statement in src/script/interpreter.cpp, could add functionality that impacts the SigOps calculation in such a way that the Block Signature Overflow Attacks are a concern?

@jamesob
Copy link
Owner

jamesob commented Jul 1, 2025

Hi @ariard, thanks for the write-up and pull request.

Since this issue applies to all witness v0 coins, which are the bulk of current bitcoin traffic, I don't think this is something that should be addressed specifically with the BIP-119 implementation.

I also think it's important that OP_CHECKTEMPLATEVERIFY be available in a witness v0 (segwit) context, as there are many potential users who may not be willing or able to upgrade to Taproot, but still want to make use of CTV.

If users are worried about the issue you're highlighting - which is very expensive to successfully exploit, and results in a relatively minor, time-bound denial or service - then they can opt to use Taproot.

@jamesob jamesob closed this Jul 1, 2025
jamesob pushed a commit that referenced this pull request Jul 1, 2025
@fanquake
lsan: add more Qt suppressions
5be31b2 
Using Clang clang version 20.1.6 (Fedora 20.1.6-9.fc43) and:
```bash
export CC=clang
export CXX=clang++
cmake -B build -DBUILD_GUI=ON -DSANITIZERS=address
cmake --build build
export LSAN_OPTIONS="suppressions=/root/bitcoin/test/sanitizer_suppressions/lsan"
ctest --test-dir build
```

```bash
Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted, 1589ms
********* Finished testing of AddressBookTests *********

=================================================================
==21869==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 88 byte(s) in 1 object(s) allocated from:
    #0 0xaaaab5d5af40 in operator new(unsigned long) (/root/bitcoin/build/bin/test_bitcoin-qt+0x39af40) (BuildId: c0e038f1c507ea6860d1cfd499ac54ad83359872)
    #1 0xffff8c8f56cc in QLayoutPrivate::createWidgetItem(QLayout const*, QWidget*) (/lib64/libQt6Widgets.so.6+0x1a56cc) (BuildId: 8b7b9e470f4d4cd920282a4f963abb01225814fa)
    #2 0xffff8c8d2f90 in QBoxLayout::insertWidget(int, QWidget*, int, QFlags<Qt::AlignmentFlag>) (/lib64/libQt6Widgets.so.6+0x182f90) (BuildId: 8b7b9e470f4d4cd920282a4f963abb01225814fa)
    #3 0xaaaab5fc7188 in SendCoinsDialog::addEntry() /root/bitcoin/build/src/qt/./qt/sendcoinsdialog.cpp:596:18
    bitcoin#4 0xaaaab5fc4eec in SendCoinsDialog::SendCoinsDialog(PlatformStyle const*, QWidget*) /root/bitcoin/build/src/qt/./qt/sendcoinsdialog.cpp:84:5
    bitcoin#5 0xaaaab5da67ac in (anonymous namespace)::MiniGUI::MiniGUI(interfaces::Node&, PlatformStyle const*) /root/bitcoin/build/src/qt/test/./qt/test/wallettests.cpp:235:75
    bitcoin#6 0xaaaab5da2000 in (anonymous namespace)::TestGUI(interfaces::Node&, std::shared_ptr<wallet::CWallet> const&) /root/bitcoin/build/src/qt/test/./qt/test/wallettests.cpp:270:13
    bitcoin#7 0xaaaab5d9ebc8 in (anonymous namespace)::TestGUI(interfaces::Node&) /root/bitcoin/build/src/qt/test/./qt/test/wallettests.cpp:453:5
    bitcoin#8 0xaaaab5d9ebc8 in WalletTests::walletTests() /root/bitcoin/build/src/qt/test/./qt/test/wallettests.cpp:475:5
    bitcoin#9 0xffff8b1c5314 in QMetaMethodInvoker::invokeImpl(QMetaMethod, void*, Qt::ConnectionType, long long, void const* const*, char const* const*, QtPrivate::QMetaTypeInterface const* const*) (/lib64/libQt6Core.so.6+0x195314) (BuildId: eacb2d1228362560e5df1a1ce496c99ad61960e7)
    bitcoin#10 0xffff8b1c5dc8 in QMetaMethod::invokeImpl(QMetaMethod, void*, Qt::ConnectionType, long long, void const* const*, char const* const*, QtPrivate::QMetaTypeInterface const* const*) (/lib64/libQt6Core.so.6+0x195dc8) (BuildId: eacb2d1228362560e5df1a1ce496c99ad61960e7)
    bitcoin#11 0xffff8cf57c54  (/lib64/libQt6Test.so.6+0x27c54) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
    bitcoin#12 0xffff8cf5fa18  (/lib64/libQt6Test.so.6+0x2fa18) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
    bitcoin#13 0xffff8cf6067c  (/lib64/libQt6Test.so.6+0x3067c) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
    bitcoin#14 0xffff8cf610a4  (/lib64/libQt6Test.so.6+0x310a4) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
    bitcoin#15 0xffff8cf61aa4 in QTest::qRun() (/lib64/libQt6Test.so.6+0x31aa4) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
    bitcoin#16 0xffff8cf61eb4 in QTest::qExec(QObject*, int, char**) (/lib64/libQt6Test.so.6+0x31eb4) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
    bitcoin#17 0xaaaab5d7d77c in main /root/bitcoin/build/src/qt/test/./qt/test/test_main.cpp:95:30
    bitcoin#18 0xffff8aad6398 in __libc_start_call_main (/lib64/libc.so.6+0x26398) (BuildId: 627f878dd454ee3cc1dfdbd347bb565f1ffb53e7)
    bitcoin#19 0xffff8aad6478 in __libc_start_main@GLIBC_2.17 (/lib64/libc.so.6+0x26478) (BuildId: 627f878dd454ee3cc1dfdbd347bb565f1ffb53e7)
    bitcoin#20 0xaaaab5c74cac in _start (/root/bitcoin/build/bin/test_bitcoin-qt+0x2b4cac) (BuildId: c0e038f1c507ea6860d1cfd499ac54ad83359872)
```

This happens when building using depends:
```bash
Indirect leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0xaaaabdbe86f8 in malloc (/root/bitcoin/build/bin/test_bitcoin-qt+0x4386f8) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    #1 0xfbff97f8c164  (<unknown module>)
    #2 0xaaaabf0cfaa4 in QDBusConnectionPrivate::QDBusConnectionPrivate() (/root/bitcoin/build/bin/test_bitcoin-qt+0x191faa4) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    #3 0xaaaabf0c9e30 in QDBusConnectionManager::doConnectToStandardBus(QDBusConnection::BusType, QString const&, bool) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1919e30) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#4 0xaaaabf0cb0e4 in QtPrivate::QCallableObject<QDBusConnectionPrivate* (QDBusConnectionManager::*)(QDBusConnection::BusType, QString const&, bool), QtPrivate::List<QDBusConnection::BusType&, QString const&, bool&>, QDBusConnectionPrivate*>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x191b0e4) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#5 0xaaaabf5cbaf0 in QObject::event(QEvent*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1e1baf0) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#6 0xaaaabf5a4ce0 in QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1df4ce0) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#7 0xaaaabf5a486c in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1df486c) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#8 0xaaaabf5a575c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1df575c) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#9 0xaaaabf66b858 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1ebb858) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#10 0xaaaabf5a9e3c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1df9e3c) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#11 0xaaaabf632a44 in QThread::exec() (/root/bitcoin/build/bin/test_bitcoin-qt+0x1e82a44) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#12 0xaaaabf0c9bd0 in QDBusConnectionManager::run() (/root/bitcoin/build/bin/test_bitcoin-qt+0x1919bd0) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#13 0xaaaabf669c30 in QThreadPrivate::start(void*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1eb9c30) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
    bitcoin#14 0xaaaabdbe5f2c in asan_thread_start(void*) asan_interceptors.cpp.o
    bitcoin#15 0xffff99538608 in thread_start (/lib64/libc.so.6+0xf8608) (BuildId: 627f878dd454ee3cc1dfdbd347bb565f1ffb53e7)

SUMMARY: AddressSanitizer: 3592 byte(s) leaked in 37 allocation(s).
```
jamesob pushed a commit that referenced this pull request Jul 1, 2025
@fanquake
Merge bitcoin#32780: lsan: add more Qt suppressions
67e6746 
5be31b2 lsan: add more Qt suppressions (fanquake)

Pull request description:

  Using Clang clang version 20.1.6 (Fedora 20.1.6-9.fc43) and:
  ```bash
  export CC=clang
  export CXX=clang++
  cmake -B build -DBUILD_GUI=ON -DSANITIZERS=address
  cmake --build build
  export LSAN_OPTIONS="suppressions=/root/bitcoin/test/sanitizer_suppressions/lsan"
  ctest --test-dir build
  ```

  ```bash
  Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted, 1589ms
  ********* Finished testing of AddressBookTests *********

  =================================================================
  ==21869==ERROR: LeakSanitizer: detected memory leaks

  Direct leak of 88 byte(s) in 1 object(s) allocated from:
      #0 0xaaaab5d5af40 in operator new(unsigned long) (/root/bitcoin/build/bin/test_bitcoin-qt+0x39af40) (BuildId: c0e038f1c507ea6860d1cfd499ac54ad83359872)
      #1 0xffff8c8f56cc in QLayoutPrivate::createWidgetItem(QLayout const*, QWidget*) (/lib64/libQt6Widgets.so.6+0x1a56cc) (BuildId: 8b7b9e470f4d4cd920282a4f963abb01225814fa)
      #2 0xffff8c8d2f90 in QBoxLayout::insertWidget(int, QWidget*, int, QFlags<Qt::AlignmentFlag>) (/lib64/libQt6Widgets.so.6+0x182f90) (BuildId: 8b7b9e470f4d4cd920282a4f963abb01225814fa)
      #3 0xaaaab5fc7188 in SendCoinsDialog::addEntry() /root/bitcoin/build/src/qt/./qt/sendcoinsdialog.cpp:596:18
      bitcoin#4 0xaaaab5fc4eec in SendCoinsDialog::SendCoinsDialog(PlatformStyle const*, QWidget*) /root/bitcoin/build/src/qt/./qt/sendcoinsdialog.cpp:84:5
      bitcoin#5 0xaaaab5da67ac in (anonymous namespace)::MiniGUI::MiniGUI(interfaces::Node&, PlatformStyle const*) /root/bitcoin/build/src/qt/test/./qt/test/wallettests.cpp:235:75
      bitcoin#6 0xaaaab5da2000 in (anonymous namespace)::TestGUI(interfaces::Node&, std::shared_ptr<wallet::CWallet> const&) /root/bitcoin/build/src/qt/test/./qt/test/wallettests.cpp:270:13
      bitcoin#7 0xaaaab5d9ebc8 in (anonymous namespace)::TestGUI(interfaces::Node&) /root/bitcoin/build/src/qt/test/./qt/test/wallettests.cpp:453:5
      bitcoin#8 0xaaaab5d9ebc8 in WalletTests::walletTests() /root/bitcoin/build/src/qt/test/./qt/test/wallettests.cpp:475:5
      bitcoin#9 0xffff8b1c5314 in QMetaMethodInvoker::invokeImpl(QMetaMethod, void*, Qt::ConnectionType, long long, void const* const*, char const* const*, QtPrivate::QMetaTypeInterface const* const*) (/lib64/libQt6Core.so.6+0x195314) (BuildId: eacb2d1228362560e5df1a1ce496c99ad61960e7)
      bitcoin#10 0xffff8b1c5dc8 in QMetaMethod::invokeImpl(QMetaMethod, void*, Qt::ConnectionType, long long, void const* const*, char const* const*, QtPrivate::QMetaTypeInterface const* const*) (/lib64/libQt6Core.so.6+0x195dc8) (BuildId: eacb2d1228362560e5df1a1ce496c99ad61960e7)
      bitcoin#11 0xffff8cf57c54  (/lib64/libQt6Test.so.6+0x27c54) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
      bitcoin#12 0xffff8cf5fa18  (/lib64/libQt6Test.so.6+0x2fa18) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
      bitcoin#13 0xffff8cf6067c  (/lib64/libQt6Test.so.6+0x3067c) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
      bitcoin#14 0xffff8cf610a4  (/lib64/libQt6Test.so.6+0x310a4) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
      bitcoin#15 0xffff8cf61aa4 in QTest::qRun() (/lib64/libQt6Test.so.6+0x31aa4) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
      bitcoin#16 0xffff8cf61eb4 in QTest::qExec(QObject*, int, char**) (/lib64/libQt6Test.so.6+0x31eb4) (BuildId: 96bb1cdeead53af0ced36d7970cf9cd79c4c4ccd)
      bitcoin#17 0xaaaab5d7d77c in main /root/bitcoin/build/src/qt/test/./qt/test/test_main.cpp:95:30
      bitcoin#18 0xffff8aad6398 in __libc_start_call_main (/lib64/libc.so.6+0x26398) (BuildId: 627f878dd454ee3cc1dfdbd347bb565f1ffb53e7)
      bitcoin#19 0xffff8aad6478 in __libc_start_main@GLIBC_2.17 (/lib64/libc.so.6+0x26478) (BuildId: 627f878dd454ee3cc1dfdbd347bb565f1ffb53e7)
      bitcoin#20 0xaaaab5c74cac in _start (/root/bitcoin/build/bin/test_bitcoin-qt+0x2b4cac) (BuildId: c0e038f1c507ea6860d1cfd499ac54ad83359872)
  ```

  This happens when building using depends:
  ```bash
  Indirect leak of 24 byte(s) in 1 object(s) allocated from:
      #0 0xaaaabdbe86f8 in malloc (/root/bitcoin/build/bin/test_bitcoin-qt+0x4386f8) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      #1 0xfbff97f8c164  (<unknown module>)
      #2 0xaaaabf0cfaa4 in QDBusConnectionPrivate::QDBusConnectionPrivate() (/root/bitcoin/build/bin/test_bitcoin-qt+0x191faa4) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      #3 0xaaaabf0c9e30 in QDBusConnectionManager::doConnectToStandardBus(QDBusConnection::BusType, QString const&, bool) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1919e30) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#4 0xaaaabf0cb0e4 in QtPrivate::QCallableObject<QDBusConnectionPrivate* (QDBusConnectionManager::*)(QDBusConnection::BusType, QString const&, bool), QtPrivate::List<QDBusConnection::BusType&, QString const&, bool&>, QDBusConnectionPrivate*>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x191b0e4) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#5 0xaaaabf5cbaf0 in QObject::event(QEvent*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1e1baf0) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#6 0xaaaabf5a4ce0 in QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1df4ce0) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#7 0xaaaabf5a486c in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1df486c) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#8 0xaaaabf5a575c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1df575c) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#9 0xaaaabf66b858 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1ebb858) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#10 0xaaaabf5a9e3c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1df9e3c) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#11 0xaaaabf632a44 in QThread::exec() (/root/bitcoin/build/bin/test_bitcoin-qt+0x1e82a44) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#12 0xaaaabf0c9bd0 in QDBusConnectionManager::run() (/root/bitcoin/build/bin/test_bitcoin-qt+0x1919bd0) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#13 0xaaaabf669c30 in QThreadPrivate::start(void*) (/root/bitcoin/build/bin/test_bitcoin-qt+0x1eb9c30) (BuildId: dd54811dc11325890f7bac3e3a49d38f5a7ffef5)
      bitcoin#14 0xaaaabdbe5f2c in asan_thread_start(void*) asan_interceptors.cpp.o
      bitcoin#15 0xffff99538608 in thread_start (/lib64/libc.so.6+0xf8608) (BuildId: 627f878dd454ee3cc1dfdbd347bb565f1ffb53e7)

  SUMMARY: AddressSanitizer: 3592 byte(s) leaked in 37 allocation(s).
  ```

ACKs for top commit:
  maflcko:
    lgtm ACK 5be31b2

Tree-SHA512: 0c33661c7ec83ea9b874c1ee4ee2de513131690287363e216a88560dfb31a59ef563a50af756c86a991583aa64a600a74e20fd5d6a104cf4c0a27532de8d2211
@ariard
Copy link
Author

ariard commented Aug 24, 2025

@average-gary

could add functionality that impacts the SigOps calculation in such a way

No this is not the concern -- iiuc your comment.

The concern is in the case of let's call "mixed script" (e.g CHECKTEMPLATEVERIFY + CHECKSIG) used
by a second layer (e.g a high-value vault), an adversary can launch a block sig overflow attack on
the spend of one of the coins encumbered by the vault, even if it's the CTV path that is used.

Indeed, the script analysis for signature ops within a witnessScript is done statically on all
the opcodes elements revealed in the script (see WitnessSigOps and GetSigOpCount).

E.g, if the coins are locked with either CTV (go to Alice) or CHECKSIG+timelock=10 (go to Bob),
Bob can overflow all the blocks between the inclusion of the parent coin until the block at
which the timelock is final, and as such spending the coins which where under the "vault semantic"
locked for Alice.

My recommendation would be to make CTV taproot-only (no hard per-block limit sigops for P2TR),
or alternatively change BIP119 to document the vector of exposure for segwit script using CTV.

@ariard
Copy link
Author

ariard commented Aug 24, 2025

@jamesob

Given the ML warms up again on this subject, coming back to the issue with block sig
overflow attacks affecting "mixed script" (hash + signature), I understand the opposite
concern with a vast majority of today coins traffic being segwit, and as such of the economical
rational to allow CTV within segwit scripts.

On the other hand, I still think the issue can be serious enough that the best is for CTV
use cases designers and developers, to not use "mixed script" in segwit ones or if all the
paths go back to the same party (with not competing interest).

Indeed, the density of signature ops per virtual bytes can be quite high by leveraging
CHECKMULTISIG signature ops counting value, and one can generate a pack of 20 transactions
per block to overflow the inclusion of a "legit" "alice" transaction. Transaction size total
is something like 5000k-10k virtual bytes (very rough estimation). So as of today with a median
fee of 1 sat / vbyte, it's like ~10_000 satoshis per block. There is the segwit discount to take
measure of, though we're in the order of $1000 per block Dosed (-- I did the math initially for
LN and given the default timelocks I was landing around something like $10k to $20k to target
some channel). Anyway, if you're using CTV to lock $$$ vaults, I think this is no a good surface
asymmetry to expose.

While this is for most of use-case a time-bound denial of service, for some off-chain design
this can be also a vector of loss of funds (though it's very specific to the in concreto design
of the use-case).

Assuming I'm correct, and please pointed out if there are flaws in my reasoning about block
sig overflow attacks, I do think there could be a footnote in BIP119 to make that aware to
CTV use cases designers and developers.

Something like the following, IMHO:

In case of time-sensitive use-cases with competing counterparties, one should be careful to
not have mixed witnessScript with both signatures opcodes elements and CHECKTEMPLATE operations
in the same script, as otherwise this is opening exposure to block signature overflow attack,
where a malicious counterparty could fulfill all the blocks for one chain time interval.

If BIP119 is upgraded to be Taproot-only, I'll also go to review it, though I'm aware it's
more engineering work, and the trade-off with constraining all the well functional segwit
software not being able to use a future CHECKTEMPLATEVERIFY. Here me thinking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@ariard @average-gary @jamesob