summaryrefslogtreecommitdiff
path: root/a8/bb44cc9b55e5814a9331ad228c45bc9d49ca3b
blob: 0a000d2f1f62cd51eb036a9e8815ec21e3cb2806 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CANEZrP3Prp6EFUdH_VDWkq508HkeFBMn+swzZ9ycAMsrOazFZA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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

<div dir=3D"ltr">I&#39;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.<div><br>=
</div><div>I make no claim to be comprehensive or unbiased but I keep being=
 asked about these topics so figured I&#39;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.<br><div><br></div><div>(1) Replace by fee scorched earth, a co=
unter argument:</div><div><br></div><div><a href=3D"https://medium.com/@oct=
skyward/replace-by-fee-43edd9a1dd6d">https://medium.com/@octskyward/replace=
-by-fee-43edd9a1dd6d</a></div></div><div><br></div><div>This article lays o=
ut the case against RBF-SE and argues it is harmful to Bitcoin.</div><div><=
br></div><div>(2) Double spending and how to make it harder:</div><div><br>=
</div><div><a href=3D"https://medium.com/@octskyward/double-spending-in-bit=
coin-be0f1d1e8008">https://medium.com/@octskyward/double-spending-in-bitcoi=
n-be0f1d1e8008</a><br></div><div><br></div><div>This article summarises a c=
ouple of double spending incidents against merchants and then discusses the=
 following techniques:</div><div><div><ol><li>Risk analysis of transactions=
</li><li>Payment channels</li><li>Countersigning by a trusted third party</=
li><li>Remote attestation</li><li>ID verification</li><li>Waiting for confi=
rmations</li><li>Punishment of double spending blocks</li></ol><div>I hope =
the material is useful / interesting.</div></div></div></div>

--047d7b3a896c3a7bfb051259a69e--