path: root/5a/505ec674ece1c8a92291489b2562278eceb173

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