BIP352: Update appendix #1633

pull josibake wants to merge 1 commits into bitcoin:master from josibake:update-bip352-appendix changing 2 files +2 −2
  1. josibake commented at 3:10 pm on July 9, 2024: member

    Numbers from the appendix were slightly innaccurate and out of date. Update to clarify unspent UTXOs always refers to non-dust UTXOs and update the numbers to reflect current usage of taproot (Jan 2023 to July 2024).

    Considering the appendix is purely informational and the corrections here are minor, I’ve opted to not add a changelog entry.

  2. in bip-0352.mediawiki:448 in d676849cc4 outdated
    444@@ -445,11 +445,11 @@ This distinction makes the problem for light clients more clear: light clients n
    445 
    446 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.
    447 
    448-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>.
    449+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 2–10 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>.
    


    jonatack commented at 3:57 pm on July 9, 2024:

    Assuming 4320 blocks/month, would 2-10 kB per block not be roughly more like 9-43 MB per month?

    0For 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 2–10 kB per block (9–43 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>.
    

    josibake commented at 8:54 am on July 10, 2024:
    30mb - 50mb is the range from the linked analysis, so I think it’s better to update the 2-10kb to 7-12kb

    josibake commented at 8:55 am on July 10, 2024:
    Done.
  3. jonatack commented at 4:06 pm on July 9, 2024: contributor
    Thanks for updating.
  4. josibake force-pushed on Jul 10, 2024
  5. in bip-0352.mediawiki:452 in 171dc5ef65 outdated
    449+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>.
    450 
    451 === Transaction cut-through ===
    452 
    453-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.
    454+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 which 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 current taproot adoption, a light client scanning once every 3 days would use roughly 30 MB per month.
    


    jonatack commented at 9:30 pm on July 11, 2024:
    • “Based on current taproot adoption” -> would it be good to describe what that level of adoption is? (and/or if this refers to a previous description)

    • s/which/that/

    0It 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 current taproot adoption, a light client scanning once every 3 days would use roughly 30 MB per month.
    

    josibake commented at 7:05 am on July 12, 2024:
    Fixed.
  6. jonatack commented at 9:45 pm on July 11, 2024: contributor
    LGTM modulo two comments
  7. jonatack added the label Proposed BIP modification on Jul 11, 2024
  8. 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.
    7a8bc14b80
  9. josibake force-pushed on Jul 12, 2024
  10. jonatack commented at 1:28 pm on July 12, 2024: contributor
    ACK 7a8bc14b80de79a6287a790337c5156c0891567c thanks!
  11. jonatack merged this on Jul 12, 2024
  12. jonatack closed this on Jul 12, 2024


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-09 06:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me