summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorjosibake <josibake@protonmail.com>2024-07-09 17:06:31 +0200
committerjosibake <josibake@protonmail.com>2024-07-12 09:05:35 +0200
commit7a8bc14b80de79a6287a790337c5156c0891567c (patch)
treeab92326fbb0d09a2d5e945583a17ca42f693441c
parent0a78fc10bdc1c4fb009c6fdb58f011a123bad97b (diff)
downloadbips-7a8bc14b80de79a6287a790337c5156c0891567c.tar.xz
bip352: update appendix
Numbers from the appendix were slightly innaccurate and out of date. Update to mention non-dust UTXOs and update the numbers to reflect current usage. Considering the appendix is purely informational and the corrections here are minor, Ive left of adding a changelong entry.
-rw-r--r--bip-0352.mediawiki4
-rw-r--r--bip-0352/scan_data_downloader_per_month.pngbin54276 -> 169753 bytes
2 files changed, 2 insertions, 2 deletions
diff --git a/bip-0352.mediawiki b/bip-0352.mediawiki
index 483bed3..634e179 100644
--- a/bip-0352.mediawiki
+++ b/bip-0352.mediawiki
@@ -445,11 +445,11 @@ This distinction makes the problem for light clients more clear: light clients n
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 ===
-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]]
diff --git a/bip-0352/scan_data_downloader_per_month.png b/bip-0352/scan_data_downloader_per_month.png
index ffcd0dd..a672a91 100644
--- a/bip-0352/scan_data_downloader_per_month.png
+++ b/bip-0352/scan_data_downloader_per_month.png
Binary files differ