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 />&gt; I don't believe the existence of a construction like=
 this poses any <br />&gt; problems in practice, however if there is going =
to be a push to activate <br />&gt; BIP 119 in parallel with features that =
directly undermine its claimed <br />&gt; motivation, then it would presuma=
bly be sensible to at least update <br />&gt; the BIP text to describe a mo=
tivation that would actually be achieved by <br />&gt; 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 &lt;si=
gnature&gt; &lt;pubkey&gt; &lt;message&gt;<br />as an input stack, one can =
have the &lt;message&gt; being an already spent transaction.<br /><br />Fro=
m then, one can build a TxWithhold for a LN commitment transaction, where<b=
r />the &lt;message&gt; 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: &lt;proof-of-target-UTXO-mining=3Dcommitment_tx"=
<br />OP_CSFS&gt; OR &lt;&lt;bounty_timelock&gt; &lt;OP_CHECKLOCKTIMEVERIFY=
&gt; &lt;recursive_bounty_sig |<br />SIGHASH_SINGLE&gt; 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&#39;t even think about this &quot;recursion&quot; as an issue in =
itself anymore. The way CSFS enables &quot;recursion&quot; 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&#39;s not even a really a meaningful distinction as you noted in gen=
eral.
<br>
<br>What&#39;s more interesting is &quot;do these set of changes allow for =
&#39;native&#39; fungible tokens you can _identify_ and interact with in sc=
ript in a way that is enforced by consensus&quot;? 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&#39;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 &lt;<a href dat=
a-email-masked rel=3D"nofollow">a...@erisian.com.au</a>&gt; wrote:
<br>
<br>&gt; Hello world,
<br>&gt;=20
<br>&gt; Some people on twitter are apparently proposing the near-term acti=
vation of
<br>&gt; CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
<br>&gt;=20
<br>&gt; <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&amp;q=3Dhttps://x.com/JeremyRubin/status/1895676912401252=
588&amp;source=3Dgmail&amp;ust=3D1741301101168000&amp;usg=3DAOvVaw0JIJbltba=
bTWAEXmwPjC0I">https://x.com/JeremyRubin/status/1895676912401252588</a>
<br>&gt; <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&amp;q=3Dhttps://x.com/lopp/status/1895837290209161358&amp;sour=
ce=3Dgmail&amp;ust=3D1741301101168000&amp;usg=3DAOvVaw1i6u-p6XV0aTVGx8t_iz0=
J">https://x.com/lopp/status/1895837290209161358</a>
<br>&gt; <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&amp;q=3Dhttps://x.com/stevenroose3/status/18958817572889=
96914&amp;source=3Dgmail&amp;ust=3D1741301101168000&amp;usg=3DAOvVaw0GqQqUM=
4VIQal1nekqrFwX">https://x.com/stevenroose3/status/1895881757288996914</a>
<br>&gt; <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&amp;q=3Dhttps://x.com/reardencode/status/1871343039123452=
340&amp;source=3Dgmail&amp;ust=3D1741301101168000&amp;usg=3DAOvVaw2tfKZfPUs=
V55xJpH5_FOHr">https://x.com/reardencode/status/1871343039123452340</a>
<br>&gt; <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&amp;q=3Dhttps://x.com/sethforprivacy/status/1895814836=
535378055&amp;source=3Dgmail&amp;ust=3D1741301101168000&amp;usg=3DAOvVaw0n0=
_zFB7fYAuV5aMxna_g4">https://x.com/sethforprivacy/status/189581483653537805=
5</a>
<br>&gt;=20
<br>&gt; Since BIP 119&#39;s motivation is entirely concerned with its conc=
ept of
<br>&gt; covenants and avoiding what it calls recursive covenants, I think =
it
<br>&gt; is interesting to note that the combination of CSFS and CTV trivia=
lly
<br>&gt; enables the construction of a &quot;recursive covenant&quot; as BI=
P 119 uses those
<br>&gt; terms. One approach is as follows:
<br>&gt;=20
<br>&gt; * Make a throwaway BIP340 private key X with 32-bit public key P.
<br>&gt; * Calculate the tapscript &quot;OP_OVER &lt;P&gt; OP_CSFS OP_VERIF=
Y OP_CTV&quot;, and
<br>&gt;=20
<br>&gt; its corresponding scriptPubKey K when combined with P as the inter=
nal public
<br>&gt; key.
<br>&gt; * Calculate the CTV hash corresponding to a payment of some specif=
ic value V
<br>&gt; to K; call this hash H
<br>&gt; * Calculate the BIP 340 signature for message H with private key X=
, call it S.
<br>&gt; * Discard the private key X
<br>&gt; * Funds sent to K can only be spent by the witness data &quot;&lt;=
H&gt; &lt;S&gt;&quot; that forwards
<br>&gt;=20
<br>&gt; an amount V straight back to K.
<br>&gt;=20
<br>&gt; Here&#39;s a demonstration on mutinynet:
<br>&gt;=20
<br>&gt; <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&amp;q=3Dhttps://m=
utinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525=
gsk5nr58&amp;source=3Dgmail&amp;ust=3D1741301101168000&amp;usg=3DAOvVaw2vPl=
HMbnv-PSut6NHSIdp6">https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pm=
afcsg2lf5jd33tznmyjejrmqqx525gsk5nr58</a>
<br>&gt;=20
<br>&gt; I&#39;d encourage people to try implementing that themselves with =
their
<br>&gt; preferred tooling; personally, I found it pretty inconvenient, whi=
ch I
<br>&gt; don&#39;t think is a good indication of ecosystem readiness wrt de=
ployment.
<br>&gt; (For me, the two components that are annoying is doing complicated
<br>&gt; taproot script path spends, and calculating CTV hashes)
<br>&gt;=20
<br>&gt; I don&#39;t believe the existence of a construction like this pose=
s any
<br>&gt; problems in practice, however if there is going to be a push to ac=
tivate
<br>&gt; BIP 119 in parallel with features that directly undermine its clai=
med
<br>&gt; motivation, then it would presumably be sensible to at least updat=
e
<br>&gt; the BIP text to describe a motivation that would actually be achie=
ved by
<br>&gt; deployment.
<br>&gt;=20
<br>&gt; Personally, I think BIP 119&#39;s motivation remains very misguide=
d:
<br>&gt;=20
<br>&gt; - the things it describes are, in general, not &quot;covenants&quo=
t; [0]
<br>&gt; - the thing it avoids is not &quot;recursion&quot; but unbounded r=
ecursion
<br>&gt; - avoiding unbounded recursion is not very interesting when arbitr=
arily
<br>&gt; large recursion is still possible [1]
<br>&gt; - despite claiming that &quot;covenants have historically been wid=
ely
<br>&gt; considering to be unfit for Bitcoin&quot;, no evidence for this cl=
aim has
<br>&gt; been able to be provided [2,3]
<br>&gt; - the opposition to unbounded recursion seems to me to either most=
ly
<br>&gt; or entirely be misplaced fear of things that are already possible =
in
<br>&gt; bitcoin and easily avoided by people who want to avoid it, eg [4]
<br>&gt;=20
<br>&gt; so, at least personally, I think almost any update to BIP 119&#39;=
s motivation
<br>&gt; section would be an improvement...
<br>&gt;=20
<br>&gt; [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&amp;q=3Dhttps://gnusha.org/pi/bitc=
oindev/20220719044458.GA26986@erisian.com.au/&amp;source=3Dgmail&amp;ust=3D=
1741301101168000&amp;usg=3DAOvVaw2mVAakpOiQKUt_RNaOeQwU">https://gnusha.org=
/pi/bitcoindev/20220719044...@erisian.com.au/</a>
<br>&gt; [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&amp;q=3Dhttps://gnusha.org/pi/bitcoindev/=
87k0dwr015.fsf@rustcorp.com.au/&amp;source=3Dgmail&amp;ust=3D17413011011690=
00&amp;usg=3DAOvVaw0ZDUKUkoVAJBg4tbTaEOKz">https://gnusha.org/pi/bitcoindev=
/87k0dwr...@rustcorp.com.au/</a>
<br>&gt; [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&amp;q=3Dhttps://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d=
-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/&amp;source=3Dgmail=
&amp;ust=3D1741301101169000&amp;usg=3DAOvVaw0dLrwRDpGoHamyeB0yRqKb">https:/=
/gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@email.amazonses=
.com/</a>
<br>&gt; [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&amp;q=3Dhttps://x.com/Ethan_Heilman/status/11946241=
66093369345&amp;source=3Dgmail&amp;ust=3D1741301101169000&amp;usg=3DAOvVaw1=
oC3mVff4KS6eFqkCguyc2">https://x.com/Ethan_Heilman/status/11946241660933693=
45</a>
<br>&gt; [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&amp;q=3Dhttps://gnusha.org/pi/bitco=
indev/20220217151528.GC1429@erisian.com.au/&amp;source=3Dgmail&amp;ust=3D17=
41301101169000&amp;usg=3DAOvVaw3pT8jgdWGRDB8ZzmRp2cK0">https://gnusha.org/p=
i/bitcoindev/2022021715...@erisian.com.au/</a>
<br>&gt;=20
<br>&gt; Beyond being a toy example of a conflict with BIP 119&#39;s motiva=
tion
<br>&gt; section, I think the above script could be useful in the context o=
f the
<br>&gt; &quot;blind-merged-mining&quot; component of spacechains [5]. For =
example, if
<br>&gt; the commitment was to two outputs, one the recursive step and the =
other
<br>&gt; being a 0sat ephemeral anchor, then the spend of the ephemeral anc=
hor
<br>&gt; would allow for both providing fees conveniently and for encoding =
the
<br>&gt; spacechain block&#39;s commitment; competing spacechain miners wou=
ld then
<br>&gt; just be rbf&#39;ing that spend with the parent spacechain update r=
emaining
<br>&gt; unchanged. The &quot;nLockTime&quot; and &quot;sequences_hash&quot=
; commitment in CTV would
<br>&gt; need to be used to ensure the &quot;one spacechain update per bitc=
oin block&quot;
<br>&gt; rule. (I believe mutinynet doesn&#39;t support ephemeral anchors h=
owever, so
<br>&gt; I don&#39;t think there&#39;s anywhere this can be tested)
<br>&gt;=20
<br>&gt; [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&amp;q=3Dhttps://gist.git=
hub.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5%23file-bmm-svg&amp;sou=
rce=3Dgmail&amp;ust=3D1741301101169000&amp;usg=3DAOvVaw2xICWELuN2AcGG8ct3C-=
97">https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#fi=
le-bmm-svg</a>
<br>&gt;=20
<br>&gt; (For a spacechain, miners would want to be confident that the priv=
ate key
<br>&gt; has been discarded. This confidence could be enhanced by creating =
X as a
<br>&gt; musig2 key by a federation, in which case provided any of the priv=
ate keys
<br>&gt; used in generating X were correctly discarded, then everything is =
fine,
<br>&gt; but that&#39;s still a trust assumption. Simple introspection opco=
des would
<br>&gt; work far better for this use case, both removing the trust assumpt=
ion
<br>&gt; and reducing the onchain data required)
<br>&gt;=20
<br>&gt; If you&#39;re providing CTV and CSFS anyway, I don&#39;t see why y=
ou wouldn&#39;t
<br>&gt; provide the same or similar functionality via a SIGHASH flag so th=
at you
<br>&gt; can avoid specifying the hash directly when you&#39;re signing it =
anyway,
<br>&gt; giving an ANYPREVOUT/NOINPUT-like feature directly.
<br>&gt;=20
<br>&gt; (Likewise, I don&#39;t see why you&#39;d want to activate CAT on m=
ainnet without
<br>&gt; also at least re-enabling SUBSTR, and potentially also the redunda=
nt
<br>&gt; LEFT and RIGHT operations)
<br>&gt;=20
<br>&gt; For comparison, bllsh [6,7] takes the approach of providing
<br>&gt; &quot;bip340_verify&quot; (directly equivalent to CSFS), &quot;ecd=
sa_verify&quot; (same but
<br>&gt; for ECDSA rather than schnorr), &quot;bip342_txmsg&quot; and &quot=
;tx&quot; opcodes. A CTV
<br>&gt; equivalent would then either involve simplying writing:
<br>&gt;=20
<br>&gt; (=3D (bip342_txmsg 3) 0x.....)
<br>&gt;=20
<br>&gt; meaining &quot;calculate the message hash of the current tx for SI=
GHASH_SINGLE,
<br>&gt; then evaluate whether the result is exactly equal to this constant=
&quot;
<br>&gt; providing one of the standard sighashes worked for your use case, =
or
<br>&gt; replacing the bip342_txmsg opcode with a custom calculation of the=
 tx
<br>&gt; hash, along the lines of the example reimplementation of bip342_tx=
msg
<br>&gt; for SIGHASH_ALL [8] in the probably more likely case that it didn&=
#39;t. If
<br>&gt; someone wants to write up the BIP 119 hashing formula in bllsh, I&=
#39;d
<br>&gt; be happy to include that as an example; I think it should be a pre=
tty
<br>&gt; straightforward conversion from the test-tx example.
<br>&gt;=20
<br>&gt; If bllsh were live today (eg on either signet or mainnet), and it =
were
<br>&gt; desired to softfork in a more optimised implementation of either C=
TV or
<br>&gt; ANYPREVOUT to replace people coding their own implementation in bl=
lsh
<br>&gt; directly, both would simply involve replacing calls to &quot;bip34=
2_txmsg&quot;
<br>&gt; with calls to a new hash calculation opcode. For CTV behaviour, us=
age
<br>&gt; would look like &quot;(=3D (bipXXX_txmsg) 0x...)&quot; as above; f=
or APO behaviour,
<br>&gt; usage would look like &quot;(bip340_verify KEY (bipXXX_txmsg) SIG)=
&quot;. That
<br>&gt; is, the underlying &quot;I want to hash a message in such-and-such=
 a way&quot;
<br>&gt; looks the same, and how it&#39;s used is the wallet author&#39;s d=
ecision,
<br>&gt; not a matter of how the consensus code is written.
<br>&gt;=20
<br>&gt; I believe simplicity/simfony can be thought of in much the same wa=
y;
<br>&gt; with &quot;jet::bip_0340_verify&quot; taking a tx hash for SIGHASH=
-like behaviour
<br>&gt; [9], or &quot;jet::eq_256&quot; comparing a tx hash and a constant=
 for CTV-like
<br>&gt; behaviour [10].
<br>&gt;=20
<br>&gt; [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&amp;q=3Dhttps://github.com/ajtowns/bllsh/&amp;source=3Dgmail&amp;ust=3D1=
741301101169000&amp;usg=3DAOvVaw3fZEVDrvAueQEMiL25M2Q4">https://github.com/=
ajtowns/bllsh/</a>
<br>&gt; [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&amp;q=3Dhttps://delvingbitcoin.org/t/debuggable-=
lisp-scripts/1224&amp;source=3Dgmail&amp;ust=3D1741301101169000&amp;usg=3DA=
OvVaw3LeVkB0QuHVj1K4BiyD5bK">https://delvingbitcoin.org/t/debuggable-lisp-s=
cripts/1224</a>
<br>&gt; [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&amp;q=3Dhttps://github.com/ajtowns/bllsh/blo=
b/master/examples/test-tx&amp;source=3Dgmail&amp;ust=3D1741301101169000&amp=
;usg=3DAOvVaw2j6Xc7O3dRQoWXgZzf3gZS">https://github.com/ajtowns/bllsh/blob/=
master/examples/test-tx</a>
<br>&gt; [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&amp;q=3Dhttps://github.com/B=
lockstreamResearch/simfony/blob/master/examples/p2pk.simf&amp;source=3Dgmai=
l&amp;ust=3D1741301101169000&amp;usg=3DAOvVaw1tOfh0CCVub4VHUVXcXUOP">https:=
//github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf</a>
<br>&gt; [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&amp;q=3Dhttps://github.com/B=
lockstreamResearch/simfony/blob/master/examples/ctv.simf&amp;source=3Dgmail=
&amp;ust=3D1741301101169000&amp;usg=3DAOvVaw0sYPl290lpgBPiawbdhWUH">https:/=
/github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf</a>
<br>&gt;=20
<br>&gt; For me, the bllsh/simplicity approach makes more sense as a design
<br>&gt; approach for the long term, and the ongoing lack of examples of ki=
ller
<br>&gt; apps demonstrating big wins from limited slices of new functionali=
ty
<br>&gt; leaves me completely unexcited about rushing something in the shor=
t term.
<br>&gt; Having a flood of use cases that don&#39;t work out when looked in=
to isn&#39;t
<br>&gt; a good replacement for a single compelling use case that does.
<br>&gt;=20
<br>&gt; Cheers,
<br>&gt; aj
<br>&gt;=20
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; 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>&gt; 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&amp;source=3Dgmail&amp;ust=3D1741301101169000&amp;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&quot; 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--