Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YLw5y-0006Kt-Ve for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 15:54:27 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.170 as permitted sender) client-ip=209.85.212.170; envelope-from=natanael.l@gmail.com; helo=mail-wi0-f170.google.com; Received: from mail-wi0-f170.google.com ([209.85.212.170]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YLw5y-0004Ek-3B for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 15:54:26 +0000 Received: by mail-wi0-f170.google.com with SMTP id hi2so5987299wib.1 for ; Thu, 12 Feb 2015 07:54:20 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.91.199 with SMTP id cg7mr8848798wjb.114.1423756459986; Thu, 12 Feb 2015 07:54:19 -0800 (PST) Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 07:54:19 -0800 (PST) Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 07:54:19 -0800 (PST) In-Reply-To: References: <20150212064719.GA6563@savin.petertodd.org> Date: Thu, 12 Feb 2015 16:54:19 +0100 Message-ID: From: Natanael To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7bf0d8620b5934050ee62233 X-Spam-Score: -0.3 (/) 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 (natanael.l[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 0.3 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YLw5y-0004Ek-3B Cc: bitcoin-development@lists.sourceforge.net 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 15:54:27 -0000 --047d7bf0d8620b5934050ee62233 Content-Type: text/plain; charset=UTF-8 Den 12 feb 2015 16:42 skrev "Mike Hearn" : > Remember that you aren't paying the bad pool, the bad pool is paying you. Whichever pool benefits from the scorched earth protocol can simply pick an address out of the transaction it perceived as starting the protocol, and pay that. My counterargument: with zero-conf but no replace-by-fee scorched earth, there would instead be a market which thieves use where pools would offer to execute doublespends that pay the thief and the pool, and where the pools would set what terms and payouts they ask for. All bidding pools with acceptable terms get a doublespend transaction that pays that specific pool and the thief, the first to mine theirs win (and the merchant loses). Your protocol requires less setup, but that's the only notable difference (besides risk of paying non-participating pools with scorched earth). No notable difference in security for merchants. --047d7bf0d8620b5934050ee62233 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Den 12 feb 2015 16:42 skrev "Mike Hearn" <mike@plan99.net>:
> Remember that you aren't paying the bad pool, the bad pool is payi= ng you. Whichever pool benefits from the scorched earth protocol can simply= pick an address out of the transaction it perceived as starting the protoc= ol, and pay that.

My counterargument: with zero-conf but no replace-by-fee sco= rched earth, there would instead be a market which thieves use where pools = would offer to execute doublespends that pay the thief and the pool, and wh= ere the pools would set what terms and payouts they ask for.

All bidding pools with acceptable terms get a doublespend tr= ansaction that pays that specific pool and the thief, the first to mine the= irs win (and the merchant loses).

Your protocol requires less setup, but that's the only n= otable difference (besides risk of paying non-participating pools with scor= ched earth).

No notable difference in security for merchants.

--047d7bf0d8620b5934050ee62233--