On 2017-06-20 12:52, Tom Zander via bitcoin-dev wrote:
Second, stating that a bloom filter is a "total loss of privacy" is
equally
baseless and doesn’t need debunking.
"On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin
Clients"
We show analytically and empirically that the
Several times. It's been debated if unconfirmed transactions are
necessary, methods of doing more private filtering have been suggested,
along with simply not filtering unconfirmed transactions at all. My
collected data suggests that there is very little use of BIP37 at
present, based on incomi
On 2017-04-16 17:04, Erik Aronesty via bitcoin-dev wrote:
This is a great solution.
8 or more secure hashes, each of which can be implemented on GPU/CPU,
but rotate through them - per block round robin.
Hardware, infrastructue investment is protected. ASIC is not.
The write time for confi
Miners blocking SegWit due to ASICBOOST requirements also means they
would block future deployment of committed bloom filters.
On 2017-04-06 00:37, Gregory Maxwell via bitcoin-dev wrote:
A month ago I was explaining the attack on Bitcoin's SHA2 hashcash
which
is exploited by ASICBOOST and the
On 2017-02-17 11:28, Chris Belcher via bitcoin-dev wrote:
I think this committed bloom filter idea is very good and much better
than bip37, but for good privacy for when bitcoin is used often still
requires certain behavior namely downloading blocks
from many different peers with new tor circuits
If a wallet is unaware of spends of its own coins (ie, transactions
were made it can't have known about), there's probably bigger problems
going on. You might enjoy the topic on this mailing list on committed
bloom filters however, as this solves a similar issue without needing
an ever-growing lis
the security or privacy of BIP37
compare favorably to any other particular thing.
https://docs.google.com/presentation/d/13MzUo2iIH9JBW29TgtPMoaMXxeEdanWDfi6SlfO-LlA
On 1/5/2017 6:04 PM, bfd--- via bitcoin-dev wrote:
You might as well replace Bitcoin with a system where these parties
sign tra
I feel you're conflating social identifiability with technical
identifiability. Sure, a node operator must always be able to remain
anonymous, but nodes themselves require a certain level of
identifiability otherwise there would be no means to communicate
between them.
Nodes running through netw
Having a commitment to a "balance" of an "address" (I assume you mean
P2SH/P2PKH script) is extremely expensive to create and validate, does
not scale and is not a particularly useful thing for a client to use.
Validating clients should never expect their UTXO to be
inconsistent with that of the n
With a credit card you have an institution worth billions of dollars
asserting that a payment has been made, with the option that it may be
retracted under special circumstances by the card issuer.
Unconfirmed Bitcoin transactions with a SPV client has you trusting
that the un-authenticated DNS s
You might as well replace Bitcoin with a system where these parties
sign transactions and skip mining altogether, it would have the same
properties and be significantly more effient.
On 2017-01-04 23:06, Chris Priest wrote:
On 1/3/17, Jonas Schnelli via bitcoin-dev
wrote:
There are plenty, m
recognize that bitcoin serves a wide variety of
use cases with different profiles for time sensitivity and fraud
risk.
Aaron
On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev
wrote:
The concept combined with the weak blocks system where miners commit
to potential transaction inclusion wit
wide variety of use
cases with different profiles for time sensitivity and fraud risk.
Aaron
On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev
wrote:
The concept combined with the weak blocks system where miners commit
to potential transaction inclusion with fractional difficulty block
The concept combined with the weak blocks system where miners commit
to potential transaction inclusion with fractional difficulty blocks
is possible. I'm not personally convinced that unconfirmed transaction
display in a wallet is worth the privacy trade-off. The user has very
little to gain from
t's run some numbers...
bfd--- via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote:
> A Bloom Filter Digest is deterministically created of every block
Bloom filters completely obfuscate the required size of the filter for
a desired
false-positive rate. But, an optimal filter is linea
We introduce several concepts that rework the lightweight Bitcoin
client model in a manner which is secure, efficient and privacy
compatible.
Thea properties of BIP37 SPV [0] are unfortunately not as strong as
originally thought:
* The expected privacy of the probabilistic nature of bloom
16 matches
Mail list logo
