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 0D81BB35 for ; Fri, 6 Jan 2017 07:07:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9AB3F10E for ; Fri, 6 Jan 2017 07:07:46 +0000 (UTC) Received: by mail-qk0-f173.google.com with SMTP id s140so44071220qke.0 for ; Thu, 05 Jan 2017 23:07:46 -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 :cc; bh=hmJ9/mID2ybsJrYKJ8t9VX6A6ZMNsno4LVNhyLFpGmk=; b=FJhT+fmtPqGgvIXsifIHPC7YXSKq9AzfUCi2PoiEx8IG/Z+LDvTOAIkPf0d/3YzGAV YjoTZsP/LpJ6Y1pFVul64D/aatcn57yIRCCDM99hvs4ciSx04FD9copwHAuHcr40QcKe 25xVrDct7zSxJEy3H+hYHh7P4z0K0pQ3dLW7M3GjIUk6kBQyoH6THPAMdkeBxmx4aCI6 xKWx6aPhtdPw1KBVpYeI8sBYPTNlTxZJLLwEatTmi9GeE1eKCoZ8MPBWl29j8OF37ZNP q0n1hx1AfS+V+yvusPpJbxQ8fpvyE2Apg5amwIWvOxAzehYEx5dlCP0o9IU4aLZM6IgL n5uA== 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:cc; bh=hmJ9/mID2ybsJrYKJ8t9VX6A6ZMNsno4LVNhyLFpGmk=; b=smUHz/qUdBVHs27cLm8dL+rKcwYkULC3A/MjHF3QafC8ArRll3nO0bIuYr0El7y7/E 1d74hD7DZmVDfmxA7r4w6afHctlHwEpuKN1svX5fMbGbokZRoxLFrGyyR3A9+ZradACn wU9RxFpB46aZF0JhTl5Vt+p0tahlzoEDQsAHBE6iwcO72CxHPrpWraeNhM6mU8v6pjqP NHqMN8VNtd+bciCLccWxk7M/Qm5dR6/f//zvKEQ+TMfWoUWBOkjoyPJnzNJwqBOM9DBL W8vWLikekt8cEH92VRLM2lixHjeCMExClxGWypHTSvUsSOLzxgJMMg0oaNsEayPMxP6a DRTw== X-Gm-Message-State: AIkVDXKHeexWVWzLXOq1lBJi2HAmfW6PZce7W64HQhFJT5NMtC+EDoR6qowS3CV0yQT3/2Wpx0aT+Cs8ZyVewQ== X-Received: by 10.55.112.65 with SMTP id l62mr84724217qkc.76.1483686465770; Thu, 05 Jan 2017 23:07:45 -0800 (PST) MIME-Version: 1.0 References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> <452d837c74b4746e781d8701c68b2205@cock.lu> In-Reply-To: <452d837c74b4746e781d8701c68b2205@cock.lu> From: Aaron Voisine Date: Fri, 06 Jan 2017 07:07:34 +0000 Message-ID: To: bfd@cock.lu Content-Type: multipart/alternative; boundary=001a114fe714c01e49054567ac22 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 Cc: Bitcoin Protocol Discussion 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: Fri, 06 Jan 2017 07:07:48 -0000 --001a114fe714c01e49054567ac22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Credit card transactions are simply an expample of a widely used payment system that has frequent fraud and chargebacks. The argument I'm making is that different people in different situations value speed and convenience over a known fraud risk. Instant zero confirmation transactions are extremely useful despite the risk in all kinds of real world situations. You can't substitute your own value judgements for everyone in every situation. Aaron On Thu, Jan 5, 2017 at 6:15 PM wrote: > 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 seed lookup has not been tampered with, > > the connection to the random node that you connect to has not been > > tampered with, and that the seed nor the node are attempting to > > manipulate you. > > > > The two scenarios aren=E2=80=99t even remotely comparable. > > > > > > On 2017-01-04 00:56, Aaron Voisine 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 > > > 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 la= ter > > >> =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 stabil= ity > > >> and > > >> > > >> (risk-)scaling =E2=80=93 we may want to recommend to scarify this feat= ure > > >> and =E2=80=93 > > >> > > >> in the same turn =E2=80=93 to use privacy-preserving BFD's. > > >> > > >> > > --001a114fe714c01e49054567ac22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Credit card transactions are simply an expample of a widely used payme= nt system that has frequent fraud and chargebacks. The argument I'm mak= ing is that different people in different situations value speed and conven= ience over a known fraud risk. Instant zero confirmation transactions are e= xtremely useful despite the risk in all kinds of real world situations. You= can't substitute your own value judgements for everyone in every situa= tion.

