path: root/f5/03337beeeb56d7c767175a0f5a7baa531a83f8

Return-Path: <rsomsen@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7DC1AC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jun 2022 10:02:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 6B499403B3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jun 2022 10:02:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level: 
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, 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
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id IQMhghhNyXwc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jun 2022 10:02:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com
 [IPv6:2607:f8b0:4864:20::b2d])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 356794011D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jun 2022 10:02:15 +0000 (UTC)
Received: by mail-yb1-xb2d.google.com with SMTP id t32so2389069ybt.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jun 2022 03:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=Ldd9vsns0OJNard8y0w0u9vuEkDlG9ZOAuGuB2jy1/E=;
 b=Z27Tmo3KAYVHr0EwwVcmLBnYGM65s/IrjtpqdSe2w2J6z5gUp/PZdDwCExd059qqSB
 zDfRYHFr3XG2JiP7PuITizClwn8TjI8YVPze5dKvolnzsal8KWM3sPucwrxMFDvpR+R6
 euVSj5THP2cro6QNlaFEYWaIlwPbU6Yxuuwiv7GIpBcUNuIgpbBxOHCQ9xCxV9FOFvkt
 b3V2Qrlr/eediO7UZOrFhBCI8X/TnYtZGVGe85tRgyOAEh2h83vGXArAu+Sf48biK1UZ
 uZ9IpqcJWdCWbFbP2+JKnLSo6Etv3pa++VuheGM3ggtACLvRgr+XjGjhROqenln4G5go
 b2VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=Ldd9vsns0OJNard8y0w0u9vuEkDlG9ZOAuGuB2jy1/E=;
 b=QJAFGIFZe93ONd+9ackxKQ+cERb0R/p3+uDgrmv4Pwpr39t9/Xdt0NtHPVU2u+eGcI
 uOtf88ffLBM4Prko30OD2/RSHII7P/f4UM7aKJ3iypsBZoiQ4kbTyFmxO5dwgl+VupO3
 uUjolGnUXt9EFtdZoWvQKe/9CyqIRUWUFCnQCnIzgqWElq8Af0zKKFHeN2Rf2Po5ZwTI
 kUVPrCHNRpJYyhxQVwsnjlQY9ut4xj275X+hreA2LD7pxckkYXLRfgPR3Ng87GyzINay
 ZpC7ZdZFfC/r9gyMMvPHRclMI6un58B8rxRnqMcMv02StpXT2CYttqlGVwr/Aj0thAyc
 keRw==
X-Gm-Message-State: AOAM531j0mPxGU3my2DuT+Fs22s/u8y9xfttLvukLnWu1iT8UWVRc3In
 R/MCXZxJv4iV3v1T1/IBXfHjN1Hhtm9ZRhywfVFGAscyZxQ=
X-Google-Smtp-Source: ABdhPJzxSyneISnnmHvYyfy/CO9e6sSAirHdWL+BTcgDMxOBaDt7TbhXK6lZKpWX2pfVXBIMUNvqUkuPP00AEIu//ao=
X-Received: by 2002:a05:6902:52e:b0:663:df20:2b4 with SMTP id
 y14-20020a056902052e00b00663df2002b4mr21797598ybs.374.1654941733785; Sat, 11
 Jun 2022 03:02:13 -0700 (PDT)
MIME-Version: 1.0
From: Ruben Somsen <rsomsen@gmail.com>
Date: Sat, 11 Jun 2022 12:01:58 +0200
Message-ID: <CAPv7TjYXSStBWCnFcuJjVv8AAD6EGN9Vxg30XCF2UHyS5z89mw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002a942505e129268a"
X-Mailman-Approved-At: Sat, 11 Jun 2022 10:02:56 +0000
Subject: [bitcoin-dev] BIP47 Prague Discussion
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, 11 Jun 2022 10:02:16 -0000

--0000000000002a942505e129268a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This discussion took place at Pizza Day Prague 2022[0] after a brief
discussion on Silent Payments[1]. The main points have been summarized
below.

