path: root/80/a24c25c100702fd3d4c9210a3b29926a10146e

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>&gt;handing out xpubs makes the gap limit problem quadr=
atic</div><div><br></div><div>Yes, my thinking on this is that if you&#39;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>&gt;Could there be some more exotic deterministic path that doesn&#39;t=
 split receive and change addresses</div><div><br></div><div>I don&#39;t fo=
llow this one. I see no reason not to split the two, and I do see potential=
 pitfalls when you don&#39;t. Conceptually, I think receiving money twice o=
n the same address is never good. Even if you&#39;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 &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; 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 &quot;invoice address&quot; (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&#39;t =
split receive and change addresses? What is the first principle of splittin=
g change and receive? What&#39;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 &quot;gap&quot;. 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--