Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

[Aaron Voisine <voisine@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]

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>
>
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4566 bytes --]