The discussion was mainly between Alekos Filini, Martin Habov=C5=A1tiak, an=
d
myself, as well as Daniela Brozzoni, Eric Sirion, Pavol Rusnak, Salvatore
Ingala, and others.

Also available as a gist:
https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae

And my personal opinion can be found in the comments:
https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae?permal=
ink_comment_id=3D4197284#gistcomment-4197284


Improving BIP47

BIP47 requires a notification transaction prior to making payments. This
transaction takes up on-chain space and can easily leak privacy if not
handled with extreme caution. In practice this is quite hard.

The discussion revolved around whether we can a.) minimize the on-chain
space required and b.) outsource the notification transaction so the link
between the sender and recipient is no longer apparent on-chain.


BIP47 space requirements

As currently implemented, BIP47 (V1/V2)[2] requires an input key for
blinding, the blinded sender payment code in an op_return, and the
recipient key in an output.

The first question that came up was whether it is necessary for the
recipient to learn the payment code of the sender. The benefit is that this
enables the recipient to send a notification transaction and subsequent
payment to the sender, but in practice this never happens. It therefore
seems acceptable to forego this requirement, as this potentially saves
space. The minimum notification payload that seems required is a fresh
sender key and a static recipient key.

The sender key should ideally be deterministically derived from the sender
xpub based on the recipient key. If the user checks all the keys that were
registered with the recipient prior to notification, it can statelessly
find out whether the sender key was already previously registered. This
step can be skipped, which is easier for light clients, but means the
notification transaction will have to be resent if the user ever forgets
they already sent a notification (such as when restoring from backup).


Outsourcing the notification

The next part of the discussion revolved around the idea of putting
multiple notifications in a single transaction that can be outsourced to a
third party in order to break the sender/recipient link. This third party
could be paid over the Lightning Network for their services.

One idea was to use the taproot annex to insert the notification payload as
(discounted) witness data. One downside with this approach is that it
requires custom software for the recipient to notice the notification,
since it's not tied to an easily noticeable output. The middle ground
solution would be to put the sender keys there but still create an output
for each recipient key.


Allowing collisions

One interesting point that came up was that you could represent the
recipient key using e.g. only 4 bytes (provided you put it in the annex).
This leaves a window of 1 in ~4.3 billion for a collision, but the extra
work that needs to be performed when it does happen is negligible
(essentially expecting a payment while there is none). This would reduce
the payload from 64 bytes to 36 bytes of witness data.

While this did not come up in the discussion, it should be noted that using
the annex makes the transaction non-standard[3]. It could either be
standardized as the first use case for the annex, or perhaps an alternative
method[4] should be considered.


[0] Pizza Day Prague 2022: https://www.pizzaday.cz

[1] Silent Payments:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8

[2] BIP47: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki

[3] Annex non-standard:
https://github.com/bitcoin/bitcoin/pull/17977/files#diff-ea6d307faa4ec9dfa5=
abcf6858bc19603079f2b8e110e1d62da4df98f4bdb9c0R250

[4] Using p2wsh:
https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae?permal=
ink_comment_id=3D4189419#gistcomment-4189419

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

<div dir=3D"ltr"><div>This discussion took place at Pizza Day Prague 2022[0=
] after a brief discussion on Silent Payments[1]. The main points have been=
 summarized below.<br></div><div><br>The discussion was mainly between Alek=
os Filini, Martin Habov=C5=A1tiak, and myself, as well as Daniela Brozzoni,=
 Eric Sirion, Pavol Rusnak, Salvatore Ingala, and others.</div><div><br></d=
iv><div>Also available as a gist:<div><a href=3D"https://gist.github.com/Ru=
benSomsen/21c477c90c942acf45f8e8f5c1ad4fae">https://gist.github.com/RubenSo=
msen/21c477c90c942acf45f8e8f5c1ad4fae</a></div><div><br></div><div>And my p=
ersonal opinion can be found in the comments:</div><div><a href=3D"https://=
gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae?permalink_comm=
ent_id=3D4197284#gistcomment-4197284">https://gist.github.com/RubenSomsen/2=
1c477c90c942acf45f8e8f5c1ad4fae?permalink_comment_id=3D4197284#gistcomment-=
4197284</a><br></div><br><br>Improving BIP47<br><br>BIP47 requires a notifi=
cation transaction prior to making payments. This transaction takes up on-c=
hain space and can easily leak privacy if not handled with extreme caution.=
 In practice this is quite hard.<br><br>The discussion revolved around whet=
