path: root/fb/bad552ebfa77ade703d0f4eb6f056362496a75

Delivery-date: Wed, 25 Jun 2025 09:54:53 -0700
Received: from mail-oo1-f55.google.com ([209.85.161.55])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDL4XL646QOBBU6T6DBAMGQEBYECVIQ@googlegroups.com>)
	id 1uUTOe-000257-B4
	for bitcoindev@gnusha.org; Wed, 25 Jun 2025 09:54:53 -0700
Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-6114d2ae259sf110177eaf.2
        for <bitcoindev@gnusha.org>; Wed, 25 Jun 2025 09:54:51 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1750870486; cv=pass;
        d=google.com; s=arc-20240605;
        b=eQutyTeKFEcSR5Ax3uIvjszogMuoKDOc2e/JYAWURYISW7qHdlFAYRrPFd4CMvzJp1
         NzfpfgFHNu3ENsWKVa8YfWUqkobhd/5w6Lr6L/fgmaPMvwUJF164tmJ1der0rugtkfUB
         aXf51bm3EcRNRRmiTPVze509ioUB9rbGjH2tzB7W1nka1szMLW6tM21nWuBYjfgbDAer
         tZp9t8iKMuG0cch6qFVG3LKYH2oyeQkTnC6rot1KZoHem3oa3q455JzwxBT9bAY0z+Bz
         f/V8nO4jD0+02tU99pvbVXFP39fLR/5nznN39s9OY2+xPh6+QFyl2vlArIgH5eNMzqkS
         gx+w==
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:reply-to:content-transfer-encoding
         :mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=fvKVUHI9MbWNtr+tYQ0k/IEI26jdaFDENMecJE1OfTc=;
        fh=YQaMNTHO/jyPKrgThu6NMXSVYwRsoZ10gSOcT2EMoB8=;
        b=Tg12EcVxIiYQ4zVpRMCOKdA+afcQSJ/BvQtrwVAHbagYxNPJ+NHu1/MjnT/gyWapRw
         zMaDyNWkF2DAslMDQHdpRsfjKm6Pl7jXkL0E0MO+DWoIuTHK5DK6/4Fua0Cbt3AbNpFV
         bn4e59YjZ6trG4h7/TwdEsu8oUKLmYtPwNiulk8mK17MCwEpWOB4Zu6zJUgzhWKjYaA8
         cjOuVrX0W4ExoIgbFTkdNAsyW0vBQtxY0DSm4yYkrBOPscJQx1esuvAbMUafxfv5PF1d
         KywrcxX4DkQ7npGR2MWkifLzRcuLUeY9qauNa6NA30FyrhLs7KsEWkbW/90O6Q6cETc4
         T7EA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=XkDF+To7;
       spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1750870486; x=1751475286; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender
         :content-transfer-encoding:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject
         :date:message-id:reply-to;
        bh=fvKVUHI9MbWNtr+tYQ0k/IEI26jdaFDENMecJE1OfTc=;
        b=gSyPSmdFerTyxqAci97tLRlRU8lex3q98EQOzLEh4pCnRTH3yvt1s7Ukf13GfqZokg
         mTrMAnZHbaY+BvS6OnfKDDFZCfYM3vTmuxLSuWd5eABrnQZCigR+8rHNaVI2gYhKGWWi
         LSHv+E8SN1eAP2yCiNmlAc2Sg8F1XdEYe4Z4F4srEKPy89ylufc4Tirz9yDL2FIJYAjA
         8tT7/35FSGRK+/2AUuh/TfFnphs5JAROBJ0xjQy3Ud3DoJt46TsNscUgezJASOdsdm4E
         Zb93aKDlxej2v/PrVOYAK2uehkwRP3dMaUlJT8sstK5MmaW3oeyDaRSppYLWNsRi9zjl
         5Neg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750870486; x=1751475286;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender
         :content-transfer-encoding:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=fvKVUHI9MbWNtr+tYQ0k/IEI26jdaFDENMecJE1OfTc=;
        b=quo/h3VVl5bszCmtWgUT7O+7IZyNMnY1LV3pzeP72am/XToqujrMnW15vCPx6HEB9U
         Uk9CsTVIIXWkstczM4qEsxWN7rUHdWVSgC3WOho6GNo9dKjVInKukNXhkpD/4Bi3M4ZP
         PoNQi96ylI5nedbLc3x1cB5KBlRBZkFnVwbfyWI8q+lfkjADYCnbpleJ7iTQKF8GhV7F
         6Wc+GG1cKecJRchl1Skb96hGXst64rfYhdKGy5hvTsUIrKMeTBZxrYf4fjzObo0Ju7xA
         0PELmVk8cyAH//3y1J/0PUzd7JLJCPdcC6gEORQv5tT8H9csCJCZxmKMCk3LlyQX+CoB
         WPNw==
