path: root/a5/23ef21ef963b5ed9e86f0857eee2d372255a7b

Return-Path: <rsomsen@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 722FFC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 23:03:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 39583611C4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 23:03:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 39583611C4
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=pR1tiNTh
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, TRACKER_ID=0.1] 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 H3u_OhKM0Yt3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 23:03:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E486160BA6
Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com
 [IPv6:2001:4860:4864:20::2f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id E486160BA6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 23:03:46 +0000 (UTC)
Received: by mail-oa1-x2f.google.com with SMTP id
 586e51a60fabf-131886d366cso3549429fac.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 16:03:46 -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=lMyIagdcnJqBVw9tXvOxK+3Q7JNSaPY10uJxZ9Ncb3w=;
 b=pR1tiNThvpI/BpnSEqojOU5+Zeh3QSFNc4uUovDeQG2ysPJtEP9GGw7z8rzbEVYL3y
 wqFDYrIg2cOkN7wWSZ4tT64wjSNuCqVnRgVtr6Viu1NWIl1uVEzrBKHUqQE0q6KBCRnp
 MHy4Y4r7puXKJWZ1VRPTv8f7S/NN8VUIlrufIXGDAJiQ9p80UNNZ5zB+tDiLNN5c2ioK
 l9TjG6pjcphM/+m5C4dY5MAFbwQbGGshx1H8Oznm05Nf4Yyhc6WMuGf2MFbp2/cZCUuA
 CYNPgc1e8WpI2HmaadRe9bPuqQ3E8LXOv1GfjTsznhQ3esLX9tRRvS/Fzm8TnV7TC34i
 2m5w==
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=lMyIagdcnJqBVw9tXvOxK+3Q7JNSaPY10uJxZ9Ncb3w=;
 b=ZIda9YDXn3DZbRTV7Jbm6tTiYLsTVNPoG0r7pek+2NxhEhUdF3RMh3BMAzYntpqwcR
 EHL2Pdc2ycaumobm0+lHMRmE0ToFik89PnxoPWP5C4PnPaEhykAOSELU51ebVOkhz9B3
 1Q6S7t5RCOpLWnxapzHQA9P+bjZKKFJmgTbRlzHY1MQNdnbjmbmNFNNyA/HvJ5wRETIN
 1vtVYckiDogeMLerQPKIInxW62y4j1SWKe0jIY62JZD9XXHx/Fml38LUvG49n8lDcvpr
 LAIpahMQGqbIj5e5K/jNUDoV+BDLXcHe6WxMjP0qUyxAWYNAn17sTzjic06nxJJNpT9Z
 J4zw==
X-Gm-Message-State: ACrzQf3HGOW9l6orXPPv2Qu+BQ+Yx0Io8mOfp/LtxuZ+j/MIRbgwy3l6
 C3wgapMF7jllq/PpuJLyQ3Sh/z00lxLvvcXjTIc=
X-Google-Smtp-Source: AMsMyM6cDo8ONti5HXkSuREN2QRNYiOQeTL6Mk8PlmkGVBIy0t83OKrTNhNa97nPjdKu+8AGTOIrftl3Z90nS5csEXU=
X-Received: by 2002:a05:6870:c0c9:b0:127:c4df:5b50 with SMTP id
 e9-20020a056870c0c900b00127c4df5b50mr3258418oad.126.1664492625760; Thu, 29
 Sep 2022 16:03:45 -0700 (PDT)
MIME-Version: 1.0
References: <BkzIoBmDaBRo-URg9JqL1fZOyN-iu32rvsv7VNfEKsnX3HuBjXEPcREYIUftcQ6TvOHY1pcjKGd8ekUYfEObGqdDNGuJYhxOqYb9_s_c80w=@protonmail.com>
In-Reply-To: <BkzIoBmDaBRo-URg9JqL1fZOyN-iu32rvsv7VNfEKsnX3HuBjXEPcREYIUftcQ6TvOHY1pcjKGd8ekUYfEObGqdDNGuJYhxOqYb9_s_c80w=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Fri, 30 Sep 2022 01:03:36 +0200
Message-ID: <CAPv7TjZOJSFeRjpJjY5Lkjpr4LRexsCuhi8t_1nkL9ys+qoYhA@mail.gmail.com>
To: woltx <woltx@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b096b105e9d8e313"
X-Mailman-Approved-At: Thu, 29 Sep 2022 23:10:59 +0000
Subject: Re: [bitcoin-dev] Third version of Silent Payment implementation
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 23:03:49 -0000

--000000000000b096b105e9d8e313
Content-Type: text/plain; charset="UTF-8"

Hi woltx,

Excellent work.

>Implements the new scheme suggested by Ruben Somsen that allows multiple
silent addresses per wallet with minimal overhead

To expand on this, the scheme basically allows the resulting address to be
recognizably marked (only recognizable by the recipient of course), which
enables you to distinguish between different payment purposes (e.g. some
people donate to you for purpose A, others for purpose B). Here's my
original comment describing it:

"Naively, the issue is that two keys means twice the scanning, but an
interesting alternative would be to simply use the same key (assuming
you're OK with using the same identity) but add a public identifier f to it
when tweaking. So instead of hash(i*X)*G + X you get hash(i*X)*G + X + f*G
. This means every additional "address" only costs one additional ECC
addition when scanning (relatively cheap compared to doing ECC
multiplications).

The main downside with this is that f becomes crucial for recovering from
backup. If we set f as an index (0, 1, 2, 3...) then you'd only have to
remember how many "addresses" you issued (and perhaps overshoot when
unsure) to ensure recovery of funds, though of course you'd rather also
remember which index is associated with what payment reason.

Absolute worst case scenario you could even do something similar to the gap
limit where you scan the full history (not just the UTXO set so you don't
miss spent outputs) with a default max index of e.g. 100, and then if you
find out most of them are in use, you scan the next 100, etc. Costly, but
thorough, and only needed as a last resort."

Original comment here:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing

Also good to note that f needs to be communicated to the sender somehow,
perhaps as part of the address format.

Cheers,
Ruben

On Fri, Sep 30, 2022 at 12:35 AM woltx via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> This new version addresses most (or all) requests made in PR:
>
> . Implements the new scheme suggested by Ruben Somsen that allows multiple
> silent addresses per wallet with minimal overhead.
> . Implements a new RPC to retrieve silent addresses, which allows users to
> assign different labels to different addresses. That way, the user knows
> which silent address the UTXO came from.
>
> Example:
>
> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
> tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
>
> # This will return the same address as above (both have no label)
> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
> tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
>
> # New label, new address
> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress 'donation'
> tsp011pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kq80t7lt
>
> In this new scheme, the address has a new field called identifier, which
> tells the receiver and sender how to set the address correctly.
>
> If the receiver, for whatever reason, doesn't know which identifiers have
> been used, there is no problem. The wallet can scan all identifiers from 0
> to 99. Currently, only 100 different identifiers per wallet are allowed.
> This limit, however, can be increased at any time in the future.
>
> Unlike address formats so far, sp addresses are not script-related and may
> eventually include any additional information needed, such as an expiration
> timestamp (or block height). That way, users don't have to track the
> address indefinitely.
>
> As usual I wrote a step by step tutorial:
> https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Hi=C2=A0woltx,</div><div><br></div><div>Excellent wor=
k.</div><div><br></div><div>&gt;<span style=3D"font-family:Arial;font-size:=
14px">Implements the new scheme suggested by Ruben Somsen that allows multi=
ple silent addresses per wallet with minimal overhead</span><br></div><div>=
<span style=3D"font-family:Arial;font-size:14px"><br></span></div><div><fon=
t face=3D"Arial"><span style=3D"font-size:14px">To expand on this, the sche=
me basically allows the resulting address to be recognizably marked (only r=
ecognizable by the recipient of course), which enables you to distinguish b=
etween different payment purposes (e.g. some people donate to you for purpo=
se=C2=A0A, others for purpose B). Here&#39;s my original comment describing=
=C2=A0</span></font>it:<font face=3D"Arial"><span style=3D"font-size:14px">=
<br></span></font></div><br>&quot;Naively, the issue is that two keys means=
 twice the scanning, but an interesting alternative would be to simply use =
the same key (assuming you&#39;re OK with using the same identity) but add =
a public identifier f to it when tweaking. So instead of hash(i*X)*G + X yo=
u get hash(i*X)*G + X + f*G . This means every additional &quot;address&quo=
t; only costs one additional ECC addition when scanning (relatively cheap c=
ompared to doing ECC multiplications).<br><br>The main downside with this i=
s that f becomes crucial for recovering from backup. If we set f as an inde=
x (0, 1, 2, 3...) then you&#39;d only have to remember how many &quot;addre=
sses&quot; you issued (and perhaps overshoot when unsure) to ensure recover=
y of funds, though of course you&#39;d rather also remember which index is =
associated with what payment reason.<br><br>Absolute worst case scenario yo=
u could even do something similar to the gap limit where you scan the full =
history (not just the UTXO set so you don&#39;t miss spent outputs) with a =
default max index of e.g. 100, and then if you find out most of them are in=
 use, you scan the next 100, etc. Costly, but thorough, and only needed as =
a last resort.&quot;<br><br>Original comment here:<br><a href=3D"https://gi=
st.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing">ht=
tps://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sha=
ring</a><br><br>Also good to note that f needs to be communicated to the se=
nder somehow, perhaps as part of the address format.<br><br>Cheers,<br>Rube=
n</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Fri, Sep 30, 2022 at 12:35 AM woltx via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div style=3D"font-family:Arial;font-size:14px"><br></div><div style=3D=
"font-family:Arial;font-size:14px"><span>This new version addresses most (o=
r all) requests made in PR:</span><div><br></div><div><span>. Implements th=
e new scheme suggested by Ruben Somsen that allows multiple silent addresse=
s per wallet with minimal overhead.</span></div><div><span>. Implements a n=
ew RPC to retrieve silent addresses, which allows users to assign different=
 labels to different addresses. That way, the user knows which silent addre=
ss the UTXO came from.</span></div><div><br></div><div><span>Example:</span=
></div><div><br></div><div><span>./src/bitcoin-cli -signet -rpcwallet=3D&qu=
ot;receiver&quot; getspaddress</span></div><div><span>tsp001pjgcwd9p6f2rcgf=
35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq</span></div><div><br></div><di=
v><span># This will return the same address as above (both have no label)</=
span></div><div><span>./src/bitcoin-cli -signet -rpcwallet=3D&quot;receiver=
&quot; getspaddress</span></div><div><span>tsp001pjgcwd9p6f2rcgf35dlgvj77h2=
afylg6lp5cdn0cztrk4k54w99kqxn48tq</span></div><div><br></div><div><span># N=
ew label, new address</span></div><div><span>./src/bitcoin-cli -signet -rpc=
wallet=3D&quot;receiver&quot; getspaddress &#39;donation&#39;</span></div><=
div><span>tsp011pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kq80t7lt=
 </span></div><div><br></div><div><span>In this new scheme, the address has=
 a new field called identifier, which tells the receiver and sender how to =
set the address correctly.</span></div><div><br></div><div><span>If the rec=
eiver, for whatever reason, doesn&#39;t know which identifiers have been us=
ed, there is no problem. The wallet can scan all identifiers from 0 to 99. =
Currently, only 100 different identifiers per wallet are allowed. This limi=
t, however, can be increased at any time in the future.</span></div><div><b=
r></div><div><span>Unlike address formats so far, sp addresses are not scri=
pt-related and may eventually include any additional information needed, su=
ch as an expiration timestamp (or block height). That way, users don&#39;t =
have to track the address indefinitely.</span></div><div><br></div><div><sp=
an>As usual I wrote a step by step tutorial:</span></div><div><span><a rel=
=3D"noreferrer nofollow noopener" href=3D"https://gist.github.com/w0xlt/c81=
277ae8677b6c0d3dd073893210875" target=3D"_blank">https://gist.github.com/w0=
xlt/c81277ae8677b6c0d3dd073893210875</a></span></div><span></span><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>

--000000000000b096b105e9d8e313--