public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: "Jorge Timón" <jtimon@jtimon.cc>,
	"Bitcoin Protocol Discussion"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security
Date: Wed, 4 Jan 2017 11:00:55 +0000	[thread overview]
Message-ID: <CALqxMTF__wPgEu9Ye5R2Aht1i2kR36TLeyzAa575dxaZy8Vycg@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDoT72nioQf9d+XFRAaJydWQqtWZ+WSQO99Dpn7HcTkfpw@mail.gmail.com>

I think this discussion started from the block bloom filter where
there is a bloom filter commitment in the block which can be
downloaded and is much smaller than the block.  An SPV node based on
that model would download headers and bloom filters, verify the bloom
filter is committed to, and test locally if any addresses managed by
the wallet are in the filter (or false positives for being in it), and
then download blocks with hits.  Apparently there are maybe 50% more
compact alternatives to bloom filters but people have been using bloom
filter as a short-hand for that.  The block bloom filter does seem to
have higher overhead than the query model, but it offers much better
privacy.  I think there was previous discussion about maybe doing
something with portions of blocks so you can know which half or
quarter of the block etc.

Adam


On 4 January 2017 at 10:13, Jorge Timón via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> There were talks about implementing spv mode for bitcoin core without using
> bloom filters. Less efficient because it downloads full blocks, but better
> for privacy. Perhaps other spv implementations should consider doing the
> same instead of committing the filters in the block?
>
> Now I feel I was missing something. I guess you can download the whole block
> you're interested in instead of only your txs and that gives you privacy.
> But how do you get to know which blocks are you interested in?
>
> If the questions are too basic or offtopic for the thread, I'm happy getting
> answers privately  (but then maybe I get them more than once).
>
>
> On 4 Jan 2017 09:57, "Aaron Voisine via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> It's easy enough to mark a transaction as "pending". People with bank
> accounts are familiar with the concept.
>
> Although the risk of accepting gossip information from multiple random
> peers, in the case where the sender does not control the receivers network
> is still minimal. Random node operators have no incentive to send fake
> transactions, and would need to control all the nodes a client connects to,
> and find a non-false-positive address belonging to the victims wallet.
>
> It's not impossible, but it's non trivial, would only temporarily show a
> pending transaction, and provide no benefit to the node operator. There are
> much juicier targets for an attacker with the ability to sybil attack the
> entire bitcoin p2p network.
>
> Aaron
>
> On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli <dev@jonasschnelli.ch> wrote:
>>
>> Hi
>>
>>
>>
>> > Unconfirmed transactions are incredibly important for real world use.
>>
>> > Merchants for instance are willing to accept credit card payments of
>>
>> > thousands of dollars and ship the goods despite the fact that the
>>
>> > transaction can be reversed up to 60 days later. There is a very large
>>
>> > cost to losing the ability to have instant transactions in many or
>>
>> > even most situations. This cost is typically well above the fraud risk.
>>
>> >
>>
>> > It's important to recognize that bitcoin serves a wide variety of use
>>
>> > cases with different profiles for time sensitivity and fraud risk.
>>
>> >
>>
>> I agree that unconfirmed transactions are incredibly important, but not
>>
>> over SPV against random peers.
>>
>>
>>
>> If you offer users/merchants a feature (SPV 0-conf against random
>>
>> peers), that is fundamentally insecure, it will – sooner or later – lead
>>
>> to some large scale fiasco, hurting Bitcoins reputation and trust from
>>
>> merchants.
>>
>>
>>
>> Merchants using and trusting 0-conf SPV transactions (retrieved from
>>
>> random peers) is something we should **really eliminate** through
>>
>> education and by offering different solution.
>>
>>
>>
>> There are plenty, more sane options. If you can't run your own full-node
>>
>> as a merchant (trivial), maybe co-use a wallet-service with centralized
>>
>> verification (maybe use two of them), I guess Copay would be one of
>>
>> those wallets (as an example). Use them in watch-only mode.
>>
>>
>>
>> For end-users SPV software, I think it would be recommended to...
>>
>> ... disable unconfirmed transactions during SPV against random peers
>>
>> ... enable unconfirmed transactions when using SPV against a trusted
>>
>> peer with preshared keys after BIP150
>>
>> ... if unconfirmed transactions are disabled, show how it can be enabled
>>
>> (how to run a full-node [in a box, etc.])
>>
>> ... educate, inform users that a transaction with no confirmation can be
>>
>> "stopped" or "redirected" any time, also inform about the risks during
>>
>> low-conf phase (1-5).
>>
>>
>>
>> I though see the point that it's nice to make use of the "incoming
>>
>> funds..." feature in SPV wallets. But – for the sake of stability and
>>
>> (risk-)scaling – we may want to recommend to scarify this feature and –
>>
>> in the same turn – to use privacy-preserving BFD's.
>>
>>
>>
>> </jonas>
>>
>>
>>
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


  reply	other threads:[~2017-01-04 11:00 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09  8:26 [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security bfd
2016-05-09  8:57 ` Gregory Maxwell
2016-05-11 20:06 ` Bob McElrath
2016-05-11 20:29   ` Bob McElrath
2016-07-28 21:07     ` Leo Wandersleb
2017-01-06 22:07       ` Erik Aronesty
2017-01-03 20:24     ` bfd
     [not found] ` <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
2017-01-03 20:18   ` bfd
2017-01-03 22:18     ` Aaron Voisine
2017-01-03 22:28       ` bfd
2017-01-03 23:06       ` adiabat
2017-01-03 23:46         ` Aaron Voisine
2017-01-04  0:10           ` bfd
2017-01-04  0:36             ` Aaron Voisine
2017-01-04  6:06               ` Eric Voskuil
2017-01-04 16:13         ` Leo Wandersleb
2017-01-04  7:47       ` Jonas Schnelli
2017-01-04  8:56         ` Aaron Voisine
2017-01-04 10:13           ` Jorge Timón
2017-01-04 11:00             ` Adam Back [this message]
2017-01-06  2:15           ` bfd
2017-01-06  7:07             ` Aaron Voisine
2017-01-05  7:06         ` Chris Priest
2017-01-05  7:45           ` Eric Voskuil
2017-01-05 14:48             ` Christian Decker
2017-01-06 20:15             ` Chris Priest
2017-01-06 21:35               ` James MacWhyte
2017-01-06 21:50                 ` Eric Voskuil
2017-01-06  2:04           ` bfd
2017-03-15 22:36             ` Tom Harding
2017-03-16  0:25               ` bfd
2017-03-16 15:05                 ` Tom Harding
2017-02-17  0:28 ` Chris Belcher
2017-04-01 23:49   ` bfd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALqxMTF__wPgEu9Ye5R2Aht1i2kR36TLeyzAa575dxaZy8Vycg@mail.gmail.com \
    --to=adam@cypherspace.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jtimon@jtimon.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox