From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4DA26C002D for ; Mon, 27 Jun 2022 18:17:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1D3004163D for ; Mon, 27 Jun 2022 18:17:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1D3004163D Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=basqDdQP X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9IYAufmR3OY for ; Mon, 27 Jun 2022 18:17:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 994E5415F0 Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by smtp4.osuosl.org (Postfix) with ESMTPS id 994E5415F0 for ; Mon, 27 Jun 2022 18:17:25 +0000 (UTC) Date: Mon, 27 Jun 2022 18:17:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1656353843; x=1656613043; bh=1owogIvWi+f+uqZ9u4qRbGWuprW/9OGSh3RAVfRolFw=; h=Date:To:From:Reply-To:Subject:Message-ID:Feedback-ID:From:To:Cc: Date:Subject:Reply-To:Feedback-ID:Message-ID; b=basqDdQPGQi0X8bZCdNeojk+vOyQTvI8INgTzWCEHobmFW3RMGNvKmM1rigTixSPT BX1hhhgHnwJnSO2jFtU/NUkozbyEzy0tF8qQcVQrA3by+QFJHIkU7M/5g8ziuX8gwV WhOYTwOmRR+HtEl506Jy471Lsq6Ccj5/Mzp39/9jNB8wMObSP04vSIi+mycMSFNJ9Z zfE+gYdSFGdQif0Fs5VzaCgVPK7LJSVccwTOtadof0Qr8V2AmvQBG3Rm6WnkBSWpzj tP5Dj1OPUo9C7bLw07epivE1zs9zfYRVe5CxlJB7KREfMUAOFPTebMsgCnnwoqcu8h LINeZhJRabpDg== To: "bitcoin-dev@lists.linuxfoundation.org" From: Alfred Hodler Reply-To: Alfred Hodler Message-ID: Feedback-ID: 44065311:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 27 Jun 2022 19:13:55 +0000 Subject: [bitcoin-dev] [BIP proposal] Private Payments 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: Mon, 27 Jun 2022 18:17:27 -0000 Hi, There have been attempts to create static payment codes that function as a = way for transacting parties to create "private" addresses, where private st= ands for "known only to transacting parties". BIP47 was one such standard. The standard suffered from a number of problems: 1. The standard promised extensibility through versioning but it never used= that capability to follow innovations in the Bitcoin protocol. It was desi= gned around the idea that legacy p2pkh addresses would always be the primar= y and only way to transact. As new standard script types started to emerge = (Segwit v0, Taproot), the creators dealt with the problem by stating that i= mplementing wallets should scan for all existing standard scripts. The inab= ility of payment codes to explicitly state which address types they derive = places a burden on more resource constrained wallets. 2. The standard relied on a notification mechanism in order to connect a se= nder with a recipient, which included either offchain technology (Bitmessag= e), or so called "notification addresses" which a) left a footprint b) crea= ted toxic change. That type of footprint is particularly harmful because it= makes it obvious that a particular recipient is going to receive private t= ransactions. If the notifying party performs this process with coins linked= to its identity (i.e. tainted or non-anonymized inputs), it forever become= s visible that Alice connected with Bob despite the fact that her payment c= ode was blinded. While future transactions and their amounts aren't visible= , this metadata makes it possible to build a social graph. 3. The standard was implemented only by an entity that disavowed the BIP pr= ocess and didn't wish to use it to keep the standard up to date. Further up= dates did take place but only outside the BIP process, creating a lack of c= larity as to what the real specification is. Ultimately the standard was ab= andoned. I propose to build on the idea of payment codes under a new BIP with the fo= llowing principal differences: 1. The new standard will allocate a 2-byte bitflag array that will signal a= ddress/script types that the receiver is deriving. Since the vast majority = of scripts are p2pkh (47.3%) and p2wpkh (26.2%), bits 0 and 1 will be used = for those respectively. Bit 2 will be p2tr. The remaining 13 bits are reser= ved for future standard script types. 2. Notification transactions still exist but no longer leave a privacy foot= print on the blockchain. Instead, a notification transaction is simply a si= ngle OP_RETURN containing a value that only Alice and Bob can calculate. If= Alice's notification transaction uses UTXOs not associated with her identi= ty, there is never a footprint showing that either her or Bob are using pri= vate payments. If Alice uses tainted coins, only she is exposed as a user o= f Private Payments but Bob still isn't. 3. Payment code versioning is no longer done because it creates the potenti= al for fragmentation and disparate standard updates by different parties th= at don't follow the BIP process (BIP47 is a good example of that). 4. Relying on static compressed pubkeys as opposed to extended keys means s= horter payment codes. =3D=3DProposed Payment Code Structure=3D=3D bytes 0-1: - enabled (watched) address types (16 possible address types) bytes 2-35: - compressed public key P =3D=3DEncoding=3D=3D A payment code is encoded in base58check and the version byte produces "S" = for the first character. A code might look like "SwLUHs3UfMUXq956aXLTUPPfow= 7a8gDfSUUAtafwqHcobf6mKcMbJk". =3D=3DPubkey Derivation=3D=3D Recipient's payment code pubkey `P` is derived from a master key using the = following path: `m/purpose'/coin_type'/account'`. `purpose` will be defined= once a BIP number is assigned. Its corresponding private key is `p`. Notifier/sender's pubkey `N` is derived using the following derivation path= : `m/purpose'/coin_type'/account'/*`, where each recipient gets a new index= . This way send-side privacy is always preserved. Its corresponding private= key is `n`. =3D=3DNotifications=3D=3D Alice wants to notify Bob that he will receive future payments from her. Al= ice selects any UTXO in her wallet (preferably not associated with her) and= `n_Alice`. Alice selects the public key contained in Bob's payment code `P= _Bob`. Alice performs the following process (`*` and `+` are EC operations)= : notification =3D SHA256(n_Alice * P_Bob) Alice then constructs a 72-byte OP_RETURN output whose value is set to `BIP= XXXX + notification + N_Alice` (`+` is concat) and sends it in a transactio= n containing no other outputs (XXXX to be replaced once a BIP number is ass= igned). Alice MUST now keep track of `n_Alice` or its derivation path as it= will be used in future transactions exclusively with Bob (not for spending= but to calculate secret addresses). Bob's wallet receives whole blocks but doesn't need to waste resources on d= ecoding them if the environment is resource constrained. Bob simply needs f= ind the string BIPXXXX in the binary blob that represents an undecoded bloc= k. Once found, Bob extracts the subsequent 32 bytes (`notification`) and th= e subsequent 33 bytes (`N_Alice`). The benefit of this approach is that Bob= doesn't have to decode blocks and extract pubkeys from scriptsigs. Since ECDH dictates that SHA256(n_Alice * P_Bob) =3D=3D SHA256(N_Alice * p_= Bob), Bob calculates the expected notification value and checks if it match= es the first value in the payload. If so, Bob found a notification transact= ion addressed to himself and stores `N_Alice` in order to be able to detect= and spend future payments from Alice. The added benefit of this approach o= ver BIP47 is that Bob doesn't learn Alice's payment code, so Alice can pay = Bob without revealing her identity. To take advantage of these privacy bene= fits, Alice simply has to engage in coin control on her end. A real world s= cenario where this might be useful is anonymous donations to a party whose = wallet may be seized in the future. Seizing such a wallet won't reveal who = Alice is (as long as she engages in coin control), whereas BIP47 would by d= efault leak her identity even if her coins as anonymized. If this process fails for any reason, Bob assumes a spurious notification o= r one not addressed to himself and gives up. =3D=3DTransacting=3D=3D Now that they are connected, Alice can send transactions to Bob. Alice need= s to keep track of her transaction count toward Bob; let's name that counte= r `X`. This process is similar to what BIP47 does. Alice calculates a secret point: S =3D n_Alice * P_Bob Alice calculates a shared secret: s =3D SHA256(S, X) Alice calculates Bob's ephemeral public key and its associated address wher= e the funds will be sent: P_Bob' =3D P_Bob + s*G When Bob detects a payment to `P_Bob'`, he can spend such coins by calculat= ing the shared secret `s` in the same manner using `N_Alice` and `p_Bob` an= d performing: p_bob' =3D p_bob + s The fact that Alice and Bob are using a shared counter means we can do away= with chain codes and make payment codes much smaller. Bob simply needs to = derive a number of addresses to watch with respect to some gap limit (which= can be as low as 1 in practice). =3D=3DAnti-spam=3D=3D While DoS hasn't been a problem with BIP47, it is possible to build anti-sp= am measures into payment codes. The owner of a code could simply demand tha= t a notification transaction meets some minimum miner fee or a multiple of = some trailing average. This would help prevent spam notifications that migh= t otherwise overwhelm a payment code with addresses to watch. But that is p= urely optional. Looking forward to hearing thoughts and ideas. Alfred