path: root/03/b29bae6a24616e01d91772ff48e5ac87df8896

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <elombrozo@gmail.com>) id 1Z697h-0005FN-Dk
	for bitcoin-development@lists.sourceforge.net;
	Sat, 20 Jun 2015 03:07:13 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.176 as permitted sender)
	client-ip=209.85.192.176; envelope-from=elombrozo@gmail.com;
	helo=mail-pd0-f176.google.com; 
Received: from mail-pd0-f176.google.com ([209.85.192.176])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z697e-0000PJ-Uy
	for bitcoin-development@lists.sourceforge.net;
	Sat, 20 Jun 2015 03:07:13 +0000
Received: by pdbci14 with SMTP id ci14so43607574pdb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 19 Jun 2015 20:07:05 -0700 (PDT)
X-Received: by 10.68.167.131 with SMTP id zo3mr37365354pbb.123.1434769625317; 
	Fri, 19 Jun 2015 20:07:05 -0700 (PDT)
Received: from [192.168.1.102] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202])
	by mx.google.com with ESMTPSA id o7sm12601565pdi.16.2015.06.19.20.07.03
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 19 Jun 2015 20:07:04 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_1312660D-E2F2-4CB0-B7E7-3268F0EB69E0";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CACq0ZD5VDJRuKiq2NaPyoJdDVMPd+9YWtEr3pauS5ZNzxXXEig@mail.gmail.com>
Date: Fri, 19 Jun 2015 20:07:02 -0700
Message-Id: <C8121F43-0A2A-4882-B98A-90AB77962550@gmail.com>
References: <20150619103959.GA32315@savin.petertodd.org>
	<20150619154054.GA13498@savin.petertodd.org>
	<CAMK47c84w=2c9y8MKHTzFf05DmKXz74a=iFViA-oZ1uRDZCAWg@mail.gmail.com>
	<6716121.uS5ifrNBZv@crushinator> <5584B80A.7000403@petersson.at>
	<CAOG=w-u6fmpnojpQmrFEMRK56WDsfhZgm406C3tVax5hsX2sOA@mail.gmail.com>
	<CACq0ZD5VDJRuKiq2NaPyoJdDVMPd+9YWtEr3pauS5ZNzxXXEig@mail.gmail.com>
