path: root/87/e3b7875b92eba91aa1fd1acead40462427c0cf

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 673C3C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 22:41:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 2D0A641C56
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 22:41:42 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2D0A641C56
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=UYRMFMEA
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 fYRU5y3UojFx
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 22:41:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5166541C52
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com
 [IPv6:2607:f8b0:4864:20::233])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 5166541C52
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 22:41:40 +0000 (UTC)
Received: by mail-oi1-x233.google.com with SMTP id m130so3061394oif.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 15:41:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date;
 bh=2iLlLw3rvO1VRBvAYIZ2g9eb4rGYb3DfWlejs3CpGQ8=;
 b=UYRMFMEARcsfjIQWPv7Do5JhOHryGjZSBIVfURXBLrk6/B3MF/Qf1/uhPbkPZanvoX
 oiH7JQdjFgtfjiMLkZsxnXJKgHo9n4o8pkSEYZa9KQ6nVAsgdBpD1EWHD3xcsqGrDQWT
 R9ggz04Hfdj79AoKB73yA7Zcamek8mfS7zzinluAFscahgwAeO4Pk0+eW0E9jwcCZehe
 nXnFCgjBvOyBTPHmppRx1KPc6buWfpas6F0sOtfwwn7uOtZ9iRgF+Q2RHrInSZV87B92
 lk2qI/IVcy3BE+ctYOfu6leLCpELY8cYjd7iwtH3sFlbFFOrYZpsdXTRWgBYoX2O0r8L
 jN4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date;
 bh=2iLlLw3rvO1VRBvAYIZ2g9eb4rGYb3DfWlejs3CpGQ8=;
 b=S054Cc8nM+DuZmIdhNIPcWTRdvytZOqBftOQ0cyf3wxVqB18Xtc2Za54zxdQk5r5sk
 kgS+zKKht/bAm0+r0vftC93CPwdZhcZqZfZ529mtz3IGW6y44hRUwOqnl8WoiI3ZmYdD
 QiTF6iLcVEEOTpmEtryHEn0elwczfF7tsSMeEZ5u5o795K/6htNZzxPQUQaAoS9jpyOL
 ollrWJqxITGste8K6JIVLvLbrZsI9szOc4YBzLAR9YvEzfYupzVF8cbKSOANE1pZQJIh
 YxIw8pCki5IlNGNUQEXa6M53Za3d7foP2bWmFQme5S7J8IFI0mrtCQWxCzuatAC7Xv3q
 c3+g==
X-Gm-Message-State: ACrzQf0mko2yhFyoz2teNuJ2nxhR7ZwOUBUXjA6WGJjC3EafxwOhO3WT
 kBm9L1eYmHPeCozTkC/yVAzlgU7stageqloUuISpwvejhCE=
X-Google-Smtp-Source: AMsMyM7vTEBsEt9MD022EwCo8zGhogia1AkcTSZG3hgLLBw8iMXVhUU+bHspkR5WbbzbFsYcAcaag5bgXOe6b2YYSWA=
X-Received: by 2002:aca:b957:0:b0:351:4ecf:477d with SMTP id
 j84-20020acab957000000b003514ecf477dmr2646319oif.126.1664491299253; Thu, 29
 Sep 2022 15:41:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAPapNH28iCxEcTOKt3YC+zuZzxbM=AudbbYByjS3aUZAgFHUag@mail.gmail.com>
In-Reply-To: <CAPapNH28iCxEcTOKt3YC+zuZzxbM=AudbbYByjS3aUZAgFHUag@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Fri, 30 Sep 2022 00:41:29 +0200
Message-ID: <CAPv7TjZFN1r84EXON_gpNmJm2=x0x6-=5SqdCP5_n2EaObUEtA@mail.gmail.com>
To: El_Hoy <eloyesp@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009fb14305e9d89492"
X-Mailman-Approved-At: Thu, 29 Sep 2022 22:42:45 +0000
Subject: Re: [bitcoin-dev] RFC for a BIP32 recurrent address derivation
	scheme
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: Thu, 29 Sep 2022 22:41:42 -0000

