Great questions.
- Currently working on technical BIP draft and implementation, hopefully
for ScalingBitcoin.org. Only the PDF is publicly available as of today.
- Yes, the initial deployment is in the same manner as size votes.
On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev
NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
which, nonetheless, provide filtered access to the data which they do have).
But is this useful without having decided on a way to signal which blocks
On 8/21/2015 3:06 PM, Peter Todd via bitcoin-dev wrote:
On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote:
Anyone have the best reference for the DoS issues?
Well actually, we can reference the DoS attacks that Bitcoin XT nodes
are undergoing right now - part of the attack is
NACK: stated rationales are invalid: both privacy and DoS (see below for
experimental data).
1 - Bloom filtering doesn't add privacy for node operators, it adds privacy
for lightweight wallets. And in fact, with a high FP rate it does do that.
Most users want both low bandwidth usage *and* query
See responses in line.
On Thu, Aug 20, 2015 at 8:28 PM, odinn via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A visualization I would like to see would include:
pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP
I'll just quote what I said on github:
Neither this pull nor the BIP has any stated intention of phasing out
bloom filtering support in the protocol. As much as I'd love to, I 100%
agree with @mikehearn here, that would break any ability of SPV clients
to operate on the P2P network (either as a
Its more of a statement of in the future, we expect things to happen
which would make this an interesting thing to do, so we state here that
it is not against spec to do so. Could reword it as NODE_BLOOM is
distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOOM but
not NODE_NETWORK
On Mon, Aug 24, 2015 at 06:15:39PM +, Eric Lombrozo via bitcoin-dev wrote:
It would be very useful to not only be able to switch filtering on and off
globally...but to be able to switch on a per-connection basis. But then
You don't necessarily need to send everyone the same nServices bits.
It would be very useful to not only be able to switch filtering on and off
globally...but to be able to switch on a per-connection basis. But then
again, perhaps it would be smarter to ditch the whole bloom filter thing in
favor of an actual client/server architecture with proper authentication
Indeed, so I don't really have a problem with this proposal.
On Mon, Aug 24, 2015, 11:30 AM Wladimir J. van der Laan laa...@gmail.com
wrote:
On Mon, Aug 24, 2015 at 06:15:39PM +, Eric Lombrozo via bitcoin-dev
wrote:
It would be very useful to not only be able to switch filtering on and
Your proposal also permanently burns a sequence bit. It depends on how
we value a nSequence bit and a nVersion bit. I think there is a
trade-off here:
1. nSequence is signed by each TxIn individually, while all TxIns must
share the same nVersion
2. If nVersion is used to indicate the
Also, the current type attribute needs modification. There are different
degrees of standard. Just because a lot of people do X doesn't need to
mean that doing X is officially endorsed by any other devs. At most
levels below 1, disagreements might be entirely tolerable for many things.
On Mon,
12 matches
Mail list logo
