From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A7D487A for ; Wed, 4 Jan 2017 08:56:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9484CCD for ; Wed, 4 Jan 2017 08:56:32 +0000 (UTC) Received: by mail-qk0-f172.google.com with SMTP id a20so5039761qkc.1 for ; Wed, 04 Jan 2017 00:56:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=L/xVMFJb+ljppAupkmweCOkFrerEBnmyqAyZU+CYdSY=; b=NYoCx5MBJg6OAmLIW9hBVgN3jP/voRynECKt5zYo0Q9tD/Qfcs1CCFie/eymOiT/3Q 4xHQTzmRPGYwMzBGBFJIOaZvG//p/Qsyaf0Db5a0tmqU9EuX/hTDeayeobV2XVnxHinh 5LFB+vYX+E9JuaCIDvRY9KntjBln7d2rRK0ck/f8jd1EIk1OWF4Sa0rfXLbkPt6paxL3 NAuBqjktrdUHhMKgkztGl3n58gdQgBJzDm3Mryp7r+zMsV2+0HmMs1kM3i3mPj8znLEb EvKT6uzC09xXcyMxVtXcs/qWwNpSxqyT1VMuA2O49y7YW0WwjgBNf/mbz3N7fOB+7sPC mLtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=L/xVMFJb+ljppAupkmweCOkFrerEBnmyqAyZU+CYdSY=; b=uW6O4Ynp71SAAR+b9KZogDJ19SIraD4rv3jFiuHBX/sSVZiS8tXZIsNtCX4Zx47BMl x4RJFyMI6JiCgNmELP9hZVDmmNo/RZPPgZxLy1RR+nwD155DAuW/ZxL4OeH3EWQaX2Td CE1Z9yOlUHJ0p5fSBl7+0mQrOQhp3hAV+1D+VgRh42F8zg6nzOvJ5Kb0hDYDLJf1jeim zQw0vvkJ8IJFNF0fq9XOF6M2kGLEk7n34i+9F+4C7enb3lkDZPTR4uRpmQ5A1mOCQKp6 c5j39StdGf5SFqb5vhhfmWf3FUPCgkEe9GQu7e357l+UONz1mC+/S/ojOUOtIoX4A+di d5hw== X-Gm-Message-State: AIkVDXIpJ2uuFYv8Y5Ps7oIfYTGnVfx0s+o+hzfnF7Tvwmclve5NwDJ00H+kvHqvB0FgCSmHOO+5kU76o7CRUQ== X-Received: by 10.55.93.131 with SMTP id r125mr64744760qkb.258.1483520191740; Wed, 04 Jan 2017 00:56:31 -0800 (PST) MIME-Version: 1.0 References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> In-Reply-To: From: Aaron Voisine Date: Wed, 04 Jan 2017 08:56:21 +0000 Message-ID: To: Bitcoin Protocol Discussion , Jonas Schnelli , bfd@cock.lu Content-Type: multipart/alternative; boundary=001a114e6ace0bcbd3054540f636 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 08:56:33 -0000 --001a114e6ace0bcbd3054540f636 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 =E2=80=93 sooner or later= =E2=80=93 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 =E2=80=93 for the sake of stability= and > > (risk-)scaling =E2=80=93 we may want to recommend to scarify this feature= and =E2=80=93 > > in the same turn =E2=80=93 to use privacy-preserving BFD's. > > > > > > > > > > --001a114e6ace0bcbd3054540f636 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's easy enough to mark a transaction as "pending". Peo= ple with bank accounts are familiar with the concept.

<= div>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 tran= sactions, and would need to control all the nodes a client connects to, and= find a non-false-positive address belonging to the victims wallet.=C2=A0

It's not impossible, but it's non trivial, = would only temporarily show a pending transaction, and provide no benefit t= o the node operator. There are much juicier targets for an attacker with th= e 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:



> Unconfirme= d transactions are incredibly important for real world use.

> Merchants for instance are willing to accept credit card p= ayments of

> thousands of dollars and ship th= e goods despite the fact that the

> transacti= on 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 s= erves a wide variety of use

> cases with diff= erent profiles for time sensitivity and fraud risk.
=
>

I agree that unconfirmed transactions a= re incredibly important, but not

over SPV agains= t random peers.



If y= ou offer users/merchants a feature (SPV 0-conf against random

peers), that is fundamentally insecure, it will =E2=80=93 soo= ner or later =E2=80=93 lead

to some large scale = fiasco, hurting Bitcoins reputation and trust from
<= br>merchants.



Mercha= nts using and trusting 0-conf SPV transactions (retrieved from

random peers) is something we should **really eliminate** th= rough

education and by offering different soluti= on.



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 ce= ntralized

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 recom= mended to...

... disable unconfirmed transaction= s during SPV against random peers

... enable unc= onfirmed 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 confir= mation can be

"stopped" or "redir= ected" 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 &qu= ot;incoming

funds..." feature in SPV wallet= s. But =E2=80=93 for the sake of stability and

(= risk-)scaling =E2=80=93 we may want to recommend to scarify this feature an= d =E2=80=93

in the same turn =E2=80=93 to use pr= ivacy-preserving BFD's.



</jonas>


<= br>

--001a114e6ace0bcbd3054540f636--