From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A5D41C002D for ; Thu, 29 Sep 2022 15:39:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 6D46461196 for ; Thu, 29 Sep 2022 15:39:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6D46461196 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=S9GF6tqH 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 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 o8gSHE2w3szr for ; Thu, 29 Sep 2022 15:39:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DBCCD6118D Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) by smtp3.osuosl.org (Postfix) with ESMTPS id DBCCD6118D for ; Thu, 29 Sep 2022 15:39:29 +0000 (UTC) Received: by mail-oo1-xc2c.google.com with SMTP id t4-20020a4aa3c4000000b00475624f2369so357895ool.3 for ; Thu, 29 Sep 2022 08:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=U/cSf4gVc7RWz3455CFWeoW09C+QBS6EY7ywT20NN0M=; b=S9GF6tqHnhS1GDt+xIdJl48Criu55W/GdyBggr67xHpLaaf8AxDJFvw/HL5LxZ3Hbu JHt3IY64fSPaI+Ia1LbpmwOHy/EprYja0pvSWf0EAOEQuio3TNzN5zr9e70xnUjFwGhN hI6SUVw0i4xTiIPQNvmfcvxucsyRVGu+mCa56yFqEz1wELCWc5B9UtFgg9Q8eqoX1Js7 iX67zGLMalSs4Utq4iEZBepo7rPXUe+0Pwew36LucLB2G7a6C8qDkZ/WpM7JCA9oUi7F ORlOxClVSoHE22tsx0FW0Ix8MWgUSqWhwwq36lrJ3kEI31/orjYYl4uyP8Bu3Kdv7XZj h8rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=U/cSf4gVc7RWz3455CFWeoW09C+QBS6EY7ywT20NN0M=; b=nQufhSMuopA8LF6R75Hvtv2QiTxuPs76ZlHQy1cv5yvKCIvEEap/8hupcuP/HdHrqO hO3YtAEvY19RlbxRtj49LMZomwu7xB3SIHVDjqJEHJfL8Mta+my2GcRI6njy4wNP7Kuu flq7IDshBE9J26sCpceBBEBKlU6M62NJYZLcuOF1qiZToA+oc0hzs3TcGb3QWf01fGj/ ddI9fK1tKwGzMvEenxzlecTGcvyLyVE1ovBM+B7b4ivcHwNjrsO4Gb3/CBBJDHJQXY3f CmXsiTIcAEy4rHOzhxgl+sGOBznmeEgVjCmTn5ghE4iLnkNQU7JSuw/EQ8Tr2UDUcJn8 8sCQ== X-Gm-Message-State: ACrzQf11NVEkwqPyOEojBdEYqnewtFC/1yqPlDL1K7MpPr8kMeASB9Uv B4RhJV0GwJVuzEbUL2YRAjxqkd9qq3PwxDDObtljhBCycKI= X-Google-Smtp-Source: AMsMyM4uCEtFDlVGgRvBBJSOiYPqdWyes9RHrGxkf5ZXG1pytn9CTVTT8GK8FK+TXktj9ItwkFknRxnwiimJoBm9+KU= X-Received: by 2002:a4a:8932:0:b0:44b:3454:a9d3 with SMTP id f47-20020a4a8932000000b0044b3454a9d3mr1569607ooi.56.1664465968405; Thu, 29 Sep 2022 08:39:28 -0700 (PDT) MIME-Version: 1.0 From: Ruben Somsen Date: Thu, 29 Sep 2022 17:39:18 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c9a19905e9d2ae9e" X-Mailman-Approved-At: Thu, 29 Sep 2022 15:41:07 +0000 Subject: [bitcoin-dev] =?utf-8?q?Trustless_Address_Server_=E2=80=93_Outsou?= =?utf-8?q?rcing_handing_out_addresses_to_prevent_address_reuse?= X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2022 15:39:31 -0000 --000000000000c9a19905e9d2ae9e Content-Type: text/plain; charset="UTF-8" Hi all, In short, this is yet another way to hand out addresses without interaction between sender and recipient (Silent Payments, BIP47). The idea here is that in non-ideal cases where you're already exposing your xpub to a server (most light clients today, unfortunately), you might as well rely on them to hand out addresses on your behalf. Other than BTCPay Server, I am not aware of any serious attempts of exploring this direction. Perhaps this is justified, due to the difficulty of dealing with the gap limit, but it seems worth discussing nonetheless. The write-up is available (and kept up-to-date) here as a gist: https://gist.github.com/RubenSomsen/960ae7eb52b79cc826d5b6eaa61291f6 And here's a copy for the list: ### Introduction Address reuse prevention generally requires interacting with the recipient in order to receive a fresh address for each payment. There are various protocols that ensure no interaction is required such as BIP47[^1] and Silent Payments[^2], though neither is without downsides. One area that is seemingly underexplored is that of outsourced interaction. BTCPay Server[^3] is an example of this. The sender interacts with a server, which acts on behalf of the recipient and hands out an address from an xpub. The recipient controls and therefore trusts the server, so malicious addresses won't be given out. ### Outsourcing and Malicious Keys The vast majority of light clients today (even ones that support BIP47, curiously) already control the user's xpub, so it seems logical to think the interaction can be outsourced to them. However, unlike when running your own server, a third party server *could* potentially hand out malicious addresses (i.e. addresses that belong to someone other than you). The solution to this is identity. As long as the sender knows a public key by which the recipient can be identified, the recipient can sign the addresses that are derived from their xpub[^4]. This way the sender can be sure that the address it receives from the server belongs to the recipient. ### Gap Limit One big remaining problem is the gap limit[^5]. When an adversary repeatedly requests addresses from the server but then never uses them, this could result in a large gap of unused addresses. This is a problem because when recovering from backup the wallet stops looking for payments when a large enough gap is encountered. Unfortunately there is no perfect solution, but mitigations are still possible. Whenever a sender wants to make their first payment, they could be expected to obtain an address at a cost (solving captchas, paying over LN, proof-of-burn[^6]). If the sender doesn't mind (or maybe even desires) having their payments correlated by the recipient, a fresh xpub[^7] can be handed out instead of an address in order to enable repeated payments. If non-correlated payments are preferable, after each successful payment the server could hand out a blind ecash[^8] token that entitles the sender to another address. An alternative mitigation (more user friendly, but more implementation complexity) would be to require the sender to reveal their intended transaction to the server prior to receiving the address[^9]. This is not a privacy degradation, since the server could already learn this information regardless. If the transaction doesn't end up getting sent, any subsequent attempt to reuse one of the inputs should either be (temporarily) blacklisted or responded to with the same address that was given out earlier[^10]. If despite best efforts the gap limit is inadvertently reached anyway, the recipient may have to be instructed to ensure they properly receive a payment to bridge the gap before new addresses can be handed out. The alternative is to forego privacy when this happens, but this seems unwise. ### Use Case This protocol seems useful for users that a.) want to use light clients, b.) accept the privacy degradation of handing out their xpub to a third party, and c.) want to receive payments non-interactively. If any one of these is not true, other protocols are likely to be a better choice[^11]. Finally, it should be acknowledged that this protocol introduces more friction on the sender side due to the need for a gap limit mitigation strategy. -- Ruben Somsen [^1]: BIP47: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki [^2]: Silent Payments: https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8 [^3]: BTCPay Server https://btcpayserver.org/ [^4]: *Specifically, this could be a single signature on a merkle root, so the amount of data that the recipient needs to send to the server can be minimized and the server can just generate the same tree from the xpub and hand out merkle proofs to senders. The order of the leaves should be randomized so senders cannot learn how many payments were made.* [^5]: Gap limit: https://bitcoin.stackexchange.com/questions/111534/bitcoin-address-gap-limit [^6]: Efficient Proof-of-Burn: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020746.html [^7]: Xpub sharing: https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing [^8]: Blind ecash: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 [^9]: *This would essentially look like an incomplete but signed transaction where the output address is still missing.* [^10]: *Keep in mind the edge case where e.g. two inputs are presented but not used, followed by two separate transactions which each use one of the priorly presented inputs.* [^11]: Protocol considerations: https://twitter.com/SomsenRuben/status/1530096037414707200 --000000000000c9a19905e9d2ae9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