X-Forwarded-Encrypted: i=2; AJvYcCXrF5uMdB9+R1E4IiBd59cDc4FQ0OS24oJu3SuYKatZXVUUnyipiF5N06547dEYu/KN0hb6deW91n19@gnusha.org
X-Gm-Message-State: AOJu0Yx+DV1grpIcALhxM/Y38TBpxrWQFajhhjFCs9fy82x7w1f8RH3Y
	CQ1jtZX1R88IYXb2cZ1lIqmryzMmEJ/Fu86pxITje3qTo9xzCezWn2Hz
X-Google-Smtp-Source: AGHT+IEEfHlqyy6oi04UJFffEF70DqNzKfCkdjHEgIeXQbkrMEdvrGWyHfWGNqPxAv/3o1w1cx341g==
X-Received: by 2002:a05:6870:a44d:b0:2d4:ce45:6983 with SMTP id 586e51a60fabf-2efb219afe6mr2628370fac.10.1750870485759;
        Wed, 25 Jun 2025 09:54:45 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf88YpJwKexYT79WBUEszStY5XfY7CvHeb/ucVrOCGycQ==
Received: by 2002:a05:6871:7893:b0:2ea:72d5:87e8 with SMTP id
 586e51a60fabf-2efcf1d59afls34027fac.1.-pod-prod-08-us; Wed, 25 Jun 2025
 09:54:43 -0700 (PDT)
X-Received: by 2002:a05:6808:140a:b0:408:e690:7e38 with SMTP id 5614622812f47-40b0574c32dmr3426287b6e.16.1750870482988;
        Wed, 25 Jun 2025 09:54:42 -0700 (PDT)
Received: by 2002:a05:600c:1d14:b0:450:9f02:8bd with SMTP id 5b1f17b1804b1-453818ec63ems5e9;
        Wed, 25 Jun 2025 09:50:22 -0700 (PDT)
X-Received: by 2002:a05:600c:8519:b0:453:b44:eb69 with SMTP id 5b1f17b1804b1-45381aaf7cbmr37404175e9.13.1750870219346;
        Wed, 25 Jun 2025 09:50:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1750870219; cv=none;
        d=google.com; s=arc-20240605;
        b=R56SmguFn927lWGZmNzz5TD5u65Pg///jql3ItXYEz2EsuK5CwQElOI4mb2Q8xfQLy
         J8LKLd4lTm1dM/WNZZmKGeqKK4Fvp8CK/7D00qbyMECmUt7L4MpzD2Ix45GlVr3qqDxD
         +bo6/egrOakj8d+kijipR30uGav+MDWftvYQfQJf3dbESY+me2xwini3G5Ty/yo8Dngl
         580Rvf+oGEjbEkt8TNlHCkOJ+M3hRP5MiGHYwubWAHaO7j8qfGZwA+YjaCHrZsKkEXc5
         e19pwF2ISwntfaWNVUef3A1nWmZth8ZvjdGhUwzYPIDzX+VDDOuheIFOikO+1lBheL7e
         gP/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature;
        bh=KLqB0QZDwsaG7Cy2Ql8cp17mIromAm3UZJ0jQBK5c0s=;
        fh=xW8bxyqQYHE1uH3XvdCMfZVppoYs0vQZCdqgnVz97es=;
        b=fEC0mVSc5yTIaeue+L+vDwc2l+h8gyQEx+74u4leKHmbPb6FgezMDY2awGUnMZItu1
         YYZ6zWpPeD0GGpLUAXTMQPV4XG6O6NWhPy7CI63p7BI5pQRtR3EfsOOxrCTa3E7/XYm9
         tps3uMmis9FJ1tL/uN7U9Us5mdshorMzoPvUoddaa6MpW+k/qlG/jkEwf0dqO3aYcvfq
         PyTuH9ZSX87kQtMEUxS54ZtZAMSdkbYnst+F1VVBnNMOG8G9+FIK25czKqVdtpjxXKXM
         gOcG6iYcKWH3OjBovJlr2o7GO8e8VEMQIuzAGwWDUntzoVN79v6XRb1V0HEDzLohAoTw
         UZ3w==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=XkDF+To7;
       spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch. [79.135.106.29])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-45382372e92si371065e9.2.2025.06.25.09.50.19
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 25 Jun 2025 09:50:19 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) client-ip=79.135.106.29;
Date: Wed, 25 Jun 2025 16:50:15 +0000
To: Matt Corallo <lf-lists@mattcorallo.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] What's a good stopping point? Making the case for
 the capabilities enabled by CTV+CSFS
