From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1Z6T6y-0007ga-8U for bitcoin-development@lists.sourceforge.net; Sun, 21 Jun 2015 00:27:48 +0000 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; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z6T6x-0003V9-0e for bitcoin-development@lists.sourceforge.net; Sun, 21 Jun 2015 00:27:48 +0000 Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 15C5D416D2; Sun, 21 Jun 2015 00:27:41 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: justusranvier) with ESMTPSA id E72F6208BA 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 In-Reply-To: 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> <8a49c53a032503eeca4f51cdef725fe1@riseup.net> Message-ID: <6d025db96e7aec4e6e47a76883a9a1e3@riseup.net> X-Sender: justusranvier@riseup.net User-Agent: Riseup mail X-Virus-Scanned: clamav-milter 0.98.7 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.0 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z6T6x-0003V9-0e Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 00:27:48 -0000 -----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 >> > 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-----