[Bitcoin-development] NODE_BLOOM service bit
BIP: https://github.com/petertodd/bips/blob/bip-node-bloom/bip-node-bloom.mediawiki Pull-req: https://github.com/bitcoin/bitcoin/pull/2900 Pretty simple really: service bit NODE_BLOOM is defined to allow nodes to advertise to their peers that they support bloom filters. The network protocol version number is also bumped. Recommended behavior for nodes that do not support bloom is to simply disconnect peers who send a filter* message anyway to let them quickly find another peer. Rational: Bloom filters are not always supported or appropriate. For instance no node implementation other than Bitcoin Core supports them, e.g btcd and obelisk. (which ironically implement this BIP already, modulo the version number bump) In the long term bloom filters will be obsoleted eventually as they have poor scaling properties - problematic with blocksize increases - and are incompatible with UTXO/TXO commitments, which will use prefix-based filtering instead. (already being implemented in electrum and obelisk) In the short term bloom filters have high IO loads, which have lead to DoS attacks, and are not an optimal use of resources for nodes which are IO constrained rather than bandwidth constrained. (common in VPS setups which could better help the network by serving full blocks) Adding NODE_BLOOM as a service bit now will save us some hassle later down the road, reflects what actual implementations do anyway, has been already deployed on Litecoin, Dogecoin, and a zillion other alts with no issues, (including SPV client support) and is a trivial patch. Gregory Maxwell: Please assign a BIP # -- 'peter'[:-1]@petertodd.org 49066dab2483c9e069656239f5782da204bd4995bd92c19f signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_BLOOM service bit
On Fri, Jun 06, 2014 at 10:48:52AM +0200, Adam Back wrote: Advertising NODE BLOOM as a service sounds good. But the critique of bloom filters, I am not so sure prefix filters are better. Prefix filters offer questionable privacy tradeoffs in my opinion. Same problem as with stealth address proposed use of prefixes. That's assuming you're doing the proposed prefix brute forcing - if you don't do that they have privacy equal or better than bloom filters, but with better scalability. In particular that better scalability lets you efficiently query multiple servers for blockchain data, only giving up info on a subset of the addresses in your wallet to each server. This can be a significant improvement to bloom filters if your attacker is running logging nodes to try to, say, deanonymize CoinJoin transactions. All for scalability, efficiency and decentralization but not ideally at the expense of nuking privacy. The effects on privacy are cumulative, and affect everyone not just the user. Same pattern of local decision, global effect as with reused addresses. Indeed. But again, remember that the existing systems suck too; prefix-brute forcing is a engineering tradeoff implementable with existing and well understood technology. Now if you want to come up with something better and write code, please do! I'm sure the math exists; what doesn't exist is robust and well tested code in multiple languages. Stealth addresses at least have been designed so that future blockchain filter upgrades can be added in a backwards compatible way. -- 'peter'[:-1]@petertodd.org 3a68ee16d702ca5dd5547fb4aead910a004747cb06241dd6 signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_BLOOM service bit
On Fri, Jun 6, 2014 at 1:48 AM, Adam Back a...@cypherspace.org wrote: Advertising NODE BLOOM as a service sounds good. But the critique of bloom filters, I am not so sure prefix filters are better. Prefix filters offer questionable privacy tradeoffs in my opinion. Same problem as with stealth address proposed use of prefixes. All for scalability, efficiency and decentralization but not ideally at the expense of nuking privacy. The effects on privacy are cumulative, and affect everyone not just the user. Same pattern of local decision, global effect as with reused addresses. The performance Bytecoin/Monero/Fantom/etc. systems that use ECDH addresses for all transactions seem to be suggesting that the prefixes aren't really needed. At least with current system rules doing the ECDH for each transaction seems pretty reasonable. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_BLOOM service bit
On Fri, Jun 06, 2014 at 02:03:29AM -0700, Gregory Maxwell wrote: On Fri, Jun 6, 2014 at 1:48 AM, Adam Back a...@cypherspace.org wrote: Advertising NODE BLOOM as a service sounds good. But the critique of bloom filters, I am not so sure prefix filters are better. Prefix filters offer questionable privacy tradeoffs in my opinion. Same problem as with stealth address proposed use of prefixes. All for scalability, efficiency and decentralization but not ideally at the expense of nuking privacy. The effects on privacy are cumulative, and affect everyone not just the user. Same pattern of local decision, global effect as with reused addresses. The performance Bytecoin/Monero/Fantom/etc. systems that use ECDH addresses for all transactions seem to be suggesting that the prefixes aren't really needed. At least with current system rules doing the ECDH for each transaction seems pretty reasonable. Yup. Obelisk's indexing is sufficiently fast that they hadn't even bothered making Dark Wallet store transaction information between sessions until recently. Prefix brute-forcing isn't yet implemented, although prefix filters is being implemented for lookups in general. (at the very least it gives the server operators some valuable plausible deniability) -- 'peter'[:-1]@petertodd.org 3a68ee16d702ca5dd5547fb4aead910a004747cb06241dd6 signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development