path: root/84/a9d2aa0c687bbb2694f8429e3d76bfaf0d4608

Delivery-date: Sun, 21 Jul 2024 13:48:53 -0700
Received: from mail-qv1-f64.google.com ([209.85.219.64])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDRYHVHZTUGRBLHI6W2AMGQE37VH4LI@googlegroups.com>)
	id 1sVdUC-00050d-Cl
	for bitcoindev@gnusha.org; Sun, 21 Jul 2024 13:48:53 -0700
Received: by mail-qv1-f64.google.com with SMTP id 6a1803df08f44-6b7a5ab3971sf60617856d6.2
        for <bitcoindev@gnusha.org>; Sun, 21 Jul 2024 13:48:51 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1721594926; cv=pass;
        d=google.com; s=arc-20160816;
        b=qufPktHWXx6haSsHhCW2At/nWxVtXF+6ixYX6myNcfD9C9j+l+ZEUNOSn5ayRsKsqD
         D1OhMGaubPvvAUS0t+JtFY45xUZqzta6fmtEL1R4UnFVrB01flNeiCJJG1vWNbDnOLoU
         oiJUpxjWwybTUAwENlCPvKVLStf0abVYiC/04A1oBFC7c1sPR4vL76AZPkdiFRra6tla
         teTQ/LpkQRqzpVyZnGWrGekLfP3rtJpIACZk6VEcfbiTHBAMOE7t1llrUTT+jV89tnNe
         k9o/C8j9ZdQCGAeyamtUrLJ1vN8OjFmL0xQDIX5nRhy6ekl9RnF5NDb8rvoydEK2O2Sr
         cxEA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:in-reply-to:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :feedback-id:sender:dkim-signature;
        bh=L7LVNr8us0rPoxnzrOpnxSp3WfE6uBkH0axRvl0juGI=;
        fh=tovN7fdLXOEAEmCZuUj/39FNP9lIUdXaIeiX8lMVY5E=;
        b=BJohUBDlXa1tTGckVIPgzDcKz3ZCgBWNo4riLAviE4UnycPIxxvbL/lGxitK11YasY
         i8qCRAGMFlPKhIkh2+KovAB4QNJQMWs4Pay75URMW88A5ZjPNCG0ch/KMl3uM6xFN0T7
         M/lUJhtyRGbo0F+2YVPwWBLf0j5y5UsITsd7NPmnynatedI79M0keU9QwWqDi2WhRrUA
         DORL5D5Sf61iDcYn6GiQw/K814YlhUubRPMxko0Yy/7MjuhEqgittYnnajWUcL8d9Ylr
         JnjObTW3ikn2lZOOUXXNiDXKZ/eil6GBzIt2ehCeJRdnwrOMJF79ykySMZtHIrO2TlL5
         ypLg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=P8+xYI3l;
       spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.150 as permitted sender) smtp.mailfrom=pete@petertodd.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1721594926; x=1722199726; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date:feedback-id:sender
         :from:to:cc:subject:date:message-id:reply-to;
        bh=L7LVNr8us0rPoxnzrOpnxSp3WfE6uBkH0axRvl0juGI=;
        b=AutRycvfFE2IDXJsj3lJ/HM5IaIhh5bCI6gP2vinkOz68Bkhh3Yf8GJPhkeQ+qSObt
         vwUDhLvZanYDLpfKysgeMnVEfZetNYXqzkmWR3sbh7WQZGlQi2msV7f0sCDm89yRJ9Ge
         NJufotpovXt3v37j5PrRv+8tO/xXrfxUE1pp6HeNw16Hg21Fx5DDis/JyArJm/xCXzvN
         dN49TYYFr9I/g7qdsxoW4+3HFgNoCBAxEYzWg7NzN54VyMq8YmTG3DIkIcN91Ftm6MWx
         geIBzezkIGqdhosBQGdsphMgbj/lNb/cwFY9QE/H7Z0qexD1RdDuUkRiKAlCL39u6fOM
         DdvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1721594926; x=1722199726;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date:feedback-id
         :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=L7LVNr8us0rPoxnzrOpnxSp3WfE6uBkH0axRvl0juGI=;
        b=Rx36Mx1CPsJFGV1ieTdRF+1LEvY2+j7PEhQM9rdmWzU/OWS+5nFu4Trw9mSq6sN6ce
         UqAicybW2N7bhYS/JyVgSCe44o2+82+oZLY791/Rm/aRAMJ8jj+UkaR1ZK0B4rgscVbi
         XBpX20HjZLvvc/wuy3HXsKTo2ZvA9CkcR9BM50N/N5nauDalRfqW1wpz+Q21ljs0fOzA
         2CrXfv2KqnG3Apuailga1Q0r4NoRQOdXd8s+jUUeKIbcpB3+gfZFKT0AeDJbO7zK3Wo4
         q5pFW4Gh9YimpCUznYjnOdPZCI8YlkUehu2qh1+P+PHK/kWHYWM1QSbygjnoqZOhHRcp
         3O5g==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVC38UcKsIXJNi5GLTf+czm8+XI+E2OBooy2IetwI6VpcBWWJLCJACbhKtgrBDq1s+PE77zix42P5YJtoy/8l9cI+nlqHQ=
