diff options
Diffstat (limited to 'bip-0037.mediawiki')
| -rw-r--r-- | bip-0037.mediawiki | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki index f1561be..77b917b 100644 --- a/bip-0037.mediawiki +++ b/bip-0037.mediawiki @@ -17,7 +17,7 @@ This document will not go into the details of how Bloom filters work and the rea As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode. -Today, [[Simplified_Payment_Verification|SPV]] clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network. +Today, [[https://bitcoin.org/en/developer-guide#simplified-payment-verification-spv|SPV]] clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network. ==Design rationale== @@ -124,7 +124,7 @@ To determine if a transaction matches the filter, the following algorithm is use # For each input, test each data element of the input script (note: input scripts only ever contain data elements). # Otherwise there is no match. -In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]]. +In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[https://en.bitcoin.it/wiki/Smart_Property|Smart property]]. The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition: |