diff options
| author | Ruben Somsen <rsomsen@gmail.com> | 2022-10-01 12:18:49 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-10-01 10:19:04 +0000 |
| commit | e1803736d3e84c6e4abfef9f5b82a3219d8cb021 (patch) | |
| tree | afe1763b58650a867d20c5bd871dfbfde358ac4a | |
| parent | 23f02a83b7cd0251b0195f0c1604775e87bff98a (diff) | |
| download | pi-bitcoindev-e1803736d3e84c6e4abfef9f5b82a3219d8cb021.tar.gz pi-bitcoindev-e1803736d3e84c6e4abfef9f5b82a3219d8cb021.zip | |
Re: [bitcoin-dev] Trustless Address Server ? Outsourcing handing out addresses
| -rw-r--r-- | 80/a24c25c100702fd3d4c9210a3b29926a10146e | 250 |
1 files changed, 250 insertions, 0 deletions
diff --git a/80/a24c25c100702fd3d4c9210a3b29926a10146e b/80/a24c25c100702fd3d4c9210a3b29926a10146e new file mode 100644 index 000000000..a00450dd4 --- /dev/null +++ b/80/a24c25c100702fd3d4c9210a3b29926a10146e @@ -0,0 +1,250 @@ +Return-Path: <rsomsen@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 72161C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 1 Oct 2022 10:19:04 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 3987A4177C + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 1 Oct 2022 10:19:04 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3987A4177C +Authentication-Results: smtp4.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20210112 header.b=lvjipETd +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id w1mjilnWl97S + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 1 Oct 2022 10:19:02 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5FDA041778 +Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com + [IPv6:2001:4860:4864:20::30]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 5FDA041778 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 1 Oct 2022 10:19:02 +0000 (UTC) +Received: by mail-oa1-x30.google.com with SMTP id + 586e51a60fabf-131ea99262dso5859744fac.9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 01 Oct 2022 03:19:02 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=cc:to:subject:message-id:date:from:in-reply-to:references + :mime-version:from:to:cc:subject:date; + bh=XiG4DW2bCp4Had49V/6BC4eRK2lHadr4hvFOycG2L1I=; + b=lvjipETdkUxwYJQHrWlelsjWg03p9pBu8gCIul55saQ3bh+ELGvsz/tNmixFJ8rCmh + T20pVFAvjp+3w9XiKNXSMFzcw5F098cjw/gizhYPYZh4e+z2J/r/fRqce4cx/41ewloo + H/nxD5iACmqiCLO2wW3OzXRpWjzTvspkqNLAQ0CwAYJtlZJS9X6tBAyA7Qgl7ybHskFW + XNylNl1+/P1CcnpZFip7b8FHEpzz9gz2kQWpOlShcPoSDh1rL0ME00pDRgf7ZEkQSL33 + yVjY+0q1WD+G5sT3HoOZOCQx746yqiNvQ3SBVSmUHLRT/RJl/tK3/23fYW2Iurbi69tr + QJ1Q== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=cc:to:subject:message-id:date:from:in-reply-to:references + :mime-version:x-gm-message-state:from:to:cc:subject:date; + bh=XiG4DW2bCp4Had49V/6BC4eRK2lHadr4hvFOycG2L1I=; + b=oA/AbEJ8KqN5HhYiWRmC9O8siKjsFH36ZWxnnnDs5WRXU5dJ3Bc4PDLAaPn0nO4rUm + VOOAljTdO9MPyevJB//Cty9DCaC1BheRNWVeRQCJwql9CYFiObCI3hjDlOeCSRmGeSQa + oCFLEamuY7z7pULXY/6r+/5xyfrZq+k1ehAcp8DVDqBcUIwoEwzbVUTbWgfv3xHkLo/b + onDMXEI1hAywAvKxk8xN3vaOFcBe+iM3vDZ4aBKcfBqaQKSmP/bxkN2Qb17HtoXJ+i8W + X1J0U/CiDB0x+D4/BkO8aqJ7+RyfVerQhoUKLkftGUFBqZ97/ImuNh6X3gk/3YqIrtuN + hVYg== +X-Gm-Message-State: ACrzQf006cKlYULrT8aHsrhXO5XskclGuzK+yh96tvoDzaQkXprgQx1h + PIqYnTtuAHgxcYPfmoecUaajKxzQu8H8P/9JcOQ= +X-Google-Smtp-Source: AMsMyM7D8PmgRdme+YOzMn8fOlH3Ag0Ytnf3ZXg22A6isTMMo4aGC1irtdxbO0KArSM7bOtBcEZKfCthe1NIH2CP4Wk= +X-Received: by 2002:a05:6870:c0c9:b0:127:c4df:5b50 with SMTP id + e9-20020a056870c0c900b00127c4df5b50mr1082882oad.126.1664619541353; Sat, 01 + Oct 2022 03:19:01 -0700 (PDT) +MIME-Version: 1.0 +References: <6xXKU-w7H59G0i0KInVVRYJWX5hPvs-5NUrsHeUEKQRWpzRxrWa4qxq4M3Hq6dcW00ps2lWdMejDtMj7640LXNTqQ3UK6j06U0-nuvOYhrA=@pointbiz.com> +In-Reply-To: <6xXKU-w7H59G0i0KInVVRYJWX5hPvs-5NUrsHeUEKQRWpzRxrWa4qxq4M3Hq6dcW00ps2lWdMejDtMj7640LXNTqQ3UK6j06U0-nuvOYhrA=@pointbiz.com> +From: Ruben Somsen <rsomsen@gmail.com> +Date: Sat, 1 Oct 2022 12:18:49 +0200 +Message-ID: <CAPv7Tjb8oOO3j76HGGuoau+Sz86rFBDFdctsgFO6QUrJNjXj-w@mail.gmail.com> +To: Peter <dizzle@pointbiz.com> +Content-Type: multipart/alternative; boundary="00000000000072d7c105e9f670ae" +X-Mailman-Approved-At: Sat, 01 Oct 2022 10:19:24 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Trustless Address Server ? Outsourcing handing + out addresses +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sat, 01 Oct 2022 10:19:04 -0000 + +--00000000000072d7c105e9f670ae +Content-Type: text/plain; charset="UTF-8" + +Hi Peter, + +Thanks for your comments. + +>handing out xpubs makes the gap limit problem quadratic + +Yes, my thinking on this is that if you're handing out xpubs you can lower +the gap limit for addresses generated by those xpubs, provided you assume +those addresses will be used by the same person, so there is less of a +reason to expect a gap. This thread is related: +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020954.html + +>How can we make a layer 1 address that expires + +This was brought up by Sjors Provoost in relation to Silent Payments. He +suggested embedding a sunset date in the address format. + +>Could there be some more exotic deterministic path that doesn't split +receive and change addresses + +I don't follow this one. I see no reason not to split the two, and I do see +potential pitfalls when you don't. Conceptually, I think receiving money +twice on the same address is never good. Even if you're doing it to +actively mislead people, that attempt is still leaking information that +simply didn't need to be leaked. + +Cheers, +Ruben + +On Sat, Oct 1, 2022 at 10:57 AM Peter via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Hi Ruben, +> +> +> I think this is an important conversation you have raised. I want to add +> some points for discussion. +> +> +> 1) handing out xpubs makes the gap limit problem quadratic. +> +> +> Each customer, of a given business, on an invoice must be given a unique +> address or xpub but they may pay in cash or credit card or bank wire. How +> do we present more than 20 customers with an "invoice address" (regular +> address or xpub)? +> +> (In Lightning world you give a Lightning address that uses plus addresses. +> Like castiron+customer1.invoice1@LSP.com +> +> +> If you hand out xpubs it can be the case that you hand out a consecutive +> streak of 20 xpubs that are never used. Your wallet has to scan 20 xpubs +> and their 20 first receive addresses. +> +> +> +> 2) Whether you give the sender an address for reuse or an xpub for reuse +> there needs to be an expiry such that the receiver can confirm they still +> have the corresponding keys. How can we make a layer 1 address that expires +> like a PGP key where it can still be used but raises a warning to the +> sender? +> +> (In Lightning we have that) +> +> +> 3) Could there be some more exotic deterministic path that doesn't split +> receive and change addresses? What is the first principle of splitting +> change and receive? What's wrong with an address reused exactly twice? The +> sender and receiver both with know what was a payment and what was change. +> Will it create plausible deniability about change addresses? +> +> +> Satoshi original wallet concept was an ever growing key pool with a 100 +> address "gap". Maybe the solution to the gap limit is to add invoice +> functionality to wallets that manage issuing fresh addresses even without +> them being used and have a configurable gap limit. Is that what +> Btcpayserver does? +> +> +> Regards +> +> Peter Kroll +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--00000000000072d7c105e9f670ae +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi Peter,<div><br></div><div>Thanks for your comments.<br>= +<div><br></div><div>>handing out xpubs makes the gap limit problem quadr= +atic</div><div><br></div><div>Yes, my thinking on this is that if you'r= +e handing out xpubs you can lower the gap limit for addresses generated by = +those xpubs, provided you assume those addresses will be used by the same p= +erson, so there is less of a reason to expect a gap. This thread is related= +:</div><div><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-= +dev/2022-September/020954.html">https://lists.linuxfoundation.org/pipermail= +/bitcoin-dev/2022-September/020954.html</a><br></div><div><br></div><div>&g= +t;How can we make a layer 1 address that expires</div><div><br></div><div>T= +his was brought up by Sjors Provoost in relation to Silent Payments. He sug= +gested embedding a sunset date in the address format.</div><div><br></div><= +div>>Could there be some more exotic deterministic path that doesn't= + split receive and change addresses</div><div><br></div><div>I don't fo= +llow this one. I see no reason not to split the two, and I do see potential= + pitfalls when you don't. Conceptually, I think receiving money twice o= +n the same address is never good. Even if you're doing it to actively m= +islead people, that attempt is still leaking information that simply didn&#= +39;t need to be leaked.</div><div><br></div><div>Cheers,</div><div>Ruben</d= +iv></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma= +il_attr">On Sat, Oct 1, 2022 at 10:57 AM Peter via bitcoin-dev <<a href= +=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo= +undation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= +g-left:1ex">Hi Ruben,<div><br></div><div><br></div>I think this is an impor= +tant conversation you have raised. I want to add some points for discussion= +. <div><br></div><div><br></div>1) handing out xpubs makes the gap limit pr= +oblem quadratic. <div><br></div><div><br></div>Each customer, of a given bu= +siness, on an invoice must be given a unique address or xpub but they may p= +ay in cash or credit card or bank wire. How do we present more than 20 cust= +omers with an "invoice address" (regular address or xpub)?<div><b= +r></div>(In Lightning world you give a Lightning address that uses plus add= +resses. Like castiron+customer1.invoice1@LSP.com<div><br></div><div><br></d= +iv>If you hand out xpubs it can be the case that you hand out a consecutive= + streak of 20 xpubs that are never used. Your wallet has to scan 20 xpubs a= +nd their 20 first receive addresses. <div><br></div><div><br></div><div><br= +></div>2) Whether you give the sender an address for reuse or an xpub for r= +euse there needs to be an expiry such that the receiver can confirm they st= +ill have the corresponding keys. How can we make a layer 1 address that exp= +ires like a PGP key where it can still be used but raises a warning to the = +sender?<div><br></div>(In Lightning we have that)<div><br></div><div><br></= +div>3) Could there be some more exotic deterministic path that doesn't = +split receive and change addresses? What is the first principle of splittin= +g change and receive? What's wrong with an address reused exactly twice= +? The sender and receiver both with know what was a payment and what was ch= +ange. Will it create plausible deniability about change addresses? <div><br= +></div><div><br></div>Satoshi original wallet concept was an ever growing k= +ey pool with a 100 address "gap". Maybe the solution to the gap l= +imit is to add invoice functionality to wallets that manage issuing fresh a= +ddresses even without them being used and have a configurable gap limit. Is= + that what Btcpayserver does? <div><br></div><div><br></div>Regards <div><b= +r></div>Peter Kroll <div><br></div>________________________________________= +_______<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--00000000000072d7c105e9f670ae-- + |