X-Gm-Message-State: AOJu0Yz8R9XWoLoNlRM59jiCkvMcJAQXebZ265RMFlr9MeFFnRQec19J
	+e0tIHElePkzoqYnshUhSz9JT6br4hr/72ZWa1WxT5k/caqwBaCw
X-Google-Smtp-Source: AGHT+IG/pfY1FhMB9sf0SkzXLwud3X5MIjjV62iZnmZ3Dib1mg1iWz9ILg3i964Ji0/DSza2+Nnsfg==
X-Received: by 2002:a05:6214:20e2:b0:6b9:60ad:a9e2 with SMTP id 6a1803df08f44-6b9610d4385mr73291726d6.11.1721594925686;
        Sun, 21 Jul 2024 13:48:45 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6820:447:b0:5b2:73ec:2f15 with SMTP id
 006d021491bc7-5d51a2447bbls3648342eaf.0.-pod-prod-09-us; Sun, 21 Jul 2024
 13:48:43 -0700 (PDT)
X-Received: by 2002:a05:6808:23c9:b0:3d9:21d0:dda9 with SMTP id 5614622812f47-3dae614185amr124260b6e.5.1721594923833;
        Sun, 21 Jul 2024 13:48:43 -0700 (PDT)
Received: by 2002:a05:6808:984:b0:3d9:302f:bb85 with SMTP id 5614622812f47-3dadf171cc4msb6e;
        Sun, 21 Jul 2024 13:25:35 -0700 (PDT)
X-Received: by 2002:a17:90b:1b01:b0:2c9:79d3:a15d with SMTP id 98e67ed59e1d1-2cd274a9f7dmr3700969a91.29.1721593534198;
        Sun, 21 Jul 2024 13:25:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1721593534; cv=none;
        d=google.com; s=arc-20160816;
        b=CuTLpdF32s9zBVI5DCHyL05lQJookC+0f8QvTR0cioqfus/WphnzZGezxTPARDAIgH
         pM1ekjEcF5xBqxIuiDKa+klZcU46UGtOJefVJb9qd2c3e3yOcxxSl8LB7AaVmxYJ82a3
         +N9JzZpEELVBfHejoUgC6nNQ+6YIwTIRBQoChQTxgPgIUnIJXlyOSyHPt8iZeo9VFnH4
         re7W4qHgp913cHvfrXXp0eHHqoB7RMRZkqseBRW92oUGBcFdvX8sjOXdzIgKRw3BJJFL
         sf2XQ9mb/uTpWVOeGbO73lSKLJI6EoOEemnGgbv1W5qv4emXaT2J3seCH3C2tTqV4ay+
         UOhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:feedback-id:dkim-signature;
        bh=M2NSwNjrJLjVaBnWZJozdLz9acGXRNk6L28B78eoHSs=;
        fh=qAkUFgesXJOBZlEhHhc6qjOrC9x9vwcQK9K5cSmyNz0=;
        b=koG7nyylvIaTUDyhTLmTxFO+h4FI2PLvk/hIyy0HxSE7eXeGvZmBuikn7JQrZAyiMT
         ct8ilT2HxdlerNnDZRvntOQ2Z3BiQyI13Oz+ba0B/v2IqiH+gj2/+10JUfCr5EdrK3dc
         vKQs5poayhxBCpinoGO1Q2FbqzSYP3E0LC64jFxEhPZlwAffu+Br6UNBWDrPbMV2BkPx
         fUR+rve8WgMYJNKpnmBQT/7sIa7Kf1JINy+1G8g/xu2Uo9ogTcEej4jE9ddgguBUjYix
         Q/akheMLXCfs5qVxYEXgtx1CRb7vRyGA3J6UQ24GO9Un8mmLz35ZeAWotNz9kk4e8hxW
         80EA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=P8+xYI3l;
       spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.150 as permitted sender) smtp.mailfrom=pete@petertodd.org
