path: root/16/bec297eb29b6d633d4e6ac901342356815ac8c

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 <btcdrak@gmail.com>) id 1Z6apP-0001h8-PE
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Jun 2015 08:42:11 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.48 as permitted sender)
	client-ip=74.125.82.48; envelope-from=btcdrak@gmail.com;
	helo=mail-wg0-f48.google.com; 
Received: from mail-wg0-f48.google.com ([74.125.82.48])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z6apO-0002ip-5V
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Jun 2015 08:42:11 +0000
Received: by wguu7 with SMTP id u7so46528126wgu.3
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 21 Jun 2015 01:42:04 -0700 (PDT)
X-Received: by 10.180.95.67 with SMTP id di3mr21139490wib.78.1434876124143;
	Sun, 21 Jun 2015 01:42:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.136.196 with HTTP; Sun, 21 Jun 2015 01:41:44 -0700 (PDT)
In-Reply-To: <30AF043D-A1F8-4502-8280-EBED6063B6B6@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>
	<CAJHLa0NkQqypvU=yANCScs3hKhTyM53rt3aNW=QRh-HmBT4-Hg@mail.gmail.com>
	<30AF043D-A1F8-4502-8280-EBED6063B6B6@gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Sun, 21 Jun 2015 09:41:44 +0100
Message-ID: <CADJgMztdPEQP+J0wc06i=abvu-2ewBqps1-Vfr9UKMtpbv0BCA@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=f46d044287e2ad24a405190321f3
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HK_RANDOM_FROM         From username looks random
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.6 HK_RANDOM_ENVFROM      Envelope sender username looks random
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(btcdrak[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: 1Z6apO-0002ip-5V
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 08:42:11 -0000

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

Eric,

BitPay clearly do understand the risks of 0-conf. In case you were not
aware BitPay does not particularly "accept zero confirm transactions". When
a payment is seen on the network the payment screen reports the invoice has
been paid, but that's front-end user facing. On the back end it's marked as
paid but the API exposes the the confirmation status allowing the merchant
to make business decisions about when to progress to fulfilment. A good
example of this is Neteller (a sort of paypal variant) which allows one to
fund the account with fiat using Bitcoin, via Bitpay. When you pay the
bitpay invoice, your account is marked as payment pending until there are
some confirmations.

Coinbase does not expose the confirmation status and from what I understand
(not checked myself) they guarantee payment to merchants for 0-confirm,
regardless of whether they confirm or not.

I want to address something stated by Justus, that signing a payment
message and broadcasting somehow solidifies intent and going back on that
would be fraud. This seriously conflates cryptographic certainty with human
behaviour. For one, humans make mistakes all the time. We get tired, we get
distracted, we make copy paste errors. It's entirely possible on sends a
payment only to find it's been sent to the wrong address or the wrong
amount has been sent or the fee is wrong. Software may also misbehave
(Electrum for example has a weird UI glitch with fees where the specified
fee can be overwritten). r/bitcoin it littered with sad examples. What
ECDSA signing tells is that it was signed by your private key, but nothing
else. It does not say if *you* signed it, or that the message you signed
was correct.


On Sun, Jun 21, 2015 at 8:42 AM, Eric Lombrozo <elombrozo@gmail.com> wrote:

>
> On Jun 20, 2015, at 11:45 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>
> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo@gmail.com>
> wrote:
>
>>  but we NEED to be applying some kind of pressure on the merchant end to
>> upgrade their stuff to be more resilient
>>
>
> Can you be specific?  What precise technical steps would you have BitPay
> and Coinbase do?  We upgrade our stuff to... what exactly?
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> Thanks for asking *the* question, Jeff. We often get caught up in these
> philosophical debates=E2=80=A6but at the end of the day we need something=
 concrete.
>
> Even more important than the specific software you=E2=80=99re using is th=
e
> security policy.
>
> If you must accept zero confirmation transactions, there are a few
> concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do
> not accept them for very high priced goods=E2=80=A6especially if they req=
uire
> physical shipping.
> 2) limit the total amount of unconfirmed revenue you=E2=80=99ll tolerate =
at any
> given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc=E2=
=80=A6)
> the ability to shut the user out if a double-spend is detected.
> 4) collect legal information on purchasers (or have the merchants collect
> this information) so you have someone to go after if they try to screw yo=
u
> 5) create a risk profile for users=E2=80=A6and flag suspicious behavior (=
i.e.
> someone trying to purchase a bunch of stuff that totally doesn=E2=80=99t =
fit into
> their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is
> probably pretty hard to obtain since statistics are generally of little
> use=E2=80=A6we=E2=80=99re entering uncharted territory).
> 7) set up a warning system and a =E2=80=9Cpanic=E2=80=9D button so that i=
f you start to
> see an attack you can immediately disable all zero confirmation
> transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple
> network nodes=E2=80=A6check them against one another.
>
>
> As for software tools to accomplish these things, we can talk about that
> offline :)
>
>
> - Eric Lombrozo
>
>
>
>
>
>
> -------------------------------------------------------------------------=
-----
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