--0000000000009fb14305e9d89492
Content-Type: text/plain; charset="UTF-8"

Hi Eloy,

Nice idea.

Note I thought about and succinctly described a similar scheme here (which
in turn was derived from work by Kixunil):
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing

I agree with your general assessment that this is a scheme that seems like
an improvement over the status quo. Note that both BIP47 and Silent
Payments don't require any interaction with the sender, while this scheme
requires one-time interaction (e.g. this wouldn't be suitable for one-time
donations). I think this would mostly be a convenience feature that
improves the regular interactive payment flow (interact once, instead of
repeatedly asking for addresses with each payment).

>master / purpose' / coin_type' / contact' / index

Despite your explanation, it's still not fully clear to me how "contact" is
defined, but I assume it's just a counter? Just in case, note that you
can't let Bob define it for Carol, as then you can't deterministically
recover your payments without also backing up how it's defined (the seed
alone won't be enough).

The gap limit also needs to be kept in mind. If we allow each xpub to have
its own gap limit, you potentially get an exponential blowup (gaps in the
xpub * gaps in the addresses generated from the xpubs). It may be OK to
define a low default gap limit for these xpubs, since there should be no
reason to expect the same sender to leave any gaps, though this may depend
on how the xpubs are used (e.g. it may also be used to derive addresses for
others) so it's probably important to be explicit about this.

Cheers,
Ruben