Received: from fout7-smtp.messagingengine.com (fout7-smtp.messagingengine.com. [103.168.172.150])
        by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-2cb76a64e4asi374667a91.0.2024.07.21.13.25.33
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 21 Jul 2024 13:25:34 -0700 (PDT)
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.150 as permitted sender) client-ip=103.168.172.150;
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
	by mailfout.nyi.internal (Postfix) with ESMTP id 7F6D8138009E;
	Sun, 21 Jul 2024 16:25:32 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
  by compute5.internal (MEProxy); Sun, 21 Jul 2024 16:25:32 -0400
X-ME-Sender: <xms:vG6dZp-Z2IWNP8wXNY68E3Y0TojoJqIsDyHBxNn4k3vOBBZKepKvzA>
    <xme:vG6dZtteyF-oURpVVtGPOAveoUg7oiIwmt7KslaF_Fbe3WRESrPVOVeDhxwzn4xci
    AKCfsxCxnXJclI3m9E>
X-ME-Received: <xmr:vG6dZnB9zSAoRLoBRVNti8x7tOKvlaYzEDOj9pP6hS2XOtVTB5oCptVV>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrheehgddugeelucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfhfgggtuggjsehgtd
    erredttdejnecuhfhrohhmpefrvghtvghrucfvohguugcuoehpvghtvgesphgvthgvrhht
    ohguugdrohhrgheqnecuggftrfgrthhtvghrnhepfffggfdtgeevjefhteffieduledugf
    egtdetgeehjeeuueeuueeiuedtueduueegnecuffhomhgrihhnpehpvghtvghrthhouggu
    rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh
    epphgvthgvsehpvghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:vG6dZtd0VJ4oQgeJ9pIK7T8iyoxDXsozJ7C69Is4CmASEpE5t8V8cQ>
    <xmx:vG6dZuOtZq9VfFhNGdprs9fIH2AkMx2kimFZsDUk9F677WY_1MdbRA>
    <xmx:vG6dZvmXHJf3Q2qAWrvTiofwA9vtn013jRnhqVEhIKVN_ybS3WsFTw>
    <xmx:vG6dZov834FLbo1UUQrES8QgM9KGceXcw3aKZTmh6XiwEBPRhRYnxA>
    <xmx:vG6dZl1-uH11QUFOCjI-V5ty1CMFSGhlkEDG5G3v4VT6LuZfOWfTuhmE>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 21 Jul 2024 16:25:31 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
	id C95B65F83F; Sun, 21 Jul 2024 20:25:25 +0000 (UTC)
Date: Sun, 21 Jul 2024 20:25:25 +0000
From: Peter Todd <pete@petertodd.org>
To: "David A. Harding" <dave@dtrt.org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
 of Full-RBF In Core
Message-ID: <Zp1utYduhnWf4oA4@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
 <ZpvRvRybauFFnhQV@petertodd.org>
 <d57a02a84e756dbda03161c9034b9231@dtrt.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="f6QbCljwwUF5QVIU"
Content-Disposition: inline
In-Reply-To: <d57a02a84e756dbda03161c9034b9231@dtrt.org>
X-Original-Sender: pete@petertodd.org
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@messagingengine.com header.s=fm3 header.b=P8+xYI3l;       spf=pass
 (google.com: domain of pete@petertodd.org designates 103.168.172.150 as
 permitted sender) smtp.mailfrom=pete@petertodd.org
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.8 (/)


--f6QbCljwwUF5QVIU
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 21, 2024 at 05:35:31AM -1000, David A. Harding wrote:
> On 2024-07-20 05:03, Peter Todd wrote:
> > What other "free" relay attacks can you think of that were fixed?
>=20
> The two you mention were the two I had in mind.

Right. So in the entire history of Core, we have two quite ridiculous free
relay attacks that got fixed, and we *added* a significant free-relay
vulnerability by adding mempool expiration. We also added a free-relay
vulnerability, and a fill-and-dump vulnerability, with the mempool size lim=
it.

