Date: Mon, 27 Jun 2022 18:17:16 +0000
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
Subject: [bitcoin-dev] [BIP proposal] Private Payments
Precedence: list

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