On Thu, Sep 22, 2022 at 5:18 PM El_Hoy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There is a known issue on bitcoin, that is that every transaction requires
> a new address to prevent address reuse, making it uncomfortable to make
> recurring payments, as every payment requires a new off-chain interaction.
> A scheme is already mentioned on the [on the BIP32 itself][1], but it
> cannot be implemented as is.
>
> Here I propose a scheme that follows the structure described on [BIP44]
> that should make it possible to send recurring payments using a single
> offline interaction.
>
> The proposed scheme is:
>
>     master / purpose' / coin_type' / contact' / index
>
> Where the definitions of all the levels follow BIP44, except for `contact`
> that is described below.
>
> Example usage: Bob wants to make recurring payments to Carol, so he asks
> her for a _contact address_, that is, an extended public key.
>
> Bob can use that public key to generate multiple derived addresses to make
> multiple recurring payments to Carol, the contact address is stored
> off-chain, anyone inspecting the chain will just see normal transactions
> on-chain.
>
> ## Considerations
>
> [BIP47] tries to solve the same issue, but the solution is more complex
> and involves more on-chain transactions that involve data, this
> implementation simpler and requires less work to implement.
>
> Also, the derivation path might need some adjustments for different
> address types on bitcoin.
>
> Finally, this only works in a single direction and does not make it
> possible for Carol to send anything to Bob, as it would require Bob sending
> her a contact address.
>
> ## Advantages
>
> A positive side effect of using this, is that Bob can choose to send
> payments to Carol using multiple outputs, giving him more privacy.
>
> Also, those payments can be easily labeled by the receiving wallet, as
> they are received.
>
> Regards.
>
> ### References
>
> [1]:
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions-nmih0
> [BIP47]: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
> "Reusable Payment Codes for Hierarchical Deterministic Wallets"
> [BIP43]:
> https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki#Purpose
>
> --- Eloy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000009fb14305e9d89492
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Eloy,<div><br></div><div>Nice idea.<br><div><br></div><=
div>Note I thought about and succinctly described a similar scheme here (wh=
ich in turn was derived from work by Kixunil):</div><div><a href=3D"https:/=
/gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing"=
>https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-=
sharing</a></div><div><br></div><div>I agree with your general assessment t=
hat this is a scheme that seems like an improvement over the status quo. No=
te that both BIP47 and Silent Payments don&#39;t require any interaction wi=
th the sender, while this scheme requires one-time interaction (e.g. this w=
ouldn&#39;t be suitable for one-time donations). I think this would mostly =
be a convenience feature that improves the regular interactive payment flow=
 (interact once, instead of repeatedly asking for addresses with each payme=
nt).</div><div><div><br></div><div>&gt;master / purpose&#39; / coin_type&#3=
9; / contact&#39; / index</div><div><br></div><div>Despite your explanation=
, it&#39;s still not fully clear to me how &quot;contact&quot; is defined, =
but I assume it&#39;s just a counter? Just in case,=C2=A0note that you can&=
#39;t let Bob define it for Carol, as then you can&#39;t deterministically =
recover your payments without also backing up how it&#39;s defined (the see=
d alone won&#39;t be enough).</div><div><br></div><div>The gap limit also n=
eeds to be kept in mind. If we allow each xpub to have its own gap limit, y=
ou potentially get an exponential blowup (gaps in the xpub * gaps in the ad=
dresses generated from the xpubs). It may be OK to define a low default gap=
 limit for these xpubs, since there should be no reason to expect the same =
sender to leave any gaps, though this may depend on how the xpubs are used =
(e.g. it may also be used to derive addresses for others) so=C2=A0it&#39;s =
probably important to be explicit about this.</div><div><br></div><div>Chee=
rs,</div><div>Ruben</div><div><br></div><div><br></div></div></div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, =
Sep 22, 2022 at 5:18 PM El_Hoy via bitcoin-dev &lt;<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr">There is a known issue on bitcoin, that is that every transacti=
on requires a new address to prevent address reuse, making it uncomfortable=
 to make recurring payments, as every payment requires a new off-chain inte=
raction. A scheme is already mentioned on the [on the BIP32 itself][1], but=
 it cannot be implemented as is.<br><br>Here I propose a scheme that follow=
s the structure described on [BIP44] that should make it possible to send r=
ecurring payments using a single offline interaction.<br><br>The proposed s=
cheme is:<br><br>=C2=A0 =C2=A0 master / purpose&#39; / coin_type&#39; / con=
tact&#39; / index<br><br>Where the definitions of all the levels follow BIP=
44, except for `contact` that is described below.<br><br><div>Example usage=
: Bob wants to make recurring payments to Carol, so he asks her for a _cont=
act address_, that is, an extended public key.</div><div><br></div>Bob can =
use that public key to generate multiple derived addresses to make multiple=
 recurring payments to Carol, the contact address is stored off-chain, anyo=
ne inspecting the chain will just see normal transactions on-chain.<br><div=
><br></div><div>## Considerations</div><div><br></div><div>[BIP47] tries to=
 solve the same issue, but the solution is more complex and involves more o=
n-chain transactions that involve data, this implementation simpler and req=
uires less work to implement.<br></div><div><br></div><div>Also, the deriva=
tion path might need some adjustments for different address types on bitcoi=
n.<br></div><div><br></div><div>Finally, this only works in a single direct=
ion and does not make it possible for Carol to send anything to Bob, as it =
would require Bob sending her a contact address.</div><div><br></div><div>#=
# Advantages<br></div><br><div>A positive side effect of using this, is tha=
t Bob can choose to send payments to Carol using multiple outputs, giving h=
im more privacy.</div><div><br></div><div>Also, those payments can be easil=
y labeled by the receiving wallet, as they are received.</div><div><br></di=
v><div>Regards.</div><div><br></div>### References<br><div><br></div><div>[=
1]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi=
ki#recurrent-business-to-business-transactions-nmih0" target=3D"_blank">htt=
ps://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-busin=
ess-to-business-transactions-nmih0</a><br></div>[BIP47]: <a href=3D"https:/=
/github.com/bitcoin/bips/blob/master/bip-0047.mediawiki" target=3D"_blank">=
https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki</a> &quot;Re=
usable Payment Codes for Hierarchical Deterministic Wallets&quot;<br>[BIP43=
]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0043.mediawik=
i#Purpose" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bi=
p-0043.mediawiki#Purpose</a><br><br>--- Eloy</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>

--0000000000009fb14305e9d89492--