From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z6jtw-0000iO-6N for bitcoin-development@lists.sourceforge.net; Sun, 21 Jun 2015 18:23:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.178 as permitted sender) client-ip=209.85.216.178; envelope-from=voisine@gmail.com; helo=mail-qc0-f178.google.com; Received: from mail-qc0-f178.google.com ([209.85.216.178]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z6jtu-0002jE-Ki for bitcoin-development@lists.sourceforge.net; Sun, 21 Jun 2015 18:23:28 +0000 Received: by qcji3 with SMTP id i3so3135775qcj.1 for ; Sun, 21 Jun 2015 11:23:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.20.16 with SMTP id e16mr53904990qkh.71.1434911001198; Sun, 21 Jun 2015 11:23:21 -0700 (PDT) Received: by 10.140.91.37 with HTTP; Sun, 21 Jun 2015 11:23:20 -0700 (PDT) In-Reply-To: <70534C5D-8834-42B5-B495-FD9975E8FCF4@gmail.com> References: <20150619103959.GA32315@savin.petertodd.org> <04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com> <812d8353e66637ec182da31bc0a9aac1@riseup.net> <1727885.UUNByX4Jyd@crushinator> <83A7C606-B601-47D2-BE10-2A1412D97514@gmail.com> <8a49c53a032503eeca4f51cdef725fe1@riseup.net> <6d025db96e7aec4e6e47a76883a9a1e3@riseup.net> <70534C5D-8834-42B5-B495-FD9975E8FCF4@gmail.com> Date: Sun, 21 Jun 2015 11:23:20 -0700 Message-ID: From: Aaron Voisine To: Eric Lombrozo Content-Type: multipart/alternative; boundary=001a1144d25482c54605190b4018 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (voisine[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z6jtu-0002jE-Ki Cc: Bitcoin Dev , Justus Ranvier Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 18:23:28 -0000 --001a1144d25482c54605190b4018 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We should use relay and default tx selection rules to raise the cost of double spend attacks as far as it is easy and practical to do so. This increases the value of the bitcoin network by making it practical to use in more situations for more people. Merchants of course can't rely on them being cryptographically safe, but the safer they are, the more useful. The argument that since they can't be made perfectly safe, they should be as easy as possible to reverse so that merchants learn not to rely on them, is an incorrect one that reduces the usefulness and value of bitcoin. Merchants will learn very quickly what the costs of accepting bitcoin payments are, and the lower they are, the greater bitcoin merchant adoption will be. Aaron Voisine co-founder and CEO breadwallet.com On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo wrote: > One more thing I would like to add to this thread: I want to make it > unequivocally clear that I believe what is making double-spends easier ha= s > relatively little to do with the protocol and almost everything to do wit= h > poor software and poor security policy on the merchant end. Perhaps it > isn=E2=80=99t prudent to push out changes to the relay policy that make t= hese > exploits even easier right now - but we NEED to be applying some kind of > pressure on the merchant end to upgrade their stuff to be more resilient = so > that we have more room for changes on things like relay policy without > significant disruption to the network. > > - Eric Lombrozo > > > -------------------------------------------------------------------------= ----- > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a1144d25482c54605190b4018 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We should use relay and default tx selection rules to rais= e the cost of double spend attacks as far as it is easy and practical to do= so. This increases the value of the bitcoin network by making it practical= to use in more situations for more people. Merchants of course can't r= ely on them being cryptographically safe, but the safer they are, the more = useful.

The argument that since they can't be made p= erfectly safe, they should be as easy as possible to reverse so that mercha= nts learn not to rely on them, is an incorrect one that reduces the usefuln= ess and value of bitcoin. Merchants will learn very quickly what the costs = of accepting bitcoin payments are, and the lower they are, the greater bitc= oin merchant adoption will be.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombro= zo <elombrozo@gmail.com> wrote:
One more thing I would like to add to this thread: I want to make i= t unequivocally clear that I believe what is making double-spends easier ha= s relatively little to do with the protocol and almost everything to do wit= h poor software and poor security policy on the merchant end. Perhaps it is= n=E2=80=99t prudent to push out changes to the relay policy that make these= exploits even easier right now - but we NEED to be applying some kind of p= ressure on the merchant end to upgrade their stuff to be more resilient so = that we have more room for changes on things like relay policy without sign= ificant disruption to the network.

- Eric Lombrozo

---------------------------------------------------------= ---------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/= listinfo/bitcoin-development


--001a1144d25482c54605190b4018--