her we can a.) minimize the on-chain space required and b.) outsource the n=
otification transaction so the link between the sender and recipient is no =
longer apparent on-chain.<br><br><br>BIP47 space requirements</div><div><br=
>As currently implemented, BIP47 (V1/V2)[2] requires an input key for blind=
ing, the blinded sender payment code in an op_return, and the recipient key=
 in an output.<br><br>The first question that came up was whether it is nec=
essary for the recipient to learn the payment code of the sender. The benef=
it is that this enables the recipient to send a notification transaction an=
d subsequent payment to the sender, but in practice this never happens. It =
therefore seems acceptable to forego this requirement, as this potentially =
saves space. The minimum notification payload that seems required is a fres=
h sender key and a static recipient key.<br><br>The sender key should ideal=
ly be deterministically derived from the sender xpub based on the recipient=
 key. If the user checks all the keys that were registered with the recipie=
nt prior to notification, it can statelessly find out whether the sender ke=
y was already previously registered. This step can be skipped, which is eas=
ier for light clients, but means the notification transaction will have to =
be resent if the user ever forgets they already sent a notification (such a=
s when restoring from backup).<br><br><br>Outsourcing the notification</div=
><div><br>The next part of the discussion revolved around the idea of putti=
ng multiple notifications in a single transaction that can be outsourced to=
 a third party in order to break the sender/recipient link. This third part=
y could be paid over the Lightning Network for their services.<br><br>One i=
dea was to use the taproot annex to insert the notification payload as (dis=
counted) witness data. One downside with this approach is that it requires =
custom software for the recipient to notice the notification, since it&#39;=
s not tied to an easily noticeable output. The middle ground solution would=
 be to put the sender keys there but still create an output for each recipi=
ent key.<br><br><br>Allowing collisions</div><div><br>One interesting point=
 that came up was that you could represent the recipient key using e.g. onl=
y 4 bytes (provided you put it in the annex). This leaves a window of 1 in =
~4.3 billion for a collision, but the extra work that needs to be performed=
 when it does happen is negligible (essentially expecting a payment while t=
here is none). This would reduce the payload from 64 bytes to 36 bytes of w=
itness data.<br><br>While this did not come up in the discussion, it should=
 be noted that using the annex makes the transaction non-standard[3]. It co=
uld either be standardized as the first use case for the annex, or perhaps =
an alternative method[4] should be considered.<br></div><div><br></div><div=
><br></div><div>[0] Pizza Day Prague 2022: <a href=3D"https://www.pizzaday.=
cz">https://www.pizzaday.cz</a></div><div><br></div><div>[1] Silent Payment=
s: <a href=3D"https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6=
dbb46b8">https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46=
b8</a></div><div><br></div><div>[2] BIP47:=C2=A0<a href=3D"https://github.c=
om/bitcoin/bips/blob/master/bip-0047.mediawiki">https://github.com/bitcoin/=
bips/blob/master/bip-0047.mediawiki</a></div><div><br></div><div>[3] Annex =
non-standard:=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/17977=
/files#diff-ea6d307faa4ec9dfa5abcf6858bc19603079f2b8e110e1d62da4df98f4bdb9c=
0R250">https://github.com/bitcoin/bitcoin/pull/17977/files#diff-ea6d307faa4=
ec9dfa5abcf6858bc19603079f2b8e110e1d62da4df98f4bdb9c0R250</a></div><div><br=
></div><div>[4] Using p2wsh:=C2=A0<a href=3D"https://gist.github.com/RubenS=
omsen/21c477c90c942acf45f8e8f5c1ad4fae?permalink_comment_id=3D4189419#gistc=
omment-4189419">https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f=
5c1ad4fae?permalink_comment_id=3D4189419#gistcomment-4189419</a></div><div>=
<br></div></div>

--0000000000002a942505e129268a--