path: root/13/6628124364e6d99e5fec5fd04cdd2a9179ae7e

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 <elombrozo@gmail.com>) id 1Z5yM3-0006dT-Oe
	for bitcoin-development@lists.sourceforge.net;
	Fri, 19 Jun 2015 15:37:19 +0000
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; 
Received: from mail-pa0-f51.google.com ([209.85.220.51])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z5yM2-0006g9-Gw
	for bitcoin-development@lists.sourceforge.net;
	Fri, 19 Jun 2015 15:37:19 +0000
Received: by padev16 with SMTP id ev16so87643527pad.0
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 19 Jun 2015 08:37:12 -0700 (PDT)
X-Received: by 10.70.134.133 with SMTP id pk5mr32939258pdb.133.1434728232819; 
	Fri, 19 Jun 2015 08:37:12 -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 t9sm11559377pbs.45.2015.06.19.08.37.11
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 19 Jun 2015 08:37:12 -0700 (PDT)
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
X-Pgp-Agent: GPGMail 2.5b6
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>
X-Mailer: Apple Mail (2.2098)
X-Spam-Score: -1.1 (-)
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
	-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.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5yM2-0006g9-Gw
Cc: bitcoin-development@lists.sourceforge.net, 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: Fri, 19 Jun 2015 15:37:19 -0000


--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--