From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ) 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 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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.