Received-SPF: pass (sog-mx-4.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: Sat, 20 Jun 2015 19:27:40 -0500
From: justusranvier@riseup.net
To: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <B4B8DB86-C03A-4C79-BD94-3E073D5E7003@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>
Message-ID: <6d025db96e7aec4e6e47a76883a9a1e3@riseup.net>
User-Agent: Riseup mail
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-06-20 19:19, Eric Lombrozo wrote:
>> On Jun 20, 2015, at 4:37 PM, justusranvier@riseup.net wrote:
>>=20
>> Signed PGP part
>> On 2015-06-20 18:20, Jorge Tim=C3=B3n wrote:
>> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo@gmail.com>
>> > wrote:
>> >> If we want a non-repudiation mechanism in the protocol, we should
>> >> explicitly define one rather than relying on =E2=80=9Cprima facie=E2=
=80=9D
>> >> assumptions. Otherwise, I would recommend not relying on the existe=
nce
>> >> of a signed transaction as proof of intent to pay=E2=80=A6
>> >
>> > Non-repudiation can be built on top of the payment protocol layer.
>>=20
>>=20
>> Non-repudiation is an intrinsic property of the ECDSA signatures which
>> Bitcoin uses - it's not a feature that needs to be built.
>>=20
>> There's no way to accidentally sign a transaction and accidentally
>> announce it publicly. There is no form of third-party error that can
>> result in a payee receiving an erroneous contract.
>>=20
>>=20
>=20
> Justus,
>=20
> We don=E2=80=99t even have a concept of identity in the Bitcoin protoco=
l, let
> alone non-repudiation. What good is non-repudiation if there=E2=80=99s =
no way
> to even associate a signature with a legal entity?
>=20
> Sure, we could use the ECDSA signatures in transactions as part of a
> non-repudiation scheme - but the recipient would have to also have a
> means to establish the identity of the sender and associate it with
> the the transaction.
>=20
>=20
> Furthermore, in light of the fact that there *are* fully legitimate
> use cases for sending conflicting transactions=E2=80=A6and the fact tha=
t
> determination of intent isn=E2=80=99t always entirely clear=E2=80=A6we =
should refrain
> from attaching any further significance transaction signatures other
> than that =E2=80=9Cthe sender was willing to have it included in the
> blockchain if a miner were to have seen it and accepted it=E2=80=A6but =
perhaps
> the sender would have changed their mind before it actually did get
> accepted.=E2=80=9D

Bitcoin has no concept of identity, but in any type of commercial=20
transaction the parties involved must know some minimal amount of=20
identity information in order to transact at all.

Except for some identifiable special cases, I think a payee is perfectly=20
justified in treating a double spend of a payment sent to them as part=20
of a commercial transaction as a fraud attempt and employing whatever=20
non-Bitcoin recourse mechanisms, if any, they have access to.

- From the perspective of the network, the obviously correct action for=20
any node or miner is to relay the first version of any transaction they=20
see. The primary purpose of mining is to resolve this=20
otherwise-unresolvable problem of determining which transaction among a=20
set of conflicting transactions happened first.

If a node or miner wants to deviate from the obviously correct=20
behaviour, and if they want to avoid harming the value of the network,=20
they should be particularly careful to make sure their deviation from=20
"first seen" doesn't introduce harmful unintended side effects, like=20
making fraud easier.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVhgTgAAoJECpf2nDq2eYjkksQAJyRVhT2vNQUqlOfH9Z/9EeT
LkUm8eg3f1i3xhJVxtLGVJkRmMYmuNtH0lIsH/B3iED732oZSzhwM1F5ky948Mw7
FFG65iUTrXVup9eKZuD7T3/FaQHfC5YME36F4UvEtSUcRDUKmongRGuuw7sNv617
APl3MDwZ8tVWaDb7yZ251is6Fx1l3b6tR4tHUzyIWPyIOuXOsyUaoS1cYJ00YcI5
WIzIXIlRDNpvpIXv4NFtr0BH6BmTCCZOJH3X9Hmtxqrg/dlnfnmc1pZgAyqRXj1d
5of7dYwb+bhHpU9TvcDYprN55Kmida2gTZewfr33rTXcVyjhs5N3bmIRIRrPltMA
fFqlKJ7Fo4ldyJ4OEK6upuFHwmQRNL7qr/ODmYg83rJj3BdTzXsJ1l3BRAUBS+cm
gc8Q3urxmVyspht+U64GO+ieLA9xb9izFMa+GL8nag0VuHc5J7XDjfzXBT8VK5be
646AZ0tFULNLOBWEJuBRbCRUs90YK2ePpGnAwiZ7HuwHMAC333FYiBuRxgwgn+xv
hHMlQWTtrl0zJrxD+pcb5axC7zQdVHVeyNJDi4RF1Wau2NX/itHcUqRr75N8/Si+
GPF8JSnvLlplEsEMBAtbKvg4dn1AOEuJpXtDYrWrzZDs+/wwz5PfQ2oCZ3YRHNx2
po6di9uOSlLq0BJJfSrM
=3DHbNG
-----END PGP SIGNATURE-----