Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YLx5V-00054f-Sw for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 16:58:01 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.176 as permitted sender) client-ip=209.85.223.176; envelope-from=btcdrak@gmail.com; helo=mail-ie0-f176.google.com; Received: from mail-ie0-f176.google.com ([209.85.223.176]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YLx5U-0001kQ-Ql for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 16:58:01 +0000 Received: by iecar1 with SMTP id ar1so13347258iec.0 for ; Thu, 12 Feb 2015 08:57:55 -0800 (PST) X-Received: by 10.50.30.202 with SMTP id u10mr4955712igh.35.1423760275481; Thu, 12 Feb 2015 08:57:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.32.77 with HTTP; Thu, 12 Feb 2015 08:57:35 -0800 (PST) In-Reply-To: References: <20150212064719.GA6563@savin.petertodd.org> From: Btc Drak Date: Thu, 12 Feb 2015 16:57:35 +0000 Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7b874b2c772955050ee705b6 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HK_RANDOM_FROM From username looks random -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.6 HK_RANDOM_ENVFROM Envelope sender username looks random 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (btcdrak[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_OBFUSCATE_05_10 BODY: Message is 5% to 10% HTML obfuscation 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: 1YLx5U-0001kQ-Ql Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 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: Thu, 12 Feb 2015 16:58:02 -0000 --047d7b874b2c772955050ee705b6 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 12, 2015 at 3:15 PM, Mike Hearn wrote: > Peter argues that this is stable and makes unconfirmed transactions safe >> because a fraudster can buy something, walk out of the shop, and broadcast >> a double spend with a higher fee. But then the merchant can re-spend the >> original payment back to themselves with an *even* higher fee than that. >> Then the fraudster can re-spend their double spend with an *even* higher >> fee than that, and so on back and forth, until *all* the money has been >> spent to miner fees. Thus the merchant loses their goods but the fraudster >> has still "paid" in some sense because they don't get the money either. >> > > This argument makes no sense for two reasons. > > The first is that this setup means miners can steal arbitrary payments if > they work together with the sender of the money. The model assumes this > collaboration won't happen, but it will. Because no existing wallet has a > "double spend this" button, to make the scheme work the dishonest miners > must create and distribute such a wallet that implements the whole > scorched-earth protocol. At that point it's easy for miners to reward the > payment fraudster with some of the stolen money the merchant lost, meaning > it now makes sense for the fraudster to always do this. The situation isn't > stable at all. > > The second is that it incentivises competitors to engage in payment fraud > against each other. A big rich coffee shop chain that is facing competition > from a small, scrappy newcomer can simply walk into the new shop and buy > things, then trigger the "scorched earth". Even with no miner > collaboration, this means the big company is down the cost of the product > *but* so is the little company who lost everything. Whoever can outspend > the other wins. > I think that is a misdirection on your part. The point of replace-by-fee is to make 0-confirms reliably unreliable. Currently people can "get away" with 0-confirms but it's only because most people arent actively double spending, and when they do it is for higher value targets. Double spend attacks *are* happening a lot more frequently than is being admitted here, according to Peter from work with various clients. Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer. --047d7b874b2c772955050ee705b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 12, 2015 at 3:15 PM, Mike Hearn <mike@plan99.net> wrot= e:
Peter argues that this is stable and makes unconfirmed transactions = safe because a fraudster can buy something, walk out of the shop, and broad= cast a double spend with a higher fee. But then the merchant can re-spend t= he original payment back to themselves with an even=C2=A0higher fee = than that. Then the fraudster can re-spend their double spend with an ev= en=C2=A0higher fee than that, and so on back and forth, until all=C2=A0the money has been spent to miner fees. Thus the merchant loses thei= r goods but the fraudster has still "paid" in some sense because = they don't get the money either.

This argument makes no sense for two reasons.<= /div>

The first is that this setup means miners can stea= l arbitrary payments if they work together with the sender of the money. Th= e model assumes this collaboration won't happen, but it will. Because n= o existing wallet has a "double spend this" button, to make the s= cheme work the dishonest miners must create and distribute such a wallet th= at implements the whole scorched-earth protocol. At that point it's eas= y for miners to reward the payment fraudster with some of the stolen money = the merchant lost, meaning it now makes sense for the fraudster to always d= o this. The situation isn't stable at all.

The= second is that it incentivises competitors to engage in payment fraud agai= nst each other. A big rich coffee shop chain that is facing competition fro= m a small, scrappy newcomer can simply walk into the new shop and buy thing= s, then trigger the "scorched earth". Even with no miner collabor= ation, this means the big company is down the cost of the product but=C2=A0so is the little company who lost everything. Whoever can outspend t= he other wins.

I th= ink that is a misdirection on your part. The point of replace-by-fee is to = make 0-confirms reliably unreliable. Currently people can "get away&qu= ot; with 0-confirms but it's only because most people arent actively do= uble spending, and when they do it is for higher value targets. Double spen= d attacks are happening a lot more frequently than is being admitted= here, according to Peter from work with various clients.=C2=A0
<= br>
Like single address reuse, people have gotten used to somethi= ng which is bad. Generally accepting 0-conf is also a bad idea(tm) and inst= ant confirmation solutions should be sought elsewhere. There are already in= teresting solutions and concepts: greenaddress for example, and CHECKLOCKTI= MEVERIFY micropayment channels for example. Rather than supporting and prom= oting risky 0-confirms, we need to spend time on better alternative solutio= ns that will work for everyone and not during the honeymoon phase where att= ackers are fewer.

--047d7b874b2c772955050ee705b6--