In short, this is yet another w= ay to hand out addresses without interaction between sender and recipient (= Silent Payments, BIP47). The idea here is that in non-ideal cases where you= 're already exposing your xpub to a server (most light clients today, u= nfortunately), you might as well rely on them to hand out addresses on your= behalf.

Other than BTCPay Server, I am not aware = of any serious attempts of exploring this direction. Perhaps this is justif= ied, due to the difficulty of dealing with the gap limit, but it seems wort= h discussing nonetheless.

The write-up is availabl= e (and kept up-to-date) here as a gist:

And here's a copy for the list:


### Introduction

Address reuse prevention generally require= s interacting with the recipient in order to receive a fresh address for ea= ch payment. There are various protocols that ensure no interaction is requi= red such as BIP47[^1] and Silent Payments[^2], though neither is without do= wnsides.

One area that is seemingly underexplored is that of outsour= ced interaction. BTCPay Server[^3] is an example of this. The sender intera= cts with a server, which acts on behalf of the recipient and hands out an a= ddress from an xpub. The recipient controls and therefore trusts the server= , so malicious addresses won't be given out.

### Outsourcing and= Malicious Keys

The vast majority of light clients today (even ones = that support BIP47, curiously) already control the user's xpub, so it s= eems logical to think the interaction can be outsourced to them. However, u= nlike when running your own server, a third party server *could* potentiall= y hand out malicious addresses (i.e. addresses that belong to someone other= than you).