Message-ID: <73PXNVcmgiN2Kba63P2SRZfs42lvgME_8EF-DlYtkOSY8mLRxEXPEw5JAi5wtPU2MEMw1C6_EDFHKKrhaa1F53OgIJOcam-kbOUP3aG2_e0=@protonmail.com>
In-Reply-To: <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com>
References: <F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com> <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: a76eb1c7d56beb30e30365c2286bf622fe520800
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=XkDF+To7;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.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: -1.0 (-)

Thanks for sharing some objections. Here is my attempt at addressing them.

> ISTM even something as simple as a rate-limit requires more full-featured=
 introspection than only
> "commit to the exact next transaction" can provide. For example, a trivia=
l construction would be
> something which requires that transactions spending an output have an out=
put which claims at least
> Amount - Rate, which requires both more full-featured introspection as we=
ll as a bit of math.

Yes. These capabilities are really only useful for reducing interactivity i=
n second-layer protocols.
They do not (reasonably) help for vaults and we do not claim it as a use ca=
se.

Previous efforts to promote opcodes implementing those capabilities have un=
fortunately fallen into
the trap of overpromising and claiming use cases they do not really enable.=
 But this should not make
us overlook what they are really good at: interactivity reduction.

Do you think that the use cases presented in OP, if demonstrated, are not e=
nough to warrant soft
forking in a primitive enabling them?

> Given one of the loudest groups advocating for the additional features of=
 CTV+CSFS are enterprise
> or large-value personal custody providers

Yes. We intentionally do not mention vaults as a use case in our steelman. =
We should not change
Bitcoin on the basis of misleading use cases. If people are interested in v=
aults, they should
sponsor efforts on a different set of capabilities. Probably "programmable =
forwarding of value from
inputs to outputs", "programmable forwarding of spending conditions from in=
puts to outputs" and maybe
"commit to the exact transaction spending an output" (or more powerful intr=
ospection).

The lack of a similar enthusiasm for proposals enabling most or all of thes=
e functionalities (like
Salvatore Ingala's BIP334 or previously James O'Beirne's and Greg Sanders' =
BIP345) suggests such
loud support are in fact in favour of "just doing something" and rationaliz=
e nice-sounding use cases
backward from this proposal (but vaults!) because it appears to them to be =
"further down the road".
I think this view is very dangerous and is part of our motivation for redir=
ecting discussions toward
what these capabilities actually enable.

> it seems somewhat of a loss to not work our way towards really basic feat=
ures for this use-case.

I personally grew more skeptical of the reactive security model of vaults a=
fter working on it.  Your
mileage may vary and that's fine if people want to work on capabilities tha=
t actually enable vaults,
but i don't think they should be a required use cases and block introducing=
 primitives that
substantially improve existing layer 2s and make new ones possible.

