[Bitcoin-development] NODE_BLOOM service bit

2014-06-06 Thread Peter Todd
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

2014-06-06 Thread Peter Todd
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

2014-06-06 Thread Gregory Maxwell
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

2014-06-06 Thread Peter Todd
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