BIP 0352 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/83a1afd985984862/bip-0352.mediawiki

2024-10-09T19:21:42Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/83a1afd985984862/bip-0352.mediawiki

← Older revision		Revision as of 19:21, 9 October 2024
Line 102:		Line 102:
	Alice performs the tweak with the sum of her input private keys in the following manner:		Alice performs the tweak with the sum of her input private keys in the following manner:

	* Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>''
	* Let ''input_hash = hash(outpoint<sub>L</sub> \|\| A)'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically<ref name="why_smallest_outpoint">'''Why use the lexicographically smallest outpoint for the hash?''' Recall that the purpose of including the input hash is so that the sender and receiver can both come up with a deterministic nonce that ensures that a unique address is generated each time, even when reusing the same scriptPubKey as an input. Choosing the smallest outpoint lexicographically satisifes this requirement, while also ensuring that the generated output is not dependent on the final ordering of inputs in the transaction. Using a single outpoint also works well with memory constrained devices (such as hardware signing devices) as it does not require the device to have the entire transaction in memory in order to generate the silent payment output.</ref>
	* Let ''a = a<sub>1</sub> + a<sub>2</sub> + ... + a<sub>n</sub>''		* Let ''a = a<sub>1</sub> + a<sub>2</sub> + ... + a<sub>n</sub>''
			* Let ''input_hash = hash(outpoint<sub>L</sub> \|\| (a·G))'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically<ref name="why_smallest_outpoint">'''Why use the lexicographically smallest outpoint for the hash?''' Recall that the purpose of including the input hash is so that the sender and receiver can both come up with a deterministic nonce that ensures that a unique address is generated each time, even when reusing the same scriptPubKey as an input. Choosing the smallest outpoint lexicographically satisfies this requirement, while also ensuring that the generated output is not dependent on the final ordering of inputs in the transaction. Using a single outpoint also works well with memory constrained devices (such as hardware signing devices) as it does not require the device to have the entire transaction in memory in order to generate the silent payment output.</ref>
	* Let ''P<sub>0</sub> = B + hash(input_hash·a·B \|\| 0)·G''		* Let ''P<sub>0</sub> = B + hash(input_hash·a·B \|\| 0)·G''

Line 283:		Line 282:

	The receiver obtains the public key from the ''scriptSig''. The receiver MUST parse the ''scriptSig'' for the public key, even if the ''scriptSig'' does not match the template specified (e.g. <code><dummy> OP_DROP <Signature> <Public Key></code>). This is to address the [https://en.bitcoin.it/wiki/Transaction_malleability third-party malleability of ''P2PKH'' ''scriptSigs''].		The receiver obtains the public key from the ''scriptSig''. The receiver MUST parse the ''scriptSig'' for the public key, even if the ''scriptSig'' does not match the template specified (e.g. <code><dummy> OP_DROP <Signature> <Public Key></code>). This is to address the [https://en.bitcoin.it/wiki/Transaction_malleability third-party malleability of ''P2PKH'' ''scriptSigs''].

	~~=== Input hash ===~~

	~~The sender and receiver MUST calculate an input hash for the transaction in the following manner:~~

	* Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>'', where each ''A<sub>i</sub>'' is the public key of an input from the ''[[#inputs-for-shared-secret-derivation\|Inputs For Shared Secret Derivation]]'' list<ref name="why_include_A"></ref>
	* Let ''input_hash = hash<sub>BIP0352/Inputs</sub>(outpoint<sub>L</sub> \|\| A)'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically by txid and vout used in the transaction<ref name="why_smallest_outpoint"></ref>

	=== Sender ===		=== Sender ===
Line 305:		Line 297:
	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:		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:

	* Generate the ''input_hash'' with the smallest outpoint lexicographically, using the method described above
	* Collect the private keys for each input from the ''[[#inputs-for-shared-secret-derivation\|Inputs For Shared Secret Derivation]]'' list		* Collect the private keys for each input from the ''[[#inputs-for-shared-secret-derivation\|Inputs For Shared Secret Derivation]]'' list
	* For each private key ''a<sub>i</sub>'' corresponding to a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output, check that the private key produces a point with an even Y coordinate and negate the private key if not<ref name="why_negate_taproot_private_keys">'''Why do taproot private keys need to be checked?''' Recall from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki 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 coordinate when performing the ECDH step since the receiver will assume the even Y coordinate when summing the taproot X-only public keys.</ref>		* For each private key ''a<sub>i</sub>'' corresponding to a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output, check that the private key produces a point with an even Y coordinate and negate the private key if not<ref name="why_negate_taproot_private_keys">'''Why do taproot private keys need to be checked?''' Recall from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki 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 coordinate when performing the ECDH step since the receiver will assume the even Y coordinate when summing the taproot X-only public keys.</ref>
	* Let ''a = a<sub>1</sub> + a<sub>2</sub> + ... + a<sub>n</sub>'', where each ''a<sub>i</sub>'' has been negated if necessary		* Let ''a = a<sub>1</sub> + a<sub>2</sub> + ... + a<sub>n</sub>'', where each ''a<sub>i</sub>'' has been negated if necessary
			** If ''a = 0'', fail
			* Let ''input_hash = hash<sub>BIP0352/Inputs</sub>(outpoint<sub>L</sub> \|\| A)'', where ''outpoint<sub>L</sub>'' is the smallest ''outpoint'' lexicographically used in the transaction<ref name="why_smallest_outpoint"></ref> and ''A = a·G''
	* Group receiver silent payment addresses by ''B<sub>scan</sub>'' (e.g. each group consists of one ''B<sub>scan</sub>'' and one or more ''B<sub>m</sub>'')		* Group receiver silent payment addresses by ''B<sub>scan</sub>'' (e.g. each group consists of one ''B<sub>scan</sub>'' and one or more ''B<sub>m</sub>'')
	* For each group:		* For each group:
Line 339:		Line 332:
	If each of the checks in ''[[#scanning-silent-payment-eligible-transactions\|Scanning silent payment eligible transactions]]'' passes, the receiving wallet must:		If each of the checks in ''[[#scanning-silent-payment-eligible-transactions\|Scanning silent payment eligible transactions]]'' passes, the receiving wallet must:

	* Generate the ''input_hash'' with the smallest outpoint lexicographically, using the method described above
	* Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>'', where each ''A<sub>i</sub>'' is the public key of an input from the ''[[#inputs-for-shared-secret-derivation\|Inputs For Shared Secret Derivation]]'' list		* Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>'', where each ''A<sub>i</sub>'' is the public key of an input from the ''[[#inputs-for-shared-secret-derivation\|Inputs For Shared Secret Derivation]]'' list
			** If ''A'' is the point at infinity, skip the transaction
			* Let ''input_hash = hash<sub>BIP0352/Inputs</sub>(outpoint<sub>L</sub> \|\| A)'', where ''outpoint<sub>L</sub>'' is the smallest ''outpoint'' lexicographically used in the transaction<ref name="why_smallest_outpoint"></ref>
	* Let ''ecdh_shared_secret = input_hash·b<sub>scan</sub>·A''		* Let ''ecdh_shared_secret = input_hash·b<sub>scan</sub>·A''
	* Check for outputs:		* Check for outputs:
Line 455:		Line 449:
	Recall that a silent payment eligible transaction follows [[#scanning-silent-payment-eligible-transactions\|certain conditions]] and should have at least one unspent taproot output. Full nodes (or any index server backed by a full node, such as electrum server) can build an index which collects all of the eligible public keys for a silent payments eligible transaction, sums them up, multiplies the sum by the ''input_hash'', and serves them to clients. This would be 33 bytes per silent payment eligible transaction.		Recall that a silent payment eligible transaction follows [[#scanning-silent-payment-eligible-transactions\|certain conditions]] and should have at least one unspent taproot output. Full nodes (or any index server backed by a full node, such as electrum server) can build an index which collects all of the eligible public keys for a silent payments eligible transaction, sums them up, multiplies the sum by the ''input_hash'', and serves them to clients. This would be 33 bytes per silent payment eligible transaction.

	For a typical bitcoin block of ~3500 txs, lets assume every transaction is a silent payments eligible transaction. This means a client would need to request ''33 bytes * 3500'' of data per block (roughly 100 kB per block). If a client were to request data for every block, this would amount to ~450 MB per month, assuming 100% taproot usage and all outputs remain unspent for > 1 month. As of today, these numbers are closer to ~~2–10~~ kB per block (~~10–50~~ MB per month)<ref name="appendix_data">''' Data for Appendix A ''' These numbers are based on data from January 2023 until ~~June 2023 (the last 6 months of data at the time of writing)~~. See [https://github.com/josibake/bitcoin-data-analysis/blob/main/notebooks/silent-payments-light-client-data.ipynb Silent payments light client data] for the full analysis.</ref>.		For a typical bitcoin block of ~3500 txs, lets assume every transaction is a silent payments eligible transaction. This means a client would need to request ''33 bytes * 3500'' of data per block (roughly 100 kB per block). If a client were to request data for every block, this would amount to ~450 MB per month, assuming 100% taproot usage and all non-dust outputs remain unspent for > 1 month. As of today, these numbers are closer to 7–12 kB per block (30–50 MB per month)<ref name="appendix_data">''' Data for Appendix A ''' These numbers are based on data from January 2023 until July 2024. See [https://github.com/josibake/bitcoin-data-analysis/blob/main/notebooks/silent-payments-light-client-data.ipynb Silent payments light client data] for the full analysis.</ref>.

	=== Transaction cut-through ===		=== Transaction cut-through ===

	It is unlikely a light client would need to scan every block and as such can take advantage of transaction cut-through, depending on how often they choose to scan for new blocks. Empirically, ~75% of transactions with at least one unspent taproot output will have spent all taproot UTXOs in ~~326~~ blocks or less<ref name="appendix_data"></ref>. This means a client ~~which~~ only scans once ~~every 3 days~~ could ''significantly'' cut down on the number of blocks and the number of transactions per block that they need to request by only asking for data on transactions that were created since their last scan and that still have at least one unspent taproot output as of the current block height~~. Assuming 100% taproot usage, a client that scans once a month would likely only need around 50 MB worth of data~~. Based on ~~current~~ taproot adoption, a light client scanning once every 3 days would use roughly ~~15 MB per month and a client scanning once per month would use less than 5~~ MB per month.		It is unlikely a light client would need to scan every block and as such can take advantage of transaction cut-through, depending on how often they choose to scan for new blocks. Empirically, ~75% of transactions with at least one non-dust unspent taproot output will have spent all non-dust taproot UTXOs in 150 blocks or less<ref name="appendix_data"></ref>. This means a client that only scans once per day could ''significantly'' cut down on the number of blocks and the number of transactions per block that they need to request by only asking for data on transactions that were created since their last scan and that still have at least one non-dust unspent taproot output as of the current block height. Based on taproot adoption as of July 2024, a light client scanning once every 3 days would use roughly 30 MB per month<ref name="appendix_data">.

	[[File:bip-0352/scan_data_downloader_per_month.png]]		[[File:bip-0352/scan_data_downloader_per_month.png]]
Line 487:		Line 481:
	Wallet designers can choose which tradeoffs they find appropriate. For example, a wallet could check the block filter to at least probabilistically confirm the likely existence of the UTXO, thus efficiently cutting down on spam. The payment could then be marked as unconfirmed until a scan is performed and the existence of the UTXO in accordance to the silent payment specification is verified.		Wallet designers can choose which tradeoffs they find appropriate. For example, a wallet could check the block filter to at least probabilistically confirm the likely existence of the UTXO, thus efficiently cutting down on spam. The payment could then be marked as unconfirmed until a scan is performed and the existence of the UTXO in accordance to the silent payment specification is verified.

			== Change Log ==

			To help implementers understand updates to this document, we attach a version number that resembles ''semantic versioning'' (<code>MAJOR.MINOR.PATCH</code>).
			The <code>MAJOR</code> version is incremented if changes to the BIP are introduced that are incompatible with prior versions.
			The <code>MINOR</code> version is incremented whenever the inputs or the output of an algorithm changes in a backward-compatible way or new backward-compatible functionality is added.
			The <code>PATCH</code> version is incremented for other changes that are noteworthy (bug fixes, test vectors, important clarifications, etc.).

			* '''1.0.1''' (2024-06-22):
			** Add steps to fail if private key sum is zero (for sender) or public key sum is point at infinity (for receiver), add corresponding test vectors.
			* '''1.0.0''' (2024-05-08):
			** Initial version, merged as BIP-352.

	== Acknowledgements ==		== Acknowledgements ==

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/9636d9c6831ff96a/bip-0352.mediawiki

2024-05-31T04:49:57Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/9636d9c6831ff96a/bip-0352.mediawiki

← Older revision		Revision as of 04:49, 31 May 2024
Line 455:		Line 455:
	Recall that a silent payment eligible transaction follows [[#scanning-silent-payment-eligible-transactions\|certain conditions]] and should have at least one unspent taproot output. Full nodes (or any index server backed by a full node, such as electrum server) can build an index which collects all of the eligible public keys for a silent payments eligible transaction, sums them up, multiplies the sum by the ''input_hash'', and serves them to clients. This would be 33 bytes per silent payment eligible transaction.		Recall that a silent payment eligible transaction follows [[#scanning-silent-payment-eligible-transactions\|certain conditions]] and should have at least one unspent taproot output. Full nodes (or any index server backed by a full node, such as electrum server) can build an index which collects all of the eligible public keys for a silent payments eligible transaction, sums them up, multiplies the sum by the ''input_hash'', and serves them to clients. This would be 33 bytes per silent payment eligible transaction.

	For a typical bitcoin block of ~3500 txs, lets assume every transaction is a silent payments eligible transaction. This means a client would need to request ''33 bytes * 3500'' of data per block (roughly 100 kB per block). If a client were to request data for every block, this would amount to ~450 MB per month, assuming 100% taproot usage and all outputs remain unspent for > 1 month. As of today, these numbers are closer to 2–10 kB per block (10–50 MB per month)<ref name="appendix_data">''' 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 [https://github.com/josibake/bitcoin-data-analysis/blob/main/notebooks/silent-payments-light-client-data.ipynb Silent payments light client data] for the full analysis.</ref>.		For a typical bitcoin block of ~3500 txs, lets assume every transaction is a silent payments eligible transaction. This means a client would need to request ''33 bytes * 3500'' of data per block (roughly 100 kB per block). If a client were to request data for every block, this would amount to ~450 MB per month, assuming 100% taproot usage and all outputs remain unspent for > 1 month. As of today, these numbers are closer to 2–10 kB per block (10–50 MB per month)<ref name="appendix_data">''' Data for Appendix A ''' These numbers are based on data from January 2023 until June 2023 (the last 6 months of data at the time of writing). See [https://github.com/josibake/bitcoin-data-analysis/blob/main/notebooks/silent-payments-light-client-data.ipynb Silent payments light client data] for the full analysis.</ref>.

	=== Transaction cut-through ===		=== Transaction cut-through ===

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/bc87508a0c0a9ce8/bip-0352.mediawiki

2024-05-13T17:05:23Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/bc87508a0c0a9ce8/bip-0352.mediawiki

← Older revision		Revision as of 17:05, 13 May 2024
Line 490:		Line 490:
	== Acknowledgements ==		== Acknowledgements ==

	This document is the result of many discussions and contains contributions by a number of people. The authors wish to thank all those who provided valuable feedback and reviews, including the participants of the [https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae BIP47 Prague discussion], the [https://github.com/josibake/silent-payments-workshop Advancing Bitcoin silent payments Workshop], and [https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-26-silent-payments/ coredev]. The authors would like to also thank [https://github.com/w0xlt w0xlt] for writing the initial implementation of silent payments.		This document is the result of many discussions and contains contributions by a number of people. The authors wish to thank all those who provided valuable feedback and reviews, including the participants of the [https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae BIP47 Prague discussion], the [https://github.com/josibake/silent-payments-workshop Advancing Bitcoin silent payments Workshop], and [https://btctranscripts.com/bitcoin-core-dev-tech/2023-04/2023-04-26-silent-payments/ coredev]. The authors would like to also thank [https://github.com/w0xlt w0xlt] for writing the initial implementation of silent payments.

	== Rationale and References ==		== Rationale and References ==
	<references/>		<references/>

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/d2300bed3335f578/bip-0352.mediawiki

2024-05-08T18:05:03Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/d2300bed3335f578/bip-0352.mediawiki

Show changes