> Indeed, ISTM many use-cases for a construction like TXHASH become a lot m=
ore substantial with Math
> [...], I'm quite skeptical that *just* looking at an individual fork on i=
ts own is the right
> benchmark.

I agree that modularity and forward composability with potential future upg=
rades are arguments in
favour of a more flexible approach. But those need to be balanced with the =
additional risk and
implementation complexity such an approach entails. I'm happy to be convinc=
ed if supporters of this
approach demonstrate the added flexibility does enable important use cases =
and the risks associated
are manageable. But if nobody is interested in doing so, i don't think it's=
 reasonable to hold off a
safer upgrade as long as it is demonstrated to provide substantial benefits=
.

It's also unclear that we should stop at "programmable introspection" in th=
is case. Why not also
include "programmable amount / spending condition forwarding" too, which wo=
uld give you vaults? Why
not even CAT, which is a neat tool in many situations and would let ZK peop=
le experiment with
validation rollups? And at this point, it would seem wiser to just work on =
a sane Bitcoin Script
replacement rather than throwing buckets of opcodes at it and hoping it hol=
ds off. Which as we say
in OP i don't think is realistic.

> I don't see how this results in a net reduction in risk to Bitcoin, rathe=
r just means more total
> work and more cruft in Bitcoin's consensus.

In theory, i agree. But by this token the same goes for every future extens=
ion that introduces more
expressivity to Bitcoin Script. This ties back to the stopping point: why a=
dd more cruft to the
existing interpreter when we could all focus on BTCLisp instead?

It's also the case that even if future extensions introduce a superset of t=
he capabilities being
discussed, it's unlikely that such simple ones like "just commit to the nex=
t transaction" and
"verify a signature for an arbitrary message" would ever be made fully redu=
ndant.

Finally, when considering technical debt we should also weigh the actual co=
st of the implementation
of these simple capabilities. Signature verification on arbitrary message r=
euses existing signature
checking logic. Similarly, committing to the next transaction can heavily l=
ean on existing Taproot
signature messages, only minimally departing when necessary, and be impleme=
nted in a strictly
simpler manner than the existing CTV proposal. A minimal implementation of =
these capabilities would
not introduce significant technical debt.

Interestingly, this argument applies more to introducing more involved capa=
bilities like arbitrary
transaction introspection, because of the substantially larger technical de=
bt it would impose to
first support in Bitcoin Script instead of focusing on a replacement with t=
ransaction introspection
from the get go.

> Indeed, more flexible introspection provides for a difference in risk to =
the system (though its
> worth noting we cannot both argue that there is no "demonstrated utility"=
 *and* that the utility
> of a change is so substantially higher that it adds material risk to the =
system in the form of
> MEVil from its use-cases).

Yes we can? It's reasonable to see how arbitrary introspection could be use=
ful in various handwavy
ways, and therefore how they can be used for undesirable applications, whil=
e also not having an
important use case it enables clearly defined, much less demonstrated.

> However, given the uses of the Bitcoin chain today, it seems entirely pos=
sible (assuming
> sufficient adoption) that we end up with a substantial MEVil risk with or=
 without any
> functionality expansion.

Sure, but I=E2=80=99d argue that the presence of risk now is a reason to be=
 more cautious about adding to
it, rather than accepting it as inevitable.

Best,
Antoine


On Tuesday, June 24th, 2025 at 12:00 PM, Matt Corallo <lf-lists@mattcorallo=
.com> wrote:

>=20
>=20
> Thanks, responding to one specific point:
>=20
> On 6/23/25 9:14 AM, 'Antoine Poinsot' via Bitcoin Development Mailing Lis=
t wrote:
>=20
> > Yet another alternative is a set of more powerful capabilities, enablin=
g the use cases that "commit to next transaction"
> > and "verify a BIP340 signature for an arbitrary message" enable and mor=
e. For instance replacing "commit to the exact
> > transaction which must spend this output" with "programmable introspect=
ion on the spending transaction's fields" has
> > been considered. However this approach increases implementation complex=
ity and broadens the risk surface[^8]
>=20
>=20
> Responded to below [1]
>=20
> > which
> > warrants a compelling demonstration that arbitrary transaction introspe=
ction does enable important use cases not
> > achievable with more minimal capabilities.
>=20
>=20
> I'm somewhat skeptical that showing this isn't rather simple, though I ad=
mit I've spent less time
> thinking about these concepts. ISTM even something as simple as a rate-li=
mit requires more
> full-featured introspection than only "commit to the exact next transacti=
on" can provide. For
> example, a trivial construction would be something which requires that tr=
ansactions spending an
> output have an output which claims at least Amount - Rate, which requires=
 both more full-featured
