Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.51 as permitted sender)
	client-ip=209.85.220.51; envelope-from=elombrozo@gmail.com;
	helo=mail-pa0-f51.google.com; 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_187EB51B-4BF2-4473-9686-3A945E4CC825";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <20150619151127.GA11263@savin.petertodd.org>
Date: Fri, 19 Jun 2015 08:37:10 -0700
Message-Id: <04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com>
References: <20150619103959.GA32315@savin.petertodd.org>
	<c2a392703d02e1d674a029c60deb6d94@riseup.net>
	<20150619151127.GA11263@savin.petertodd.org>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoin-development@lists.sourceforge.net, justusranvier@riseup.net
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Precedence: list


--Apple-Mail=_187EB51B-4BF2-4473-9686-3A945E4CC825
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

OK, a few things here:

The Bitcoin network was designed (or should be designed) with the =
requirement that it can withstand deliberate double-spend attacks that =
can come from anywhere at any time=E2=80=A6and relaxing this assumption =
without adequately assessing the risk (i.e. I=E2=80=99ve never been =
hacked before so I can assume it=E2=80=99s safe) is extremely dangerous =
at best and just horrid security practice at worst. Your users might not =
thank you for not getting hacked - but they surely will not like it when =
you DO get hacked=E2=80=A6and lack a proper recovery plan.

Furthermore, the protocol itself makes no assumptions regarding the =
intentions behind someone signing two conflicting transactions. There =
are many potential use cases where doing so could make a lot of sense. =
Had the protocol been designed along the lines of, say, =
tendermint=E2=80=A6where signing multiple conflicting blocks results in =
loss of one=E2=80=99s funds=E2=80=A6then the protocol itself =
disincentivizes the behavior without requiring any sort of altruistic, =
moralistic assumptions. That would also mean we=E2=80=99d need a =
different mechanism for the use cases that things like RBF address.

Thirdly, taken to the extreme, the viewpoint of =E2=80=9Csigning a =
conflicting transaction is fraud and vandalism=E2=80=9D means that if =
for whatever reason you attempt to propagate a transaction and nobody =
mines it for a very long time, you=E2=80=99re not entitled to =
immediately reclaim those funds=E2=80=A6they must remain in limbo =
forever.


- Eric Lombrozo


> On Jun 19, 2015, at 8:11 AM, Peter Todd <pete@petertodd.org> wrote:
>=20
> On Fri, Jun 19, 2015 at 03:00:57PM +0000, justusranvier@riseup.net =
wrote:
>> On 2015-06-19 10:39, Peter Todd wrote:
>>=20
>>     Yesterday F2Pool, currently the largest pool with 21% of the =
hashing
>>     power, enabled full replace-by-fee (RBF) support after =
discussions
>> with
>>     me. This means that transactions that F2Pool has will be replaced =
if
>> a
>>     conflicting transaction pays a higher fee. There are no =
requirements
>> for
>>     the replacement transaction to pay addresses that were paid by =
the
>>     previous transaction.
>>=20
>>=20
>> Intentional fraud is a bad thing to add to a financial protocol.
>>=20
>> A user who creates conflicting transactions, one that pays someone =
else
>> and another which does not pay them, and broadcasts both of them, has
>> just self-incriminated themselves by producing prima facie evidence =
of
>> fraud.
>=20
> Depends.
>=20
> If you ask me to pay you 1BTC at address A and I create tx1 that pays
> 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
> that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
> defrauding you, I'm just reducing the value of my change address to =
pay
> a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
> tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
>=20
> Yet from the point of view of an external observer they have no idea =
why
> the transaction outputs reduced in size, nor any way of knowing if =
fraud
> did or did not occur.
>=20
> Equally, maybe you tell me "Actually, just give me 0.5BTC to cancel =
out
> that debt", in which case I'm not breaking any contract at all by =
giving
> you less money than I first promised - the contract has changed.
>=20
> Again, none of this can or should be observable to anyone other than =
the
> parties directly involved.
>=20
>> It may be the case that since Bitcoin spans multiple legal =
jurisdictions
>> and can be use anonymously that the victims of such fraud can not =
rely
>> on legal recourse, and it may also be the case that proof of work is =
how
>> Bitcoin deals with the aforementioned factors, but regardless
>> un-prosecutable fraud is still fraud and anyone who encourages it =
should
>> be recognied as a bad actors.
>>=20
>> Committing vandalism and encouraging fraud to prove a point may be
>> something the network can't stop on a technical level, but there's no
>> reason not to call it out for what it is.
>=20
> What do you think of Bitcoin XT then? It relays double-spends, which
> makes it much easier to get double-spends to miners than before. In
> particular you see a lot of zero-fee transactions being replaced by
> fee-paying transactions, relayed through Bitcoin XT nodes and then
> mined. Is that encouraging fraud?
>=20
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000003932458055c68d4ee2b6d68441c4764efbdf6b0b1683717
> =
--------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--Apple-Mail=_187EB51B-4BF2-4473-9686-3A945E4CC825
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

iQIcBAEBCgAGBQJVhDcmAAoJEJNAI64YFENUA1QP/2SwmqlPHFsfhHVhNxsDBo6Q
xp7urHl1P6rj8XUuHo7XCBYCtDSL+MAEexzivw8gRUqbKorjbxaPOxKKqCrG16++
GE/E/i/pU6EoIMcLikicDo+YfA5n1zJjyyVkbD6WQgYkUsP+ugYlp3uTuKjNT+Vp
quu1IorzX8D8tw47s/eno3C100I43z1aJ4mh4tIPkH5ltkdoQ4gX+nyDOoKQ5gVk
NzZSVDMUDPQc4NiZAYJG/M/4I2keKEmoSA1ombwNeem4uPWxpVEyag6sk+ksa9kx
Y45AdLWstdGJ5FzWR842knCi5Ho6nCXyx2ZafT7qbgKRv3MbJrRlePThQM+v2v4a
QyBqt6TOQWe8kiyOhbCLg1bY20fc4vXev54qSsmvIOPfDkeM/kr9jyWVwJekernr
aA+uvjXIfmTwPOB7pIXGPLxr6enDa/imw0+Lu/LWEse3cHjSrTIfgbduNGZc5vIy
63zO56zqgquY8TmIc0mdsguRdM6nkeoAuDhE822Y9k6qL/uPWWPcOf+8Tjs3JsLs
tSEOAKwjrgjKkmgML+YeLVvqqoVTmJzi8OBv/tRhw01jpv2ed67kI8j/FDwGPypo
BJcjN1ysm68W6iEjxxQBcynFqrWpfmDk+AZcA0HU9U8Ux5R2/GGFYMDsoWBRLtEZ
hPmsZXnJBTCtZrHEoEU/
=tKtV
-----END PGP SIGNATURE-----

--Apple-Mail=_187EB51B-4BF2-4473-9686-3A945E4CC825--