summaryrefslogtreecommitdiff
path: root/08/b1cd90ac57b99bc19521fbbf5715418c9be6fb
blob: 450c57311d3b8f4a5501cc48c45bada8dcfd1cd3 (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
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <voisine@gmail.com>) id 1Z6jtw-0000iO-6N
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Jun 2015 18:23:28 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.178 as permitted sender)
	client-ip=209.85.216.178; envelope-from=voisine@gmail.com;
	helo=mail-qc0-f178.google.com; 
Received: from mail-qc0-f178.google.com ([209.85.216.178])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z6jtu-0002jE-Ki
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Jun 2015 18:23:28 +0000
Received: by qcji3 with SMTP id i3so3135775qcj.1
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 21 Jun 2015 11:23:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.20.16 with SMTP id e16mr53904990qkh.71.1434911001198;
	Sun, 21 Jun 2015 11:23:21 -0700 (PDT)
Received: by 10.140.91.37 with HTTP; Sun, 21 Jun 2015 11:23:20 -0700 (PDT)
In-Reply-To: <70534C5D-8834-42B5-B495-FD9975E8FCF4@gmail.com>
References: <20150619103959.GA32315@savin.petertodd.org>
	<04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com>
	<812d8353e66637ec182da31bc0a9aac1@riseup.net>
	<1727885.UUNByX4Jyd@crushinator>
	<83A7C606-B601-47D2-BE10-2A1412D97514@gmail.com>
	<CABm2gDrHFB_XtQXVvoFeEH5TUfWSc3JLcNuo-oSXNJaExB+Vdg@mail.gmail.com>
	<8a49c53a032503eeca4f51cdef725fe1@riseup.net>
	<B4B8DB86-C03A-4C79-BD94-3E073D5E7003@gmail.com>
	<6d025db96e7aec4e6e47a76883a9a1e3@riseup.net>
	<70534C5D-8834-42B5-B495-FD9975E8FCF4@gmail.com>
Date: Sun, 21 Jun 2015 11:23:20 -0700
Message-ID: <CACq0ZD6BLTEL36oO-ywcVB17LMREVN1s9Vwpe8K-P=J++4wHGA@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a1144d25482c54605190b4018
X-Spam-Score: -0.6 (/)
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
	(voisine[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
X-Headers-End: 1Z6jtu-0002jE-Ki
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Justus Ranvier <justusranvier@riseup.net>
Subject: Re: [Bitcoin-development] F2Pool has enabled full 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: Sun, 21 Jun 2015 18:23:28 -0000

--001a1144d25482c54605190b4018
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We should use relay and default tx selection rules to raise the cost of
double spend attacks as far as it is easy and practical to do so. This
increases the value of the bitcoin network by making it practical to use in
more situations for more people. Merchants of course can't rely on them
being cryptographically safe, but the safer they are, the more useful.

The argument that since they can't be made perfectly safe, they should be
as easy as possible to reverse so that merchants learn not to rely on them,
is an incorrect one that reduces the usefulness and value of bitcoin.
Merchants will learn very quickly what the costs of accepting bitcoin
payments are, and the lower they are, the greater bitcoin merchant adoption
will be.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:

> One more thing I would like to add to this thread: I want to make it
> unequivocally clear that I believe what is making double-spends easier ha=
s
> relatively little to do with the protocol and almost everything to do wit=
h
> poor software and poor security policy on the merchant end. Perhaps it
> isn=E2=80=99t prudent to push out changes to the relay policy that make t=
hese
> exploits even easier right now - but we NEED to be applying some kind of
> pressure on the merchant end to upgrade their stuff to be more resilient =
so
> that we have more room for changes on things like relay policy without
> significant disruption to the network.
>
> - Eric Lombrozo
>
>
> -------------------------------------------------------------------------=
-----
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--001a1144d25482c54605190b4018
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We should use relay and default tx selection rules to rais=
e the cost of double spend attacks as far as it is easy and practical to do=
 so. This increases the value of the bitcoin network by making it practical=
 to use in more situations for more people. Merchants of course can&#39;t r=
ely on them being cryptographically safe, but the safer they are, the more =
useful.<div><br></div><div>The argument that since they can&#39;t be made p=
erfectly safe, they should be as easy as possible to reverse so that mercha=
nts learn not to rely on them, is an incorrect one that reduces the usefuln=
ess and value of bitcoin. Merchants will learn very quickly what the costs =
of accepting bitcoin payments are, and the lower they are, the greater bitc=
oin merchant adoption will be.</div></div><div class=3D"gmail_extra"><br cl=
ear=3D"all"><div><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div =
dir=3D"ltr"><div><br>Aaron Voisine</div><div>co-founder and CEO<br><a href=
=3D"http://breadwallet.com" target=3D"_blank">breadwallet.com</a></div></di=
v></div></div></div></div>
<br><div class=3D"gmail_quote">On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombro=
zo <span dir=3D"ltr">&lt;<a href=3D"mailto:elombrozo@gmail.com" target=3D"_=
blank">elombrozo@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">One more thing I would like to add to this thread: I want to make i=
t unequivocally clear that I believe what is making double-spends easier ha=
s relatively little to do with the protocol and almost everything to do wit=
h poor software and poor security policy on the merchant end. Perhaps it is=
n=E2=80=99t prudent to push out changes to the relay policy that make these=
 exploits even easier right now - but we NEED to be applying some kind of p=
ressure on the merchant end to upgrade their stuff to be more resilient so =
that we have more room for changes on things like relay policy without sign=
ificant disruption to the network.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Eric Lombrozo<br>
</font></span><br>---------------------------------------------------------=
---------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div>

--001a1144d25482c54605190b4018--