20

You are right that SPV as described in the Bitcoin paper does not explain how to discover payments to yourself, without downloading full blocks. My guess is that Satoshi either planned to develop this later, or that he assumed you'd just be told about payments to yourself (pay-to-IP, as existed next to pay-to-pubkeyhash as is used now). Practical ...


14

0.8 doesn't actually use the bloom filter feature, but it enables support for letting other nodes use it. 0.8 does download the entire chain.


11

It inevitably leaks information, but Bloom filters have a (controllable) false-positive rate. So a wallet client that is very concerned with privacy could make the false positive rate high enough so it becomes hard to distinguish which transactions the client was interested in.


7

There is a known but fairly undocumented method of drastically improving SPV filtering that happens to remove this as an issue entirely, but it comes at the cost of requiring a hard fork change to Bitcoin. Traditional BIP37 SPV For BIP37, a client sets bloom filters on their peers and sequentially downloads transactions and blocks, relying on the remote peer ...


6

If it helps https://gist.github.com/TOMOAKI12345/7e0aa1c6b8ace4a70ca6 Breadwallet source code is really good source to learn about the network protocol of SPV wallet.


6

I know it is an old question, but it deserves an updated answer. Since the introduction of BIP37 (=SPV with bloom filters) a number of serious privacy vulnerabilities have been discovered. By using SPV + address bloom filters you are exposing all the addresses of your wallet with every Blockchain surveillance company. The reason behind this near ...


5

I can imagine that an SPV node encodes the transaction(s) it's interested in, into a BF and sends it to full node. What I don't understand is that what does the full node do after that? The full node goes through every transaction on the blockchain. (Or, at least, every transaction that happened after the wallet was created.) It checks the following things ...


5

Electrum: No protection, the server you are connected to knows every address you own and will own in the future. If you use Tor your IP address is hidden, but the addresses are still associated. Bloom filters are not in use for this client. MultiBit In theory the bloom filter can be modified to include junk data to hide your addresses with loads of fake ...


5

Bloom filters are probabilistic, each attempted match you make with it has a specific chance of being a false positive. The rate of false positives is determined by the construction of the filter (how wide it is and how many elements have been added to it). A transaction either probably matches, or certainly doesn't match a given bloom filter. BIP37 does ...


4

Block fetching requests are also filtered, so the client requests every single block they missed out on seeing since the last time they were last online, sequentially. The client downloads all block headers from genesis up to the current head using getheaders, sets a filter on their peer with filterload, and then downloads filtered blocks with getdata until ...


4

This question has the answer. For the first question when an SPV client starts up and sets a bloom filter it will not receive any special messages from connected bitcoin nodes. The bloom filter will result in transaction broadcasts to the SPV being filtered. In answer to the second question an SPV client must still request ALL block headers and send a ...


4

Does the current release of BitcoinJ add both a public key and its hash value to its Bloom filters? If not, which release stopped it from occuring? Yes. The following code implements it: /** Inserts the given key and equivalent hashed form (for the address). */ public synchronized void insert(ECKey key) { insert(key.getPubKey()); insert(key....


4

I found out that SPV has no mempool, but although SPV client is participating in transaction verification. So, what happens when node verifies transaction? Is SPV client checking only owner's outgoing transactions? That depends on what you mean by "verification". SPV clients cannot and do not verify the validity of transactions themselves; they ...


3

Pruned peers do not have the full blockchain history and therefore have only limited value for SPV clients. With Bitcoin Core 0.16, pruned peers will announce their service via NODE_NETWORK_LIMITED (see BIP159). BIP159 is not a consensus change. This will allow SPV clients to connect to pruned peers. But, since they only signal for the last 288 blocks, SPV/...


3

Just found something in bitcoinj sourcecode: /** * The "getheaders" command is structurally identical to "getblocks", but has different meaning. On receiving this * message a Bitcoin node returns matching blocks up to the limit, but without the bodies. It is useful as an * optimization: when your wallet does not contain any keys created before a ...


3

From my experience, your solution is the MultiBit Wallet software - it should satisfy all your requirements: https://multibit.org/index.html I use it on a regular basis and found it satisfying, and also have the possibility of storing more than one wallet, you should give it a try. Cheers.


3

See this paper for a good discussion: On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients


2

The reason you pre-generate some forward keys is to avoid the situation you describe, if you only looked ahead one you risk missing a transaction in the current block (the order of the transactions in the block are unrelated to the order of your keys). The term "gap limit" refers to a parameter of non bloomfilter SPV clients which do look ups by querying ...


2

You don't! The SPV client security model depends on miner confirmations for security. From the Thin Client Security page of the Bitcoin Wiki: As Satoshi writes, "[the thin client] can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the ...


2

I don't see your desired trusted full node setup. But if you can control a the trusted full-nodes, you might consider using the REST getutxo command. It's more or less similar to a not implemented Bip64. In my opinion you don't need bloom filter for the getutxo command. Don't expose the REST/RPC interface to the public. Instead build a reverse proxy with ...


2

Bitcoin Core maintains an index of blocks and their locations on disk. When someone requests a block, it pulls the block from disk, and if they used BIP 37, it will run the block through the filter. The block index is required for normal node operation; there are no other indexes created. The only "index" like thing is the mempool, and that is maintained ...


2

https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki Upon receiving a filterload command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below. The flags control the update behaviour of the matching algorithm....


1

That is based on the minimum indexing required to run a full-node. A getdata msg to peers can only request TX resources in mempool (valid, unconfirmed). Not all full-nodes index confirmed transactions. UTXO and mempool tx are necessarily indexed for validation and tx propagation/block template creation respectively. Confirmed transaction are supplied as ...


1

A mobile connects to a node using rpc. Nodes don't connect each other using RPC. RPC is for node owners, and usually has a long password. The mobile then asks the node, to give him a set of transactions for a set of public keys. Not exactly. First of all, block headers have a part that's named "Merkle root" that allows clients to check if a transaction ...


1

They will not do so automatically. When a peer sets a bloom filter, the node will not do any additional work except note that there is a bloom filter set for a given peer and begin matching things against the filter. It will not go back in history to match historical data against the filter and then relaying everything that matches. Doing so would be ...


1

I assume you are talking about BIP 37 which uses bloom filters for SPV wallets. Currently there are no alternatives to BIP 37 for SPV wallets. However roasbeef is working on a proposal for client side filtering, which you can read about here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014474.html. Client side filtering is an ...


1

So I guess the answer is "Yes, nodes accept Bloom filters because filtering does not make existing DoS attacks any worse nor do they introduce any new DoS attacks."


1

The purpose of IBLT-based block transfer mechanism is reducing bandwidth (how much data is sent in total) and latency (how long it takes to transfer the block), and depending on which has the priority there are different solutions. If latency is of no concern at all, you would simply send a block header together with a list of (truncated) txids, and the ...


1

false positives addresses ... do not need to necessarily be on the blockchain You can think of bloom filter matching like a function. def matches(tx, filter): ... You could make a transactions that returns true for this function with a given filter, which also was not meant to return true for that transaction, so false positives can exist outside of ...


1

If a SPV client wants to monitor its wallet balance, it has to track both incoming funds - transactions with outputs containing the wallet public key hash (the bitcoin address), as well as the outgoing funds - transactions with inputs having the wallet public key in their signature script. (Of course the SPV client has to monitor all the pub keys / addresses ...


Only top voted, non community-wiki answers of a minimum length are eligible