The solution to this is identity. As long as the sender = knows a public key by which the recipient can be identified, the recipient = can sign the addresses that are derived from their xpub[^4]. This way the s= ender can be sure that the address it receives from the server belongs to t= he recipient.

### Gap Limit

One big remaining problem is the = gap limit[^5]. When an adversary repeatedly requests addresses from the ser= ver but then never uses them, this could result in a large gap of unused ad= dresses. This is a problem because when recovering from backup the wallet s= tops looking for payments when a large enough gap is encountered. Unfortuna= tely there is no perfect solution, but mitigations are still possible.
<= br>Whenever a sender wants to make their first payment, they could be expec= ted to obtain an address at a cost (solving captchas, paying over LN, proof= -of-burn[^6]). If the sender doesn't mind (or maybe even desires) havin= g their payments correlated by the recipient, a fresh xpub[^7] can be hande= d out instead of an address in order to enable repeated payments. If non-co= rrelated payments are preferable, after each successful payment the server = could hand out a blind ecash[^8] token that entitles the sender to another = address.

An alternative mitigation (more user friendly, but more im= plementation complexity) would be to require the sender to reveal their int= ended transaction to the server prior to receiving the address[^9]. This is= not a privacy degradation, since the server could already learn this infor= mation regardless. If the transaction doesn't end up getting sent, any = subsequent attempt to reuse one of the inputs should either be (temporarily= ) blacklisted or responded to with the same address that was given out earl= ier[^10].

If despite best efforts the gap limit is inadvertently rea= ched anyway, the recipient may have to be instructed to ensure they properl= y receive a payment to bridge the gap before new addresses can be handed ou= t. The alternative is to forego privacy when this happens, but this seems u= nwise.

### Use Case

This protocol seems useful for users that= a.) want to use light clients, b.) accept the privacy degradation of handi= ng out their xpub to a third party, and c.) want to receive payments non-in= teractively. If any one of these is not true, other protocols are likely to= be a better choice[^11]. Finally, it should be acknowledged that this prot= ocol introduces more friction on the sender side due to the need for a gap = limit mitigation strategy.

-- Ruben Somsen


[^1]: BIP47: <= a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki">h= ttps://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki

[^= 2]: Silent Payments: https://gist.github.com/RubenSomsen/c43b79517e7c= b701ebf77eec6dbb46b8

[^3]: BTCPay Server https://btcpayserver.org/

[^4]: *Specifically, th= is could be a single signature on a merkle root, so the amount of data that= the recipient needs to send to the server can be minimized and the server = can just generate the same tree from the xpub and hand out merkle proofs to= senders. The order of the leaves should be randomized so senders cannot le= arn how many payments were made.*

[^5]: Gap limit: htt= ps://bitcoin.stackexchange.com/questions/111534/bitcoin-address-gap-limit

[^6]: Efficient Proof-of-Burn: https://lists.linux= foundation.org/pipermail/bitcoin-dev/2022-July/020746.html

[^7]:= Xpub sharing: https://gist.github.com/RubenSomsen/c43b7= 9517e7cb701ebf77eec6dbb46b8#xpub-sharing

[^8]: Blind ecash: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406<= br>
[^9]: *This would essentially look like an incomplete but signed tra= nsaction where the output address is still missing.*

[^10]: *Keep in= mind the edge case where e.g. two inputs are presented but not used, follo= wed by two separate transactions which each use one of the priorly presente= d inputs.*

[^11]: Protocol considerations: https://twitter.com/SomsenRub= en/status/1530096037414707200
--000000000000c9a19905e9d2ae9e--