summaryrefslogtreecommitdiff
path: root/1a/f6f80d24295ddb5f7156010c407acd07c2c260
blob: a435c34782b6e1571847b407bdecb8e129e37787 (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
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 <natanael.l@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CANEZrP2Bg=yzoc0br7u=uNnZK4TMoaBbff+0t4uP3DcRaAnW7w@mail.gmail.com>
References: <20150212064719.GA6563@savin.petertodd.org>
	<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
	<CAE28kUQ87jWhq1p6RK1eKEuEP1ERxN_P2SS0=YsFEGAqRyMPLA@mail.gmail.com>
	<CANEZrP2H2T2QFZceCc=YzwwiApJy7kY7FN0LoAZODGbW12SYsw@mail.gmail.com>
	<CAE28kURa8g3YTPi-GHKAt4v0csxXe=QhGhV3aQcDZGSr=Lb7RQ@mail.gmail.com>
	<CANEZrP2hAUsRfeXUo-DLiiRmG5uJcwFuP4=o1S6Fb7ts5Ud=bw@mail.gmail.com>
	<CAAt2M1-L+3KEvWV+4UUSZX7meXkdTMPdz8SsxqsRtGhxsjHKmg@mail.gmail.com>
	<CANEZrP2Bg=yzoc0br7u=uNnZK4TMoaBbff+0t4uP3DcRaAnW7w@mail.gmail.com>
Date: Thu, 12 Feb 2015 16:54:19 +0100
Message-ID: <CAAt2M18BBuxDGzbUQ3ZmhoAw1EH3K1PiMz=vJ2B9ithve6kMUQ@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Mike Hearn <mike@plan99.net>
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: <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: 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" <mike@plan99.net>:
> 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

<p dir=3D"ltr"><br>
Den 12 feb 2015 16:42 skrev &quot;Mike Hearn&quot; &lt;<a href=3D"mailto:mi=
ke@plan99.net">mike@plan99.net</a>&gt;:<br>
&gt; Remember that you aren&#39;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.</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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). </p>
<p dir=3D"ltr">Your protocol requires less setup, but that&#39;s the only n=
otable difference (besides risk of paying non-participating pools with scor=
ched earth).</p>
<p dir=3D"ltr">No notable difference in security for merchants. </p>

--047d7bf0d8620b5934050ee62233--