> introspection as well as a bit of math. Given one of the loudest groups a=
dvocating for the
> additional features of CTV+CSFS are enterprise or large-value personal cu=
stody providers, it seems
> somewhat of a loss to not work our way towards really basic features for =
this use-case.
>=20
> More generally, more full-featured introspection like TXHASH provides a l=
ot of flexibility in the
> constructs people can build. For example, allowing BYO fees in the form o=
f an additional input +
> output in a transaction, rather than fixing an anchor output in the fixed=
 "next transaction"
> commitment to allow for fees (and then requiring the same additional inpu=
t + output later). There's
> also open questions as to the incentive-compatibility of anchors in a wor=
ld with expensive block
> space, as OOB fees become much cheaper.
>=20
> Indeed, ISTM many use-cases for a construction like TXHASH become a lot m=
ore substantial with Math
> (though, again, I spend less time thinking about the use-cases of these t=
hings than most, so I'm
> sure others have more examples), I'm quite skeptical that just looking at=
 an individual fork on
> its own is the right benchmark. Sure, functionality in proposed changes t=
o Bitcoin's consensus need
> to be well-justified, but they don't need to be well-justified purely on =
their own. We add things
> like OP_SUCCESS opcodes in soft forks specifically to expand the set of t=
hings we can do later, not
> specifically in this fork.
>=20
> If we assume that we end up wanting things like velocity limits (which I =
imagine we would?) then it
> seems to me we should do a logical fork that adds features today, but whi=
ch will allow us to make
> minimal extensions in the future to further expand its use-cases later. T=
aking a more myopic view of
> the present and ignoring the future results in us doing one thing today, =
then effectively replacing
> it later by adding more flexibility in a new opcode later, subsuming the =
features of what we do
> today. I don't see how this results in a net reduction in risk to Bitcoin=
, rather just means more
> total work and more cruft in Bitcoin's consensus.
>=20
> [1]
>=20
> Responding to the MEVil question OOO because I think the above should go =
first :).
>=20
> Indeed, more flexible introspection provides for a difference in risk to =
the system (though its
> worth noting we cannot both argue that there is no "demonstrated utility"=
 and that the utility of
> a change is so substantially higher that it adds material risk to the sys=
tem in the form of MEVil
> from its use-cases). However, given the uses of the Bitcoin chain today, =
it seems entirely possible
> (assuming sufficient adoption) that we end up with a substantial MEVil ri=
sk with or without any
> functionality expansion. This mandates a response from the Bitcoin develo=
pment community in either
> case, and I'm confident that response can happen faster than any reasonab=
le soft fork timeline.
>=20
> While its possible that existing CSV-based MEVil risk never grows beyond =
its current anemic state
> (due to preferences for stronger trust models from their users), and that=
 there's a particularly
> clever design using expanded introspection that improves the trust model =
such that suddenly
> CSV-based protocol use explodes, ISTM given the risk and the need to miti=
gate it on its own, taking
> decisions that are sub-optimal for Bitcoin's consensus on this basis isn'=
t accomplishing much and
> has real costs.
>=20
> Matt
>=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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/8a9a2299-ab4b-45a4-8b9d-95798e6bb62a%40mattcorallo.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/=
73PXNVcmgiN2Kba63P2SRZfs42lvgME_8EF-DlYtkOSY8mLRxEXPEw5JAi5wtPU2MEMw1C6_EDF=
HKKrhaa1F53OgIJOcam-kbOUP3aG2_e0%3D%40protonmail.com.