Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net
	designates 198.252.153.129 as permitted sender)
	client-ip=198.252.153.129;
	envelope-from=justusranvier@riseup.net; helo=mx1.riseup.net; 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Date: Fri, 19 Jun 2015 15:53:01 +0000
From: justusranvier@riseup.net
To: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com>
References: <20150619103959.GA32315@savin.petertodd.org>
	<c2a392703d02e1d674a029c60deb6d94@riseup.net>
	<20150619151127.GA11263@savin.petertodd.org>
	<04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com>
Message-ID: <812d8353e66637ec182da31bc0a9aac1@riseup.net>
User-Agent: Riseup mail
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-19 15:37, Eric Lombrozo wrote:
> OK, a few things here:
>=20
> 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 hac=
ked
> before so I can assume it=E2=80=99s safe) is extremely dangerous at bes=
t 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.
>=20
> 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 cas=
es that
> things like RBF address.
>=20
> Thirdly, taken to the extreme, the viewpoint of =E2=80=9Csigning a conf=
licting
> 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 fun=
ds=E2=80=A6they
> must remain in limbo forever.

I'm not talking about changing the protocol - I'm talking about the=20
business relationships between users of Bitcoin.

I would expect a payment processor to inform the merchants of relevant=20
double spends that it observes on the network, even if the payment is=20
actually successful, so that the merchant can decide for themselves=20
whether or not to pursue it out of band.

Mining is a kind of technical fallback that allows the network to=20
resolve human misbehavior without human intervention. If nobody ever=20
attempted to make a fraudulent payment, we wouldn't need mining at all=20
because the signed transaction itself is proof of intention to pay. That=20
it exists doesn't suddenly make fraud less fraudulent and mean that=20
users who are in a position to pursue out of band recourse shouldn't do=20
so.

I agree that there are valid reasons for replacing transactions in the=20
mempool, I just think they should be implemented in a way that doesn't=20
facilitate fraud.

I'd also like to note that "prima facie" doesn't mean "always", it means=20
that "the default assumption, unless proven otherwise."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhDqcAAoJECpf2nDq2eYjX/UP/RlVIGqzwvdKftFW8kRW1+Dk
3befE2vEIEWFAShNt0pk7/Isqk7prRWQDKP+VNZSJfaoyE3akOe7s3OPWuevVRqM
Y1N658hYnG6NPebkyp5zUQkjT3mXVxOo9Fw9k7JyHgkWaDcwx330z2n6yztleodq
7hlKdW6sZrgqHw+DoF0Zal3QPN0WYm0XAno3uy71RXOs5cAoUxViuVzWHY0oReTQ
uggTggT1A5acmyOM7v65h9Cb2AKcLvHKfSEIwVQbHxYMOT+3GIJOXPKAluh8MjB3
oWg8ERy5dEEHu5kF/MLPQMg5yVQACuQmO2dlmtRoOs3mUQQj+q7dEil/dZMIp0f+
unDKIwLhXMa0sZ+63123UOgaKGZkF7afed3ueniJWQM80VS0WoZvZYhQadT/sCED
Ntfxifi1ZqCiKFeshyN9z7jDC8QEJ3N176Kr/wX76h/vvnPYicMEcfRgSE8EGd10
+oRQQpYzb69WPSFRhhrR3yG9Dev1JfzNPEaIKKYerDk9Vo3OnQ3VaaqBNZwBDo46
4r3O5orFES/ZxMdzWE1cWp99n4T4L6KxdZXmfQSYHehUJBnt62vKuEk9X/Li2ZWo
i3dr3yxx8xhKGGjsSjG03arz70bkXE7SvrICPOs9OEAdGlJI2liLrSWzYU9BbTle
eWvElyVQJsJHgAU8ygvn
=3D77NP
-----END PGP SIGNATURE-----