path: root/42/50d78f58674954b6dca0c600cb7c2c3ea1ef7e

Return-Path: <truthcoin@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 939BCC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jun 2022 14:30:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 7450660AE8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jun 2022 14:30:30 +0000 (UTC)
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
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 fxBRYwVxjNVX
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jun 2022 14:30:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [IPv6:2a00:1450:4864:20::12a])
 by smtp3.osuosl.org (Postfix) with ESMTPS id E657F60AA7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jun 2022 14:30:28 +0000 (UTC)
Received: by mail-lf1-x12a.google.com with SMTP id c2so2641044lfk.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jun 2022 07:30:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=B7DdUgX9XzJkLBFO+GnuFoFTgHTUYMvj8x8OiQphk1Y=;
 b=Uio1lDqHgE29fuLtGYUfsK3QZUXpgE9qwIkeoF1Cym/sulfa2Y42DYEyFWshsq54Vq
 UYZYUqys/8S+OFw5W+J7vXBIzlEOPK28I6rkBdkDLmXXS1VAPiBMe0T2jp8aW9wI/JGd
 XTTpxi6D6GOhGoIW4oGaZmjDz7KZpqkEtHGGtLJtV1gY2wFIxuA2jzrHo9jwm/XqFogu
 jVdavTa5gX9lgKoboprpL/3GsPpIo2Vr9ALJCJhMM1Qg0LxM3d95wF9dISG0Q0TCY1ix
 KRKO3OAL/HBPXs0QpkKjad3/7reeeB2sAXz9MdqvlYMVzeFCmStXB6zEEaLqli2JJ30R
 6jOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=B7DdUgX9XzJkLBFO+GnuFoFTgHTUYMvj8x8OiQphk1Y=;
 b=X8ojc7yKJsbVwYcRp3Z/O8EAeQ/I5uAxFNZpHKseVhUInipFsG9pkkxGiNg9xeJjR3
 KQDZAAweFYKyIMLrYU81RRsOaprDijc43BOqEIgNNQdztQlAxi1X2WVgZBaw7nh1zUyE
 evLE1Yt4vkkaNx9nLrB0YF1RJqOKilj+9IknG3lD2pA3fXK7uNE8BYmEUh7DodOcBBMT
 v7xMhbwMYbPXLJITR9S3RyCcUhEen//jt/SVPiAto0WYe0ppXxA6FBrW38qJcaXiixJC
 KzTcj8TaLBonkWmlZOP83C+K0s3x+IZRBlUsXkFn/OrhkY8wl/HTmh7gKf7lauzbnfrX
 aeTg==
X-Gm-Message-State: AOAM532+bPFRSOtAHgvsmY2m/yAMQzMAjwUSmLc0ARQ1rG4F5CjEGuHr
 o/7I6MAWOyOG4Dr9ZjPz11g8c9isl0AfxbC7kL415w3J
X-Google-Smtp-Source: ABdhPJx1TkxUQLJ6mxzaiTD9t/xzKPTs2uHxOECPloPFx4VuIicUvjeQcbTtN4mS2c/Cq2EyJzSY5QmYvCPb8IS9ttw=
X-Received: by 2002:a05:6512:22c4:b0:47d:aab8:8ba4 with SMTP id
 g4-20020a05651222c400b0047daab88ba4mr5946436lfu.212.1654957826733; Sat, 11
 Jun 2022 07:30:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjYXSStBWCnFcuJjVv8AAD6EGN9Vxg30XCF2UHyS5z89mw@mail.gmail.com>
