summaryrefslogtreecommitdiff
path: root/42/50d78f58674954b6dca0c600cb7c2c3ea1ef7e
diff options
context:
space:
mode:
authorPaul Sztorc <truthcoin@gmail.com>2022-06-11 10:30:13 -0400
committerbitcoindev <bitcoindev@gnusha.org>2022-06-11 14:30:30 +0000
commit6dd8765e8a49d69b82d8897eb3ba90b50dfd235e (patch)
tree969fa6a3abed851abbf1e0ffa9b322ed48e7209a /42/50d78f58674954b6dca0c600cb7c2c3ea1ef7e
parent7bdb1185499e2859939f22e3c22741cdda552d58 (diff)
downloadpi-bitcoindev-6dd8765e8a49d69b82d8897eb3ba90b50dfd235e.tar.gz
pi-bitcoindev-6dd8765e8a49d69b82d8897eb3ba90b50dfd235e.zip
Re: [bitcoin-dev] BIP47 Prague Discussion
Diffstat (limited to '42/50d78f58674954b6dca0c600cb7c2c3ea1ef7e')
-rw-r--r--42/50d78f58674954b6dca0c600cb7c2c3ea1ef7e332
1 files changed, 332 insertions, 0 deletions
diff --git a/42/50d78f58674954b6dca0c600cb7c2c3ea1ef7e b/42/50d78f58674954b6dca0c600cb7c2c3ea1ef7e
new file mode 100644
index 000000000..d9a8f1cfa
--- /dev/null
+++ b/42/50d78f58674954b6dca0c600cb7c2c3ea1ef7e
@@ -0,0 +1,332 @@
+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--
+
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-13 14:56:31 +0000