From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 02 Nov 2025 11:27:59 -0800 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vFdk5-0001xM-Vz for bitcoindev@gnusha.org; Sun, 02 Nov 2025 11:27:59 -0800 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-6569a7babccsf2269941eaf.0 for ; Sun, 02 Nov 2025 11:27:57 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1762111672; cv=pass; d=google.com; s=arc-20240605; b=aqU9TrS1HnKeVTGw9TIm18MFQ7SSVcaoaqkNXIHgnJcy5F1s/GRIO9FhbVkwJzUpKN FWtSnr3UxJBdMHZBheJwCT5df1My9jDTXiFbdmUyBb8MzkEQMCHjoKo69VWvAOMBYvmZ G7vMykUXKvl6Ip3vaez68iqxDo/aW+j7OcXOMh628461jC8E7XYxWCPnTj6oYaU7nIt0 UFMsFY2OYRgg0K+ou0LKnccdbIrpzYWdk3elQw6X5uPsFTi1TO1VBPa3gdiun9iZxRPf 4Ww5W1HZ9u2LgtB33BynHeRmhFIZtI2NKgdtfa7ZI4Vlf6IGNt2cSWpiv0cwE8w2Djsr TDOw== ARC-Message-Signature: i=2; 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:content-transfer-encoding:to :subject:message-id:date:from:in-reply-to:references:mime-version :sender:dkim-signature; bh=hK6hKcpjASruNJNdnop3VCkHZVIxwqtUxtttDsRkbgw=; fh=4GP1vKWet5UytGdHANDpBcHjQTptTzjdF9BdFuSjzuU=; b=SMIQ5BVw+CASZq3oXQeK+9qyeNMoj7AgLnWjU2jRBRJ0cFKgf6z4xm7KoZR/4ry2M+ +/J2+quLdF+Upohnn4+jBwzktXC91AQpEEk9Ypq0uaPIok98qk/ZUYgNmgvoEuwhtYt6 M81h4JP5tAvobKQ3o/tHBL8XPM4lt7C44JzOSSDxkcZXm9h+P973s6YYe4wFH13TtsPY u42GyybggRtjc51g4sDUPAsIHuBylolxOu34JY5AdssQT6JZ2/1yJ/BRA/6a29/ixxva flkInN9ZeTba6Pf/p5+vTM7Jk5ohUVa7/yxyCkY3MoZ35QqECboaBusPzkLS3Hrq9HML lSuQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@awsomnet-org.20230601.gappssmtp.com header.s=20230601 header.b=Fa+Z4TeJ; spf=none (google.com: rx@awsomnet.org does not designate permitted sender hosts) smtp.mailfrom=rx@awsomnet.org; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762111672; x=1762716472; 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:content-transfer-encoding:to:subject:message-id :date:from:in-reply-to:references:mime-version:sender:from:to:cc :subject:date:message-id:reply-to; bh=hK6hKcpjASruNJNdnop3VCkHZVIxwqtUxtttDsRkbgw=; b=kK5qhxXM126wGQXcti5mMYy5MXxm9xpegnQ3OV/+UJe/JbP0yD1n5GzQ9GJ61CC2iO 647md9ZMpyZVN7pXtjS6itTwXtusIHPqJ0aekUMSoNGvoDOp4Q3+wyKBLkfQqWP60bdb qOpu5bRIkNNfBdJmv6P01IlbbYHgQZss0eW1NqpXwpDTxOosJeeDKVvk23W6tOlE/D+6 NhftFzWsWuBpcOE55D8MMBaOGNRf1mhi+INrao1ypRcJZHFn4n/oO+WUq7GoaSWJJXxi gBs5yNgneTm612NZ/EO+4BtNQ0aiwbTd2IaR/1aBvbmcHoY/mmDPTnGLHQ8PbBD91+5b Kyjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762111672; x=1762716472; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=hK6hKcpjASruNJNdnop3VCkHZVIxwqtUxtttDsRkbgw=; b=tq2VxM4emwCC927AZVNp+3qzdh6/WP6qBWY203fRIzKKwIT9TRNPh/5UbQo9VEJqBY icdzW/Cd3BXAPxhTjWvL2plTV/cxm93Qd39kbS8RLeuI+Z2RKWOlfU+RZ8vS7RhX84AG V3XQNIleOgTmA8ljsl60hcAHWuZzH/B5cJPJKBLyeL/RytPE1ijArcNv8VN6jwZt38aP OTClyP4tAnAAaPO1tPbagTNFpPGhpQJ52xizjHqa/otQSBiSKj/CYubswkStzkUCwETF FLKY0w+5RvdAzXWhjT0DXdmWqpf6iBRqB8af1dJ87bBj47YTZNwO5WCk45/7eq2wOPZO KRCw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVtWoExiRD9R8+fyC1ELkOQVJ3ybplTAl0i32BGxxtrqVOVTmom/ZOzCs0c3tpeJ6iGt2shQF2LHep3@gnusha.org X-Gm-Message-State: AOJu0Yxxuu9Mgmzjy4zAEHzveBvKlBPobtbgThOTKnO0RQgGn9QO960g mWdR1Q+elwvA3bZnFo5xYV7s2cppq9hkKF8TLjiPtLBQaNzbPru5x321 X-Google-Smtp-Source: AGHT+IE0TMESMgky2z34VsmUF+hHUEJu23SMl0vQ3ym7l0w+izo4Lu3omIQ10XqSE9AwsuHqO7KPEQ== X-Received: by 2002:a05:6871:51ca:b0:3c9:8a1b:7e53 with SMTP id 586e51a60fabf-3dac9f0dc2emr4211220fac.6.1762111671780; Sun, 02 Nov 2025 11:27:51 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+aiRVOTJRQYQwFvanzYGp/cql/ytcM4BiKIseOY7ULa8g==" Received: by 2002:a05:6871:8702:20b0:3de:cd92:aba0 with SMTP id 586e51a60fabf-3decd930253ls65720fac.1.-pod-prod-01-us; Sun, 02 Nov 2025 11:27:48 -0800 (PST) X-Received: by 2002:a05:6808:4f21:b0:441:8f74:fb2 with SMTP id 5614622812f47-44f9602f9f3mr4475197b6e.63.1762111667966; Sun, 02 Nov 2025 11:27:47 -0800 (PST) Received: by 2002:a05:6808:aab:b0:442:1282:b401 with SMTP id 5614622812f47-44f994aeb87msb6e; Sun, 2 Nov 2025 10:47:51 -0800 (PST) X-Received: by 2002:a05:6a20:3ca1:b0:263:9d85:3733 with SMTP id adf61e73a8af0-348cbdaa917mr13799615637.31.1762109269482; Sun, 02 Nov 2025 10:47:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1762109269; cv=none; d=google.com; s=arc-20240605; b=CslU4rJ6vfgNeIKenipbXMqAHimnppw1mvnJl+uswrzxJyitZPxBGbd46JRpdRh7Ro 1TjUWyUDJtBDeOpzR27M8n9iTGGbPRg54vlzHXQYfvwXk0QM9yIr1rW3mWxVbz6+4owo SDJejYnfqmS6IB1MIRuB1DPTsAL42qsL/9XeaSKC/4213O6GfINfair1BLAgAlgeYBbz dDemAbJjDCzcsALuvYe/++lDww36x1QhAc7VxG94L5ueIJmS3X30N1TFyeBeu39yMegs MjByOpH0KNWZJHx2KXuhbG3nNyGa51Ol08Fh4l/CfP+kiVVlQx9l7JkwVpx5Os644Erf N+tA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=n2nVVGX6XUX7gCPASYrCNCIMQ/FOy+NgSk77kSPsW1k=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=LEbNiJpFhIBOBdE9bzw16HtSgSvyQ+Hk1/O++1cAh9BWi32h857gbgldiuDdHgdEdr rKv4UjL8wvRcD3WeoDnuV0QVrJhz7NSXqoURqL2NgYB4BirGtrtll8CP/rEDjjChJSAe x28F4Y3SUrTt7aNUHpZIe7GHjpNOmIqgEY1It48+OODKMtFPzeNc5sCs0Rky/aq95DAC 9aIadxfP1ApB62UOtyG64QM4D/A6Dd+MEkRnG1/dksmSvYsVXFfGn4qanrlASDjlhT3s i9m1Cz6LtQVGTZwdvIxsJCiuMRR+Kgs/M/HCHvEVr9myuUXbFEFn59JnUZsBg7XsoelY 2zEQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@awsomnet-org.20230601.gappssmtp.com header.s=20230601 header.b=Fa+Z4TeJ; spf=none (google.com: rx@awsomnet.org does not designate permitted sender hosts) smtp.mailfrom=rx@awsomnet.org; dara=pass header.i=@googlegroups.com Received: from mail-yx1-xb12e.google.com (mail-yx1-xb12e.google.com. [2607:f8b0:4864:20::b12e]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-b99ba4bf309si126573a12.3.2025.11.02.10.47.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Nov 2025 10:47:49 -0800 (PST) Received-SPF: none (google.com: rx@awsomnet.org does not designate permitted sender hosts) client-ip=2607:f8b0:4864:20::b12e; Received: by mail-yx1-xb12e.google.com with SMTP id 956f58d0204a3-63f96d5038dso2230859d50.1 for ; Sun, 02 Nov 2025 10:47:49 -0800 (PST) X-Gm-Gg: ASbGnct3cX7qmUyGnbsVixFYxfml4+Wv/RuhnhuJhfGQUbAbEONZs/aiYEoctmt92uv AmGrHqkqPz4ZA5zWE05TtIWU/NgrCCTjiCura0RL1d0FdZph1eRRVya0zHZj0Zh8MeII05zGws7 9o4BAoowTw9vNuD5X62Yi/6Z3UBYoJiEdZ2ngNyyn7QvPdJRxMmtolNNYeDUTo1yQZsdytJAFfN 4qSeWPbj+qIuq0iJ036FVZu3UtWlgeuCTq18xKH3W47rX9BquFnW3m740qufOHNlLA5SCUotM9O SJAReQ== X-Received: by 2002:a05:690c:6f85:b0:786:5212:4a7b with SMTP id 00721157ae682-78652124de4mr85183457b3.58.1762109268370; Sun, 02 Nov 2025 10:47:48 -0800 (PST) MIME-Version: 1.0 References: <05195086-ee52-472c-962d-0df2e0b9dca2n@googlegroups.com> <19701913-9225-45b3-8a2c-d620c53d8873n@googlegroups.com> In-Reply-To: <19701913-9225-45b3-8a2c-d620c53d8873n@googlegroups.com> From: adiabat Date: Sun, 2 Nov 2025 13:47:37 -0500 X-Gm-Features: AWmQ_bmbG_RGaGdKykww4S6Ug69n9mi_nQuCBxr--EXZSyKF5vOxlwq1A5Bhw6o Message-ID: Subject: Re: [bitcoindev] OP_CIV - Post-Quantum Signature Aggregation To: Bitcoin Development Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: rx@awsomnet.org X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@awsomnet-org.20230601.gappssmtp.com header.s=20230601 header.b=Fa+Z4TeJ; spf=none (google.com: rx@awsomnet.org does not designate permitted sender hosts) smtp.mailfrom=rx@awsomnet.org; 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.8 (/) Hi Conduition & Boris- (I wrote a response yesterday but it's gone, I think I used the google groups interface instead of the e-mail client... anyway if a similar / duplicate response ends up on this mailing list, oops) I agree that using "addresses" (scriptPubKeys) (yeah I know they're not quite the same thing but close enough :) ) instead of outpoints would probably work, and would have some advantages. But I lean towards using outpoints mostly for privacy reasons. It seems that if you're OK with having 1 address link to another address, then an obvious optimization would be to have the addresses implicitly linked to themselves. So if a transaction has 2 inputs, both with the same scriptPubKey, only 1 of them needs to sign. Why bother sending and verifying 2 signatures from the same key? But if you do implement that, then the incentive for all wallets is to just use 1 address. Because not only is it simpler, it's also cheaper. Part of why I like linking to outpoints is that it disincentivizes address re-use. If you just keep using the same address many times, you can't use OP_CIV, and can't get any fee savings through it. If instead you generate a new address each time you need one, and that address commits to some / most of your UTXOs at the time, then you can use OP_CIV and will have lower fees when spending. You could, in theory, use the same root pubkey and *only* change which OP_CIV branches you add, but that seems like a bad idea: if you're changing the address anyway, why not change the pubkey. A related reason is that in SPHINCS+ and other hash-based signature designs, one of the most important parameters is how many times a pubkey can be re-used before becoming insecure. Since in bitcoin we tend to want to discourage address re-use, it makes sense to reduce that parameter, which would give smaller, faster to verify signatures, at the cost of not allowing many instances of address re-use. These are somewhat subjective reasons, and I agree that in terms of coding a wallet to do this stuff, having addresses point to each other is probably easier than having addresses point to outpoints. I think the privacy gains could be worth using outpoints, but even then, maybe there's a better way that can really preserve privacy, and be used with coinjoin transactions. (OP_CIV maybe could but only with multisig outputs set up beforehand, which seems impractical.) Thanks for feedback on this & I will also keep looking at it -Tadge On Sat, Nov 1, 2025 at 9:45=E2=80=AFPM Boris Nagaev wro= te: > > Hi Tadge, Conduition, and all, > > I think Conduition's stateless take 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 keys K_0, K_1, .... When we create address= i, we add taproot leaves for K_i through K_{i+N-1}. That is a sliding wind= ow of size N. > > When a spend gathers a set of our inputs, let i_min be the smallest index= and i_max the largest. If i_max - i_min < N, every input already has a lea= f 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 that ever reveals K_i. Backups stay simple too: any d= evice with the master seed can recompute the indices and shared keys withou= t knowing past wallet state, as long as it knows N. > > Larger N means more leaves per address but keeps aggregation working acro= ss older UTXOs. Wallets that need giant sweeps can still consolidate inside= windows. The number of full signatures in a transaction is the number of w= indows 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 wrot= e: > > Neat idea! The need to commit each script pubkey to other prevouts in the= TX would probably hold the concept back from being practical, especially f= or deterministic backup wallets which is likely the bulk of modern Bitcoin = usage. I could imagine offline/hardware wallets having a very tough time wi= th this. > > Consider a more conservative (but also very common) use case: Aggregating= inputs controlled by the same owner. In this context, what the sender is r= eally trying to prove here isn't whether UTXO A committed to UTXO B. For si= gnature aggregation 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 t= hat they, the pubkey owner, authorized both of them via a single signature. > > So instead of committing a taptree to pre-existing UTXOs (which creates s= tatefulness), you could 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 signat= ure that covers all the inputs. This would allow stateless address generati= on, while also allowing a single signature to cover all common inputs in a = wallet. > > This would have pretty bad effects on UTXO privacy, because the common-ow= ner heuristic would become even stronger and would be provable on-chain, bu= t OP_CIV would also likely have a similar effect on chain forensics. Maybe = the fee savings 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 wrote: > > Hello- > > Here's an idea for Post-Quantum cross-input signature aggregation. It's n= ot quite "signature aggregation" the way we normally think of it, but gives= similar benefits while not being tied to a particular signature scheme. > Folks have discussed Cross-input signature aggregation (CISA) in Bitcoin = a while now, and while related research such as MuSig2, FROST, and ROAST ha= ve been implemented in wallets, so far there is no consensus change in bitc= oin to enable CISA. My hunch is that one of the reasons this hasn't been ad= opted is that the space savings aren't that large. With taproot outputs, si= gnatures are 64 bytes, and discounted to 16 vBytes. https://github.com/Bloc= kstreamResearch/cross-input-aggregation/blob/master/savings.org shows a 7.1= % vByte savings using full aggregation. Signatures just aren't that big of = a part of the transaction, especially after the 75% segwit discount. > > One place where the size of signatures *is* a problem is with post-quantu= m signatures. The two most discussed PQ signature schemes, SPHINCS+ and CRY= STALS-Dilithium, both have pubkey+signature sizes in the kilobytes range. T= his would be a great opportunity for CISA, since even with a 75% witness di= scount, signatures would cost over 90% of the vBytes in a transaction. > > Unfortunately all the great EC based signature aggregation tools people h= ave built don't work for lattices and hash-based signatures. Here's a way t= o get some of the same effects which would work with any signature type (in= cluding EC signatures, but if you've got EC signatures, existing CISA techn= iques are much better). I'm not attached to the name but for people familia= r with bitcoin, the easiest to understand would be OP_CIV or OP_CHECKINPUTV= ERIFY. > > The basic idea is that a transaction input can prove a linkage to another= input within the same transaction, and by pointing to another input say "t= hat's the signature I'm using", without providing one of its own. Take for = example a transaction with 2 inputs: input 0 and input 1. Input 0 has a nor= mal (perhaps PQ) SIGHASH_ALL signature. Input 1 has a proof pointing to inp= ut 0. Since input 0 exists within the transaction, input 1 is valid. > > The arguments and usage of the would be: > > > > Where is the input number in the current transaction being = validated to look. If this stack element isn't a number, or the number exce= eds the number of inputs in the transaction, the opcode fails. > > and together form the outpoint, or UTXO identifier = to look for at the location. If these two stack elements are = malformed, or the resulting outpoint does not match the outpoint seen in th= e transaction, the opcode fails. > > is popped off the stack and discarded. It can be OP_0, but random= bytes here can protect privacy. After an output is spent revealing the tap= tree, someone could try to grind through other possible outpoints to see if= they show up elsewhere in the tree, trying to assign UTXOs to the same own= er. 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" p= ubkey capable of creating arbitrary signatures. Lower down in the tree, the= re would be several / many OP_CIV scripts, each one pointing to a different= outpoint. When a UTXO is being spent, if it is being spent in the same tra= nsaction 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 possible for every inpu= t in a transaction to use OP_CIV since that would require a hash cycle. > > For the wallet side implementation, every time a wallet generates a new a= ddress, it looks up some or all of the current UTXOs in the wallet, and add= s a branch for each of them in the taproot tree. The wallet adds blinding d= ata to each OP_CIV script to prevent an attacker from being able to guess o= ther UTXO linkages other than those explicitly revealed. The last argument,= , is left empty in the script and supplied at spending time. = To avoid the need to generate and store additional entropy, the wallet can = generate the blinding data deterministically, using the root pubkey's priva= te 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 t= ransaction, as all other UTXOs could point to the oldest input in the trans= action. This savings doesn't work when a new wallet generates many addresse= s at once, and then over time coins are sent to those addresses. In that ca= se a wallet would end up with a number of UTXOs which don't point to each o= ther. Those UTXOs would all need to sign, but they might be paired with lat= er UTXOs which point to them. > > Deterministic key wallets > > One complication is key recovery for deterministic wallets. If only the m= aster key / seed phrase is known, all the root pubkeys can be recovered, bu= t the wallet has "forgotten" which pubkeys point to which UTXOs. Determinis= tic nonces make recovery possible, but in a naive implementation, there wou= ld be an exponential blowup if when addresses are created they point to all= existing UTXOs in the wallet. There are several workarounds, such as limit= ing the number of OP_CIV scripts in the tree to eg 10 (resulting in a ~1000= X slowdown in recovery while maintaining a good chance of OP_CIV use), or i= ncluding OP_CIV scripts pointing to all TXOs that the wallet knows have alr= eady been spent, increasing taptree 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 to outpoints, not addresses or keys, so addres= s reuse for the UTXOs being pointed to shouldn't matter. For address re-use= with addresses that have OP_CIV scripts in them, replay attacks are avoide= d by using SIGHASH_ALL in the input that does sign, so that even if an atta= cker learns the full taptree of all the UTXOs of a wallet, they can't const= ruct 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 = haven't come up 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 the= y already control a different specified UTXO. I think it's mostly useful fo= r making PQ transactions smaller, but transaction introspection opcodes oft= en 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 h= ave 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 th= at also means that this mailing list post is able to link to the TABConf ta= lk: https://www.youtube.com/watch?v=3Dcqjo3rmd6hY. > > Wonder if anyone has ideas / improvements / downsides to this idea. Thank= s 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= email to bitcoindev+...@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/05195086-ee52-472c-962d-0df2e0b9dca2n%40googlegroups.com. > > > -- > 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/bitcoinde= v/19701913-9225-45b3-8a2c-d620c53d8873n%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/= CAKEeUhhagHCBCd%2Bdgddq8xG4285u_2Li0vKLxvVsdQkGH3gL-w%40mail.gmail.com.