path: root/86/0f67695bd0d2fbd3acede6ce3f6121339c219d

Delivery-date: Tue, 13 Feb 2024 13:12:47 -0800
Received: from mail-oa1-f56.google.com ([209.85.160.56])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBSFWV6XAMGQEZN5DGSA@googlegroups.com>)
	id 1ra058-0000G8-KE
	for bitcoindev@gnusha.org; Tue, 13 Feb 2024 13:12:47 -0800
Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-219688c2d4csf6928678fac.1
        for <bitcoindev@gnusha.org>; Tue, 13 Feb 2024 13:12:46 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1707858760; cv=pass;
        d=google.com; s=arc-20160816;
        b=wS5dQaZ1HtKHdkOP6foTpU6VGsG4dZz80RfMTetY5ML3iGzSRxy7Z5UBg8gHdOuakC
         fCJ12mNPvIHvp4iZdiHNza/Evr6bq8qvVJP9hCNOATbwUPtkXvaG+9nlvB74yViBwcdI
         4kz1K9w3ImelBKLiUU7OitXpP5d8m7/yviJQhS+iqroiVyVk+rGpHgvH8ETnpzjbaOsV
         H1Kn+oD71pN2LCgODH4Zi282tr5zosdq8TKet4vHTtXwhssS/x58pSGqZB/0940krYLw
         mQ8ilKgZGrQc5P4V0N5tcvw9YfulwwhibZLunbqbZ2ILokliFYEQl+cvC1tonWlEwMR4
         k09Q==
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:content-transfer-encoding
         :in-reply-to:to:references:content-language:subject:from
         :mime-version:date:message-id:sender:dkim-signature;
        bh=2Xi58OPE1tj27ch9faiLQJ+ban8eDf2JhM5/qbIpiYY=;
        fh=GF82EJ4ES29n/xfdGev5qQe7/gDaEy3OrOcO1CyBaDE=;
        b=vD6Askd6ar3MmWAGTvXX3wXkvOgIKVZnIsCywr/s4N1/fxhi2ZJKwe8qfoZnzC899v
         Den+WrugP17YOzxu2rPkRDQjKBXeUMsyQABIIemOZ3kz1ZjTrrwmM8wpDDv+/pjcU8qB
         x9wQmFvu30nWlQLUcSZK102vqyptpTvXCOfmb7ewp6/vIdk56LHrxWvEvo4CzoaFuEFZ
         vZ5XBZLe/5dAQeNtYw8eNcJMGKGlTB3tlxDRs9nDZxqbLEEBVA3ZmLQRlUDb6p6KJ0RW
         2mzG667S7F0+FakSTnv/g7F27Fue7pCqEOUjQcGbE2v0lRZV/JGFGg7Y71QHGz0VA6hW
         f0jw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@mattcorallo.com header.s=1707852062 header.b=r7KgMXPw;
       dkim=pass header.i=@clients.mail.as397444.net header.s=1707852064 header.b=ZhK5MXDN;
       spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com;
       dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1707858760; x=1708463560; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding:in-reply-to:to
         :references:content-language:subject:from:mime-version:date
         :message-id:sender:from:to:cc:subject:date:message-id:reply-to;
        bh=2Xi58OPE1tj27ch9faiLQJ+ban8eDf2JhM5/qbIpiYY=;
        b=S85wpg66NIvOaf7Tni/FDc1MivMRrJlSUVcwWxvkyEL7cbC7nfe4EWqdQLGduszuc3
         vYsnJ8ICjBl4scsnxGJgLVdzU3x5EhySfRZk7NIfS3Sd5lqjSiErsp/fUG7/jbG1CE7L
         bijadAHqIsKbSfiau3eyJ9LR8BD1WCMwdQ549UgFCN1Z94Q7/sBYIMq1A5oZPpMabcAd
         ea4dHs8646S3y8aAADiQmQNAzoGrKQSwUTqhsmGr0DrynxzaTCAiegccKRi11ZsAsk7y
         cdKn2m2puNoIq/hkExt13TUkE0wohx6ErFlI5Py1uDQ6ICvnzYPCJOflgUNcAXf2wP7u
         tTvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1707858760; x=1708463560;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding:in-reply-to:to
         :references:content-language:subject:from:mime-version:date
         :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject
         :date:message-id:reply-to;
        bh=2Xi58OPE1tj27ch9faiLQJ+ban8eDf2JhM5/qbIpiYY=;
        b=nbzuKleVg68DRVtlIc8CTCbqi3XFkWkmNkRgOhS5gpE9WhzJKMHtGubFEN09bjGnks
         3erxRotI8jHHieu9+ITGTjilRIGCGhtHm6KDiVyA+P5Jk9mY6ke1Fq7p/BgYg3YdvIVQ
         I7eFCmVi7ClmwZ2lY8gx2fCpLtJs+nfRuNU2ZlKrH3mmGueXHtkDBEbjcGfasDFqWJGK
         g5KkPOH0IL56Wk3LiiIL1y3fCtl+etswdPtwXPH8TqkxKsepmgNhja4LG7Vjz17upJp+
         ly6AfcrRPouateLgeG8hNveK9FNUBFwOVQvL0vFJEfyxEomy2ivrDUz7/EpEifpsC3dO
         00GQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVmtweC5VRNfdQJbxD82IKnZ4sxrr/IzAs0IqdFTfuyy201i3UZP4j5LX3DXEpYabYQYoyyaLamsHeCQaoEdCzMfTfHxK8=
