diff options
| author | Alfred Hodler <alfred_hodler@protonmail.com> | 2022-06-27 18:17:16 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-06-27 18:17:27 +0000 |
| commit | aa7fee1a7badc79dc738dc6c5c76841d8f635062 (patch) | |
| tree | 4b78282bf91a763d0dcadaed27f231b7c2e1f0a0 | |
| parent | db24783601d63ad4609df80f12d3989ea146c0c2 (diff) | |
| download | pi-bitcoindev-aa7fee1a7badc79dc738dc6c5c76841d8f635062.tar.gz pi-bitcoindev-aa7fee1a7badc79dc738dc6c5c76841d8f635062.zip | |
[bitcoin-dev] [BIP proposal] Private Payments
| -rw-r--r-- | 5a/505ec674ece1c8a92291489b2562278eceb173 | 232 |
1 files changed, 232 insertions, 0 deletions
diff --git a/5a/505ec674ece1c8a92291489b2562278eceb173 b/5a/505ec674ece1c8a92291489b2562278eceb173 new file mode 100644 index 000000000..e55983cac --- /dev/null +++ b/5a/505ec674ece1c8a92291489b2562278eceb173 @@ -0,0 +1,232 @@ +Return-Path: <alfred_hodler@protonmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 4DA26C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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" + <bitcoin-dev@lists.linuxfoundation.org> +From: Alfred Hodler <alfred_hodler@protonmail.com> +Reply-To: Alfred Hodler <alfred_hodler@protonmail.com> +Message-ID: <rH1Js_T_UWcAg9lS9NDw_Qb6Js5bgs8rPILej69BjqsEZcJZwsvHhZRilkkOQZRGXabai63hrGgbTP2Yk99ojKEN6fU6HT4TmukiafqiKjo=@protonmail.com> +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 <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: 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 + + |