That's not evidence that Core actually cares much about "free" relay.

> > Did you actually read my One-Shot RBFR proposal?
>=20
> Yes.  It didn't provide any examples of RBFr free relay and I wanted to
> see whether a basic RBFr free relay attack would use significantly more,
> significantly less, or about the same amount of bandwidth per dollar
> spent as other free relay attacks.  My conclusion is that it's about the
> same.

Good. So you basically agree with me that RBFR does _not_ significantly cha=
nge
the status quo.

I'll respond to the specifics of your RBFR analysis separately; it does *no=
t*
apply to one-shot RBFR.

> > Weak blocks are not a solution to any of the "free" relay attacks I've
> > disclosed and your source does not claim that they are a "free" relay
> > solution.
>=20
> It does not explicitly say that, but it does say: "bonus use-cases:
> =E2=80=9CForcible insertion=E2=80=9D of transactions that are incentive-c=
ompatible but
> violate anti-DoS rules".
>=20
> For example, in some of the scenarios you describe, the attacker sends
> an appealing transaction to miners and then sends less appealing
> versions of that transaction to relay nodes.  If the appealing
> transaction enters the top mempool and gets included in a weak block,
> relay nodes will stop relaying less appealing variations minutes to
> hours before they otherwise would.

Yes, "minutes to hours". Transactions relay on the order of seconds to tens=
 of
seconds. Weak blocks simply aren't relevant.

Also, the attacks I've described are ones that can be pulled off by having =
a
tiny minority of hash power mine a double spend. Weak blocks don't help you
there, as that tiny minority isn't likely to even find a weak block.

> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes.  That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.

For weak blocks to be a solution, you at minimum need to take away the abil=
ity
of miners to choose what transactions they mine. For example, consider the
scenario where you do a "free" relay attack by broadcasting transactions th=
at
OCEAN rejects, and then double-spending them via OCEAN _after_ the transact=
ions
have been broadcast. Equally, you'd need to take away the ability of RBFR
miners to do the revenue maximizing thing: mining RBFR replacements.

I'll also second Antoine Riard's objections to this class of idea in genera=
l:
you're really proposing a secondary pseudo-consensus mechanism to solve the
problems in your first pseud-consensus mechanism.

> > 1) Have you've read my One Shot RBFR proposal? In particular, my
> > analysis of DoS attacks *including* existing DoS attacks like
> > simultaneous broadcast.
> >=20
> > 2) Do you agree or disagree with me that these existing DoS attacks
> > are real?
>=20
> Yes, I've read your proposal, and I agree those attacks are plausible.
> In my mind, the major difference between those free relay attacks
> and RBFR free relay attacks is how solvable they are.
>=20
> I think it's easy to sketch a significant mitigation to all free relay
> attacks (including RBFR):
>=20
> - Reduce the maximum size of both relayable transactions and in-mempool
>   packages, e.g. from 100,000 vbytes to 1,000 vbytes.
>=20
> - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
>=20
> - Increase the default mempool feerate floor, e.g. from e.g. from 1
>   sat/vb to 100 sat/vb.
>=20
> That would break relay of many existing presigned transactions,
> potentially leading to money loss, and would break other existing
> usecases, not to mention introduce other problems.  However, I think
> it's sufficient to prove that a mitigation to free relay is possible
> without rendering the network unusable.

The irony here is you've almost described a _good_ mitigation to "free" rel=
ay
attacks: just reduce the size of the default mempool. A big reason why we h=
ave
"free" relay attacks right now is because we allow transactions to be broad=
cast
that are uneconomical to mine; if you limit transaction broadcast to
transactions that are economical to mine in the near future, relay is more
expensive.

For miners, you can make a decent argument that they want to have on-hand a=
 big
backlog of transactions in case mempools empty out; in my conversations wit=
h
miners almost all of them claim they run with much larger than default memp=
ools
(eg >1GB). I've even discussed mempool emptying attacks and RBFR in this
context with miners: they didn't think they were an issue as replacing thei=
r
mempools was absurdly expensive.

Fee estimation of course can make use of knowing what backlog of transactio=
ns
exist. But I'm sure only a small minority of nodes do fee estimation.

A variant of this solution would be to just pick the minimum relay fee to b=
e
some number N blocks worth of transactions "back" from the highest fee-rate=
 tip