X-Gm-Message-State: AOJu0YweM3LwGG+qXR5N5F9DYXwVNPaCaz9iRBMQTeNKfKvfUpiexqPE
	xTgeRxzMQWxOa0oQHyUERxEssXwB6pVPslV34VBOofdqdEgavoeo
X-Google-Smtp-Source: AGHT+IFepnmAQYbULiCHQGwMjxeeoV5Vjp9F5EcbBTr0gASKwb3j1NB2/R8opCS+D89sSSJXu/dt7Q==
X-Received: by 2002:a05:6870:8186:b0:21a:177e:b181 with SMTP id k6-20020a056870818600b0021a177eb181mr644790oae.10.1707858760495;
        Tue, 13 Feb 2024 13:12:40 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6870:ed91:b0:219:fe45:3b95 with SMTP id
 fz17-20020a056870ed9100b00219fe453b95ls2692847oab.1.-pod-prod-05-us; Tue, 13
 Feb 2024 13:12:39 -0800 (PST)
X-Received: by 2002:a05:6871:3a13:b0:218:d1b7:e8dc with SMTP id pu19-20020a0568713a1300b00218d1b7e8dcmr28009oac.1.1707858759849;
        Tue, 13 Feb 2024 13:12:39 -0800 (PST)
Received: by 2002:a05:6808:13d5:b0:3c0:34d4:886b with SMTP id 5614622812f47-3c04a3416ebmsb6e;
        Tue, 13 Feb 2024 11:56:41 -0800 (PST)
X-Received: by 2002:a17:903:25cf:b0:1db:28b6:cb3b with SMTP id jc15-20020a17090325cf00b001db28b6cb3bmr546731plb.6.1707854200019;
        Tue, 13 Feb 2024 11:56:40 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1707854200; cv=none;
        d=google.com; s=arc-20160816;
        b=tZf6HANPFV7hoKI6XwR0fv4TBfriA5QSjdRv65eclJu2zqw+4PICHZumSIzAtbu9ZF
         bAU4HlNGTQ0lqUK2AnG5wPzjF+taLQbp5jTGxE7iDdl7UgJBFSeMnWrQlxLzPGuA4blY
         1PeOskHCNNm2OZqllxIK8hSO+WvEY7Gk+KWmjptConDuP3e9P16XWmPvF8ioO9i9wYAv
         iJXLkKnorGxZ8ZnM3QhgOK89bPF7uWE581LcehFXLwypbKkNP9ScSeyafhNF4ECCCDWr
         txwr7aj78FUUU2xKreQtvJh6ZEKGYdBmayFzhy1W3RQE4SfuKUuax81P1Gq0ffCzqdyA
         1XNw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:in-reply-to:to:references
         :content-language:subject:from:mime-version:date:message-id
         :dkim-signature:dkim-signature;
        bh=9dG0KzSB3T7wytYgcEGnsCJVKHp5Fdn+pcejPMzScKo=;
        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
        b=s9nBUNPCX+XKLYM1rkpbWk80KLAcdx8bffQ2kenh5lYP+uHZiUaErd7IMriv1RNSPa
         oNjoXc1yFntdOkk9Wd0T0DF++wQFcl6tCDiniwLnr6CV+Y28MdtcexTvloy/P/TCaWFJ
         0pqvQYaVLnl2yaOwTtdRYuj1onhH7MpsCT0i6Xy0JDpBV2Cb4qHeiFeTzgxKkMhL9YJx
         mi2WR+/V3MVI3G7GebBuQddysH5OVntAyMkbstD9sIo8jMoRrc0qlnsVw5kNaYJDMZt7
         /2OSwt4zdQeUWsoLxZWoryti4xKfhB9i4B9xYZVIn5WJF4v8KfuvMAaUmlrg2UYRBfh0
         ND1w==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@mattcorallo.com header.s=1707852062 header.b=r7KgMXPw;
       dkim=pass header.i=@clients.mail.as397444.net header.s=1707852064 header.b=ZhK5MXDN;
       spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com;
       dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com
