josibake [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2023-04-21 to 2023-04-21
💬 Posted a total of 1 messages
📚 Participated in the following categories:
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-08-06 23:37:35

- reply

📅 Original date posted:2023-08-06
🗒️ Summary of this message: The author acknowledges the feedback on expiration dates in Bitcoin but expresses skepticism about their effectiveness and potential drawbacks. They highlight scenarios where expiration dates may cause issues and suggest exploring a wallet protocol instead. They also mention privacy concerns and the need for enforceability by consensus. Overall, expiration dates are seen as a separate problem from the scope of BIP352.
📝 Original message:
Hi Peter,
Thanks for the feedback! As you mentioned, this is a more general problem in Bitcoin and not specific to BIP352. Therefore, if expiration dates are indeed something we want, they should be proposed and discussed as their own BIP and be a standard that can work for xpubs, static payment codes, as well as existing and future address formats. If that were to happen, it would be easy enough to add this expiration standard to silent payments as a new silent payments address version.
That being said, I'm a bit skeptical in general of expiration dates and think that they weaken the value proposition of silent payments while not actually solving the problems you described. Consider the following scenarios:
1. Bob's wallet is compromised with a one-year expiry and for the next year, funds are sent to the attacker. The attacker may have the ability to update the expiration, and thus be able to keep receiving funds as Bob.
2. Bob loses his keys with a one-year expiry but finds them again 3 years later. The expiration causes Bob to miss out on 2 years worth of potential payments.
3. Bob dies with a one-year expiry but an heir inherits his backups several years down the road. The expiration date causes the heir to miss out on several years worth of potential payments.
4. Bob is prevented from updating his address for several years but retains access to his keys/backups. The expiration date causes Bob to miss out on several years worth of potential payments.
5. Bob regularly updates his address with a new expiry, but not all senders are able to find the new, updated address causing Bob to miss out on potential payments.
6. By updating his address, Bob is leaking metadata about himself, potentially compromising his safety.
You could argue that none of the scenarios above would be an issue if Bob just sets a very long expiry, but then the expiry doesn't really help in solving the issues you mentioned. What we really want is a way for Bob to revoke his silent payment address. For this, I think building a wallet protocol on top of silent payments is a better path to explore. Additionally, expiration dates as proposed degrade the privacy of silent payments: any outside observer can conclude that all transactions mined at block height N or greater were not payments to any silent payment address with an expiry less than N. As I mentioned already, there may also be privacy and safety concerns with the user needing to regularly update their silent payment address expiration date.
Lastly, on the subject of expiration dates in general, your proposed solution is not enforceable: any wallet can just ignore the extra bytes and send to the address/xpub/static payment code, anyways. For expiration dates to be useful, I'd argue they need to be enforced by consensus (which I am not convinced is a good idea).
In summary, expiration dates are a separate problem, outside the scope of what BIP352 is trying to address. If we can work toward a more general solution, there is nothing preventing us from adding this to a future silent payments version, but even then, I'm still not convinced expiration dates for static payment codes is a good idea, for the reasons I mentioned above.
Cheers,
Josie
Sent with Proton Mail secure email.
------- Original Message -------
On Friday, August 4th, 2023 at 7:39 PM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> tl;dr: Wallets don't last forever. They are often compromised or lost. When
> this happens, the addresses generated from those wallets become a form of toxic
> data: funds sent to those addresses can be easily lost forever.
>
> All Bitcoin addresses have this problem. But at least existing Bitcoin
> addresses aren't supposed to be reused. Silent Payments are: the whole point is
> to have a single address that you can safely pay to multiple times, without
> privacy concerns. Failing to make Silent Payment addresses eventually expire in
> a reasonable amount of time is thus a particularly harmful mistake.
>
> Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
> the expiration date in terms of days after some epoch. 2^24 days is 45,000
> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180
> years. We'll be lucky if Bitcoin still exists in 180 years.
>
> Wallets should pick a reasonable default, eg 1 year, for newly created
> addresses. Attempts to pay an expired address should just fail with a simple
> "address expired". Lightning invoices are a good example here: while invoices
> does not require expiration from a technical point of view, they do expire for
> similar UX reasons as applies to silent payments.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - josibake at protonmail.com - 0x616516B8.asc
Type: application/pgp-keys
Size: 3154 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230806/edd207c8/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 855 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230806/edd207c8/attachment-0001.sig>

2023-08-03 17:31:03

- reply

📅 Original date posted:2023-08-03
🗒️ Summary of this message: The BIP for Silent Payments has undergone several revisions, including changes to key sizes and a versioning scheme for addresses. Bitcoin Core implementation has been updated.
📝 Original message:
Hi all,
Since first posting the BIP for Silent Payments back in June, we've gone through several rounds of review and revision (a big thanks to everyone who has reviewed so far!). We've also updated the BIP with a python reference implementation and wallet test vectors. To summarize a few of the major changes:
- Use 33-byte compressed keys instead of 32-byte x-only keys, except when creating the outputs
- Negate the private key if necessary when spending taproot outputs
- If the receiving wallet uses labels, add a step to also check the negated output
- Add a versioning scheme for silent payment addresses
For those interested, the implementation for Bitcoin Core has been updated to reflect these changes here: https://github.com/bitcoin/bitcoin/pull/27827 . For convenience, and in the hopes of soliciting another round of review, the full specification is posted below and the full text of the BIP including the overview, test vectors and appendix on light client support can be found here: https://github.com/bitcoin/bips/pull/1458).
Cheers!
-- Ruben, Josie
== Specification ==
--------------------
We use the following functions and conventions:
- outpoint (36 bytes): the COutPoint of an input (32-byte txid, least significant byte first || 4-byte vout, least significant byte first)[6]
- sortoutpoints(v): sorts a vector v of outpoints in ascending order by doing a byte by byte comparison lexicographically.
- ser32(i): serializes a 32-bit unsigned integer i as a 4-byte sequence, most significant byte first.
- ser256(p): serializes the integer p as a 32-byte sequence, most significant byte first.
- serP(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1's compressed form: (0x02 or 0x03) || ser256(x), where the header byte depends on the parity of the omitted y coordinate.
For everything not defined above, we use the notation from BIP340.
### === Versions ===
This document defines Silent Payments v0. Version is communicated through the address in the same way as Segwit addresses. Future upgrades to silent payments will require a new version. As much as possible, future upgrades should support receiving from older wallets (e.g. a silent payments v0 wallet can send to both v0 and v1 addresses). Any changes that break compatibility with older silent payment versions should be a new BIP.
Future Silent Payments versions will use the following versioning scheme:
0
1
2
3
4
5
6
7
Compatibility
+0
q
p
z
r
y
9
x
8
backwards compatible
+8
g
f
2
t
v
d
w
0
+16
s
3
j
n
5
4
k
h
+24
c
e
6
m
u
a
7
-
v31 (l) is reserved for a backwards incompatible change, if needed. For Silent Payments v0:
- If the receiver's silent payment address version is:
- v0: check that the data part is exactly 66-bytes. Otherwise, fail
- v1 through v30: read the first 66-bytes of the data part and discard the remaining bytes (if any)
- v31: fail
- Receiver addresses are always BIP341 taproot outputs[7]
- The sender should sign with one of the sighash flags DEFAULT, ALL, SINGLE, NONE (ANYONECANPAY is unsafe). It is strongly recommended implementations use SIGHASH_DEFAULT when applicable, or SIGHASH_ALL[8]
- Inputs used to derive the shared secret are from the Inputs For Shared Secret Derivation list
### === Scanning transactions ===
A transaction is a Silent Payments v0 transaction and MUST be scanned if and only if all of the following are true:
- The transaction contains at least one BIP341 taproot output
- The transaction has at least one input from the Inputs For Shared Secret Derivation list
- The transaction does not spend a new, undefined output type (e.g. SegWit versions > 1)[9]
Otherwise, skip the transaction. This is to ensure forward compatibility with future versions of silent payments without requiring future versions to scan a transaction multiple times with different rule sets.
### === Address encoding ===
A silent payment address is constructed in the following manner:
- Let Bscan, bscan = Receiver's scan public key and corresponding private key
- Let Bspend, bspend = Receiver's spend public key and corresponding private key
- Let Bm = Bspend + m·G, where m an optional integer tweak for labeling
- In the case of m = 0, no label is applied and Bm = Bspend
- The final address is a Bech32m encoding of:
- The human-readable part "sp" for mainnet, "tsp" for testnets (e.g. signet, testnet)
- The data-part values:
- The character "q", to represent a silent payment address of version 0
- The 66 byte concatenation of the receiver's public keys, serP(Bscan) || serP(Bm)
Note: BIP173 imposes a 90 character limit for Bech32 strings, whereas a silent payment address requires at least 117 characters[10]. Additionally, since higher versions may add to the data field, it is recommended implementations use a limit of 1023 characters (see BIP173: Checksum design for more details).
### === Outpoints hash ===
The sender and receiver MUST calculate an outpoints hash for the transaction in the following manner:
- Collect each outpoint used as an input to the transaction
- Sort the outpoints with sortoutpoints(outpoints)[11]
- Let outpoints = outpoint0 || … || outpointn
- Let outpoints_hash = sha256(outpoints)
### === Inputs For Shared Secret Derivation ===
While any UTXO with known output scripts can be used to fund the transaction, the sender and receiver MUST use inputs from the following list when deriving the shared secret:
- P2TR
- P2WPKH
- P2SH-P2WPKH
- P2PKH
Inputs with conditional branches or multiple public keys (e.g. CHECKMULTISIG) are not included as this introduces malleability and would allow a sender to re-sign with a different set of public keys after the silent payment output has been derived. This is not a concern when the sender controls all of the inputs, but is an issue for CoinJoins and other collaborative protocols, where a malicious participant can participate in deriving the silent payment address with one set of keys and then re-broadcast the transaction with signatures for a different set of public keys. P2TR can have hidden conditional branches (script path), but we work around this as described below.
==== P2TR ====
The sender MUST use the private key corresponding to the taproot output key (i.e. the tweaked private key for a key path spend). This can be a single private key or an aggregate key (e.g. taproot outputs using MuSig2 or FROST)[12]. If this key is not available, the output cannot be included as an input to the transaction. The receiver always uses the taproot output key when scanning, regardless of whether the taproot output is using a key path spend or a script path spend[13].
The one exception is script path spends that use NUMS point H as their internal key (where H = lift_x(0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0) which is constructed by taking the hash of the standard uncompressed encoding of the secp256k1 base point G as X coordinate, see BIP341: Constructing and spending Taproot outputs for more details), in which case the output will be skipped for the purposes of shared secret derivation[14].
==== P2WPKH ====
The sender performs the tweak using the private key for the output and the receiver obtains the public key from the witness.
==== P2SH-P2WPKH ====
The sender performs the tweak using the private key for the nested P2WPKH output and the receiver obtains the public key from the witness.
==== P2PKH ====
The sender performs the tweak using the private key for the output and SHOULD sign using the standard script template:
scriptSig: <Signature> <Public Key>
The receiver obtains the public key from the scriptSig. The receiver MUST parse the scriptSig for the public key, even if the scriptSig is non-standard (e.g. <dummy> OP_DROP <Signature> <Public Key>). This is to address the third-party malleability of P2PKH scriptSigs.
### === Sender ===
#### ==== Selecting inputs ====
The sending wallet performs coin selection as usual with the following restrictions:
- At least one input MUST be from the Inputs For Shared Secret Derivation list
- Exclude inputs with witness version > 1 (see Scanning transactions)
- For each taproot output spent the sending wallet MUST have access to the private key corresponding to the taproot output key, unless H is used as the internal public key
#### ==== Creating outputs ====
After the inputs have been selected, the sender can create one or more outputs for one or more silent payment addresses in the following manner:
- Collect the private keys for each input from the Inputs For Shared Secret Derivation list
- For each private key ai corresponding to a BIP341 taproot output, check that the private key produces a point with an even y-value and negate the private key if not[15]
- Let a = a0 + a1 + … an, where each ai has been negated if necessary
- Generate the outpoints_hash, using the method described above
- Group receiver silent payment addresses by Bscan (e.g. each group consists of one Bscan and one or more Bm)
- For each group:
- Let ecdh_shared_secret = outpoints_hash·a·Bscan
- Let n = 0
- For each Bm in the group:
- Let tn = sha256(serP(ecdh_shared_secret) || ser32(n))
- Let Pmn = Bm + tn·G
- Encode Pmn as a BIP341 taproot output
- Optionally, repeat with n++ to create additional outputs for the current Bm
- If no additional outputs are required, continue to the next Bm with n++[16]
- Optionally, if the sending wallet implements receiving silent payments, it can create change outputs in the following manner:
- Let Achange = Aspend + sha256(ser256(ascan))·G
- Let change_shared_secret = outpoints_hash·a·Ascan
- Let n = 0
- For each change output desired:
- Let cn = sha256(serP(change_shared_secret) || ser32(n))
- Let Cn = Achange + cn·G
- Encode Cn as a BIP341 taproot output
- Repeat with n++ for additional change outputs
### === Receiver ===
#### ==== Key Derivation ====
Two keys are needed to create a silent payments address: the spend key and the scan key. While these keys can be generated independently, wallet software SHOULD use BIP32 derivation[17] to ensure compatibility across wallets.
A scan and spend key pair using BIP32 derivation are defined (taking inspiration from BIP44) in the following manner:
Scan private key: m / purpose' / coin_type' / account' / 1' / 0
Spend private key: m / purpose' / coin_type' / account' / 0' / 0
Wallet software MUST use hardened derivation to ensure the master key is not exposed in the event the scan private key is compromised. Purpose is a constant set to 352 following the BIP43 recommendation. Refer to BIP43 and BIP44 for more details.
#### ==== Scanning ====
If each of the checks in Scanning transactions passes, the receiving wallet must:
- Generate the outpoints_hash, using the method described above
- Let A = A0 + A1 + … An, where each Ai is the public key of an input from the Inputs For Shared Secret Derivation list
- Let ecdh_shared_secret = outpoints_hash·bscan·A
- Check for outputs:
- Let outputs_to_check = the taproot output key from each unspent taproot output in the transaction
- Starting with n = 0:
- Let tn = sha256(serP(ecdh_shared_secret) || ser32(n))
- Compute Pn = Bspend + tn·G
- For each output in outputs_to_check:
- If Pn equals output:
- Add Pn to the wallet
- Remove output from outputs_to_check and rescan outputs_to_check with n++
- Else, if the wallet has precomputed labels (including the change label, if used)[18]:
- Compute m·G = output - Pn
- Check if m·G exists in the list of labels used by the wallet
- If a match is found:
- Add the Pn + m·G to the wallet
- Remove output from outputs_to_check and rescan outputs_to_check with n++
- If the label is not found, negate output and check again
- If no matches are found, stop
#### ==== Backup and Recovery ====
Since each silent payment output address is derived independently, regular backups are recommended. When recovering from a backup, the wallet will need to scan since the last backup to detect new payments.
If using a seed/seed phrase only style backup, the user can recover the wallet's unspent outputs from the UTXO set (i.e. only scanning transactions with at least one unspent taproot output) and can recover the full wallet history by scanning the blockchain starting from the wallet birthday. If a wallet uses labels or generates its change addresses using the change label, this information SHOULD be included in the backup. If the user does not know whether labels or the change label were used, it is strongly recommended they always check for the change label when recovering from backup and precompute a large number of labels (e.g. 100k labels) to use when re-scanning. This ensures that the wallet can recover all funds from only a seed/seed phrase backup.
== Backward Compatibility ==
-----------------------------
Silent payments introduces a new address format and protocol for sending and as such is not compatible with older wallet software or wallets which have not implemented the silent payments protocol.
== Rationale and References ==
-------------------------------
1. Why not use out-of-band notifications Out of band notifications (e.g. using something other than the Bitcoin blockchain) have been proposed as a way of addressing the privacy and cost concerns of using the Bitcoin blockchain as a messaging layer. This, however, simply moves the privacy and cost concerns somewhere else and increases the risk of losing money due to a notification not being reliably delivered, or even censored, and makes this notification data critical for backup to recover funds.
2. Why allow for more than one output? Allowing Alice to break her payment to Bob into multiple amounts opens up a number of privacy improving techniques for Alice, making the transaction look like a CoinJoin or better hiding the change amount by splitting both the payment and change outputs into multiple amounts. It also allows for Alice and Carol to both have their own unique output paying Bob in the event they are in a collaborative transaction and both paying Bob's silent payment address.
3. What about inputs without public keys? Inputs without public keys can still be spent in the transaction but are simply ignored in the Silent Payments protocol.
4. How does using all inputs help light clients? If Alice uses a random input for the tweak, Bob necessarily has to have access to and check all transaction inputs, which requires performing an ECC multiplication per input. If instead Alice performs the tweak with the sum of the input public keys, Bob only needs the summed 33 byte public key per transaction and only does one ECC multiplication per transaction. Bob can then use BIP158 block filters to determine if any of the outputs exist in a block and thus avoids downloading transactions which don't belong to him. It is still an open question as to how Bob can source the 32 bytes per transaction in a trustless manner, see Appendix A: Light Client Support for more details.
5. Why does using all inputs matter for CoinJoin? If Alice uses a random input to create the output for Bob, this necessarily reveals to Bob which input Alice has control of. If Alice is paying Bob as part of a CoinJoin, this would reveal which input belongs to her, degrading the anonymity set of the CoinJoin and giving Bob more information about Alice. If instead all inputs are used, Bob has no way of knowing which input(s) belong to Alice. This comes at the cost of increased complexity as the CoinJoin participants now need to coordinate to create the silent payment output and would need to use Blind-Diffie-Hellman to prevent the other participants from learning who Alice is paying.
6. Why are outpoints little-endian? Despite using big endian throughout the rest of the BIP, outpoints are sorted and hashed matching their transaction serialization, which is little-endian. This allows a wallet to parse a serialized transaction for use in silent payments without needing to re-order the bytes when compute the outpoint hash. Note: despite outpoints being stored and serialized as little-endian, the transaction hash (txid) is always displayed as big-endian.
7. Why only taproot outputs? Providing too much optionality for the protocol makes it difficult to implement and can be at odds with the goal of providing the best privacy. Limiting to taproot outputs helps simplify the implementation significantly while also putting users in the best eventual anonymity set.
8. Why recommend SIGHASH_[DEFAULT|ALL]? Since the output address for the receiver is derived from from the sum of the Inputs For Shared Secret Derivation public keys, the inputs must not change once the sender has signed the transaction. If the inputs are allowed to change after the fact, the receiver will not be able to calculate the shared secret needed to find and spend the output. It is currently an open question on how a future version of silent payments could be made to work with new sighash flags such as SIGHASH_GROUP and SIGHASH_ANYPREVOUT.
9. Why skip transactions that spend unknown output scripts? Skipping transactions that spend unknown output scripts allows us to have a clean upgrade path for Silent Payments by avoiding the need to scan the same transaction multiple times with different rule sets. If a fancy new output type is added in the future and Silent Payments v1 is released with support, we would want to avoid having to first scan the transaction with the silent payment v0 rules and then again with the silent payment v1 rules. Note: this restriction only applies to the inputs of a transaction.
10. Why do silent payment addresses need at least 117 characters? A silent payment address is a bech32m encoding comprised of the following parts:
- HRP [2-3]
- separator [1]
- version [1-2]
- payload, 66 bytes concatenated pubkeys [ceil(66*8/5)]
- checksum [6]
For a silent payments v0 address, this results in a 117 character address when using a 3 character HRP. Future versions of silent payment addresses may add to the payload, which is why a 1023 character limit is suggested.
11. Why are outpoints sorted before hashing? This way the silent payment otuput does not need to be recalculated if the wallet changes the order of inputs, e.g. at signing time or during an RBF bump.
12. Are key aggregation techniques like FROST and MuSig2 supported? Any taproot output able to do a key path spend is supported. While a full specification of how to do this securely is outside the scope of this BIP, in theory any offline key aggregation technique can be used, such as FROST or MuSig2. This would require participants to perform the ECDH step collaboratively e.g. ECDH = a0·Bscan + a1·Bscan + ... + at·Bscan and P = Bspend + hash(outpoints_hash·ECDH || 0)·G. Additionally, it may be necessary for the participants to provide a DLEQ proof to ensure they are not acting maliciously.
13. Why not skip all taproot script path spends? This causes malleability issues for CoinJoins. If the silent payments protocol skipped taproot script path spends, this would allow an attacker to join a CoinJoin round, participate in deriving the silent payment address using the tweaked private key for a key path spend, and then broadcast their own version of the transaction using the script path spend. If the receiver were to only consider key path spends, they would skip the attacker's script path spend input when deriving the shared secret and not be able to find the funds. Additionally, there may be scenarios where a sender has access to the key path private key but spends the output using the script path.
14. Why skip outputs with H as the internal taproot key? If use cases get popularized where the taproot key path cannot be used, these outputs can still be included without getting in the way of making a silent payment, provided they specifically use H as their internal taproot key.
15. Why do taproot private keys need to be checked? Recall from BIP340 that each x-only public key has two corresponding private keys, d and n - d. To maintain parity between sender and receiver, it is necessary to use the private key corresponding to the even y-value when performing the ECDH step since the receiver will assume the even y-value when summing the taproot x-only public keys.
16. Why not re-use tn? when paying different labels to the same receiver? If paying the same entity but to two separate labeled addresses in the same transaction without incrementing n, the two outputs would be Bspend + tn·G + i·G and Bspend + tn·G + j·G. The attacker could subtract the two values and observe that the distance between i and j is small. This would allow them to deduce that this transaction is a silent payment transaction and that a single entity received two outputs, but won't tell them who the entity is.
17. Why use BIP32 hardened derivation? Using BIP32 derivation allows users to add silent payments to an existing master seed. It also ensures that a user's silent payment funds are recoverable in any wallet which supports BIP32 derivation. Using hardened derivation ensures that it is safe to export the scan private key without exposing the master key or spend private key.
18. ^Why precompute labels? Precomputing the labels is not strictly necessary: a wallet could track the max number of labels it has used (call it M) and scan for labels by adding m·G to P0 for each label m up to M and comparing to the transaction outputs. This is more performant than precomputing the labels and checking via subtraction in cases where the number of eligible outputs exceeds the number of labels in use. In practice this will mainly apply to users that choose never to use labels, or users that use a single label for generating silent payment change outputs. If using a large number of labels, the wallet would need to add all possible labels to each output. This ends up being n·M additions, where n is the number of outputs in the transaction and M is the number of labels in the wallet. By precomputing the labels, the wallet only needs to compute m·G once when creating the labeled address and can determine if a label was used via a lookup, rather than adding each label to each output.
19. Data for Appendix A These numbers are based on data from January 2023 until June 2023 (the last 6 months of data at time time of writing). See Silent payments light client data for the full analysis.
Sent with Proton Mail secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230803/abfcf098/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - josibake at protonmail.com - 0x616516B8.asc
Type: application/pgp-keys
Size: 3154 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230803/abfcf098/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 855 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230803/abfcf098/attachment-0001.sig>

2023-08-03 17:31:03

- reply

2023-06-15 00:33:42

- reply

📅 Original date posted:2023-06-05
🗒️ Summary of this message: A Silent Payments BIP has been proposed to address the limitations of current payment protocols by eliminating the need for interaction and notifications, while protecting sender and receiver privacy. The protocol aims to blend in with other bitcoin transactions, avoid address reuse, and support payment labeling. Light client support is an area of open research.
📝 Original message:
Hi all,
After what has seemed like an eternity of refining and tweaking (pun intended) the original write-up proposed by Ruben Somsen back in March 2022, we'd like to submit a Silent Payments BIP for your consideration and review.
For convenience, the overview from the BIP is in plain text below. Please note: the overview is not the full specification; the full specification can be found at https://github.com/bitcoin/bips/pull/1458/files , along with a WIP implementation for Bitcoin Core at https://github.com/bitcoin/bitcoin/pull/27827 .
Looking forward to hearing your thoughts!
-- Ruben, Josie
== Silent Payments ==
Using a new address for each Bitcoin transaction is a crucial aspect of maintaining privacy. This often requires a secure interaction between sender and receiver so that the receiver can hand out a fresh address, a batch of fresh addresses, or a method for the sender to generate addresses on-demand, such as an xpub.
However, interaction is often infeasible and in many cases undesirable. To solve for this, various protocols have been proposed which use a static payment address and notifications sent via the blockchain. These protocols eliminate the need for interaction, but at the expense of increased costs for one-time payments and a noticeable footprint in the blockchain, potentially revealing metadata about the sender and receiver. Notification schemes also allow the receiver to link all payments from the same sender, compromising sender privacy.
This proposal aims to address the limitations of these current approaches by presenting a solution that eliminates the need for interaction, eliminates the need for notifications, and protects both sender and receiver privacy. These benefits come at the cost of requiring wallets to scan the blockchain in order to detect payments. This added requirement is generally feasible for full nodes but poses a challenge for light clients. While it is possible today to implement a privacy-preserving light client at the cost of increased bandwidth, light client support is considered an area of open research
== Goals ==
We aim to present a protocol which satisfies the following properties:
- No increase in the size or cost of transactions
- Resulting transactions blend in with other bitcoin transactions and can’t be distinguished
- Transactions can’t be linked to a silent payment address by an outside observer
- No sender-receiver interaction required
- No linking of multiple payments to the same sender
- Each silent payment goes to a unique address, avoiding accidental address reuse
- Supports payment labeling
- Uses existing seed phrase or descriptor methods for backup and recovery
- Separates scanning and spending responsibilities
- Compatible with other spending protocols, such as CoinJoin
- Light client/SPV wallet support
- Protocol is upgrade-able
== Overview ==
We first present an informal overview of the protocol. In what follows, uppercase letters represent public keys, lowercase letters represent private keys, || refers to byte concatenation, and G represents the generator point for secp256k1. Each section of the overview is incomplete on its own and is meant to build on the previous section in order to introduce and briefly explain each aspect of the protocol.
=== Simple case ===
Bob publishes a public key B as a silent payment address. Alice discovers Bob's silent payment address, selects a UTXO with private key a, public key A and creates a destination output P for Bob in the following manner:
- Let P = hash(a·B)·G + B
- Encode P as a BIP341 taproot output
Since a·B == b·A (Elliptic Curve Diffie-Hellman), Bob scans with his private key b by collecting the input public keys for each transaction with at least one unspent taproot output and performing the ECDH calculation until P is found (e.g. calculating P = hash(b·A)·G + B and seeing that P is present in the transaction outputs).
=== Creating more than one output ===
In order to allow Alice to create more than one output for Bob, we included an integer in the following manner:
- Let n = 0
- Let P0 = hash(a·B || n)·G + B
- For additional outputs:
- Increment n by one (n++)
- Let Pi = hash(a·B || n)·G + B
Bob detects this output the same as before by searching for P0 = hash(b·A || 0)·G + B. Once he detects the first output, he must:
- Check for P1 = hash(b·A || 1)·G + B
- If P1 is not found, stop
- If P1 is found, continue to check for P2 and so on until an additional output is not found
Since Bob will only perform these subsequent checks after a transaction with at least one output paying him is found, the increase to his overall scanning requirement is negligible.
=== Preventing address reuse ===
If Alice were to use a different UTXO from the same public key A for a subsequent payment to Bob, she would end up deriving the same destination P. To prevent this, Alice should include a hash of the outpoint in the following manner:
- Let outpoint_hash = hash(txid || vout)
- Let P0 = hash(outpoint_hash·a·B || 0)·G + B
Bob must include the same outpoint_hash when scanning.
=== Using all inputs ===
In our simplified example we have been referring to Alice’s transactions as having only one input A, but in reality a Bitcoin transaction can have many inputs. Instead of requiring Alice to pick a particular input and requiring Bob to check each input separately, we can instead require Alice to perform the tweak with the sum of the input public keys[3]. This significantly reduces Bob's scanning requirement, makes light client support more feasible[4], and protects Alice's privacy in collaborative transaction protocols such as CoinJoin[5].
Alice performs the tweak with the sum of her input private keys in the following manner:
- Let outpoints_hash = hash(txid0 || vout0 || … txidn || voutn)
- Let a = a0 + a1 … + an
- Let P0 = hash(outpoints_hash·a·B || 0)·G + B
=== Spend and Scan Key ===
Since Bob needs his private key b to check for incoming payments, this requires b to be exposed to an online device. To minimize the risks involved, Bob can instead publish an address of the form (Bscan, Bspend). This allows Bob to keep bspend in offline cold storage and perform the scanning with the public key Bspend and private key bscan. Alice performs the tweak using both of Bob’s public keys in the following manner:
- Let P0 = hash(outpoints_hash·a·Bscan || 0)·G + Bspend
Bob detects this payment by calculating P0 = hash(outpoints_hash·bscan·A)·G + Bspend with his online device and can spend from his cold storage signing device using (hash(outpoints_hash·bscan·A) + bspend) mod p as the private key.
=== Labels ===
For a single silent payment address of the form (Bscan, Bspend), Bob may wish to differentiate incoming payments. Naively, Bob could publish multiple silent payment addresses, but this would require him to scan for each one, which becomes prohibitively expensive. Instead, Bob can label his spend public key Bspend with an integer m in the following way:
- Let Bm = Bspend + m·G
- Publish (Bscan, B0), (Bscan, B1) …
Alice performs the tweak as before using one of the published (Bscan, Bm) pairs. Bob detects the labeled payment in the following manner:
- Let P0 = hash(outpoints_hash·bscan·A || 0)·G + Bspend
- Subtract P0 from each of the transaction outputs and check if the remainder matches any of the labels (1·G, 2·G ..) that the wallet has previously used
It is important to note that an outside observer can easily deduce that each published (Bscan, Bm) pair is owned by the same entity as each published address will have Bscan in common. As such, labels are not meant as a way for Bob to manage separate identities, but rather a way for Bob to determine the source of an incoming payment.
=== Labels for change ===
Bob can also use labels for managing his own change outputs. To do so, he can reserve a secret change label in the following manner:
- Let Bchange = Bspend + hash(bscan)·G
Now, whenever Bob is spending (to a silent payment address or otherwise), he can create a change output for himself using the silent payments protocol and his change label in the following manner:
- Let a = a0 + a1 … + an represent the private keys of the inputs Bob is using to fund the transaction
- Let Pchange = hash(outpoints_hash·a·Bchange || 0)·G + Bspend
This gives Bob an alternative to using BIP32 for managing change, while still allowing him to know which of his unspent outputs were change when recovering his wallet from the master key. The change label needs to remain a secret in order to ensure nobody else can label payments as change.
Sent with Proton Mail secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230605/d75c160e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - josibake at protonmail.com - 0x616516B8.asc
Type: application/pgp-keys
Size: 3154 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230605/d75c160e/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 855 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230605/d75c160e/attachment-0001.sig>

2023-06-07 23:20:23

- reply

📅 Original date posted:2023-04-21
🗒️ Summary of this message: A proposed BIP aims to establish a shared vocabulary for Bitcoin transactions, reducing confusion and cognitive load for developers and students.
📝 Original message:Big Concept ACK.
I've participated in several Bitcoin developer education programs over the past few years and have noticed that a consistent stumbling block for students is reconciling the different terms used in blogs, transcripts, mailing list posts, etc.
Having a reference document like this to include early in the curriculum(s) will help reduce cognitive load.
In particular, I'd like to highlight the importance of the "synonyms" field: since we can't retroactively re-write materials using different terms, having the synonyms will help map various resources to a shared terminology.
Thanks for working on this!
Cheers,
Josie
Sent with Proton Mail secure email.
------- Original Message -------
On Wednesday, April 5th, 2023 at 8:54 PM, Murch via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hey everyone,
>
> Over the years, I have participated in a few conversations about various
> aspects of transactions. Often a chunk of the conversation is spent on
> establishing a shared vocabulary. There are many competing terms—e.g. I
> can think of at least three additional terms that refer to `scriptPubKey`.
>
> I’ve drafted an informational BIP that proposes terminology for various
> components and aspects of transactions. As some established terms are
> already contradictory, the proposal does not aim for a perfectly
> consistent selection of terms, but rather just to establish a shared
> vocabulary to avoid confusion.
>
> Draft: https://github.com/Xekyo/bips/pull/1
>
> Please let me know whether you’d be interested in the creation of such a
> BIP.
>
> Cheers,
> Murch
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - josibake at protonmail.com - 0x616516B8.asc
Type: application/pgp-keys
Size: 3154 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230421/4f5c2878/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 855 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230421/4f5c2878/attachment.sig>