of the mempool. Obviously, this will be easier to implement with a cluster
mempool, and requires package relay for the CPFP case.

> Of course, an ideal solution wouldn't require placing any additional
> constraints on mempool policy.  For the case of free relay due to
> divergent mempool policies, maybe it's something that could be done with
> transaction set reconciliation (~erlay), functions for allowing

Erlay (and transaction set reconciliation in general) does not help you
reconcile conflicting transactions. It simply lets you efficiently learn ab=
out
the total set of known transactions. Notice how the Erlay is based on WTXID=
s,
and the BIP doesn't even talk about dealing with conflicts.

> independent nodes to come to consistent conclusions about the best
> revenue set of transactions (~cluster mempool),

That's quite irrelevant as RBFR _is_ the highest revenue policy in lots of
situations. That's one reason why in my discussions with miners/pools, they=
're
interested in implementing it (mining pools have very low profit margins, s=
o
every cent counts, and RBFR replacements are reasonably common already). Mi=
ning
pools implemented full-RBF against the wishes of Core for the same reason:
full-RBF earns you more revenue, and I made it easy to implement.

Implementing one-shot RBFR is probably going to be quite a bit cleaner with
cluster mempools, as it'll provide a nice way to rapidly determine what the
minimum economic fee-rate is to get into the next (N) blocks. (though you c=
an
do this in a less clean way by just periodically assembling a trial block a=
nd
recording the value, or using the fee estimation code)

Finally, why are clusters even relevant to "free" relay? Most "free" relay
attacks don't even need transaction packages. The really boring and unsolva=
ble
"free" relay attack of simply broadcasting large transactions that conflict
with small ones is done with single transaction packages.

> P2P relay of non-obvious
> cluster linearizations[1], and miners voluntarily committing to their
> mempool contents in candidate blocks and P2P relaying those commitments
> in weak blocks.

As I explained above, weak blocks is not a "free" relay solution.

> Innovations like that don't work for RBFR.  If mempool policy is kept
> the same, free relay attacks with RBFR remain equally effective no
> matter what mechanisms we implement to improve preconsensus consistency.

I could also argue that magic ponies will solve "free" relay. We have to we=
ight
that hope with the likelyhood it will happen; none of the technical
advancements you have mentioned even come close.


Anyway, I'll reply to the rest of your other email separately.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--=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 on the web visit https://groups.google.com/d/msgid/=
bitcoindev/Zp1utYduhnWf4oA4%40petertodd.org.

--f6QbCljwwUF5QVIU
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmadbqwACgkQLly11TVR
LzfEuA//Vua35mgw1JMzh3drOYzEdP/59EpLDMGmcAsfNBoYfM+oEKsCpgtbv71K
u1XF1C83DonGutMHnPVzRbQiQ7fx6MBI8gaY+5hU4XY9hyBBsWhSnXW3c+UVvEj6
pvhsvU+ceB5DCsNnGVNHssxKw8XIGMI3+RZIqC+l9NsjXn6xe7296DUgE1p0tcR/
SS0krPd+hoFVFBiEjQMopDEjHhmFOznIJlkNmYnfMT8nhVCgGmZBsVEi5+c1b0LL
WbZpaoWqXdKbr0mZ3Wsr0nGnkXhvQme5bBe1nOBhSMexcpIEC1686Y0MIcXMWzsJ
S2U3KuUHn9i56RFGJ79OIxn5vrbXOBmxFcB3gDxgn7hnnGX3j+es2ZKoHinwTl97
yLanngdwQc8P+uU70K9ZgAoDh9Iu3BNbvAD0Rs3qFaHG+kAOZQBfnHRUXizfwGCn
EvasTpTPNQvtz5jnKe1dI9Z8fyxN5YKUjC7fagyzXrXtfOfLQOb6lCiVTTdyn1h8
5S/eN6v5X3TZ7aTdflOYcMIy8p2vlLjb6urW/afsX6e2Sv65AoRX81EdXTj6AHXf
wbfOZikjgshWediIHVNufZdlW438RAhnJIgpzg5XCqzWZmQgRIlWpreinNHyobDr
oQ/UrXSJNbFOKgoCwKmYfPFb9TUGz6sOvCosBrjXzBN7xUcXwm0=
=V5E8
-----END PGP SIGNATURE-----

--f6QbCljwwUF5QVIU--