📅 Original date posted:2022-06-29
📝 Original message:Alfred,
Thanks for the proposal. This is really interesting, especially the
additional on-chain privacy improvements over BIP47: ephemeral
notifier/sender keys and shielding of the sender key(s) against
seizure of the recipient's wallet.
> A payment code is encoded in base58check and the version byte produces "S" for the first character.
This is a bit under-specified, but let me bike-shed here and suggest
going with a Bech32m encoding. We gain more compact QR codes as well
as error detection/correction.
Alternate proposal:
- Bech32m human-readable part = "pay"
- Data payload is [watched address type bytes (2), compressed pubkey (33)]
Example:
- Address type bytes = c000
- Pubkey 03b54543fbed9d17d9300b508c55769bc4c8385620626730b4d52e5f3e30d9a6c1
- Published payment code:
pay1cqqq8d29g0a7m8ghmycqk5yv24mfh3xg8ptzqcn8xz6d2tjl8ccdnfkpjl7p84
> The owner of a code could simply demand that a notification transaction meets some minimum miner fee or a multiple of some trailing average.
I don't see how this would work, and others have pointed out that the
cost of block space is itself an anti-spam measure.
== Notification Service Idea ==
A third-party service could offer to publish OP_RETURN notification
payloads in the blockchain for a fee, paid over Lightning Network.
This completely de-links Alice's notification from her wallet, while
accepting the less-known privacy implications of a Lightning payment.
The service would remain ignorant of Bob's identity in any event. Such
a service would also be incentivized to charge market rates for the
potential privacy boost and for block space.
== Data Service Idea ==
Another service could publish only the OP_RETURN data pertaining to
this BIP, which is easy to obtain due to the clear tagging scheme.
Light wallets would check in with this service on a regular basis,
performing the ECDH filtering steps on each output. Upon further
request, the service furnishes transaction proofs for the full
transaction containing the OP_RETURN. Care would need to be taken to
avoid leaking too much information to the service, and techniques such
as using separate Tor circuits or requesting tx proofs on a bulk set
of transactions could help obfuscate the exact transaction of
interest. These concerns are similar to those found in BIP157
client-side block filtering (Neutrino filters).
Alternatively, the service publishes the block height along with the
notification data contained within that block. Light clients could
download relevant blocks over the p2p network and perform full
validation.
-Clark
On Mon, Jun 27, 2022 at 2:14 PM Alfred Hodler via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi,
>
> There have been attempts to create static payment codes that function as a way for transacting parties to create "private" addresses, where private stands 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 designed around the idea that legacy p2pkh addresses would always be the primary 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 implementing wallets should scan for all existing standard scripts. The inability 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 sender with a recipient, which included either offchain technology (Bitmessage), or so called "notification addresses" which a) left a footprint b) created toxic change. That type of footprint is particularly harmful because it makes it obvious that a particular recipient is going to receive private transactions. If the notifying party performs this process with coins linked to its identity (i.e. tainted or non-anonymized inputs), it forever becomes visible that Alice connected with Bob despite the fact that her payment code 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 process and didn't wish to use it to keep the standard up to date. Further updates did take place but only outside the BIP process, creating a lack of clarity as to what the real specification is. Ultimately the standard was abandoned.
>
> I propose to build on the idea of payment codes under a new BIP with the following principal differences:
>
> 1. The new standard will allocate a 2-byte bitflag array that will signal address/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 reserved for future standard script types.
>
> 2. Notification transactions still exist but no longer leave a privacy footprint on the blockchain. Instead, a notification transaction is simply a single OP_RETURN containing a value that only Alice and Bob can calculate. If Alice's notification transaction uses UTXOs not associated with her identity, there is never a footprint showing that either her or Bob are using private payments. If Alice uses tainted coins, only she is exposed as a user of Private Payments but Bob still isn't.
>
> 3. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that 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 shorter payment codes.
>
> ==Proposed Payment Code Structure==
>
> bytes 0-1: - enabled (watched) address types (16 possible address types)
> bytes 2-35: - compressed public key P
>
> ==Encoding==
>
> A payment code is encoded in base58check and the version byte produces "S" for the first character. A code might look like "SwLUHs3UfMUXq956aXLTUPPfow7a8gDfSUUAtafwqHcobf6mKcMbJk".
>
> ==Pubkey Derivation==
>
> 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`.
>
> ==Notifications==
>
> Alice wants to notify Bob that he will receive future payments from her. Alice 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 = SHA256(n_Alice * P_Bob)
>
> Alice then constructs a 72-byte OP_RETURN output whose value is set to `BIPXXXX + notification + N_Alice` (`+` is concat) and sends it in a transaction containing no other outputs (XXXX to be replaced once a BIP number is assigned). 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 decoding them if the environment is resource constrained. Bob simply needs find the string BIPXXXX in the binary blob that represents an undecoded block. Once found, Bob extracts the subsequent 32 bytes (`notification`) and the 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) == SHA256(N_Alice * p_Bob), Bob calculates the expected notification value and checks if it matches the first value in the payload. If so, Bob found a notification transaction 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 over 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 benefits, Alice simply has to engage in coin control on her end. A real world scenario 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 default leak her identity even if her coins as anonymized.
>
> If this process fails for any reason, Bob assumes a spurious notification or one not addressed to himself and gives up.
>
> ==Transacting==
>
> Now that they are connected, Alice can send transactions to Bob. Alice needs to keep track of her transaction count toward Bob; let's name that counter `X`. This process is similar to what BIP47 does.
>
> Alice calculates a secret point:
>
> S = n_Alice * P_Bob
>
> Alice calculates a shared secret:
>
> s = SHA256(S, X)
>
> Alice calculates Bob's ephemeral public key and its associated address where the funds will be sent:
>
> P_Bob' = P_Bob + s*G
>
> When Bob detects a payment to `P_Bob'`, he can spend such coins by calculating the shared secret `s` in the same manner using `N_Alice` and `p_Bob` and performing:
>
> p_bob' = 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).
>
> ==Anti-spam==
>
> While DoS hasn't been a problem with BIP47, it is possible to build anti-spam measures into payment codes. The owner of a code could simply demand that a notification transaction meets some minimum miner fee or a multiple of some trailing average. This would help prevent spam notifications that might otherwise overwhelm a payment code with addresses to watch. But that is purely optional.
>
> Looking forward to hearing thoughts and ideas.
>
> Alfred
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Clark Moody [ARCHIVE] /
npub1nr…0hypj
2023-06-07 23:10:49
in reply to nevent1q…kxr7
Author Public Key
npub1nr02dq8fsgnt758nyp29waulhwwhj6j9gmlsqsknlwjem2hu8twqp0hypjPublished at
2023-06-07 23:10:49Event JSON
{
"id": "d0af9a67aebc60ec297bb5f5650d8e01f1a8993bcef490dac052bae36a758aca",
"pubkey": "98dea680e98226bf50f3205457779fbb9d796a4546ff0042d3fba59daafc3adc",
"created_at": 1686179449,
"kind": 1,
"tags": [
[
"e",
"2c117deceb80922b32181925f44f4eb7705b67956a1c3a9bf3e3a63b07a98031",
"",
"root"
],
[
"e",
"7f495c5bed1f44e7ac2801e9cb70009e852c166e8815270e01b74a58a893bbba",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-06-29\n📝 Original message:Alfred,\n\nThanks for the proposal. This is really interesting, especially the\nadditional on-chain privacy improvements over BIP47: ephemeral\nnotifier/sender keys and shielding of the sender key(s) against\nseizure of the recipient's wallet.\n\n\u003e A payment code is encoded in base58check and the version byte produces \"S\" for the first character.\n\nThis is a bit under-specified, but let me bike-shed here and suggest\ngoing with a Bech32m encoding. We gain more compact QR codes as well\nas error detection/correction.\n\nAlternate proposal:\n\n- Bech32m human-readable part = \"pay\"\n- Data payload is [watched address type bytes (2), compressed pubkey (33)]\n\nExample:\n\n- Address type bytes = c000\n- Pubkey 03b54543fbed9d17d9300b508c55769bc4c8385620626730b4d52e5f3e30d9a6c1\n- Published payment code:\npay1cqqq8d29g0a7m8ghmycqk5yv24mfh3xg8ptzqcn8xz6d2tjl8ccdnfkpjl7p84\n\n\u003e The owner of a code could simply demand that a notification transaction meets some minimum miner fee or a multiple of some trailing average.\n\nI don't see how this would work, and others have pointed out that the\ncost of block space is itself an anti-spam measure.\n\n== Notification Service Idea ==\n\nA third-party service could offer to publish OP_RETURN notification\npayloads in the blockchain for a fee, paid over Lightning Network.\nThis completely de-links Alice's notification from her wallet, while\naccepting the less-known privacy implications of a Lightning payment.\nThe service would remain ignorant of Bob's identity in any event. Such\na service would also be incentivized to charge market rates for the\npotential privacy boost and for block space.\n\n== Data Service Idea ==\n\nAnother service could publish only the OP_RETURN data pertaining to\nthis BIP, which is easy to obtain due to the clear tagging scheme.\nLight wallets would check in with this service on a regular basis,\nperforming the ECDH filtering steps on each output. Upon further\nrequest, the service furnishes transaction proofs for the full\ntransaction containing the OP_RETURN. Care would need to be taken to\navoid leaking too much information to the service, and techniques such\nas using separate Tor circuits or requesting tx proofs on a bulk set\nof transactions could help obfuscate the exact transaction of\ninterest. These concerns are similar to those found in BIP157\nclient-side block filtering (Neutrino filters).\n\nAlternatively, the service publishes the block height along with the\nnotification data contained within that block. Light clients could\ndownload relevant blocks over the p2p network and perform full\nvalidation.\n\n\n-Clark\n\nOn Mon, Jun 27, 2022 at 2:14 PM Alfred Hodler via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Hi,\n\u003e\n\u003e There have been attempts to create static payment codes that function as a way for transacting parties to create \"private\" addresses, where private stands for \"known only to transacting parties\". BIP47 was one such standard.\n\u003e\n\u003e The standard suffered from a number of problems:\n\u003e\n\u003e 1. The standard promised extensibility through versioning but it never used that capability to follow innovations in the Bitcoin protocol. It was designed around the idea that legacy p2pkh addresses would always be the primary 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 implementing wallets should scan for all existing standard scripts. The inability of payment codes to explicitly state which address types they derive places a burden on more resource constrained wallets.\n\u003e\n\u003e 2. The standard relied on a notification mechanism in order to connect a sender with a recipient, which included either offchain technology (Bitmessage), or so called \"notification addresses\" which a) left a footprint b) created toxic change. That type of footprint is particularly harmful because it makes it obvious that a particular recipient is going to receive private transactions. If the notifying party performs this process with coins linked to its identity (i.e. tainted or non-anonymized inputs), it forever becomes visible that Alice connected with Bob despite the fact that her payment code was blinded. While future transactions and their amounts aren't visible, this metadata makes it possible to build a social graph.\n\u003e\n\u003e 3. The standard was implemented only by an entity that disavowed the BIP process and didn't wish to use it to keep the standard up to date. Further updates did take place but only outside the BIP process, creating a lack of clarity as to what the real specification is. Ultimately the standard was abandoned.\n\u003e\n\u003e I propose to build on the idea of payment codes under a new BIP with the following principal differences:\n\u003e\n\u003e 1. The new standard will allocate a 2-byte bitflag array that will signal address/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 reserved for future standard script types.\n\u003e\n\u003e 2. Notification transactions still exist but no longer leave a privacy footprint on the blockchain. Instead, a notification transaction is simply a single OP_RETURN containing a value that only Alice and Bob can calculate. If Alice's notification transaction uses UTXOs not associated with her identity, there is never a footprint showing that either her or Bob are using private payments. If Alice uses tainted coins, only she is exposed as a user of Private Payments but Bob still isn't.\n\u003e\n\u003e 3. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process (BIP47 is a good example of that).\n\u003e\n\u003e 4. Relying on static compressed pubkeys as opposed to extended keys means shorter payment codes.\n\u003e\n\u003e ==Proposed Payment Code Structure==\n\u003e\n\u003e bytes 0-1: - enabled (watched) address types (16 possible address types)\n\u003e bytes 2-35: - compressed public key P\n\u003e\n\u003e ==Encoding==\n\u003e\n\u003e A payment code is encoded in base58check and the version byte produces \"S\" for the first character. A code might look like \"SwLUHs3UfMUXq956aXLTUPPfow7a8gDfSUUAtafwqHcobf6mKcMbJk\".\n\u003e\n\u003e ==Pubkey Derivation==\n\u003e\n\u003e 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`.\n\u003e\n\u003e 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`.\n\u003e\n\u003e ==Notifications==\n\u003e\n\u003e Alice wants to notify Bob that he will receive future payments from her. Alice 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):\n\u003e\n\u003e notification = SHA256(n_Alice * P_Bob)\n\u003e\n\u003e Alice then constructs a 72-byte OP_RETURN output whose value is set to `BIPXXXX + notification + N_Alice` (`+` is concat) and sends it in a transaction containing no other outputs (XXXX to be replaced once a BIP number is assigned). 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).\n\u003e\n\u003e Bob's wallet receives whole blocks but doesn't need to waste resources on decoding them if the environment is resource constrained. Bob simply needs find the string BIPXXXX in the binary blob that represents an undecoded block. Once found, Bob extracts the subsequent 32 bytes (`notification`) and the subsequent 33 bytes (`N_Alice`). The benefit of this approach is that Bob doesn't have to decode blocks and extract pubkeys from scriptsigs.\n\u003e\n\u003e Since ECDH dictates that SHA256(n_Alice * P_Bob) == SHA256(N_Alice * p_Bob), Bob calculates the expected notification value and checks if it matches the first value in the payload. If so, Bob found a notification transaction 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 over 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 benefits, Alice simply has to engage in coin control on her end. A real world scenario 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 default leak her identity even if her coins as anonymized.\n\u003e\n\u003e If this process fails for any reason, Bob assumes a spurious notification or one not addressed to himself and gives up.\n\u003e\n\u003e ==Transacting==\n\u003e\n\u003e Now that they are connected, Alice can send transactions to Bob. Alice needs to keep track of her transaction count toward Bob; let's name that counter `X`. This process is similar to what BIP47 does.\n\u003e\n\u003e Alice calculates a secret point:\n\u003e\n\u003e S = n_Alice * P_Bob\n\u003e\n\u003e Alice calculates a shared secret:\n\u003e\n\u003e s = SHA256(S, X)\n\u003e\n\u003e Alice calculates Bob's ephemeral public key and its associated address where the funds will be sent:\n\u003e\n\u003e P_Bob' = P_Bob + s*G\n\u003e\n\u003e When Bob detects a payment to `P_Bob'`, he can spend such coins by calculating the shared secret `s` in the same manner using `N_Alice` and `p_Bob` and performing:\n\u003e\n\u003e p_bob' = p_bob + s\n\u003e\n\u003e 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).\n\u003e\n\u003e ==Anti-spam==\n\u003e\n\u003e While DoS hasn't been a problem with BIP47, it is possible to build anti-spam measures into payment codes. The owner of a code could simply demand that a notification transaction meets some minimum miner fee or a multiple of some trailing average. This would help prevent spam notifications that might otherwise overwhelm a payment code with addresses to watch. But that is purely optional.\n\u003e\n\u003e Looking forward to hearing thoughts and ideas.\n\u003e\n\u003e Alfred\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "1642b5417f074b4548d7069b84c7d4b8935c55a79f7d77c420b9f32db1ae8e765d14be918be8f218d1718c0de4d2ba390964da6624375995c97cfaeb27ac1c76"
}