From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YbrGP-0005S9-GX for bitcoin-development@lists.sourceforge.net; Sat, 28 Mar 2015 13:59:01 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.179 as permitted sender) client-ip=209.85.212.179; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f179.google.com; Received: from mail-wi0-f179.google.com ([209.85.212.179]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YbrGN-0002c5-Tv for bitcoin-development@lists.sourceforge.net; Sat, 28 Mar 2015 13:59:01 +0000 Received: by wibbg6 with SMTP id bg6so55974964wib.0 for ; Sat, 28 Mar 2015 06:58:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.2.145 with SMTP id 17mr45563778wju.79.1427551133791; Sat, 28 Mar 2015 06:58:53 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.194.188.11 with HTTP; Sat, 28 Mar 2015 06:58:53 -0700 (PDT) Date: Sat, 28 Mar 2015 14:58:53 +0100 X-Google-Sender-Auth: 47veVFCP-f6lb7O9gwUg58zNGTc Message-ID: From: Mike Hearn To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7b3a896c3a7bfb051259a69e X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1YbrGN-0002c5-Tv Subject: [Bitcoin-development] Double spending and 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: Sat, 28 Mar 2015 13:59:01 -0000 --047d7b3a896c3a7bfb051259a69e Content-Type: text/plain; charset=UTF-8 I've written a couple of blog posts on replace by fee and double spending mitigations. They sum up the last few years (!) worth of discussions on this list and elsewhere, from my own perspective. I make no claim to be comprehensive or unbiased but I keep being asked about these topics so figured I'd just write up my thoughts once so I can send links instead of answers :) And then so can anyone who happens to agree. (1) Replace by fee scorched earth, a counter argument: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d This article lays out the case against RBF-SE and argues it is harmful to Bitcoin. (2) Double spending and how to make it harder: https://medium.com/@octskyward/double-spending-in-bitcoin-be0f1d1e8008 This article summarises a couple of double spending incidents against merchants and then discusses the following techniques: 1. Risk analysis of transactions 2. Payment channels 3. Countersigning by a trusted third party 4. Remote attestation 5. ID verification 6. Waiting for confirmations 7. Punishment of double spending blocks I hope the material is useful / interesting. --047d7b3a896c3a7bfb051259a69e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've written a couple of blog posts on replace by fee = and double spending mitigations. They sum up the last few years (!) worth o= f discussions on this list and elsewhere, from my own perspective.

=
I make no claim to be comprehensive or unbiased but I keep being= asked about these topics so figured I'd just write up my thoughts once= so I can send links instead of answers :) And then so can anyone who happe= ns to agree.

(1) Replace by fee scorched earth, a co= unter argument:


This article lays o= ut the case against RBF-SE and argues it is harmful to Bitcoin.
<= br>
(2) Double spending and how to make it harder:

=

This article summarises a c= ouple of double spending incidents against merchants and then discusses the= following techniques:
  1. Risk analysis of transactions=
  2. Payment channels
  3. Countersigning by a trusted third party
  4. Remote attestation
  5. ID verification
  6. Waiting for confi= rmations
  7. Punishment of double spending blocks
I hope = the material is useful / interesting.
--047d7b3a896c3a7bfb051259a69e--