path: root/52/325aedff5443bec82bb1590767b10fcb0b6101

Return-Path: <eloyesp@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 30FC2C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Oct 2022 19:08:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 10C696072A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Oct 2022 19:08:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 10C696072A
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=MLZIAKmE
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id vfUi2NGRyNxZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Oct 2022 19:08:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4882C605DB
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com
 [IPv6:2607:f8b0:4864:20::f2f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 4882C605DB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Oct 2022 19:08:47 +0000 (UTC)
Received: by mail-qv1-xf2f.google.com with SMTP id g9so5464299qvo.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 04 Oct 2022 12:08:47 -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:message-id:reply-to;
 bh=mKBRxViCXk6R5lc+Bj4VV3InY0DJG9hEU+rxYzodY98=;
 b=MLZIAKmEESHT2mK6MO46xQwURLOmzvwR3von0CBV/S2bQyLwy+Q3fyyONVfis8EqKv
 XtP8NC6fpDb6nsAsF7TiyBgPNQENsVisb0mmmpu45bvVTnjLwoADE1rC4TMwQ1bYc8YF
 gc3VkAI/Ki0xG+v5IoP+V6rWKy4wI1LC9mjNTQ5buNAxSy2oUpZCG8zL8bs7f9WREK3L
 +mD6LCBOeGVvkgj+Nu9wgJcv3+u8viJmgctNLZR9DK5Kp+8IwALTgbs4+7OIjyE+ViNr
 PZ7LeEskkSvmSrIxrKH2bIPvi/draZYBJxvGq4seEtxYHOVioCe76Hhp7k7A52YFw9hN
 8+Dw==
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:message-id
 :reply-to;
 bh=mKBRxViCXk6R5lc+Bj4VV3InY0DJG9hEU+rxYzodY98=;
 b=6nEo8KbMS2IWQmV6pjJL59ZelD/peJ3v6XhfbETYIEHAe2QSbSE1+ab86AJB04X6XC
 foeRwSRfAFcubGncmoi5rBZAjlfbGrUCtwhddmEXP/LHJU/MbxECH7t+I09N85wtodcw
 RX9p5G9pFy+LGw8gdjmODtbmaPEP9ldcrvq8LQT0A5TWXW2ZHRvvbhbfVtNJGhHE8RU7
 UWoXzBQZH4qnvbWbYUo3nTnWW079161Mpz5VIUzmOY+nGzvIJwCCjCW5qx7ApMRgzGmk
 gKF6ZKd3en0F3As1ni9v5d4jRF1ehYOXFWOafK8mnsYCw4jyrjkefmJ42C7yKbV+GkZU
 MrhA==
X-Gm-Message-State: ACrzQf1npbxyZNa26GZz/ooHovY/2YUWi8uxygPhxshs6Zt2ISUT8HxI
 Im5CzC99rNFFgDpJ2qjdVlBwxG0kRcW6zadNqrhZUDmE
X-Google-Smtp-Source: AMsMyM7Sm20caWM8vKTjax0meRra4dkpsw0DGi0DWT9HuEOCRbt/4yWdEklLJX4Usa3POtFmLfNRjZEfBcHWFfj6LW8=
X-Received: by 2002:a05:6214:1c05:b0:4b1:7ff8:4c11 with SMTP id
 u5-20020a0562141c0500b004b17ff84c11mr11565577qvc.108.1664910526089; Tue, 04
 Oct 2022 12:08:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAPapNH28iCxEcTOKt3YC+zuZzxbM=AudbbYByjS3aUZAgFHUag@mail.gmail.com>
 <CAPv7TjZFN1r84EXON_gpNmJm2=x0x6-=5SqdCP5_n2EaObUEtA@mail.gmail.com>
In-Reply-To: <CAPv7TjZFN1r84EXON_gpNmJm2=x0x6-=5SqdCP5_n2EaObUEtA@mail.gmail.com>
From: El_Hoy <eloyesp@gmail.com>
Date: Tue, 4 Oct 2022 16:08:34 -0300
Message-ID: <CAPapNH1US_OPtzgT8dwVh2ieborNg6OxPDz7LoFQkkwB-3Rcyg@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007d8f5a05ea3a30df"
X-Mailman-Approved-At: Tue, 04 Oct 2022 19:17:46 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Tue, 04 Oct 2022 19:08:49 -0000

--0000000000007d8f5a05ea3a30df
Content-Type: text/plain; charset="UTF-8"

Hi Ruben,

Thanks for your comments.

I've noticed that there are lots of mentions of using a scheme like this,
but there is no framework to ease the usage of such a scheme and to add
interoperability between different implementations. So any implementation
requires some manual work on both parties. The idea is to have a BIP to
make this easy for developers to implement and users to use.

The main advantage against silent payments or BIP47 is just that it should
be easier to implement on both parties involved.

Regarding the `contact`, you are right, it is just a counter, and Carol
simply increments this one with each `contact` created. The association
between a `contact` and the metadata of the contact needs to be stored
off-chain, so when recovering the wallet that information is lost if there
is no backup.

Regarding the gap limit, I think that we can be quite strict with it, to
make it easier to implement, I would use a gap limit of 2 for contacts and
no gap limit for the index, there is no point in someone skipping an
address.

Regards.

---  Eloy


On Thu, Sep 29, 2022 at 7:41 PM Ruben Somsen <rsomsen@gmail.com> wrote:

> 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
>>
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi Ruben,</div><div><br></div><div>T=
hanks for your comments.</div><div><br></div><div><div>I&#39;ve noticed tha=
t there are lots of mentions of using a scheme like this, but there is no f=
ramework to ease the usage of such a scheme and to add interoperability bet=
ween different implementations. So any implementation requires some manual =
work on both parties. The idea is to have a BIP to make this easy for devel=
opers to implement and users to use.</div><div><br></div><div>The main adva=
ntage against silent payments or BIP47 is just that it should be easier to =
implement on both parties involved.</div><div><br></div><div>Regarding the =
`contact`, you are right, it is just a counter, and Carol simply increments=
 this one with each `contact` created. The association between a `contact` =
and the metadata of the contact needs to be stored off-chain, so when recov=
ering the wallet that information is lost if there is no backup.</div><div>=
<br></div><div>Regarding the gap limit, I think that we can be quite strict=
 with it, to make it easier to implement, I would use a gap limit of 2 for =
contacts and no gap limit for the index, there is no point in someone skipp=
ing an address.</div></div><div><br></div><div>Regards.</div><div><br></div=
><div><div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=
=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"color:rgb(56,118,29)">=
<span style=3D"font-family:arial,helvetica,sans-serif">---=C2=A0 Eloy</span=
></span><br></div></div></div><br></div></div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 29, 2022 at 7:41 =
PM Ruben Somsen &lt;<a href=3D"mailto:rsomsen@gmail.com">rsomsen@gmail.com<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr">Hi Eloy,<div><br></div><div>Nice idea.<br><div><br></div><d=
iv>Note I thought about and succinctly described a similar scheme here (whi=
ch in turn was derived from work by Kixunil):</div><div><a href=3D"https://=
gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing" =
target=3D"_blank">https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77=
eec6dbb46b8#xpub-sharing</a></div><div><br></div><div>I agree with your gen=
eral assessment that this is a scheme that seems like an improvement over t=
he status quo. Note that both BIP47 and Silent Payments don&#39;t require a=
ny interaction with the sender, while this scheme requires one-time interac=
tion (e.g. this wouldn&#39;t be suitable for one-time donations). I think t=
his would mostly be a convenience feature that improves the regular interac=
tive payment flow (interact once, instead of repeatedly asking for addresse=
s with each payment).</div><div><div><br></div><div>&gt;master / purpose&#3=
9; / coin_type&#39; / contact&#39; / index</div><div><br></div><div>Despite=
 your explanation, it&#39;s still not fully clear to me how &quot;contact&q=
uot; is defined, but I assume it&#39;s just a counter? Just in case,=C2=A0n=
ote that you can&#39;t let Bob define it for Carol, as then you can&#39;t d=
eterministically recover your payments without also backing up how it&#39;s=
 defined (the seed alone won&#39;t be enough).</div><div><br></div><div>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 th=
e 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><b=
r></div><div>Cheers,</div><div>Ruben</div><div><br></div><div><br></div></d=
iv></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Thu, Sep 22, 2022 at 5:18 PM El_Hoy via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr">There is a known issue on bi=
tcoin, that is that every transaction requires a new address to prevent add=
ress reuse, making it uncomfortable to make recurring payments, as every pa=
yment requires a new off-chain interaction. A scheme is already mentioned o=
n the [on the BIP32 itself][1], but it cannot be implemented as is.<br><br>=
Here I propose a scheme that follows the structure described on [BIP44] tha=
t should make it possible to send recurring payments using a single offline=
 interaction.<br><br>The proposed scheme is:<br><br>=C2=A0 =C2=A0 master / =
purpose&#39; / coin_type&#39; / contact&#39; / index<br><br>Where the defin=
itions of all the levels follow BIP44, except for `contact` that is describ=
ed below.<br><br><div>Example usage: Bob wants to make recurring payments t=
o Carol, so he asks her for a _contact address_, that is, an extended publi=
c key.</div><div><br></div>Bob can use that public key to generate multiple=
 derived addresses to make multiple recurring payments to Carol, the contac=
t address is stored off-chain, anyone inspecting the chain will just see no=
rmal 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 on-chain transactions that involve data, =
this implementation simpler and requires less work to implement.<br></div><=
div><br></div><div>Also, the derivation path might need some adjustments fo=
r different address types on bitcoin.<br></div><div><br></div><div>Finally,=
 this only works in a single direction and does not make it possible for Ca=
rol 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 positiv=
e side effect of using this, is that Bob can choose to send payments to Car=
ol using multiple outputs, giving him more privacy.</div><div><br></div><di=
v>Also, those payments can be easily labeled by the receiving wallet, as th=
ey are received.</div><div><br></div><div>Regards.</div><div><br></div>### =
References<br><div><br></div><div>[1]: <a href=3D"https://github.com/bitcoi=
n/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transa=
ctions-nmih0" target=3D"_blank">https://github.com/bitcoin/bips/blob/master=
/bip-0032.mediawiki#recurrent-business-to-business-transactions-nmih0</a><b=
r></div>[BIP47]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip=
-0047.mediawiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/mas=
ter/bip-0047.mediawiki</a> &quot;Reusable Payment Codes for Hierarchical De=
terministic Wallets&quot;<br>[BIP43]: <a href=3D"https://github.com/bitcoin=
/bips/blob/master/bip-0043.mediawiki#Purpose" target=3D"_blank">https://git=
hub.com/bitcoin/bips/blob/master/bip-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>
</blockquote></div></div>

--0000000000007d8f5a05ea3a30df--