Received: from mail.as397444.net (mail.as397444.net. [69.59.18.99])
        by gmr-mx.google.com with ESMTPS id q14-20020a170902a3ce00b001d6f295bc4esi58625plb.4.2024.02.13.11.56.39
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 13 Feb 2024 11:56:39 -0800 (PST)
Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99;
X-DKIM-Note: Keys used to sign are likely public at
X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and
X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net
X-DKIM-Note: For more info, see https://as397444.net/dkim/
Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim)
	(envelope-from <lf-lists@mattcorallo.com>)
	id 1rZytS-009z13-26 for bitcoindev@googlegroups.com;
	Tue, 13 Feb 2024 19:56:38 +0000
Message-ID: <34eaef2a-b53f-4622-a620-a3bc5161cbf7@mattcorallo.com>
Date: Tue, 13 Feb 2024 11:56:38 -0800
MIME-Version: 1.0
From: Matt Corallo <lf-lists@mattcorallo.com>
Subject: [bitcoindev] Mapping Human-Readable Names to Payment Instructions
Content-Language: en-US
References: <3452d0b7-2d46-46bd-a59d-5b1206d882d0@mattcorallo.com>
To: bitcoindev@googlegroups.com
In-Reply-To: <3452d0b7-2d46-46bd-a59d-5b1206d882d0@mattcorallo.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Original-Sender: lf-lists@mattcorallo.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@mattcorallo.com header.s=1707852062 header.b=r7KgMXPw;
       dkim=pass header.i=@clients.mail.as397444.net header.s=1707852064
 header.b=ZhK5MXDN;       spf=pass (google.com: domain of lf-lists@mattcorallo.com
 designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com;
       dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.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.8 (/)


Hey new-list!

I'd like to propose a BIP defining a mechanism to resolve human-readable na=
mes to Bitcoin payment=20
instructions in a way that supports lightning/on-chain/payjoin/silent addre=
sses/etc/etc. Below you=20
can find the full BIP draft for comments, as well as in the BIPs repo at=20
https://github.com/bitcoin/bips/pull/1551

Matt



=3D=3DAbstract=3D=3D
This BIP proposes a standard format for encoding [[bip-0021.mediawiki|BIP 2=
1]] URI schemes in DNS=20
TXT records.

=3D=3DMotivation=3D=3D
Various Bitcoin and other cryptocurrency applications have developed human-=
readable names for=20
payment instructions over time, with marketplace adoption signaling strong =
demand for it from users.

The DNS provides a standard, global, hierarchical namespace mapping human-r=
eadable labels to records=20
of various forms. Using DNSSEC, the DNS provides cryptographic guarantees u=
sing a straightforward=20
PKI which follows the hierarchical nature of the DNS, allowing for stateles=
s and even offline=20
validation of DNS records from a single trusted root.

Further, because DNS queries are generally proxied through ISP-provided or =
other resolvers, DNS=20
queries usually do not directly expose the queryer's IP address. Further, b=
ecause of the prevalence=20
of open resolvers, the simplicity of the protocol, and broad availability o=
f DNS recursive resolver=20
implementations, finding a proxy for DNS records is trivial.

Thus, using TXT records to store Bitcoin payment instructions allows for hu=
man-readable Bitcoin=20
payment destinations which can be trivially verified on hardware wallets an=
d which can be resolved=20
relatively privately.

=3D=3DSpecification=3D=3D

=3D=3D=3D General rules for handling =3D=3D=3D
Bitcoin wallets MUST NOT prefer to use DNS-based resolving when methods wit=
h explicit public keys=20
are available. In other words, if a standard Bitcoin address or direct BIP =
21 URI is available or=20
would suffice, Bitcoin wallets MUST prefer to use that instead.

=3D=3D=3D Records =3D=3D=3D
Payment instructions are indexed by both a user and a domain. Instructions =
for a given `user` and=20
`domain` are stored at `user`.user._bitcoin-payment.`domain` in a single TX=
T record.

All payment instructions MUST be DNSSEC-signed.

Payment instructions MAY resolve through CNAME or DNAME records as long as =
all such records and the=20
ultimate records pointed to by them are DNSSEC signed.

User and domain names which are not expressible using standard printable AS=
CII MUST be encoded using=20
the punycode IDN encoding defined in [[https://datatracker.ietf.org/doc/htm=
l/rfc3492|RFC 3492]] and=20
[[https://datatracker.ietf.org/doc/html/rfc5891|RFC 5891]].

=3D=3D=3D Resolution =3D=3D=3D

Clients resolving Bitcoin payment instructions MUST ignore any TXT records =
at the same label which=20
do not begin with (ignoring case) "bitcoin:". Resolvers encountering multip=
le "bitcoin:"-matching=20
TXT records at the same label MUST treat the records as invalid and refuse =
to use any payment=20
instructions therein.

Clients resolving Bitcoin payment instructions MUST fully validate DNSSEC s=
ignatures leading to the=20
DNS root (including any relevant CNAME or DNAME records) and MUST NOT accep=
t DNSSEC signatures which=20
use SHA-1 or RSA with keys shorter than 1024 bits. Resolvers MAY accept SHA=
-1 DS records.

Clients resolving Bitcoin payment instructions MUST NOT trust a remote reso=
lver to validate DNSSEC=20
records on their behalf.

Clients resolving Bitcoin payment instructions MUST support resolving throu=
gh CNAME or DNAME records.

Resolvers MAY support resolving non-ASCII user and domain identifiers. Reso=
lvers which do support=20
non-ASCII user and domain identifiers MUST take precautions to prevent homo=
graph attacks and SHOULD=20
consider denying paste functionality when entering non-ASCII identifiers.

=3D=3D=3D Address Reuse =3D=3D=3D

Payment instructions with on-chain addresses which will be re-used SHOULD b=
e rotated as regularly as=20
possible to reduce address reuse. Such payment instructions SHOULD also use=
 a relatively short DNS=20
TTL to ensure regular rotation takes effect quickly. In cases where this is=
 not practical, payment=20
instructions SHOULD NOT contain on-chain addresses (i.e. the URI path SHOUL=
D be empty).

=3D=3D=3D Display =3D=3D=3D

Wallets SHOULD parse recipient information in the form `user`@`domain` and =
resolve such entry into=20
recipient information using the above record. Similarly, wallets accepting =
payment information from=20
external devices (e.g. hardware wallets) SHOULD accept RFC 9102-formatted p=
roofs (as a series of=20
unsorted `AuthenticationChain` records) and, if they verify, SHOULD display=
 the recipient in the=20
form `user`@`domain`.

=3D=3D Rationale =3D=3D

There are many existing schemes to resolve human-readable names to cryptocu=
rrency payment=20
instructions. Sadly, these current schemes suffer from a myriad of drawback=
s, including (a) lacking=20
succinct proofs of namespace to public key mappings, (b) revealing sender I=
P addresses to recipients=20
or other intermediaries as a side-effect of payment, (c) relying on the blo=
ated TLS Certificate=20
Authority infrastructure, or (d) lacking open access, not allowing anyone t=
o create a namespace mapping.

=3D=3D=3D DNS Rather than blockchain-based solutions =3D=3D=3D
There are many blockchain-based alternatives to the DNS which feature bette=
r censorship-resistance=20
and, in many cases, security. However, here we chose to use the standard IC=
ANN-managed DNS namespace=20
as many blockchain-based schemes suffer from (a), above (though in some cas=
es this could be=20
addressed with cryptographic SNARK schemes). Further, because they do not h=
ave simple client-side=20
querying ability, many of these schemes use trusted intermediaries which re=
solve names on behalf of=20
clients. This reintroduces drawbacks (b) and often (c) as well.

Finally, its worth noting that none of the blockchain-based alternatives to=
 the DNS have had=20
material adoption outside of their specific silos, and committing Bitcoin w=
allets to rely on a=20
separate system which doesn't see broad adoption may not be sustainable.

=3D=3D=3D DNS Rather than HTTP-based solutions =3D=3D=3D
HTTP(s)-based payment instruction resolution protocols suffer from drawback=
s (a), (b), and (c),=20
above, and generally shouldn't be considered a serious alternative for paym=
ent instruction resolution.

=3D=3D=3D Private DNS Querying =3D=3D=3D
While public recursive DNS resolvers are very common (e.g. 1.1.1.1, 8.8.8.8=
, and 9.9.9.9), using=20
such resolvers directly (even after validating DNSSEC signatures) introduce=
s drawback (b), at least=20
in regard to a centralized intermediary. Resolving payment instructions rec=
ursively locally would=20
instead introduce drawback (b) directly to the recipient, which may well be=
 worse.

For payers not using VPN or other proxying technologies, they generally tru=
st their ISP for=20
protection against denial of service anyway, so using ISP-provided recursiv=
e DNS resolvers is=20
sufficient.

However, for the best privacy, payers are encouraged to perform DNS resolut=
ion over Tor or another=20
VPN technology.

Lightning payers should consider utilizing DNS resolution over native onion=
 messages, using the=20
protocol described in [[BLIP 32|https://github.com/lightning/blips/blob/mas=
ter/blip-0032.md]]

=3D=3D=3D DNS Enumeration =3D=3D=3D

In most cases where payments are accepted from any third-party, user enumer=
ation is practical by=20
simply attempting to send small value payments to a list of possible user n=
ames. However, storing=20
all valid users in the DNS directly may make such enumeration marginally mo=
re practical. Thus, those=20
wishing to avoid such enumeration should carefully ensure all DNS names ret=
urn valid payment=20
instructions. Note when doing so that wildcard records are identified as su=
ch by the DNSSEC RRSIG=20
labels counter and are differentiable from non-wildcard records.

=3D=3D Examples =3D=3D

`matt@mattcorallo.com` resolves to
`matt.user._bitcoin-payment.mattcorallo.com. 3600 IN TXT=20
"bitcoin:?b12=3Dlno1qsgqmqvgm96frzdg8m0gc6nzeqffvzsqzrxqy32afmr3jn9ggkwg3eg=
fwch2hy0l6jut6vfd8vpsc3h89l6u3dm4q2d6nuamav3w27xvdmv3lpgklhg7l5teypqz9l53hj=
7zvuaenh34xqsz2sa967yzqkylfu9xtcd5ymcmfp32h083e805y7jfd236w9afhavqqvl8uyma7=
x77yun4ehe9pnhu2gekjguexmxpqjcr2j822xr7q34p078gzslf9wpwz5y57alxu99s0z2ql0kf=
qvwhzycqq45ehh58xnfpuek80hw6spvwrvttjrrq9pphh0dpydh06qqspp5uq4gpyt6n9mwexde=
44qv7lstzzq60nr40ff38u27un6y53aypmx0p4qruk2tf9mjwqlhxak4znvna5y"`
Note that `b12` indicates a value containing a lightning BOLT12 offer.

=3D=3D Reference Implementations =3D=3D
* A DNSSEC proof generation and validation implementation can be found at=
=20
https://git.bitcoin.ninja/index.cgi?p=3Ddnssec-prover;a=3Dsummary
* A lightning-specific name to payment instruction resolver can be found at=
=20
https://git.bitcoin.ninja/index.cgi?p=3Dlightning-resolver;a=3Dsummary
* Reference implementations for parsing the URI contents can be found in [[=
bip-0021.mediawiki|BIP 21]].

--=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/34eaef2a-b53f-4622-a620-a3bc5161cbf7%40mattcorallo.com.