<div dir=3D"ltr">Eric,<div><br></div><div>BitPay clearly do understand the =
risks of 0-conf. In case you were not aware BitPay does not particularly &q=
uot;accept zero confirm transactions&quot;. When a payment is seen on the n=
etwork the payment screen reports the invoice has been paid, but that&#39;s=
 front-end user facing. On the back end it&#39;s marked as paid but the API=
 exposes the the confirmation status allowing the merchant to make business=
 decisions about when to progress to fulfilment. A good example of this is =
Neteller (a sort of paypal variant) which allows one to fund the account wi=
th fiat using Bitcoin, via Bitpay. When you pay the bitpay invoice, your ac=
count is marked as payment pending until there are some confirmations.<br><=
/div><div><br></div><div>Coinbase does not expose the confirmation status a=
nd from what I understand (not checked myself) they guarantee payment to me=
rchants for 0-confirm, regardless of whether they confirm or not.<br><div><=
br></div><div>I want to address something stated by Justus, that signing a =
payment message and broadcasting somehow solidifies intent and going back o=
n that would be fraud. This seriously conflates cryptographic certainty wit=
h human behaviour. For one, humans make mistakes all the time. We get tired=
, we get distracted, we make copy paste errors. It&#39;s entirely possible =
on sends a payment only to find it&#39;s been sent to the wrong address or =
the wrong amount has been sent or the fee is wrong. Software may also misbe=
have (Electrum for example has a weird UI glitch with fees where the specif=
ied fee can be overwritten). r/bitcoin it littered with sad examples. What =
ECDSA signing tells is that it was signed by your private key, but nothing =
else. It does not say if *you* signed it, or that the message you signed wa=
s correct.</div><div><br></div><div><br></div><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote">On Sun, Jun 21, 2015 at 8:42 AM, Eric Lombrozo <sp=
an 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"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div style=3D"word-wrap:break-word"><br><div><blockquote type=3D"cite"><d=
iv>On Jun 20, 2015, at 11:45 PM, Jeff Garzik &lt;<a href=3D"mailto:jgarzik@=
bitpay.com" target=3D"_blank">jgarzik@bitpay.com</a>&gt; wrote:</div><br><d=
iv><div dir=3D"ltr"><span class=3D"">On Sat, Jun 20, 2015 at 5:54 PM, Eric =
Lombrozo <span dir=3D"ltr">&lt;<a href=3D"mailto:elombrozo@gmail.com" targe=
t=3D"_blank">elombrozo@gmail.com</a>&gt;</span> wrote:<br></span><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">=C2=A0but we NEED to be applying some kind of pressure on =
the merchant end to upgrade their stuff to be more resilient<br></blockquot=
e><div><br></div></span><div>Can you be specific?=C2=A0 What precise techni=
cal steps would you have BitPay and Coinbase do?=C2=A0 We upgrade our stuff=
 to... what exactly?</div></div><span class=3D""><div><br></div>-- <br><div=
>Jeff Garzik<br>Bitcoin core developer and open source evangelist<br>BitPay=
, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" target=3D"_blank=
">https://bitpay.com/</a></div>
</span></div></div>
</div></blockquote></div><br><div>Thanks for asking *the* question, Jeff. W=
e often get caught up in these philosophical debates=E2=80=A6but at the end=
 of the day we need something concrete.</div><div><br></div><div>Even more =
important than the specific software you=E2=80=99re using is the security p=
olicy.</div><div><br></div><div>If you must accept zero confirmation transa=
ctions, there are a few concrete things you can do to reduce your exposure:=
</div><div><br></div><div>1) limit the transaction amounts for zero confirm=
ation transactions - do not accept them for very high priced goods=E2=80=A6=
especially if they require physical shipping.</div><div>2) limit the total =
amount of unconfirmed revenue you=E2=80=99ll tolerate at any given moment -=
 if the amount is exceeded, require confirmations.</div><div>3) give mercha=
nts of subscription services (i.e. servers, hosting, etc=E2=80=A6) the abil=
ity to shut the user out if a double-spend is detected.</div><div>4) collec=
t legal information on purchasers (or have the merchants collect this infor=
mation) so you have someone to go after if they try to screw you</div><div>=
5) create a risk profile for users=E2=80=A6and flag suspicious behavior (i.=
e. someone trying to purchase a bunch of stuff that totally doesn=E2=80=99t=
 fit into their purchasing habits).</div><div>6) get insurance (although ri=
ght now reasonably-priced insurance is probably pretty hard to obtain since=
 statistics are generally of little use=E2=80=A6we=E2=80=99re entering unch=
arted territory).</div><div>7) set up a warning system and a =E2=80=9Cpanic=
=E2=80=9D button so that if you start to see an attack you can immediately =
disable all zero confirmation transactions system-wide.</div><div>8) indepe=
ndently verify all inbound transactions and connect to multiple network nod=
es=E2=80=A6check them against one another.</div><div><br></div><div><br></d=
iv><div>As for software tools to accomplish these things, we can talk about=
 that offline :)</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><=
br></div><div><br></div><div>- Eric Lombrozo</div><div><br></div><div><br><=
/div><div><br></div><div><br></div></font></span></div><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></div></div>

--f46d044287e2ad24a405190321f3--