From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 01 Nov 2025 18:45:13 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.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 1vFN9c-0006rT-LC for bitcoindev@gnusha.org; Sat, 01 Nov 2025 18:45:13 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-3c9b1b356casf5236874fac.1 for ; Sat, 01 Nov 2025 18:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762047901; x=1762652701; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=MHENLHEoIPLfCYUuknkXvKhUvUR+D/9Je4IsxjNsNgo=; b=vhXXt79DLwGbwLw50C8YcI99N6CpPhuNGuGfOv3gH3ARj5px3p11XnTDeyC4pu5XOL +/0COO1yZMfFtMFY6P4Rdy5jDeRdL/WNgp4DcOUklqNcSrBSH5mlZN3nTkVhQolTjaFO TtP11yfrFUjtCmGig6wpaSVAQQkq3ZGeH7RUU5vsph2YBqKjlSbnqLEZnbPnizCryWUy J1v3d5r3j1mwZ4WTMLKtjYlDHT+PWq22p3mMpseyw/06ZflwuvLCIEBjomQaTKy2QTNf QEaUyWYP7tF3X98dEmj5hhWYbpEzSM0V7Zg/k88JTTjMtzDF15AiiljW1qANFDHaZ7OB RV2w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762047901; x=1762652701; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=MHENLHEoIPLfCYUuknkXvKhUvUR+D/9Je4IsxjNsNgo=; b=AF86w0ITfkJXTt+orFqBz/gkrD+40RruyeoZIFNqn2tCauzKWOLfZQSrsRGoaDlgu9 BWJlJ72Bv5Iuo4wo4etvywq+/H3UqPkDW5g7COK31YH8HS83qXCHrg4F9N+bgj5UV9oG ZSPZn4Vox8rB5TVKwbP/QaGWRSavDRY23zIYnZyCYqL5uOW4RWKxNvljk1Qimz1E9quf WobvJWO8OS9ZcuIWnLkeSrC6+Ao1BqMIGMQj9TF6H5VJk4cu6vm7f4gw5YERJ10BBmqw l78KqGCXRT4Zc8C8OjRPFPFjuJ2q+LfgUASvZ4/Nr4dJvdfuBC8uYqKbtgjzz2K7Ufyy tw8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762047901; x=1762652701; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=MHENLHEoIPLfCYUuknkXvKhUvUR+D/9Je4IsxjNsNgo=; b=xGG4inKRPfhD8CzjWw9++dmZx5HaJQfY2GuBoRmSVeKnudooPgu5HOW7f2liBf1oI+ Lr8CGWb9Kw6fupp5zV3rHG1FHo1GsY6L2WmVi/ojsuu7HUaQx50X/Ky3+1m8pL1oxrEe bk/78uOUZfbzcr+/waon+0x6KMIeQjPXLlJJbnpa9ERlwiCWAXnOtdTyWwNUmxD+/BbK 7I77KR+VoNbZYtcxEADbx4sDK6+Qf+k4VZAqA6wsjBTJSoerTA/be/y/pfWdkPmvrcpI t06Uamdg6dYZVeZlKOx2lXO3GvZWj3KNBfsN/4jKvuIiQoBYoR6c7ILGlZzueWnVKseo JbRA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXpAz/V3Bk50G8y34vpS34lJ09LXT6pAUFDSqNkmduano2K7TTWwiayCHG63LL/AQesWoMHl7fyB/pq@gnusha.org X-Gm-Message-State: AOJu0YyAZGAGzOC1op14s8EAnrc3I+ukDeXBsWJi7D2RgVEbjqiXAZa/ GWnlNw+dgPRNlL7s0VpoW5lL2Bi1jzXfx/rNys5XjCHrddI2EFvKJVJj X-Google-Smtp-Source: AGHT+IHxN9EOqmWDAUnfnC2/XcIxCNa9yK15nejWoNkpDMi2Wht+vJisGRKzyhLz8366SmeQ6q/x/g== X-Received: by 2002:a05:6871:4b12:b0:3d3:9912:a3cf with SMTP id 586e51a60fabf-3dacab28cc7mr3497423fac.19.1762047901310; Sat, 01 Nov 2025 18:45:01 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+a9ZtBZhBTRLjVeT3q1sDTzqzu4Rjj/eaKIBgIG1kiM0A==" Received: by 2002:a05:6870:11c7:b0:3d3:2f56:6730 with SMTP id 586e51a60fabf-3d8b9665bafls1155010fac.0.-pod-prod-03-us; Sat, 01 Nov 2025 18:44:56 -0700 (PDT) X-Received: by 2002:a05:6808:1b10:b0:43b:8b5e:d127 with SMTP id 5614622812f47-44f95dfc6d1mr3967446b6e.13.1762047896298; Sat, 01 Nov 2025 18:44:56 -0700 (PDT) Received: by 2002:a05:690c:ea:b0:780:f7eb:fdf with SMTP id 00721157ae682-7865fb1b7c5ms7b3; Sat, 1 Nov 2025 18:34:46 -0700 (PDT) X-Received: by 2002:a05:690c:688f:b0:786:5789:57c4 with SMTP id 00721157ae682-78657895a5amr48924117b3.39.1762047286048; Sat, 01 Nov 2025 18:34:46 -0700 (PDT) Date: Sat, 1 Nov 2025 18:34:45 -0700 (PDT) From: Boris Nagaev To: Bitcoin Development Mailing List Message-Id: <19701913-9225-45b3-8a2c-d620c53d8873n@googlegroups.com> In-Reply-To: References: <05195086-ee52-472c-962d-0df2e0b9dca2n@googlegroups.com> Subject: Re: [bitcoindev] OP_CIV - Post-Quantum Signature Aggregation MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_316496_538412423.1762047285703" X-Original-Sender: bnagaev@gmail.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 (/) ------=_Part_316496_538412423.1762047285703 Content-Type: multipart/alternative; boundary="----=_Part_316497_2061236534.1762047285703" ------=_Part_316497_2061236534.1762047285703 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tadge, Conduition, and all, I think Conduition's stateless take can go a little further with a simple= =20 indexing trick. Give every address a monotonic index i, and from the seed= =20 derive a long sequence of shared keys K_0, K_1, .... When we create address= =20 i, we add taproot leaves for K_i through K_{i+N-1}. That is a sliding=20 window of size N. When a spend gathers a set of our inputs, let i_min be the smallest index= =20 and i_max the largest. If i_max - i_min < N, every input already has a leaf= =20 for K_{i_max}, so we reveal that leaf everywhere and sign once under=20 K_{i_max}. No state needed: the rule is deterministic. Because an index i is spent only once, the first spend that touches it is= =20 the only transaction that ever reveals K_i. Backups stay simple too: any=20 device with the master seed can recompute the indices and shared keys=20 without knowing past wallet state, as long as it knows N. Larger N means more leaves per address but keeps aggregation working across= =20 older UTXOs. Wallets that need giant sweeps can still consolidate inside=20 windows. The number of full signatures in a transaction is the number of=20 windows inputs belong to. Curious whether this sounds workable. Best, Boris On Saturday, November 1, 2025 at 8:09:52=E2=80=AFPM UTC-3 conduition wrote: Neat idea! The need to commit each script pubkey to other prevouts in the= =20 TX would probably hold the concept back from being practical, especially=20 for deterministic backup wallets which is likely the bulk of modern Bitcoin= =20 usage. I could imagine offline/hardware wallets having a very tough time=20 with this. Consider a more conservative (but also very common) use case: Aggregating= =20 inputs controlled by the same owner. In this context, what the sender is=20 really trying to prove here isn't whether UTXO A committed to UTXO B. For= =20 signature aggregation across commonly-owned inputs, they just need to be=20 able to prove that UTXO A and UTXO B are spendable under the same pubkey,= =20 and that they, the pubkey owner, authorized both of them via a single=20 signature. So instead of committing a taptree to pre-existing UTXOs (which creates=20 statefulness), you could commit a taptree to a deterministic set of=20 pubkeys, such as "the nearest 100 addresses in the same BIP32 account". At= =20 spending time, we reveal the same pubkey's script leaf on all inputs, plus= =20 a signature that covers all the inputs. This would allow stateless address= =20 generation, while also allowing a single signature to cover all common=20 inputs in a wallet. This would have pretty bad effects on UTXO privacy, because the=20 common-owner heuristic would become even stronger and would be provable=20 on-chain, but OP_CIV would also likely have a similar effect on chain=20 forensics. Maybe the fee savings would be worth it, esp for big exchanges= =20 which consolidate hundreds or thousands of UTXOs at a time. -conduition On Saturday, November 1st, 2025 at 2:02 PM, Tadge Dryja = =20 wrote: Hello- Here's an idea for Post-Quantum cross-input signature aggregation. It's not= =20 quite "signature aggregation" the way we normally think of it, but gives=20 similar benefits while not being tied to a particular signature scheme. Folks have discussed Cross-input signature aggregation (CISA) in Bitcoin a= =20 while now, and while related research such as MuSig2, FROST, and ROAST have= =20 been implemented in wallets, so far there is no consensus change in bitcoin= =20 to enable CISA. My hunch is that one of the reasons this hasn't been=20 adopted is that the space savings aren't that large. With taproot outputs,= =20 signatures are 64 bytes, and discounted to 16 vBytes.=20 https://github.com/BlockstreamResearch/cross-input-aggregation/blob/master/= savings.org=20 shows a 7.1% vByte savings using full aggregation. Signatures just aren't= =20 that big of a part of the transaction, especially after the 75% segwit=20 discount. One place where the size of signatures *is* a problem is with post-quantum= =20 signatures. The two most discussed PQ signature schemes, SPHINCS+ and=20 CRYSTALS-Dilithium, both have pubkey+signature sizes in the kilobytes=20 range. This would be a great opportunity for CISA, since even with a 75%=20 witness discount, signatures would cost over 90% of the vBytes in a=20 transaction. Unfortunately all the great EC based signature aggregation tools people=20 have built don't work for lattices and hash-based signatures. Here's a way= =20 to get some of the same effects which would work with any signature type=20 (including EC signatures, but if you've got EC signatures, existing CISA=20 techniques are much better). I'm not attached to the name but for people=20 familiar with bitcoin, the easiest to understand would be OP_CIV or=20 OP_CHECKINPUTVERIFY. The basic idea is that a transaction input can prove a linkage to another= =20 input within the same transaction, and by pointing to another input say=20 "that's the signature I'm using", without providing one of its own. Take=20 for example a transaction with 2 inputs: input 0 and input 1. Input 0 has a= =20 normal (perhaps PQ) SIGHASH_ALL signature. Input 1 has a proof pointing to= =20 input 0. Since input 0 exists within the transaction, input 1 is valid. The arguments and usage of the would be: =20 Where is the input number in the current transaction being=20 validated to look. If this stack element isn't a number, or the number=20 exceeds the number of inputs in the transaction, the opcode fails. and together form the outpoint, or UTXO identifier to= =20 look for at the location. If these two stack elements are=20 malformed, or the resulting outpoint does not match the outpoint seen in=20 the transaction, the opcode fails. is popped off the stack and discarded. It can be OP_0, but random= =20 bytes here can protect privacy. After an output is spent revealing the=20 taptree, someone could try to grind through other possible outpoints to see= =20 if they show up elsewhere in the tree, trying to assign UTXOs to the same= =20 owner. This nonce would prevent such an attack. That's pretty much it for script evaluation. The idea would be that a taproot tree would have at the root a "normal"=20 pubkey capable of creating arbitrary signatures. Lower down in the tree,=20 there would be several / many OP_CIV scripts, each one pointing to a=20 different outpoint. When a UTXO is being spent, if it is being spent in the= =20 same transaction as any of the UTXOs pointed to by the OP_CIV scripts, one= =20 of those can be revealed instead of supplying a signature. At least one=20 input in a transaction would have a normal signature; it's not possible for= =20 every input in a transaction to use OP_CIV since that would require a hash= =20 cycle. For the wallet side implementation, every time a wallet generates a new=20 address, it looks up some or all of the current UTXOs in the wallet, and=20 adds a branch for each of them in the taproot tree. The wallet adds=20 blinding data to each OP_CIV script to prevent an attacker from being able= =20 to guess other UTXO linkages other than those explicitly revealed. The last= =20 argument, , is left empty in the script and supplied at=20 spending time. To avoid the need to generate and store additional entropy,= =20 the wallet can generate the blinding data deterministically, using the root= =20 pubkey's private key and the outpoint being pointed to, somewhat like the= =20 use of RFC6979 for ECDSA nonces. (Eg nonce =3D hash(private_key, outpoint))= . Wallets constructed in such a way would often only need 1 signature per=20 transaction, as all other UTXOs could point to the oldest input in the=20 transaction. This savings doesn't work when a new wallet generates many=20 addresses at once, and then over time coins are sent to those addresses. In= =20 that case a wallet would end up with a number of UTXOs which don't point to= =20 each other. Those UTXOs would all need to sign, but they might be paired=20 with later UTXOs which point to them.=20 Deterministic key wallets One complication is key recovery for deterministic wallets. If only the=20 master key / seed phrase is known, all the root pubkeys can be recovered,= =20 but the wallet has "forgotten" which pubkeys point to which UTXOs.=20 Deterministic nonces make recovery possible, but in a naive implementation,= =20 there would be an exponential blowup if when addresses are created they=20 point to all existing UTXOs in the wallet. There are several workarounds,= =20 such as limiting the number of OP_CIV scripts in the tree to eg 10=20 (resulting in a ~1000X slowdown in recovery while maintaining a good chance= =20 of OP_CIV use), or including OP_CIV scripts pointing to all TXOs that the= =20 wallet knows have already been spent, increasing taptree size but reducing= =20 the number of guesses needed for recovery. Address re-use and replay attacks=20 I don't think replay attacks are too much of a problem here. I thought it= =20 might be, but OP_CIV points to outpoints, not addresses or keys, so address= =20 reuse for the UTXOs being pointed to shouldn't matter. For address re-use= =20 with addresses that have OP_CIV scripts in them, replay attacks are avoided= =20 by using SIGHASH_ALL in the input that does sign, so that even if an=20 attacker learns the full taptree of all the UTXOs of a wallet, they can't= =20 construct or modify a transaction without the ability to sign. Other uses There might be other contract use cases for such an opcode even today. I=20 haven't come up with one, but it gives a tool where you can reveal a secret= =20 (a spend path & nonce) that allows someone to take a UTXO, but only if they= =20 already control a different specified UTXO. I think it's mostly useful for= =20 making PQ transactions smaller, but transaction introspection opcodes often= =20 have interesting use cases and OP_CIV may as well Real life example of OP_CIV commitments I gave a talk about this at TABConf a couple weeks ago; I was hoping to=20 have sent this writeup out before the talk but didn't have time. That means= =20 that my TABConf talk was not able to link to this mailing list post. But=20 that also means that this mailing list post is able to link to the TABConf= =20 talk: https://www.youtube.com/watch?v=3Dcqjo3rmd6hY. Wonder if anyone has ideas / improvements / downsides to this idea. Thanks= =20 for any feedback! -Tadge=20 --=20 You received this message because you are subscribed to the Google Groups= =20 "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an= =20 email to bitcoindev+...@googlegroups.com. To view this discussion visit=20 https://groups.google.com/d/msgid/bitcoindev/05195086-ee52-472c-962d-0df2e0= b9dca2n%40googlegroups.com . --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 19701913-9225-45b3-8a2c-d620c53d8873n%40googlegroups.com. ------=_Part_316497_2061236534.1762047285703 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tadge, Conduition, and all,

I think Conduition's stateless ta= ke can go a little further with a simple indexing trick. Give every address= a monotonic index i, and from the seed derive a long sequence of shared ke= ys K_0, K_1, .... When we create address i, we add taproot leaves for K_i t= hrough K_{i+N-1}. That is a sliding window of size N.

When a spe= nd gathers a set of our inputs, let i_min be the smallest index and i_max t= he largest. If i_max - i_min < N, every input already has a leaf for K_{= i_max}, so we reveal that leaf everywhere and sign once under K_{i_max}. No= state needed: the rule is deterministic.

Because an index i is = spent only once, the first spend that touches it is the only transaction th= at ever reveals K_i. Backups stay simple too: any device with the master se= ed can recompute the indices and shared keys without knowing past wallet st= ate, as long as it knows N.

Larger N means more leaves per addre= ss but keeps aggregation working across older UTXOs. Wallets that need gian= t sweeps can still consolidate inside windows. The number of full signature= s in a transaction is the number of windows inputs belong to.

Cu= rious whether this sounds workable.

Best,
Boris

=
On Saturday, November 1, 2025 at 8:09:52=E2=80=AFPM = UTC-3 conduition wrote:
Neat idea! The = need to commit each script pubkey to other prevouts in the TX would probabl= y hold the concept back from being practical, especially for deterministic = backup wallets which is likely the bulk of modern Bitcoin usage. I could im= agine offline/hardware wallets having a very tough time with this.

Consider a mo= re conservative (but also very common) use case: Aggregating inputs control= led by the same owner. In this context, what the sender is really trying to= prove here isn't whether UTXO A committed to UTXO B. For signature aggrega= tion across commonly-owned inputs, they just need to be able to prove that = UTXO A and UTXO B are spendable under the same pubkey, and that they, the p= ubkey owner, authorized both of them via a single signature.

So instead of commi= tting a taptree to pre-existing UTXOs (which creates statefulness), you cou= ld commit a taptree to a deterministic set of pubkeys, such as "the nearest= 100 addresses in the same BIP32 account". At spending time, we reveal the= same pubkey's script leaf on all inputs, plus a signature that covers all = the inputs.=C2=A0This would allow stateless address generation, while also allo= wing a single signature to cover all common inputs in a wallet.

This woul= d have pretty bad effects on UTXO privacy, because the common-owner heurist= ic would become even stronger and would be provable on-chain, but OP_CIV wo= uld also likely have a similar effect on chain forensics. Maybe the fee sav= ings would be worth it, esp for big exchanges which consolidate hundreds or= thousands of UTXOs at a time.

-conduition
=
On Saturday, November 1st, 2025 at 2:02 PM, Tadge Dryja <r...@awsomnet.org> wrote:
Hello-

Here's an idea for Post-Quantum cross-input s= ignature aggregation. It's not quite "signature aggregation" the way we no= rmally think of it, but gives similar benefits while not being tied to a pa= rticular signature scheme.
Folks have discussed Cross= -input signature aggregation (CISA) in Bitcoin a while now, and while relat= ed research such as MuSig2, FROST, and ROAST have been implemented in walle= ts, so far there is no consensus change in bitcoin to enable CISA. My hunc= h is that one of the reasons this hasn't been adopted is that the space sav= ings aren't that large. With taproot outputs, signatures are 64 bytes, and= discounted to 16 vBytes. https://github.com/BlockstreamResearch/cross-input-aggregation/b= lob/master/savings.org shows a 7.1% vByte savings using full aggregatio= n. Signatures just aren't that big of a part of the transaction, especiall= y after the 75% segwit discount.

One place where= the size of signatures *is* a problem is with post-quantum signatures. Th= e two most discussed PQ signature schemes, SPHINCS+ and CRYSTALS-Dilithium,= both have pubkey+signature sizes in the kilobytes range. This would be a = great opportunity for CISA, since even with a 75% witness discount, signatu= res would cost over 90% of the vBytes in a transaction.

Unfortunately all the great EC based signature aggregation tools pe= ople have built don't work for lattices and hash-based signatures. Here's = a way to get some of the same effects which would work with any signature t= ype (including EC signatures, but if you've got EC signatures, existing CIS= A techniques are much better). I'm not attached to the name but for people= familiar with bitcoin, the easiest to understand would be OP_CIV or OP_CHE= CKINPUTVERIFY.

The basic idea is that a transact= ion input can prove a linkage to another input within the same transaction,= and by pointing to another input say "that's the signature I'm using", wit= hout providing one of its own. Take for example a transaction with 2 input= s: input 0 and input 1. Input 0 has a normal (perhaps PQ) SIGHASH_ALL sign= ature. Input 1 has a proof pointing to input 0. Since input 0 exists with= in the transaction, input 1 is valid.

The argume= nts and usage of the would be:

<input_index> <output_in= dex> <txid> <nonce> <OP_CIV>

Where <inp= ut_index> is the input number in the current transaction being validated= to look. If this stack element isn't a number, or the number exceeds the = number of inputs in the transaction, the opcode fails.

<outpu= t_index> and <txid> together form the outpoint, or UTXO identifier= to look for at the <input_index> location. If these two stack eleme= nts are malformed, or the resulting outpoint does not match the outpoint se= en in the transaction, the opcode fails.

<nonce> is popped= off the stack and discarded. It can be OP_0, but random bytes here can pr= otect privacy. After an output is spent revealing the taptree, someone cou= ld try to grind through other possible outpoints to see if they show up els= ewhere in the tree, trying to assign UTXOs to the same owner. This nonce w= ould prevent such an attack.

That's pretty much it for script ev= aluation.

The idea would be that a taproot tree would have at th= e root a "normal" pubkey capable of creating arbitrary signatures. Lower d= own in the tree, there would be several / many OP_CIV scripts, each one poi= nting to a different outpoint. When a UTXO is being spent, if it is being = spent in the same transaction as any of the UTXOs pointed to by the OP_CIV = scripts, one of those can be revealed instead of supplying a signature. At= least one input in a transaction would have a normal signature; it's not p= ossible for every input in a transaction to use OP_CIV since that would req= uire a hash cycle.

For the wallet side implementation, every tim= e a wallet generates a new address, it looks up some or all of the current = UTXOs in the wallet, and adds a branch for each of them in the taproot tree= . The wallet adds blinding data to each OP_CIV script to prevent an attack= er from being able to guess other UTXO linkages other than those explicitly= revealed. The last argument, <input_index>, is left empty in the sc= ript and supplied at spending time. To avoid the need to generate and stor= e additional entropy, the wallet can generate the blinding data determinist= ically, using the root pubkey's private key and the outpoint being pointed = to, somewhat like the use of RFC6979 for ECDSA nonces. (Eg nonce =3D hash(= private_key, outpoint)).

Wallets constructed in such a way would= often only need 1 signature per transaction, as all other UTXOs could poin= t to the oldest input in the transaction. This savings doesn't work when a= new wallet generates many addresses at once, and then over time coins are = sent to those addresses. In that case a wallet would end up with a number = of UTXOs which don't point to each other. Those UTXOs would all need to si= gn, but they might be paired with later UTXOs which point to them.
Deterministic key wallets

One complication is key recovery f= or deterministic wallets. If only the master key / seed phrase is known, a= ll the root pubkeys can be recovered, but the wallet has "forgotten" which = pubkeys point to which UTXOs. Deterministic nonces make recovery possible,= but in a naive implementation, there would be an exponential blowup if whe= n addresses are created they point to all existing UTXOs in the wallet. Th= ere are several workarounds, such as limiting the number of OP_CIV scripts = in the tree to eg 10 (resulting in a ~1000X slowdown in recovery while main= taining a good chance of OP_CIV use), or including OP_CIV scripts pointing = to all TXOs that the wallet knows have already been spent, increasing taptr= ee size but reducing the number of guesses needed for recovery.

= Address re-use and replay attacks

I don't think replay attacks = are too much of a problem here. I thought it might be, but OP_CIV points t= o outpoints, not addresses or keys, so address reuse for the UTXOs being po= inted to shouldn't matter. For address re-use with addresses that have OP_= CIV scripts in them, replay attacks are avoided by using SIGHASH_ALL in the= input that does sign, so that even if an attacker learns the full taptree = of all the UTXOs of a wallet, they can't construct or modify a transaction = without the ability to sign.

Other uses

There might b= e other contract use cases for such an opcode even today. I haven't come u= p with one, but it gives a tool where you can reveal a secret (a spend path= & nonce) that allows someone to take a UTXO, but only if they already = control a different specified UTXO. I think it's mostly useful for making = PQ transactions smaller, but transaction introspection opcodes often have i= nteresting use cases and OP_CIV may as well

Real life example of= OP_CIV commitments

I gave a talk about this at TABConf a couple= weeks ago; I was hoping to have sent this writeup out before the talk but = didn't have time. That means that my TABConf talk was not able to link to = this mailing list post. But that also means that this mailing list post is= able to link to the TABConf talk: https://www.youtube.co= m/watch?v=3Dcqjo3rmd6hY.

Wonder if anyone has ideas / improv= ements / downsides to this idea. Thanks for any feedback!
-Tadge

--
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 e= mail to bitcoindev+...@go= oglegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/05195086-ee52-472c-962d-0df2e0b9dca2n%40googlegroups.com= .

--
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/bitcoind= ev/19701913-9225-45b3-8a2c-d620c53d8873n%40googlegroups.com.
------=_Part_316497_2061236534.1762047285703-- ------=_Part_316496_538412423.1762047285703--