In-Reply-To: <CAPv7TjYXSStBWCnFcuJjVv8AAD6EGN9Vxg30XCF2UHyS5z89mw@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Date: Sat, 11 Jun 2022 10:30:13 -0400
Message-ID: <CA+XQW1gYpv5BNBP07xP5RVRF4KD=K+tN8-3uxU3nai9x5Z5eZA@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000617d0505e12ce5e1"
Subject: Re: [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 14:30:30 -0000

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

FYI there is a version 3 of bip47 (which Ranvier published somewhere else
[0]). It already gets them down to a marginal 64 bytes, with a small
privacy drawback.

The transaction from A can be double used as both a notification to Bob and
a payment to Bob. The notification output is multisig OP [Key1] [Key2]
[Key3] , one being change for A (a sunk cost), K2 being the signal to B,
and K3 being a blinded code only B can read.

From there you can simply insert another output to Bob (to actually pay
him), insert decoy change outputs, or swap Key1 for Bobs key, making it
impossible (at least) to tell *how much* someone is paying to Bob and how
much is change for Alice.

But everyone does know that a new bidirectional relationship to Bob (from
someone) is being established, of course.

[0]
https://github.com/OpenBitcoinPrivacyProject/rfc/blob/master/obpp-05.mediaw=
iki

Paul


On Sat, Jun 11, 2022, 6:03 AM Ruben Somsen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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, =
and
> 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?perm=
alink_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 th=
is
> 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 sende=
r
> xpub based on the recipient key. If the user checks all the keys that wer=
e
> 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 alternati=
ve
> 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-ea6d307faa4ec9df=
a5abcf6858bc19603079f2b8e110e1d62da4df98f4bdb9c0R250
>
> [4] Using p2wsh:
> https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae?perm=
alink_comment_id=3D4189419#gistcomment-4189419
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto"><div>FYI there is a version 3 of bip47 (which Ranvier pub=
lished somewhere else [0]). It already gets them down to a marginal 64 byte=
s, with a small privacy drawback.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">The transaction from A can be double used as both a notification =
to Bob and a payment to Bob. The notification output is multisig OP [Key1] =
[Key2] [Key3] , one being change for A (a sunk cost), K2 being the signal t=
o B, and K3 being a blinded code only B can read.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">From there you can simply insert another output t=
o Bob (to actually pay him), insert decoy change outputs, or swap Key1 for =
Bobs key, making it impossible (at least) to tell *how much* someone is pay=
ing to Bob and how much is change for Alice.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">But everyone does know that a new bidirectional relati=
onship to Bob (from someone) is being established, of course.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">[0] <a href=3D"https://github.com/Ope=
nBitcoinPrivacyProject/rfc/blob/master/obpp-05.mediawiki">https://github.co=
m/OpenBitcoinPrivacyProject/rfc/blob/master/obpp-05.mediawiki</a></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">Paul</div><div dir=3D"auto"><br><=
br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_=
attr">On Sat, Jun 11, 2022, 6:03 AM Ruben Somsen via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxf=
oundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>This discussion took place at Pizza Day Prague 2022[0] afte=
r a brief discussion on Silent Payments[1]. The main points have been summa=
rized below.<br></div><div><br>The discussion was mainly between Alekos Fil=
ini, Martin Habov=C5=A1tiak, and myself, as well as Daniela Brozzoni, Eric =
Sirion, Pavol Rusnak, Salvatore Ingala, and others.</div><div><br></div><di=
v>Also available as a gist:<div><a href=3D"https://gist.github.com/RubenSom=
sen/21c477c90c942acf45f8e8f5c1ad4fae" target=3D"_blank" rel=3D"noreferrer">=
https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae</a></d=
iv><div><br></div><div>And my personal opinion can be found in the comments=
:</div><div><a href=3D"https://gist.github.com/RubenSomsen/21c477c90c942acf=
45f8e8f5c1ad4fae?permalink_comment_id=3D4197284#gistcomment-4197284" target=
=3D"_blank" rel=3D"noreferrer">https://gist.github.com/RubenSomsen/21c477c9=
0c942acf45f8e8f5c1ad4fae?permalink_comment_id=3D4197284#gistcomment-4197284=
</a><br></div><br><br>Improving BIP47<br><br>BIP47 requires a notification =
transaction prior to making payments. This transaction takes up on-chain sp=
ace and can easily leak privacy if not handled with extreme caution. In pra=
ctice this is quite hard.<br><br>The discussion revolved around whether we =
can a.) minimize the on-chain space required and b.) outsource the notifica=
tion 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 cur=
rently implemented, BIP47 (V1/V2)[2] requires an input key for blinding, th=
e 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 necessary =
for the recipient to learn the payment code of the sender. The benefit is t=
hat this enables the recipient to send a notification transaction and subse=
quent payment to the sender, but in practice this never happens. It therefo=
re seems acceptable to forego this requirement, as this potentially saves s=
pace. The minimum notification payload that seems required is a fresh sende=
r key and a static recipient key.<br><br>The sender key should ideally be d=
eterministically derived from the sender xpub based on the recipient key. I=
f the user checks all the keys that were registered with the recipient prio=
r to notification, it can statelessly find out whether the sender key was a=
lready previously registered. This step can be skipped, which is easier for=
 light clients, but means the notification transaction will have to be rese=
nt if the user ever forgets they already sent a notification (such as when =
restoring from backup).<br><br><br>Outsourcing the notification</div><div><=
br>The next part of the discussion revolved around the idea of putting mult=
iple notifications in a single transaction that can be outsourced to a thir=
d party in order to break the sender/recipient link. This third party could=
 be paid over the Lightning Network for their services.<br><br>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&#39;s not t=
ied 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=
.<br><br><br>Allowing collisions</div><div><br>One interesting point that c=
ame up was that you could represent the recipient key using e.g. only 4 byt=
es (provided you put it in the annex). This leaves a window of 1 in ~4.3 bi=
llion for a collision, but the extra work that needs to be performed when i=
t 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.<br><br>While this did not come up in the discussion, it should be not=
ed that using the annex makes the transaction non-standard[3]. It could eit=
her be standardized as the first use case for the annex, or perhaps an alte=
rnative 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" tar=
get=3D"_blank" rel=3D"noreferrer">https://www.pizzaday.cz</a></div><div><br=
></div><div>[1] Silent Payments: <a href=3D"https://gist.github.com/RubenSo=
msen/c43b79517e7cb701ebf77eec6dbb46b8" target=3D"_blank" rel=3D"noreferrer"=
>https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8</a></=
div><div><br></div><div>[2] BIP47:=C2=A0<a href=3D"https://github.com/bitco=
in/bips/blob/master/bip-0047.mediawiki" target=3D"_blank" rel=3D"noreferrer=
">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.c=
om/bitcoin/bitcoin/pull/17977/files#diff-ea6d307faa4ec9dfa5abcf6858bc196030=
79f2b8e110e1d62da4df98f4bdb9c0R250" target=3D"_blank" rel=3D"noreferrer">ht=
tps://github.com/bitcoin/bitcoin/pull/17977/files#diff-ea6d307faa4ec9dfa5ab=
cf6858bc19603079f2b8e110e1d62da4df98f4bdb9c0R250</a></div><div><br></div><d=
iv>[4] Using p2wsh:=C2=A0<a href=3D"https://gist.github.com/RubenSomsen/21c=
477c90c942acf45f8e8f5c1ad4fae?permalink_comment_id=3D4189419#gistcomment-41=
89419" target=3D"_blank" rel=3D"noreferrer">https://gist.github.com/RubenSo=
msen/21c477c90c942acf45f8e8f5c1ad4fae?permalink_comment_id=3D4189419#gistco=
mment-4189419</a></div><div><br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--000000000000617d0505e12ce5e1--