To: Aaron Voisine <voisine@gmail.com>
X-Mailer: Apple Mail (2.2098)
X-Spam-Score: -0.7 (/)
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
	(elombrozo[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.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z697e-0000PJ-Uy
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.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: Sat, 20 Jun 2015 03:07:13 -0000


--Apple-Mail=_1312660D-E2F2-4CB0-B7E7-3268F0EB69E0
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E0C07B8B-C29C-422B-B828-6755DA12F367"


--Apple-Mail=_E0C07B8B-C29C-422B-B828-6755DA12F367
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It all comes down to managing risk. If you=E2=80=99ve got a decent risk =
model with capped losses and safe recovery mechanisms=E2=80=A6and it=E2=80=
=99s still profitable=E2=80=A6it=E2=80=99s fine. But most payment =
processors and merchants right now probably don=E2=80=99t have =
particularly good risk models and are making many dangerous =
assumptions=E2=80=A6and probably would not be able to gracefully handle =
very many risk scenarios.

- Eric Lombrozo


> On Jun 19, 2015, at 6:23 PM, Aaron Voisine <voisine@gmail.com> wrote:
>=20
> > What retail needs is escrowed microchannel hubs (what lightning =
provides, for example), which enable untrusted instant payments. Not =
reliance on single-signer zeroconf transactions that can never be made =
safe.
>=20
> They don't need to be made cryptographically safe, they just have to =
be safer than, for instance, credit card payments that can be charged =
back. As long as it's reasonably good in practice, that's fine.
>=20
>=20
> Aaron Voisine
> co-founder and CEO
> breadwallet.com <http://breadwallet.com/>
> On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach =
<mark@friedenbach.org <mailto:mark@friedenbach.org>> wrote:
> What retail needs is escrowed microchannel hubs (what lightning =
provides, for example), which enable untrusted instant payments. Not =
reliance on single-signer zeroconf transactions that can never be made =
safe.
>=20
> On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson =
<andreas@petersson.at <mailto:andreas@petersson.at>> wrote:
> I have some experience here. If you are seriously suggesting these
> measures, you might as well kill retail transactions altogether.
>=20
> In practice, if a retail place starts to accept bitcoin they have a
> similar situation as with cash, only that the fraud potential is much
> lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
> and the fraud frequency is also much lower.
>=20
> 0-conf concerns were never a problem in practice. except for 2-way =
atms
> i have never heard of a problem that was caused by double spends.
> while adding these measures is generally positive, requiring them =
means
> excluding 99.9% of the potential users. so you might as well not do =
it.
>=20
> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
> value. So it's a bad thing.
>=20
> for any online or automated system, waiting for a handful of
> confirmations was always recommended practice.
>=20
> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> > Retail POS merchants probably should not be accepting vanilla =
Bitcoin
> > payments, as Bitcoin alone does not (and cannot) guarantee the
> > irreversibility of a transaction until it has been buried several
> > blocks deep in the chain. Retail merchants should be requiring a
> > co-signature from a mutually trusted co-signer that vows never to =
sign
> > a double-spend.
>=20
>=20
> =
--------------------------------------------------------------------------=
----
>=20
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net =
<mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development =
<https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>=20
>=20
>=20
> =
--------------------------------------------------------------------------=
----
>=20
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net =
<mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development =
<https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>=20
>=20
> =
--------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--Apple-Mail=_E0C07B8B-C29C-422B-B828-6755DA12F367
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">It all comes down to managing risk. If you=E2=80=99ve got a =
decent risk model with capped losses and safe recovery mechanisms=E2=80=A6=
and it=E2=80=99s still profitable=E2=80=A6it=E2=80=99s fine. But most =
payment processors and merchants right now probably don=E2=80=99t have =
particularly good risk models and are making many dangerous =
assumptions=E2=80=A6and probably would not be able to gracefully handle =
very many risk scenarios.<div class=3D""><br class=3D""></div><div =
class=3D"">- Eric Lombrozo<br class=3D""><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""><div><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Jun 19, 2015, at 6:23 PM, =
Aaron Voisine &lt;<a href=3D"mailto:voisine@gmail.com" =
class=3D"">voisine@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">&gt;&nbsp;<span style=3D"font-size:13px" class=3D"">What =
retail needs is escrowed microchannel hubs (what lightning provides, for =
example), which enable untrusted instant payments. Not reliance on =
single-signer zeroconf transactions that can never be made =
safe.</span><div class=3D""><span style=3D"font-size:13px" class=3D""><br =
class=3D""></span></div><div class=3D"">They don't need to be made =
cryptographically safe, they just have to be safer than, for instance, =
credit card payments that can be charged back. As long as it's =
reasonably good in&nbsp;practice, that's fine.</div></div><div =
class=3D"gmail_extra"><br clear=3D"all" class=3D""><div class=3D""><div =
class=3D"gmail_signature"><div dir=3D"ltr" class=3D""><div class=3D""><div=
 dir=3D"ltr" class=3D""><div class=3D""><br class=3D"">Aaron =
Voisine</div><div class=3D"">co-founder and CEO<br class=3D""><a =
href=3D"http://breadwallet.com/" target=3D"_blank" =
class=3D"">breadwallet.com</a></div></div></div></div></div></div>
<br class=3D""><div class=3D"gmail_quote">On Fri, Jun 19, 2015 at 6:09 =
PM, Mark Friedenbach <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:mark@friedenbach.org" target=3D"_blank" =
class=3D"">mark@friedenbach.org</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" =
class=3D"">What retail needs is escrowed microchannel hubs (what =
lightning provides, for example), which enable untrusted instant =
payments. Not reliance on single-signer zeroconf transactions that can =
never be made safe.<br class=3D""></div><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote"><div class=3D""><div class=3D"h5">On=
 Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson <span dir=3D"ltr" =
class=3D"">&lt;<a href=3D"mailto:andreas@petersson.at" target=3D"_blank" =
class=3D"">andreas@petersson.at</a>&gt;</span> wrote:<br =
class=3D""></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
class=3D""><div class=3D"h5">I have some experience here. If you are =
seriously suggesting these<br class=3D"">
measures, you might as well kill retail transactions altogether.<br =
class=3D"">
<br class=3D"">
In practice, if a retail place starts to accept bitcoin they have a<br =
class=3D"">
similar situation as with cash, only that the fraud potential is much<br =
class=3D"">
lower. (e.g. 100-dollar bill for a sandwich might turn out fake =
later)<br class=3D"">
and the fraud frequency is also much lower.<br class=3D"">
<br class=3D"">
0-conf concerns were never a problem in practice. except for 2-way =
atms<br class=3D"">
i have never heard of a problem that was caused by double spends.<br =
class=3D"">
while adding these measures is generally positive, requiring them =
means<br class=3D"">
excluding 99.9% of the potential users. so you might as well not do =
it.<br class=3D"">
<br class=3D"">
RBF as implemented by F2Pool just flat out lowers Bitcoins utility<br =
class=3D"">
value. So it's a bad thing.<br class=3D"">
<br class=3D"">
for any online or automated system, waiting for a handful of<br =
class=3D"">
confirmations was always recommended practice.<br class=3D"">
<div class=3D""><div class=3D""><br class=3D"">
Am 19.06.2015 um 22:39 schrieb Matt Whitlock:<br class=3D"">
&gt; Retail POS merchants probably should not be accepting vanilla =
Bitcoin<br class=3D"">
&gt; payments, as Bitcoin alone does not (and cannot) guarantee the<br =
class=3D"">
&gt; irreversibility of a transaction until it has been buried =
several<br class=3D"">
&gt; blocks deep in the chain. Retail merchants should be requiring a<br =
class=3D"">
&gt; co-signature from a mutually trusted co-signer that vows never to =
sign<br class=3D"">
&gt; a double-spend.<br class=3D"">
<br class=3D"">
</div></div><br class=3D""></div></div><span =
class=3D"">---------------------------------------------------------------=
---------------<br class=3D"">
<br class=3D"">_______________________________________________<br =
class=3D"">
Bitcoin-development mailing list<br class=3D"">
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" =
target=3D"_blank" =
class=3D"">Bitcoin-development@lists.sourceforge.net</a><br class=3D"">
<a =
href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development" =
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen=
t</a><br class=3D"">
<br class=3D""></span></blockquote></div><br class=3D""></div>
<br =
class=3D"">---------------------------------------------------------------=
---------------<br class=3D"">
<br class=3D"">_______________________________________________<br =
class=3D"">
Bitcoin-development mailing list<br class=3D"">
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" =
class=3D"">Bitcoin-development@lists.sourceforge.net</a><br class=3D"">
<a =
href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development" =
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen=
t</a><br class=3D"">
<br class=3D""></blockquote></div><br class=3D""></div>
=
--------------------------------------------------------------------------=
----<br class=3D"">_______________________________________________<br =
class=3D"">Bitcoin-development mailing list<br class=3D""><a =
href=3D"mailto:Bitcoin-development@lists.sourceforge.net" =
class=3D"">Bitcoin-development@lists.sourceforge.net</a><br =
class=3D"">https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen=
t<br class=3D""></div></blockquote></div><br =
class=3D""></div></div></body></html>=

--Apple-Mail=_E0C07B8B-C29C-422B-B828-6755DA12F367--

--Apple-Mail=_1312660D-E2F2-4CB0-B7E7-3268F0EB69E0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVhNjWAAoJEJNAI64YFENUDkoP/2Em2k2Yt60m3Djca2V68tyc
y5PxIgr5F0KSGNu3mFsamM118K1fv+DNmva149QUDu3pB7EB2QUaJnNu57rF3Lpc
DVdqDVG8Ny9Rbc2PR6sgp6Hr5FuttPTJfMQWHhzuHhNlVbglQ/uIbvEAxlajcdBX
FT23llYev9/kSSJRFm5aY9NELNCxhh51eKEMAyAI6sLDpjv9NKsegrNPeleZYwnJ
LT1UDVf3AIwuxcextiZjhzbn4mughZ4eMq34/6e9qoFY8yn7bUOzijtcGadn3t6n
moWfEut46f59SPnuT18pgdZQ/nYeBExImwNjrs2t8WTT51yI0csTbWM51mDuZHD4
wIMa7fQCIMKNP1qvMT3foVPSDJOHccC9vsPMdKr+d64cYINxz/k2t9GGemcDHfto
UkA41b75j29BZ/aff8EGTmPV4aHfXXiim6BOsYDa98RO+8AfRnaJJ3w2jouswuzX
WWQcw4UjFcI4pSIDz89+e0N34CmGu1mBK8D9+Pi4K2yAoscDeSwKuq1XzTg27eSA
YjlFRlpzl32EnDlQ9vkaK7ZRA7dB488M+k8VMY4TE9Pv5o1PovhJwWfdkd+ivEqw
Yj+QXPalIPWaIxRaRr3mBkmW7GUQtCOMcgbkV7HMx17KQAR/Ostb+ivdVnZVgwSD
x7pO6oazDwLtm45hM8j6
=U8Mk
-----END PGP SIGNATURE-----

--Apple-Mail=_1312660D-E2F2-4CB0-B7E7-3268F0EB69E0--