From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 25 Mar 2026 16:48:17 -0700 Received: from mail-ot1-f63.google.com ([209.85.210.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w5XxQ-0003jO-4g for bitcoindev@gnusha.org; Wed, 25 Mar 2026 16:48:16 -0700 Received: by mail-ot1-f63.google.com with SMTP id 46e09a7af769-7d496d080d8sf820893a34.0 for ; Wed, 25 Mar 2026 16:48:15 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1774482490; cv=pass; d=google.com; s=arc-20240605; b=Ck9bycLCiyac+yxwyyJk84I3QmiK/d7FE7yN4AQxnel/+TMQ1uDpPW1f6QPO+86NSi TJfstbWJQfAGgHPO2OeMLDKOeX1uPwyIocpRXzdZv99dOLZkCHzmGgo+WWHZNHEF9EvD LgU87OEA7Ly27T4ud/r7QADpPa9M56vYY7sEWo+AOT8XPcDCzg9BqkafjjQH2TTYk8Xq D7i+E0K4j9esePpPSmAYjJutVVxF3zsSk2x+YDU6M2nyNNfVyh/MAVGfNG90moiTJrPT 6uXhdHNxZvVP0g7fhMwp8QELsaSkuI2LcJg1eHx5nqcUbzngN9OcH3q4KwNhHbRyOgIl ngPA== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:to:subject:message-id:date:from :mime-version:sender:dkim-signature:dkim-signature; bh=Je1DRu9XXyaU+Wox9AXeK2CNOCtVuam7lhxsPFvd/Ks=; fh=Cl1qhV8CI7RTkWRjSwIf3NfXdWBV3qTUu8kxJ8T1V7I=; b=O9w7FaasqUf7pR+dKeDjJtEsXg3E31GJVAJL86Nb75sViRF97Tt1NqWULp7YblnYfX g6F9u8poMtr1AViL++Y2spqj9mz+Qm1lTn6ZKH7VeAMzBjPOzlrA1wkvXruLHJA647GY oen+GHzP3/1B0FbjWtCexO14PbICEQVIGos089FDmbC4fIj7KaM/QbIm9lFrzdFAxijQ fJAnt0Bet3cS73fWv9lTWtEH61oUEmnQoFhVI5Z7F/rrXslZCIjF4Z4TdvBfiu/WnyzI xqlqNmBsryiEqZoG1KuzWg4Eh0J0uKin/3eK+5h+0BL37cFgSMqfkXMej7jak5W9pavF vi6w==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=EM1jjCTz; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::132e as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1774482490; x=1775087290; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:mime-version :sender:from:to:cc:subject:date:message-id:reply-to; bh=Je1DRu9XXyaU+Wox9AXeK2CNOCtVuam7lhxsPFvd/Ks=; b=M7iAE4ow1L5aMgbNDfcLDzIFNMa/qDmcxDVi/5/HjhdrI5QtQkDSyhSoPKiuFhInL3 KmLYJ4BEoD9PP9bq/BenFeWT9vwCvL2ZmhC746u5egP5gUTaK9TdSLfUdyeKm7D5Gi9Y blYpl8r2U2XPH5ILXM1l9Izfei+yhj2Zn0eYmjL1amo9gSSArtwPtz2K76Lcufaa98Ds JD0K4Z916TwwG6lafAVHaqdsty7I8790fvvKBOSessoswNeq6sX81X4HDTVOPensCJ3p /K6QH0NZdJXb70icn/NxXedsMEipSBDKuxHxLs6wlQ2Co0/vGHXkHhkroYR0zb/SZgmp MCsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774482490; x=1775087290; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:mime-version:from :to:cc:subject:date:message-id:reply-to; bh=Je1DRu9XXyaU+Wox9AXeK2CNOCtVuam7lhxsPFvd/Ks=; b=I04BeHCfkXVyrMeDxbsDfelVM1LABmQVCSOgZCm7BbUdOUpbsXy+oNUN1uuV2VBx4Y cPTFBQfqeenYodEee6DuEsLuG9+pUjCoArKSjXe9WNGcGBfvjx/ZgcjCBSl1seBlk1KI wxarcCKsBeffNlyOKNTKvLwvfb32aHnVc0U4IiFtoP/zLhNuyAetBJTlrNe5zqzWRyM7 vQV6Te+T+F9g8gw3QgCrF7A0dmBlwXPx/1m1TU9x5c7jGlAqpRvq4oGDoIjqYFqGdZbZ avRSgvZy7LX1vm3E861XjOsaues3zT8hYgFxA535AlWh43735mqVtl9gee6lMLC32jFT zA7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774482490; x=1775087290; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:mime-version :x-gm-gg:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=Je1DRu9XXyaU+Wox9AXeK2CNOCtVuam7lhxsPFvd/Ks=; b=nTRRN1vNV0uoXdFKrAdMyhX/UyyHyXK/T9eWGu8N2FuIcuOzeFcQ76+1eXiyLHW1Ux IpISOt0+33tqu03X5zk2T62cz0QlVJa84go7fvWeYHKjmpGCro9RNQuHJTkS2VHXWpaL wtcwwDNwjHSkUhDoiGoUAfnfN2cPkcPPCnv6JwFyM9FcK3A5+4jYmy/4GXe/MZOd8ZLU 6Gf+Kz36x0MaRAAxXKR2h5LkrbefSJFco7fAdmidzjOfIAtigxLeS+gLaFeWh46EHeSz PKot8lJ9I21TY/i5fzmxpFYsyO5hq0wh4v0cOqCwO/iXTUocvFNZZJ/ItxmC7y4Qpyc/ Sk1w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCWZRw3jQRiX1Hq2EuXy3n39JwM7QMYNMM1SCQTNcQJCZK2U3fBoqmNeLxrORBjFnbzpph0Mn7lZTDng@gnusha.org X-Gm-Message-State: AOJu0Yx0twXuTUoBC+ZF4QbbovyfOf9XDOOaY+jwUDHHvwHcykEwFUOS qR1Rh42kodITtkgeUd3hRm/i/j6vc+0gMfTW7STAJw7ijRlkXZ2QlafJ X-Received: by 2002:a05:6820:f021:b0:67b:b1a2:b4d6 with SMTP id 006d021491bc7-67dff623ddfmr2579386eaf.68.1774482489202; Wed, 25 Mar 2026 16:48:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HI5cQztdK3MCKxEJlRncQzNtyCAlkdCNIYc9AOyQjP4A==" Received: by 2002:a05:6820:2221:b0:67d:eff0:e6d9 with SMTP id 006d021491bc7-67e0d016040ls97251eaf.2.-pod-prod-02-us; Wed, 25 Mar 2026 16:48:02 -0700 (PDT) X-Received: by 2002:a05:6808:17aa:b0:462:dc57:f8ba with SMTP id 5614622812f47-46a5c70a809mr2647513b6e.27.1774482482705; Wed, 25 Mar 2026 16:48:02 -0700 (PDT) Received: by 2002:a05:6808:4d0:b0:467:52e4:df4a with SMTP id 5614622812f47-46a5e9bd64emsb6e; Wed, 25 Mar 2026 15:30:32 -0700 (PDT) X-Received: by 2002:a05:6a20:748d:b0:39c:5624:ee6d with SMTP id adf61e73a8af0-39c5624f1e6mr4039023637.60.1774477831312; Wed, 25 Mar 2026 15:30:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1774477831; cv=pass; d=google.com; s=arc-20240605; b=iEZAFO3IjT9O8Aa56+XZJpPO/xPdTYU50t1AUZgsYjk8Kaw78CND0PnRvVKssC4N/m irN4YorZI7RJ8fQsrK9RDXW2IW1msI9rGWmmqoGwm/eZZC4pkqJJv3CJrQ2lTtlP4CZU 2QdlvO7zHgET7MKMkeLnLjBeElXDv5SPrnwGsN65C1iExkajQk/6zqbYY6RxGC723dqk 7mWEJyWEsuxHGr8KOyXTMa238/jeaaJOSm+b4bon+AJ9tS/FJoYyEa4JAmMjnLjjtSt7 CIAzS/MrZkCYjmaxGNhyq0L6jfifHqQPj1xyu6tH98ity0jY2loO83qiyz6wHYSbyfbL G3xA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=EtC8JbfoxmPn3aOtd1xPG24kHtRPCgilmscy2DD+10o=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=Y/IW+i2s1X6w10wnRtzGrNTBfjtuKEjsibXosdvia+IxOQJFTn3CItut1qAYCZiuUD CyjdDFhWlxsqrkMCV7nHEp4U9Vugxcm+l0X8q9BQI/dRnaO1WChbWaukEmOBKUAcRoys pbunqIqHLcK+Drhe71+DRBrdtj4dWRHVp++vbRI31qJiJkcTlOWNa5o8ijW5W2iVFS6t zANPMtqgtHHkymO7ffYaMjClizGP+Rwscgotp0oogW3YewczyoTkbvqlyrg0D4XRW3oj DV+xishVJsnq9Nc70VowilKCHL9rax/SpxdCNCi0PRzPdnUk1HQuo4b3e15qBYo3tquk SibA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=EM1jjCTz; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::132e as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-dy1-x132e.google.com (mail-dy1-x132e.google.com. [2607:f8b0:4864:20::132e]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-c767396a666si30476a12.3.2026.03.25.15.30.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Mar 2026 15:30:31 -0700 (PDT) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::132e as permitted sender) client-ip=2607:f8b0:4864:20::132e; Received: by mail-dy1-x132e.google.com with SMTP id 5a478bee46e88-2c160308a54so733315eec.0 for ; Wed, 25 Mar 2026 15:30:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774477830; cv=none; d=google.com; s=arc-20240605; b=Oaun6RpWOeujeA07/n+dXFnBLSBHhP1Lar3rOqO6ulSMsAS/E5zdo+ghKln8gw1k0/ t1uhDqNSfFNQ0iNYY3KvX9Q+Va4aB8FuvGSUzddYpiEwebwuS6KMzsOt3bMFnY+Q9I2/ 9Yyils/QKkVfx+xc08ifhdo3koL43lUmHcMa4Oa7S7qlIyAIajEliKn0wY+I0F3Arckl 7ZkmIchn70C+6yj1jFL6K86sgFq1OzeynaR8KbmHiI3lMupcu0pZc2edAHbLry7eCL1f Gvs1iUN4hxlSm7JOQnkQbgpEXRUcabFeAayDKCasfIXJzxSqfFOESTWVvYW7ibo3BQcY g2xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=EtC8JbfoxmPn3aOtd1xPG24kHtRPCgilmscy2DD+10o=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=agp3oTVs6NHyLesLu7wsPanO4abvlPxxds0aY0XMTG2RJ7v5cROB/DioA1GsD3v85j mRZ4x9WMxFNPeq3oQxEpNRdwLr6SqB0HTIPr3gntFWXw6zfIFxWxZbk1GoPQoPcWHa3q ca/lX/gC4dON1GaNh+tScAcj8hdCMXgxf7RxHHTBtEN3mVaq9vnXIqB/PXl5LVlChpdV L4EjTDVhL2PcTY6fA6Mzd9LPdlJyhR6wvLOxSZ1bdjj8z52Z906M5x9vp3EG/5c/j4Ma IFVp4pXt8wGbqvxL7oHHSM6/fv/lJPvg4pa3T0iEdQ2zfAwH5kf/uAZEokjdt+XoYBl3 hNJQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: ATEYQzyEQFgC0Kr/oELAEMSPgHVXiIdOO3xihecKVE9uh1IvaaaSuwavY4q5GB22wHz d2x7kMxvz+UIaEJ+upD04YwkeYoClCaCgLJSgwsWrcmz9aeyCxJKxjHi2SiJPg1TUJ1LASkHVlR YQukk0WFzFXOCnSRbRAS48zEtB8i9b6l0zFIN4yGq/vEoxEwPIZNKNRsWVv7X9N9agjopJ8/rqv nL2VnmXzvDYBY0EptZfP2TDzlYtRgB2HwksT2OekuumNNBrvVBZvakP5kJSykUrJ3PZe2c4A0Q2 aaC6LUFN X-Received: by 2002:a05:7022:618b:b0:119:e56b:958a with SMTP id a92af1059eb24-12a96e5e7a0mr2689491c88.15.1774477825325; Wed, 25 Mar 2026 15:30:25 -0700 (PDT) MIME-Version: 1.0 From: Antoine Riard Date: Wed, 25 Mar 2026 22:30:13 +0000 X-Gm-Features: AaiRm51F1MhGL5RGyTQsOz5Fyl4hIlyw7-0BrvbvdaHXyHKLtkSob4PMlMseCG8 Message-ID: Subject: [bitcoindev] Building a CoinPool with OP_CHECKCONTRACTVERIFY To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000070beaf064de0d030" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=EM1jjCTz; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::132e as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --00000000000070beaf064de0d030 Content-Type: text/plain; charset="UTF-8" Hi list, In this post, I'm digging on OP_CHECKCONTRACTVERIFY (OP_BIP 443) and how it can be leveraged to design UTXO-sharing schemes like CoinPool, and the limits of the primitive in this regard. ### CoinPool: Main Operations In this section, I'm reminding the main operations of a coinpool (for more in-depth reminders, see [0], [1], [2]). Basically, a coinpool is a multi-party construction designed to improve the onboarding and transactional scaling of bitcoin users by orders of magnitude. To work in an efficient way, it requires some consensus changes, e.g a TAPROOT_LEAF_UPDATE_VERIFY or OP_MERKLE_SUB [3] (the primitive matters less than the level of expressivity brought by the primitive). A coinpool instance is defined by a set of public keys and the associated balances, which are debited and credited during pool operation. State is maintained by an on-chain UTXO and a set of pre-signed transactions encoding the users' balances. Off-chain transfers between pool accounts require replacing old pre-signed txn and all the pool participants have to approve. Once the off-chain pool state has hit the chain, all the users can recursively and non-interactively withdraw their funds, one by one. This recursive update of the state pool is the mechanism on which to draw attention in the present post, and especially in which measure it can be (imperfectly) reproduced with OP_CHECKCONTRACTVERIFY. Let's say you have a pool of four (A,B,C,D) [4] Funding UTXO script is a multisig of ABCD. Each update transaction has a Eltoo-encoded nLockime. In the output of each update transaction, each participant with a balance has an exit path. Any withdraw transaction can consume an update tx exit path. The MERKLESUB (or TLUV) ensure that the withdraw output is the similar script with 3 modifications: - the withdrawing participant balance has been subtracted from the pool balance amount - the withdrawing participant point has been subtracted from the curve point constituting the internal point - the withdrawing participant script has been subtracted from the tree of scripts This mechanism allows the participants to withdraw from the update tx output in any-order, i.e without having to know at setup who is the first that is going to exit the off-chain construction. This is ensuring reasonable fault-tolerance of the construction, where one bad party cannot force a massive on-chain footprint, of which the cost would be burden by all the pool participants (and the chain txn logs be unnecessarily inflated). ### A CoinPool built with OP_CCV The proposed opocode OP_CHECKCONTRACTVERIFY, in my understanding, works in the following way. When evaluating an OP_CCV, the interpreter is excpecting 5 elements on the stack: - : the selected verification mode - : the tweaked taptree - : the verified naked key - : the verified input or output index - : a buffer of arbitrary data length By selecting the accurate mode (i.e `CCV_MODE_CHECK_OUTPUT`), one can ensure that an output is encumbered by an expected taptree and an expected internal public key. The output amount and its update can be selected with the combinatory `CCV_MODE_CHECK_OUTPUT_DEDUCT_AMOUNT`. Going back to CoinPool design, any order recursive mechanism for the withdrawals can be implemented with CCV in the following way. At each update tx, the participants builts a withdraw tx for each participant and multi-sign it. The output in the update has all the branches of the `taptree`. When a pool participant wishes to withdraw, it gives the `updated_taptree` in the witness of the withdraw transaction as a CCV argument. The multi-signature ensures that the pre-image `update_taptree` matches the expected withdraw output. The multi-signature can also ensure the amount matches the off-chain balance. However, this approach is limited for one step, as otherwise the pool participant would have to generate a withdraw tx for each combination. While this workable for small sized pool, this is a practical exponential limit for a high number of participants (from previous measures around the 11th or 12th participant). ## Open Design Questions This is an open design question if CCV can be combined with other opcodes, where introspection would be done on the argument to deduce from it what should be the triplet (pubkey, tree, amount) for the withdraw tx output based on the input state. >From laying out the question, there are 2 obvious observations for the bitcoin script experts (a) if this hypothetical introspection phase can be rendered unforgeable by any of the participant to the pool and (b) if a contrario a templated approach a la MERKLESUB and OP_TLUV is not more efficient witness space wise. This short analysis is limited to the usage of OP_CCV for the precise case of UTXO-sharing like CoinPool, and its design trade-offs might be more fruitful and is more adapted for other use-cases. Cheers, Antoine OTS hash: 15a8f04022265a0258e51ca54d98285bc9e33df0342f5700cd91e750febbe4de [0] https://gnusha.org/pi/bitcoindev/CALZpt+FqAWCAqCLF2HsajL84sOvst_X9_34bb_tvUxLFw=HTAA@mail.gmail.com/ [1] https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i5cJ4h12TuG8tnWswqbfAnRdA@mail.gmail.com/ [2] https://github.com/ariard/coinpool-gitbook/blob/master/coinpool-v0.1.pdf [3] https://gnusha.org/pi/bitcoindev/20210909064138.GA22496@erisian.com.au/ [4] https://gist.github.com/ariard/713ce396281163337c175d9122163e8f -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BFfC6hnN1i32OJVJ-VKvg0Z%3DtbpNB-97ZZ_7TMaLj8E9g%40mail.gmail.com. --00000000000070beaf064de0d030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi list,

In this post, I'm digging on OP_CHECKC= ONTRACTVERIFY (OP_BIP 443)
and how it can be leveraged to design UTXO-sh= aring schemes like
CoinPool, and the limits of the primitive in this reg= ard.

### CoinPool: Main Operations

In this section, I'm r= eminding the main operations of a coinpool
(for more in-depth reminders,= see [0], [1], [2]). Basically, a
coinpool is a multi-party construction= designed to improve the
onboarding and transactional scaling of bitcoin= users by orders of
magnitude. To work in an efficient way, it requires = some consensus
changes, e.g a TAPROOT_LEAF_UPDATE_VERIFY or OP_MERKLE_SU= B [3] (the
primitive matters less than the level of expressivity brought= by
the primitive).

A coinpool instance is defined by a set of pu= blic keys and the
associated balances, which are debited and credited du= ring pool
operation. State is maintained by an on-chain UTXO and a set o= f
pre-signed transactions encoding the users' balances. Off-chaintransfers between pool accounts require replacing old pre-signed
txn an= d all the pool participants have to approve.

Once the off-chain pool= state has hit the chain, all the users
can recursively and non-interact= ively withdraw their funds, one
by one.

This recursive update of = the state pool is the mechanism on which
to draw attention in the presen= t post, and especially in which measure
it can be (imperfectly) reproduc= ed with OP_CHECKCONTRACTVERIFY.

Let's say you have a pool of fou= r (A,B,C,D) [4]

Funding UTXO script is a multisig of ABCD.

Ea= ch update transaction has a Eltoo-encoded nLockime.

In the output of= each update transaction, each participant with
a balance has an exit pa= th.

Any withdraw transaction can consume an update tx exit path.
=
The MERKLESUB (or TLUV) ensure that the withdraw output is the
simil= ar script with 3 modifications:
- the withdrawing participant balance ha= s been subtracted
=C2=A0 from the pool balance amount
- the withdrawi= ng participant point has been subtracted
=C2=A0 from the curve point con= stituting the internal point
- the withdrawing participant script has be= en subtracted
=C2=A0 from the tree of scripts

This mechanism allo= ws the participants to withdraw from the update
tx output in any-order, = i.e without having to know at setup who is
the first that is going to ex= it the off-chain construction.

This is ensuring reasonable fault-tol= erance of the construction, where
one bad party cannot force a massive o= n-chain footprint, of which the
cost would be burden by all the pool par= ticipants (and the chain txn logs
be unnecessarily inflated).

###= A CoinPool built with OP_CCV

The proposed opocode OP_CHECKCONTRACTV= ERIFY, in my understanding, works
in the following way. When evaluating = an OP_CCV, the interpreter is excpecting
5 elements on the stack:
- &= lt;mode> : the selected verification mode
- <taptree> : the twe= aked taptree
- <pk> : the verified naked key
- <index> : = the verified input or output index
- <data> : a buffer of arbitrar= y data length

By selecting the accurate mode (i.e `CCV_MODE_CHECK_OU= TPUT`), one
can ensure that an output is encumbered by an expected taptr= ee and
an expected internal public key. The output amount and its update=
can be selected with the combinatory `CCV_MODE_CHECK_OUTPUT_DEDUCT_AMO= UNT`.

Going back to CoinPool design, any order recursive mechanismfor the withdrawals can be implemented with CCV in the following way.
=
At each update tx, the participants builts a withdraw tx for each parti= cipant and multi-sign it.

The output in the update has all the branc= hes of the `taptree`.

When a pool participant wishes to withdraw, it= gives the `updated_taptree` in the
witness of the withdraw transaction = as a CCV argument.

The multi-signature ensures that the pre-image `u= pdate_taptree` matches the expected
withdraw output. The multi-signature= can also ensure the amount matches the off-chain
balance. However, this= approach is limited for one step, as otherwise the pool participant
wou= ld have to generate a withdraw tx for each combination. While this workable= for
small sized pool, this is a practical exponential limit for a high = number of participants
(from previous measures around the 11th or 12th p= articipant).

## Open Design Questions

This is an open design = question if CCV can be combined with other opcodes,
where introspection = would be done on the <data> argument to deduce from it
what should= be the triplet (pubkey, tree, amount) for the withdraw tx output
based = on the input state.

From laying out the question, there are 2 obviou= s observations for the bitcoin
script experts (a) if this hypothetical i= ntrospection phase can be rendered
unforgeable by any of the participant= to the pool and (b) if a contrario a
templated approach a la MERKLESUB = and OP_TLUV is not more efficient witness
space wise.

This short = analysis is limited to the usage of OP_CCV for the precise case
of UTXO-= sharing like CoinPool, and its design trade-offs might be more fruitful
= and is more adapted for other use-cases.

Cheers,
Antoine
OTS h= ash: 15a8f04022265a0258e51ca54d98285bc9e33df0342f5700cd91e750febbe4de
[0] https://gnusha.org/pi/bitcoin= dev/CALZpt+FqAWCAqCLF2HsajL84sOvst_X9_34bb_tvUxLFw=3DHTAA@mail.gmail.com/
[1] https://gnusha.org/pi/bitco= indev/CALZpt+E+eKKtOXd-8A6oThw-1i5cJ4h12TuG8tnWswqbfAnRdA@mail.gmail.com/
[2] https://github.com/ariard/coinpool-gitbook/blob/master/= coinpool-v0.1.pdf
[3] https://gnusha.org/pi/bitcoindev/2021= 0909064138.GA22496@erisian.com.au/
[4] https://gist.github.com/aria= rd/713ce396281163337c175d9122163e8f

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/CALZpt%2BFfC6hnN1i32OJVJ-VKvg0Z%3DtbpNB-97ZZ_7TMaLj8E9g%= 40mail.gmail.com.
--00000000000070beaf064de0d030--