diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2025-03-05 14:46:08 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2025-03-05 14:57:04 -0800 |
| commit | d056934528a032ad2f00f34c41c155a1781aa125 (patch) | |
| tree | 241e627c751543a3a862fdc87a849ad3cec92f3b | |
| parent | 22a52ab9c9f261949934648be1602d49747e8d93 (diff) | |
| download | pi-bitcoindev-d056934528a032ad2f00f34c41c155a1781aa125.tar.gz pi-bitcoindev-d056934528a032ad2f00f34c41c155a1781aa125.zip | |
Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
| -rw-r--r-- | 5f/e2d85ca51f37753b8516f5279e176b8004ad94 | 860 |
1 files changed, 860 insertions, 0 deletions
diff --git a/5f/e2d85ca51f37753b8516f5279e176b8004ad94 b/5f/e2d85ca51f37753b8516f5279e176b8004ad94 new file mode 100644 index 000000000..76ae4e77f --- /dev/null +++ b/5f/e2d85ca51f37753b8516f5279e176b8004ad94 @@ -0,0 +1,860 @@ +Delivery-date: Wed, 05 Mar 2025 14:57:04 -0800 +Received: from mail-yb1-f183.google.com ([209.85.219.183]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBC3PT7FYWAMRBNNNUO7AMGQEN4IGU2I@googlegroups.com>) + id 1tpxfi-0004QO-Ad + for bitcoindev@gnusha.org; Wed, 05 Mar 2025 14:57:04 -0800 +Received: by mail-yb1-f183.google.com with SMTP id 3f1490d57ef6-e39fd56398csf33413276.1 + for <bitcoindev@gnusha.org>; Wed, 05 Mar 2025 14:57:02 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=googlegroups.com; s=20230601; t=1741215416; x=1741820216; 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=noJ6JP82JhBabthR/m6z9YlUqdLlvM+RHAaWZ5pfr0U=; + b=X2Kz279T30Cx1aEdtQdwnhUA5Z0er43wz86j4TzyyPytyBhVAZ96cO5Y08vKQ8Gv78 + hXDzU8uqFDnJm4kbTwiBIntO6piPej/FrDLkgz3xpoVDeq60ZFjVs1F9mSB1xndhP6Sy + 0w/kjBPHhRhxtQW9UcdyH0k9Q53Ng/23XgsTy3WSggFlnNBpAcfZ4vttr+Ut4t0+eMsx + Ut+wqou6rh5JMcRjfB126vxIB/ejIc6VVahNw4RwO/H8FmchEQ4YKMVaAAqZkdX2QCSh + pZbWBpllre0IZ2TwkNCip8T2rWtskQOi50ZY1s9EZbvuBhdJ7kWzt/iM21BGe9xoGL+s + 7uqQ== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1741215416; x=1741820216; 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=noJ6JP82JhBabthR/m6z9YlUqdLlvM+RHAaWZ5pfr0U=; + b=T2F3sFWUUrgi6CIUuVCCpHXtd0lpwQUU/bz3jC0rV5INFUSEVS4kYuRaCsiFIXZrxS + OxszGrExnBEJOTjfknnd5EhMvT+rCcKMTr8houuugN36dQOlsQtrNJQxn5N9A6E/O+Cu + LBguVRer6f6ZwYqbO+wvN4cC4ldX38jdCUJ3hJNJj99FIOJRnLOZTcuex75TrIBEaef1 + XUy8kFk1A9kgPAMW3NJNKaOtM/D8XpunoDZmYydhY1xzbefJG2fxKUVO8fWxGus676EZ + ChMMiD7EgZbF54t+ubg6mBovD8hiLwnm6X4G7HUUNr88oO/vCtBCkxEUBXqrHQBk/LZ5 + 5bKA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1741215416; x=1741820216; + 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=noJ6JP82JhBabthR/m6z9YlUqdLlvM+RHAaWZ5pfr0U=; + b=apgsiYStnjR+A5ss56d9kKqsKtdlsldGjrBr4zOZNCw+lvduHn+aLp9pmTVkvsiBhm + 3sbqBwjNIvbwlO4dXjlZ93Ro6NTtoAMMT+MLMa2cA0oP+iGHPHY8jVhYoM9QTgpEvCKe + BvTm7EsdtP4i7KA0XveiUbGRMCuiGbc33wZ2fUX/0zZmTMfi0m14HzFRUz2eytpSpuEd + bjgzn+HVvX2FcFVmDt2UvErB2fOb22nZtH5CbniE6CNrjUGEgIKgxar9G41C+lFHufOD + 6s4v+XOz8nswPProMFmtsrRi2toXnduDlxZYhrQeSNYxq/VxalyJbGvzOtdrseMyaqXx + qvlw== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=1; AJvYcCUz7UDqOCpFD6dBu4IHAc7pChQwygQm0b+LBIn3V8+ZoXf5EGvsp3q5cv4mbI9VNUTny+k8Vh3e6iXk@gnusha.org +X-Gm-Message-State: AOJu0YyzpuxsR5iMaE9/cirv1W9mIL3bPUn0mLrexwHuilmWNJUkEgg1 + dzifIb2leHww3iRIv6BL4snW4rHAp+1M+8FApkY2BlsJUOCDnnIw +X-Google-Smtp-Source: AGHT+IFBvYVluUZFcTsyaFtIMfjZiBFJFpYhECuHSIAn+wlU4s+KbUaaRUa61bIxG29czM7e5AyjXQ== +X-Received: by 2002:a05:6902:2407:b0:e57:f841:949f with SMTP id 3f1490d57ef6-e611e1b1e7amr6165697276.19.1741215416279; + Wed, 05 Mar 2025 14:56:56 -0800 (PST) +X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVFy/+3lSCnv/VEGS7GmxxKJQsRhm2VuButrRcHAvlX6Uw== +Received: by 2002:a25:df45:0:b0:e61:b422:146b with SMTP id 3f1490d57ef6-e6348a06077ls343890276.2.-pod-prod-01-us; + Wed, 05 Mar 2025 14:56:52 -0800 (PST) +X-Received: by 2002:a05:690c:380d:b0:6fd:3dd3:c768 with SMTP id 00721157ae682-6fda2fecf3bmr68464697b3.2.1741215412731; + Wed, 05 Mar 2025 14:56:52 -0800 (PST) +Received: by 2002:a05:690c:b87:b0:6fb:b341:b6f6 with SMTP id 00721157ae682-6fda2c0e805ms7b3; + Wed, 5 Mar 2025 14:46:10 -0800 (PST) +X-Received: by 2002:a05:690c:3384:b0:6fd:a226:fb23 with SMTP id 00721157ae682-6fda2f2d8c1mr76569997b3.10.1741214768961; + Wed, 05 Mar 2025 14:46:08 -0800 (PST) +Date: Wed, 5 Mar 2025 14:46:08 -0800 (PST) +From: Antoine Riard <antoine.riard@gmail.com> +To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com> +Message-Id: <6a9d4eea-51bd-45d8-b839-4ac3cefdbb7en@googlegroups.com> +In-Reply-To: <A1uNlgzWNUB3L_ITCAGDB85UhNdcF4GX6zZhkaEFHPmLmQivzXnY7stFGtG8iR_8cmVCxiWklqO9VEN6SqDyO6fMEuN3gJDnDEOIN-60sDE=@protonmail.com> +References: <Z8eUQCfCWjdivIzn@erisian.com.au> + <A1uNlgzWNUB3L_ITCAGDB85UhNdcF4GX6zZhkaEFHPmLmQivzXnY7stFGtG8iR_8cmVCxiWklqO9VEN6SqDyO6fMEuN3gJDnDEOIN-60sDE=@protonmail.com> +Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="----=_Part_7770_538642493.1741214768530" +X-Original-Sender: antoine.riard@gmail.com +Precedence: list +Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com +List-ID: <bitcoindev.googlegroups.com> +X-Google-Group-Id: 786775582512 +List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com> +List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com> +List-Archive: <https://groups.google.com/group/bitcoindev +List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com> +List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>, + <https://groups.google.com/group/bitcoindev/subscribe> +X-Spam-Score: -0.5 (/) + +------=_Part_7770_538642493.1741214768530 +Content-Type: multipart/alternative; + boundary="----=_Part_7771_1561631642.1741214768530" + +------=_Part_7771_1561631642.1741214768530 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi AJ, + +> I don't believe the existence of a construction like this poses any=20 +> problems in practice, however if there is going to be a push to activate= +=20 +> BIP 119 in parallel with features that directly undermine its claimed=20 +> motivation, then it would presumably be sensible to at least update=20 +> the BIP text to describe a motivation that would actually be achieved by= +=20 +> deployment.=20 + +I do... + +https://gnusha.org/pi/bitcoindev/f594c2f8-d712-48e4-a010-778dd4d0cadb@Spark= +/ +https://blog.bitmex.com/txwithhold-smart-contracts/ + +Terminology in the article is the following, as a reminder: +- target transaction: a tx to be withheld +- target tx: a fee, which a victim pays for the target tx inclusion +- attacker: an actor willing to withhold the target tx +- victim: a spender of the target tx +- reward transaction: a tx paying out a reward to the miner which withheld= +=20 +a target tx + +With OP_CHECKSIGFROMSTACK, which is iirc <signature> <pubkey> <message> +as an input stack, one can have the <message> being an already spent=20 +transaction. + +From then, one can build a TxWithhold for a LN commitment transaction, wher= +e +the <message> is the latest valid commitment transaction to spend a chan=20 +funding +output (each counterparty re-build the remote commitment tx for=20 +counter-signature +of the 2-of-2 P2WSH). + +After that, one can build a script:=20 +<proof-of-target-UTXO-mining=3Dcommitment_tx" +OP_CSFS> OR <<bounty_timelock> <OP_CHECKLOCKTIMEVERIFY>=20 +<recursive_bounty_sig | +SIGHASH_SINGLE> OP_CHECKSIG. Using SIGHASH_SINGLE the TxWithhold attacker= +=20 +can +make the funding UTXO amount available as a "anyone-can-spend" and force a= +=20 +re- +commitment to the same tx-withholding script. + +There is no hash dependency, as the "proof-of-target-UTXO-mining" is a hash= +=20 +given +as part of the input stack, be it for legacy spends or segwit spends. + +One can have multiple script branches for all the versions of the commitmen= +t +transaction, at least the latest 2 no-penalty one. + +The TxWithhold attacker can publish the script in an unrelated inscription +in the chain itself, to make the "bribing" TxWithhold contract available to +any miner anonymously wishing to engage in a TxWithhold to maximize its=20 +income +for given hashrate capabilities. + +Bonus point: if you the reader can come with a construction to do a=20 +TxWithold on +the spend of any coinbase output, at least more than the delay of=20 +COINBASE_MATURITY=3D +100 blocks to get the `blockReward`. + +Bonus Bonus point: if you the reader can come with a detailed protocol for= +=20 +all +the miners in a N retarget period to get a reward % share of a TxWithhold= +=20 +instance +weighted by their respective hashrate capabilities, by only using on-chain +inscriptions. + +Best, +Antoine +OTS hash: 28d42f8caeedb4760f3a4ddb39adf5443edaf63741560e3cee264237c0c126b5 + +Le mercredi 5 mars 2025 =C3=A0 18:16:02 UTC, moonsettler a =C3=A9crit : + +> Hi AJ, +> +> I don't even think about this "recursion" as an issue in itself anymore.= +=20 +> The way CSFS enables "recursion" with deleted key covenants basically is= +=20 +> useful for some things not so much for others. Useful for vaults, possibl= +y=20 +> somewhat useful for spacechains, pretty useless for tokens. +> +> It's not even a really a meaningful distinction as you noted in general. +> +> What's more interesting is "do these set of changes allow for 'native'=20 +> fungible tokens you can _identify_ and interact with in script in a way= +=20 +> that is enforced by consensus"? Can you build AMMs for them? For a lot of= +=20 +> proposals currently discussed we actually know how to do that. Anything= +=20 +> fully generic will trivially unlock this capability. +> +> The two primitives involved are state carrying (amounts) and quining (aka= +=20 +> recursion). These are the truly significant thresholds for changes that c= +an=20 +> possibly alter the nature of bitcoin and how people use it. Only one of= +=20 +> them is not enough. Beyond these there remains the issue of novel trust= +=20 +> minimized two way pegs to other chains like Ethereum which would also be = +in=20 +> high demand, in fact probably prioritized in funding over all other thing= +s=20 +> we are discussing in relation to covenants. +> +> After all these years I'm confident that for LNhance (CTV+CSFS+IKEY+PC)= +=20 +> the answer is NO. +> +> BR, +> moonsettler +> +> On Wednesday, March 5th, 2025 at 1:01 AM, Anthony Towns < +> a...@erisian.com.au> wrote: +> +> > Hello world, +> >=20 +> > Some people on twitter are apparently proposing the near-term activatio= +n=20 +> of +> > CTV and CSFS (BIP 119 and BIP 348 respectively), eg: +> >=20 +> > https://x.com/JeremyRubin/status/1895676912401252588 +> > https://x.com/lopp/status/1895837290209161358 +> > https://x.com/stevenroose3/status/1895881757288996914 +> > https://x.com/reardencode/status/1871343039123452340 +> > https://x.com/sethforprivacy/status/1895814836535378055 +> >=20 +> > Since BIP 119's motivation is entirely concerned with its concept of +> > covenants and avoiding what it calls recursive covenants, I think it +> > is interesting to note that the combination of CSFS and CTV trivially +> > enables the construction of a "recursive covenant" as BIP 119 uses thos= +e +> > terms. One approach is as follows: +> >=20 +> > * Make a throwaway BIP340 private key X with 32-bit public key P. +> > * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and +> >=20 +> > its corresponding scriptPubKey K when combined with P as the internal= +=20 +> public +> > key. +> > * Calculate the CTV hash corresponding to a payment of some specific=20 +> value V +> > to K; call this hash H +> > * Calculate the BIP 340 signature for message H with private key X, cal= +l=20 +> it S. +> > * Discard the private key X +> > * Funds sent to K can only be spent by the witness data "<H> <S>" that= +=20 +> forwards +> >=20 +> > an amount V straight back to K. +> >=20 +> > Here's a demonstration on mutinynet: +> >=20 +> >=20 +> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmy= +jejrmqqx525gsk5nr58 +> >=20 +> > I'd encourage people to try implementing that themselves with their +> > preferred tooling; personally, I found it pretty inconvenient, which I +> > don't think is a good indication of ecosystem readiness wrt deployment. +> > (For me, the two components that are annoying is doing complicated +> > taproot script path spends, and calculating CTV hashes) +> >=20 +> > I don't believe the existence of a construction like this poses any +> > problems in practice, however if there is going to be a push to activat= +e +> > BIP 119 in parallel with features that directly undermine its claimed +> > motivation, then it would presumably be sensible to at least update +> > the BIP text to describe a motivation that would actually be achieved b= +y +> > deployment. +> >=20 +> > Personally, I think BIP 119's motivation remains very misguided: +> >=20 +> > - the things it describes are, in general, not "covenants" [0] +> > - the thing it avoids is not "recursion" but unbounded recursion +> > - avoiding unbounded recursion is not very interesting when arbitrarily +> > large recursion is still possible [1] +> > - despite claiming that "covenants have historically been widely +> > considering to be unfit for Bitcoin", no evidence for this claim has +> > been able to be provided [2,3] +> > - the opposition to unbounded recursion seems to me to either mostly +> > or entirely be misplaced fear of things that are already possible in +> > bitcoin and easily avoided by people who want to avoid it, eg [4] +> >=20 +> > so, at least personally, I think almost any update to BIP 119's=20 +> motivation +> > section would be an improvement... +> >=20 +> > [0] https://gnusha.org/pi/bitcoindev/20220719044...@erisian.com.au/=20 +> <https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/> +> > [1] https://gnusha.org/pi/bitcoindev/87k0dwr...@rustcorp.com.au/=20 +> <https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/> +> > [2]=20 +> https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@email.= +amazonses.com/=20 +> <https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d= +2-4a82b580ba99-000000@email.amazonses.com/> +> > [3] https://x.com/Ethan_Heilman/status/1194624166093369345 +> > [4] https://gnusha.org/pi/bitcoindev/2022021715...@erisian.com.au/=20 +> <https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/> +> >=20 +> > Beyond being a toy example of a conflict with BIP 119's motivation +> > section, I think the above script could be useful in the context of the +> > "blind-merged-mining" component of spacechains [5]. For example, if +> > the commitment was to two outputs, one the recursive step and the other +> > being a 0sat ephemeral anchor, then the spend of the ephemeral anchor +> > would allow for both providing fees conveniently and for encoding the +> > spacechain block's commitment; competing spacechain miners would then +> > just be rbf'ing that spend with the parent spacechain update remaining +> > unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would +> > need to be used to ensure the "one spacechain update per bitcoin block" +> > rule. (I believe mutinynet doesn't support ephemeral anchors however, s= +o +> > I don't think there's anywhere this can be tested) +> >=20 +> > [5]=20 +> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file= +-bmm-svg +> >=20 +> > (For a spacechain, miners would want to be confident that the private k= +ey +> > has been discarded. This confidence could be enhanced by creating X as = +a +> > musig2 key by a federation, in which case provided any of the private= +=20 +> keys +> > used in generating X were correctly discarded, then everything is fine, +> > but that's still a trust assumption. Simple introspection opcodes would +> > work far better for this use case, both removing the trust assumption +> > and reducing the onchain data required) +> >=20 +> > If you're providing CTV and CSFS anyway, I don't see why you wouldn't +> > provide the same or similar functionality via a SIGHASH flag so that yo= +u +> > can avoid specifying the hash directly when you're signing it anyway, +> > giving an ANYPREVOUT/NOINPUT-like feature directly. +> >=20 +> > (Likewise, I don't see why you'd want to activate CAT on mainnet withou= +t +> > also at least re-enabling SUBSTR, and potentially also the redundant +> > LEFT and RIGHT operations) +> >=20 +> > For comparison, bllsh [6,7] takes the approach of providing +> > "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but +> > for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV +> > equivalent would then either involve simplying writing: +> >=20 +> > (=3D (bip342_txmsg 3) 0x.....) +> >=20 +> > meaining "calculate the message hash of the current tx for=20 +> SIGHASH_SINGLE, +> > then evaluate whether the result is exactly equal to this constant" +> > providing one of the standard sighashes worked for your use case, or +> > replacing the bip342_txmsg opcode with a custom calculation of the tx +> > hash, along the lines of the example reimplementation of bip342_txmsg +> > for SIGHASH_ALL [8] in the probably more likely case that it didn't. If +> > someone wants to write up the BIP 119 hashing formula in bllsh, I'd +> > be happy to include that as an example; I think it should be a pretty +> > straightforward conversion from the test-tx example. +> >=20 +> > If bllsh were live today (eg on either signet or mainnet), and it were +> > desired to softfork in a more optimised implementation of either CTV or +> > ANYPREVOUT to replace people coding their own implementation in bllsh +> > directly, both would simply involve replacing calls to "bip342_txmsg" +> > with calls to a new hash calculation opcode. For CTV behaviour, usage +> > would look like "(=3D (bipXXX_txmsg) 0x...)" as above; for APO behaviou= +r, +> > usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That +> > is, the underlying "I want to hash a message in such-and-such a way" +> > looks the same, and how it's used is the wallet author's decision, +> > not a matter of how the consensus code is written. +> >=20 +> > I believe simplicity/simfony can be thought of in much the same way; +> > with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour +> > [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like +> > behaviour [10]. +> >=20 +> > [6] https://github.com/ajtowns/bllsh/ +> > [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224 +> > [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx +> > [9]=20 +> https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.= +simf +> > [10]=20 +> https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.s= +imf +> >=20 +> > For me, the bllsh/simplicity approach makes more sense as a design +> > approach for the long term, and the ongoing lack of examples of killer +> > apps demonstrating big wins from limited slices of new functionality +> > leaves me completely unexcited about rushing something in the short ter= +m. +> > Having a flood of use cases that don't work out when looked into isn't +> > a good replacement for a single compelling use case that does. +> >=20 +> > Cheers, +> > aj +> >=20 +> > -- +> > You received this message because you are subscribed to the Google=20 +> Groups "Bitcoin Development Mailing List" group. +> > To unsubscribe from this group and stop receiving emails from it, send= +=20 +> an email to bitcoindev+...@googlegroups.com. +> > To view this discussion visit=20 +> https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.c= +om.au +> . +> + +--=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/= +6a9d4eea-51bd-45d8-b839-4ac3cefdbb7en%40googlegroups.com. + +------=_Part_7771_1561631642.1741214768530 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi AJ,<br /><br />> I don't believe the existence of a construction like= + this poses any <br />> problems in practice, however if there is going = +to be a push to activate <br />> BIP 119 in parallel with features that = +directly undermine its claimed <br />> motivation, then it would presuma= +bly be sensible to at least update <br />> the BIP text to describe a mo= +tivation that would actually be achieved by <br />> deployment. <br /><b= +r />I do...<br /><br />https://gnusha.org/pi/bitcoindev/f594c2f8-d712-48e4-= +a010-778dd4d0cadb@Spark/<br />https://blog.bitmex.com/txwithhold-smart-cont= +racts/<br /><br />Terminology in the article is the following, as a reminde= +r:<br />- target transaction: a tx to be withheld<br />- target tx: a fee, = +which a victim pays for the target tx inclusion<br />- attacker: an actor w= +illing to withhold the target tx<br />- victim: a spender of the target tx<= +br />- reward transaction: a tx paying out a reward to the miner which with= +held a target tx<br /><br />With OP_CHECKSIGFROMSTACK, which is iirc <si= +gnature> <pubkey> <message><br />as an input stack, one can = +have the <message> being an already spent transaction.<br /><br />Fro= +m then, one can build a TxWithhold for a LN commitment transaction, where<b= +r />the <message> is the latest valid commitment transaction to spend= + a chan funding<br />output (each counterparty re-build the remote commitme= +nt tx for counter-signature<br />of the 2-of-2 P2WSH).<br /><br />After tha= +t, one can build a script: <proof-of-target-UTXO-mining=3Dcommitment_tx"= +<br />OP_CSFS> OR <<bounty_timelock> <OP_CHECKLOCKTIMEVERIFY= +> <recursive_bounty_sig |<br />SIGHASH_SINGLE> OP_CHECKSIG. Using = +SIGHASH_SINGLE the TxWithhold attacker can<br />make the funding UTXO amoun= +t available as a "anyone-can-spend" and force a re-<br />commitment to the = +same tx-withholding script.<br /><br />There is no hash dependency, as the = +"proof-of-target-UTXO-mining" is a hash given<br />as part of the input sta= +ck, be it for legacy spends or segwit spends.<br /><br />One can have multi= +ple script branches for all the versions of the commitment<br />transaction= +, at least the latest 2 no-penalty one.<br /><br />The TxWithhold attacker = +can publish the script in an unrelated inscription<br />in the chain itself= +, to make the "bribing" TxWithhold contract available to<br />any miner ano= +nymously wishing to engage in a TxWithhold to maximize its income<br />for = +given hashrate capabilities.<br /><br />Bonus point: if you the reader can = +come with a construction to do a TxWithold on<br />the spend of any coinbas= +e output, at least more than the delay of COINBASE_MATURITY=3D<br />100 blo= +cks to get the `blockReward`.<br /><br />Bonus Bonus point: if you the read= +er can come with a detailed protocol for all<br />the miners in a N retarge= +t period to get a reward % share of a TxWithhold instance<br />weighted by = +their respective hashrate capabilities, by only using on-chain<br />inscrip= +tions.<br /><br />Best,<br />Antoine<br />OTS hash: 28d42f8caeedb4760f3a4dd= +b39adf5443edaf63741560e3cee264237c0c126b5<br /><br /><div class=3D"gmail_qu= +ote"><div dir=3D"auto" class=3D"gmail_attr">Le mercredi 5 mars 2025 =C3=A0 = +18:16:02 UTC, moonsettler a =C3=A9crit=C2=A0:<br/></div><blockquote class= +=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(2= +04, 204, 204); padding-left: 1ex;">Hi AJ, +<br> +<br>I don't even think about this "recursion" as an issue in = +itself anymore. The way CSFS enables "recursion" with deleted key= + covenants basically is useful for some things not so much for others. Usef= +ul for vaults, possibly somewhat useful for spacechains, pretty useless for= + tokens. +<br> +<br>It's not even a really a meaningful distinction as you noted in gen= +eral. +<br> +<br>What's more interesting is "do these set of changes allow for = +'native' fungible tokens you can _identify_ and interact with in sc= +ript in a way that is enforced by consensus"? Can you build AMMs for t= +hem? For a lot of proposals currently discussed we actually know how to do = +that. Anything fully generic will trivially unlock this capability. +<br> +<br>The two primitives involved are state carrying (amounts) and quining (a= +ka recursion). These are the truly significant thresholds for changes that = +can possibly alter the nature of bitcoin and how people use it. Only one of= + them is not enough. Beyond these there remains the issue of novel trust mi= +nimized two way pegs to other chains like Ethereum which would also be in h= +igh demand, in fact probably prioritized in funding over all other things w= +e are discussing in relation to covenants. +<br> +<br>After all these years I'm confident that for LNhance (CTV+CSFS+IKEY= ++PC) the answer is NO. +<br> +<br>BR, +<br>moonsettler +<br> +<br>On Wednesday, March 5th, 2025 at 1:01 AM, Anthony Towns <<a href dat= +a-email-masked rel=3D"nofollow">a...@erisian.com.au</a>> wrote: +<br> +<br>> Hello world, +<br>>=20 +<br>> Some people on twitter are apparently proposing the near-term acti= +vation of +<br>> CTV and CSFS (BIP 119 and BIP 348 respectively), eg: +<br>>=20 +<br>> <a href=3D"https://x.com/JeremyRubin/status/1895676912401252588" t= +arget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.googl= +e.com/url?hl=3Dfr&q=3Dhttps://x.com/JeremyRubin/status/1895676912401252= +588&source=3Dgmail&ust=3D1741301101168000&usg=3DAOvVaw0JIJbltba= +bTWAEXmwPjC0I">https://x.com/JeremyRubin/status/1895676912401252588</a> +<br>> <a href=3D"https://x.com/lopp/status/1895837290209161358" target= +=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com= +/url?hl=3Dfr&q=3Dhttps://x.com/lopp/status/1895837290209161358&sour= +ce=3Dgmail&ust=3D1741301101168000&usg=3DAOvVaw1i6u-p6XV0aTVGx8t_iz0= +J">https://x.com/lopp/status/1895837290209161358</a> +<br>> <a href=3D"https://x.com/stevenroose3/status/1895881757288996914" = +target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.goog= +le.com/url?hl=3Dfr&q=3Dhttps://x.com/stevenroose3/status/18958817572889= +96914&source=3Dgmail&ust=3D1741301101168000&usg=3DAOvVaw0GqQqUM= +4VIQal1nekqrFwX">https://x.com/stevenroose3/status/1895881757288996914</a> +<br>> <a href=3D"https://x.com/reardencode/status/1871343039123452340" t= +arget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.googl= +e.com/url?hl=3Dfr&q=3Dhttps://x.com/reardencode/status/1871343039123452= +340&source=3Dgmail&ust=3D1741301101168000&usg=3DAOvVaw2tfKZfPUs= +V55xJpH5_FOHr">https://x.com/reardencode/status/1871343039123452340</a> +<br>> <a href=3D"https://x.com/sethforprivacy/status/1895814836535378055= +" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.go= +ogle.com/url?hl=3Dfr&q=3Dhttps://x.com/sethforprivacy/status/1895814836= +535378055&source=3Dgmail&ust=3D1741301101168000&usg=3DAOvVaw0n0= +_zFB7fYAuV5aMxna_g4">https://x.com/sethforprivacy/status/189581483653537805= +5</a> +<br>>=20 +<br>> Since BIP 119's motivation is entirely concerned with its conc= +ept of +<br>> covenants and avoiding what it calls recursive covenants, I think = +it +<br>> is interesting to note that the combination of CSFS and CTV trivia= +lly +<br>> enables the construction of a "recursive covenant" as BI= +P 119 uses those +<br>> terms. One approach is as follows: +<br>>=20 +<br>> * Make a throwaway BIP340 private key X with 32-bit public key P. +<br>> * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIF= +Y OP_CTV", and +<br>>=20 +<br>> its corresponding scriptPubKey K when combined with P as the inter= +nal public +<br>> key. +<br>> * Calculate the CTV hash corresponding to a payment of some specif= +ic value V +<br>> to K; call this hash H +<br>> * Calculate the BIP 340 signature for message H with private key X= +, call it S. +<br>> * Discard the private key X +<br>> * Funds sent to K can only be spent by the witness data "<= +H> <S>" that forwards +<br>>=20 +<br>> an amount V straight back to K. +<br>>=20 +<br>> Here's a demonstration on mutinynet: +<br>>=20 +<br>> <a href=3D"https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pm= +afcsg2lf5jd33tznmyjejrmqqx525gsk5nr58" target=3D"_blank" rel=3D"nofollow" d= +ata-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://m= +utinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525= +gsk5nr58&source=3Dgmail&ust=3D1741301101168000&usg=3DAOvVaw2vPl= +HMbnv-PSut6NHSIdp6">https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pm= +afcsg2lf5jd33tznmyjejrmqqx525gsk5nr58</a> +<br>>=20 +<br>> I'd encourage people to try implementing that themselves with = +their +<br>> preferred tooling; personally, I found it pretty inconvenient, whi= +ch I +<br>> don't think is a good indication of ecosystem readiness wrt de= +ployment. +<br>> (For me, the two components that are annoying is doing complicated +<br>> taproot script path spends, and calculating CTV hashes) +<br>>=20 +<br>> I don't believe the existence of a construction like this pose= +s any +<br>> problems in practice, however if there is going to be a push to ac= +tivate +<br>> BIP 119 in parallel with features that directly undermine its clai= +med +<br>> motivation, then it would presumably be sensible to at least updat= +e +<br>> the BIP text to describe a motivation that would actually be achie= +ved by +<br>> deployment. +<br>>=20 +<br>> Personally, I think BIP 119's motivation remains very misguide= +d: +<br>>=20 +<br>> - the things it describes are, in general, not "covenants&quo= +t; [0] +<br>> - the thing it avoids is not "recursion" but unbounded r= +ecursion +<br>> - avoiding unbounded recursion is not very interesting when arbitr= +arily +<br>> large recursion is still possible [1] +<br>> - despite claiming that "covenants have historically been wid= +ely +<br>> considering to be unfit for Bitcoin", no evidence for this cl= +aim has +<br>> been able to be provided [2,3] +<br>> - the opposition to unbounded recursion seems to me to either most= +ly +<br>> or entirely be misplaced fear of things that are already possible = +in +<br>> bitcoin and easily avoided by people who want to avoid it, eg [4] +<br>>=20 +<br>> so, at least personally, I think almost any update to BIP 119'= +s motivation +<br>> section would be an improvement... +<br>>=20 +<br>> [0] <a href=3D"https://gnusha.org/pi/bitcoindev/20220719044458.GA2= +6986@erisian.com.au/" target=3D"_blank" rel=3D"nofollow" data-saferedirectu= +rl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://gnusha.org/pi/bitc= +oindev/20220719044458.GA26986@erisian.com.au/&source=3Dgmail&ust=3D= +1741301101168000&usg=3DAOvVaw2mVAakpOiQKUt_RNaOeQwU">https://gnusha.org= +/pi/bitcoindev/20220719044...@erisian.com.au/</a> +<br>> [1] <a href=3D"https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rus= +tcorp.com.au/" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"h= +ttps://www.google.com/url?hl=3Dfr&q=3Dhttps://gnusha.org/pi/bitcoindev/= +87k0dwr015.fsf@rustcorp.com.au/&source=3Dgmail&ust=3D17413011011690= +00&usg=3DAOvVaw0ZDUKUkoVAJBg4tbTaEOKz">https://gnusha.org/pi/bitcoindev= +/87k0dwr...@rustcorp.com.au/</a> +<br>> [2] <a href=3D"https://gnusha.org/pi/bitcoindev/0100017ee6472e02-0= +37d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/" target=3D"= +_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url= +?hl=3Dfr&q=3Dhttps://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d= +-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/&source=3Dgmail= +&ust=3D1741301101169000&usg=3DAOvVaw0dLrwRDpGoHamyeB0yRqKb">https:/= +/gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@email.amazonses= +.com/</a> +<br>> [3] <a href=3D"https://x.com/Ethan_Heilman/status/1194624166093369= +345" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www= +.google.com/url?hl=3Dfr&q=3Dhttps://x.com/Ethan_Heilman/status/11946241= +66093369345&source=3Dgmail&ust=3D1741301101169000&usg=3DAOvVaw1= +oC3mVff4KS6eFqkCguyc2">https://x.com/Ethan_Heilman/status/11946241660933693= +45</a> +<br>> [4] <a href=3D"https://gnusha.org/pi/bitcoindev/20220217151528.GC1= +429@erisian.com.au/" target=3D"_blank" rel=3D"nofollow" data-saferedirectur= +l=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://gnusha.org/pi/bitco= +indev/20220217151528.GC1429@erisian.com.au/&source=3Dgmail&ust=3D17= +41301101169000&usg=3DAOvVaw3pT8jgdWGRDB8ZzmRp2cK0">https://gnusha.org/p= +i/bitcoindev/2022021715...@erisian.com.au/</a> +<br>>=20 +<br>> Beyond being a toy example of a conflict with BIP 119's motiva= +tion +<br>> section, I think the above script could be useful in the context o= +f the +<br>> "blind-merged-mining" component of spacechains [5]. For = +example, if +<br>> the commitment was to two outputs, one the recursive step and the = +other +<br>> being a 0sat ephemeral anchor, then the spend of the ephemeral anc= +hor +<br>> would allow for both providing fees conveniently and for encoding = +the +<br>> spacechain block's commitment; competing spacechain miners wou= +ld then +<br>> just be rbf'ing that spend with the parent spacechain update r= +emaining +<br>> unchanged. The "nLockTime" and "sequences_hash"= +; commitment in CTV would +<br>> need to be used to ensure the "one spacechain update per bitc= +oin block" +<br>> rule. (I believe mutinynet doesn't support ephemeral anchors h= +owever, so +<br>> I don't think there's anywhere this can be tested) +<br>>=20 +<br>> [5] <a href=3D"https://gist.github.com/RubenSomsen/5e4be6d18e5fa52= +6b17d8b34906b16a5#file-bmm-svg" target=3D"_blank" rel=3D"nofollow" data-saf= +eredirecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://gist.git= +hub.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5%23file-bmm-svg&sou= +rce=3Dgmail&ust=3D1741301101169000&usg=3DAOvVaw2xICWELuN2AcGG8ct3C-= +97">https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#fi= +le-bmm-svg</a> +<br>>=20 +<br>> (For a spacechain, miners would want to be confident that the priv= +ate key +<br>> has been discarded. This confidence could be enhanced by creating = +X as a +<br>> musig2 key by a federation, in which case provided any of the priv= +ate keys +<br>> used in generating X were correctly discarded, then everything is = +fine, +<br>> but that's still a trust assumption. Simple introspection opco= +des would +<br>> work far better for this use case, both removing the trust assumpt= +ion +<br>> and reducing the onchain data required) +<br>>=20 +<br>> If you're providing CTV and CSFS anyway, I don't see why y= +ou wouldn't +<br>> provide the same or similar functionality via a SIGHASH flag so th= +at you +<br>> can avoid specifying the hash directly when you're signing it = +anyway, +<br>> giving an ANYPREVOUT/NOINPUT-like feature directly. +<br>>=20 +<br>> (Likewise, I don't see why you'd want to activate CAT on m= +ainnet without +<br>> also at least re-enabling SUBSTR, and potentially also the redunda= +nt +<br>> LEFT and RIGHT operations) +<br>>=20 +<br>> For comparison, bllsh [6,7] takes the approach of providing +<br>> "bip340_verify" (directly equivalent to CSFS), "ecd= +sa_verify" (same but +<br>> for ECDSA rather than schnorr), "bip342_txmsg" and "= +;tx" opcodes. A CTV +<br>> equivalent would then either involve simplying writing: +<br>>=20 +<br>> (=3D (bip342_txmsg 3) 0x.....) +<br>>=20 +<br>> meaining "calculate the message hash of the current tx for SI= +GHASH_SINGLE, +<br>> then evaluate whether the result is exactly equal to this constant= +" +<br>> providing one of the standard sighashes worked for your use case, = +or +<br>> replacing the bip342_txmsg opcode with a custom calculation of the= + tx +<br>> hash, along the lines of the example reimplementation of bip342_tx= +msg +<br>> for SIGHASH_ALL [8] in the probably more likely case that it didn&= +#39;t. If +<br>> someone wants to write up the BIP 119 hashing formula in bllsh, I&= +#39;d +<br>> be happy to include that as an example; I think it should be a pre= +tty +<br>> straightforward conversion from the test-tx example. +<br>>=20 +<br>> If bllsh were live today (eg on either signet or mainnet), and it = +were +<br>> desired to softfork in a more optimised implementation of either C= +TV or +<br>> ANYPREVOUT to replace people coding their own implementation in bl= +lsh +<br>> directly, both would simply involve replacing calls to "bip34= +2_txmsg" +<br>> with calls to a new hash calculation opcode. For CTV behaviour, us= +age +<br>> would look like "(=3D (bipXXX_txmsg) 0x...)" as above; f= +or APO behaviour, +<br>> usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)= +". That +<br>> is, the underlying "I want to hash a message in such-and-such= + a way" +<br>> looks the same, and how it's used is the wallet author's d= +ecision, +<br>> not a matter of how the consensus code is written. +<br>>=20 +<br>> I believe simplicity/simfony can be thought of in much the same wa= +y; +<br>> with "jet::bip_0340_verify" taking a tx hash for SIGHASH= +-like behaviour +<br>> [9], or "jet::eq_256" comparing a tx hash and a constant= + for CTV-like +<br>> behaviour [10]. +<br>>=20 +<br>> [6] <a href=3D"https://github.com/ajtowns/bllsh/" target=3D"_blank= +" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3D= +fr&q=3Dhttps://github.com/ajtowns/bllsh/&source=3Dgmail&ust=3D1= +741301101169000&usg=3DAOvVaw3fZEVDrvAueQEMiL25M2Q4">https://github.com/= +ajtowns/bllsh/</a> +<br>> [7] <a href=3D"https://delvingbitcoin.org/t/debuggable-lisp-script= +s/1224" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://= +www.google.com/url?hl=3Dfr&q=3Dhttps://delvingbitcoin.org/t/debuggable-= +lisp-scripts/1224&source=3Dgmail&ust=3D1741301101169000&usg=3DA= +OvVaw3LeVkB0QuHVj1K4BiyD5bK">https://delvingbitcoin.org/t/debuggable-lisp-s= +cripts/1224</a> +<br>> [8] <a href=3D"https://github.com/ajtowns/bllsh/blob/master/exampl= +es/test-tx" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"http= +s://www.google.com/url?hl=3Dfr&q=3Dhttps://github.com/ajtowns/bllsh/blo= +b/master/examples/test-tx&source=3Dgmail&ust=3D1741301101169000&= +;usg=3DAOvVaw2j6Xc7O3dRQoWXgZzf3gZS">https://github.com/ajtowns/bllsh/blob/= +master/examples/test-tx</a> +<br>> [9] <a href=3D"https://github.com/BlockstreamResearch/simfony/blob= +/master/examples/p2pk.simf" target=3D"_blank" rel=3D"nofollow" data-safered= +irecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://github.com/B= +lockstreamResearch/simfony/blob/master/examples/p2pk.simf&source=3Dgmai= +l&ust=3D1741301101169000&usg=3DAOvVaw1tOfh0CCVub4VHUVXcXUOP">https:= +//github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf</a> +<br>> [10] <a href=3D"https://github.com/BlockstreamResearch/simfony/blo= +b/master/examples/ctv.simf" target=3D"_blank" rel=3D"nofollow" data-safered= +irecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://github.com/B= +lockstreamResearch/simfony/blob/master/examples/ctv.simf&source=3Dgmail= +&ust=3D1741301101169000&usg=3DAOvVaw0sYPl290lpgBPiawbdhWUH">https:/= +/github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf</a> +<br>>=20 +<br>> For me, the bllsh/simplicity approach makes more sense as a design +<br>> approach for the long term, and the ongoing lack of examples of ki= +ller +<br>> apps demonstrating big wins from limited slices of new functionali= +ty +<br>> leaves me completely unexcited about rushing something in the shor= +t term. +<br>> Having a flood of use cases that don't work out when looked in= +to isn't +<br>> a good replacement for a single compelling use case that does. +<br>>=20 +<br>> Cheers, +<br>> aj +<br>>=20 +<br>> -- +<br>> You received this message because you are subscribed to the Google= + Groups "Bitcoin Development Mailing List" group. +<br>> To unsubscribe from this group and stop receiving emails from it, = +send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@= +googlegroups.com</a>. +<br>> To view this discussion visit <a href=3D"https://groups.google.com= +/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au" target=3D"_blank" re= +l=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&a= +mp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%2540er= +isian.com.au&source=3Dgmail&ust=3D1741301101169000&usg=3DAOvVaw= +3aYJChhCGpQ2DCJ7eWBeT0">https://groups.google.com/d/msgid/bitcoindev/Z8eUQC= +fCWjdivIzn%40erisian.com.au</a>. +<br></blockquote></div> + +<p></p> + +-- <br /> +You received this message because you are subscribed to the Google Groups &= +quot;Bitcoin Development Mailing List" group.<br /> +To unsubscribe from this group and stop receiving emails from it, send an e= +mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind= +ev+unsubscribe@googlegroups.com</a>.<br /> +To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/= +bitcoindev/6a9d4eea-51bd-45d8-b839-4ac3cefdbb7en%40googlegroups.com?utm_med= +ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind= +ev/6a9d4eea-51bd-45d8-b839-4ac3cefdbb7en%40googlegroups.com</a>.<br /> + +------=_Part_7771_1561631642.1741214768530-- + +------=_Part_7770_538642493.1741214768530-- + |