Aaron

On Thu, Jan 5, 2017 at 6:15 PM <b= fd@cock.lu> wrote:
With a c= redit card you have an institution worth billions of dollars

asserting that a payment has been made, with the option that i= t may be

retracted under special circumstances b= y the card issuer.



U= nconfirmed Bitcoin transactions with a SPV client has you trusting

that the un-authenticated DNS seed lookup has not been t= ampered with,

the connection to the random node = that you connect to has not been

tampered with, = and that the seed nor the node are attempting to
manipulate you.



The= two scenarios aren=E2=80=99t even remotely comparable.





On 2017-01-= 04 00:56, Aaron Voisine wrote:

> It's eas= y 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 receive= rs

> network is still minimal. Random node op= erators 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 belongin= g 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.<= br class=3D"gmail_msg">
> There are much juicier targets for an attac= ker with the ability to

> sybil attack the en= tire bitcoin p2p network.

>

> Aaron

>

> On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli <dev@jonassc= hnelli.ch>

> wrote:

>

>> Hi

>>

>>> Unconfirmed transacti= ons are incredibly important for real world

>= > use.

>>

&g= t;>> Merchants for instance are willing to accept credit card payment= s

>> 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 situ= ations. This cost is typically well above the fraud
=
>> risk.

>>

>>>

>>

>>> It's important to recognize that bitcoin serves a = wide variety of

>> use

>>

>>> cases with differe= nt profiles for time sensitivity and fraud risk.
>>

>>>
>>

>> I agree that unconfirmed tra= nsactions 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 la= rge scale fiasco, hurting Bitcoins reputation and trust

>> from

>>

>> merchants.

>>

>> Merchants using and trusting 0-conf SPV transac= tions (retrieved from

>>

>> random peers) is something we should **really eliminate*= * through

>>

&g= t;> education and by offering different solution.

>>

>> There are plenty, more sa= ne options. If you can't run your own

>&g= t; full-node

>>
>> as a merchant (trivial), maybe co-use a wallet-service with

>> centralized

>&= gt;

>> verification (maybe use two of them= ), I guess Copay would be one of

>>

>> those wallets (as an example). Use them in wa= tch-only mode.

>>
<= br>>> For end-users SPV software, I think it would be recommended to.= ..

>>

>> = ... disable unconfirmed transactions during SPV against random peers

>>

>> ... enabl= e unconfirmed transactions when using SPV against a trusted

>>

>> peer with preshare= d keys after BIP150

>>

>> ... if unconfirmed transactions are disabled, show how it = can be

>> enabled
<= br>>>

>> (how to run a full-node [in= a box, etc.])

>>
<= br>>> ... educate, inform users that a transaction with no confirmati= on

>> can be

&g= t;>

>> "stopped" or "red= irected" any time, also inform about the risks
=
>> during

>>

>> low-conf phase (1-5).

>><= br class=3D"gmail_msg">
>> I though see the point that it's ni= ce to make use of the "incoming

>>
>> funds..." feature in SPV wallets. Bu= t =E2=80=93 for the sake of stability

>> a= nd

>>

>> = (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.

>>

>> </jonas>

<= /blockquote>
--001a114fe714c01e49054567ac22--