Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z6TFr-0005GD-35 for bitcoin-development@lists.sourceforge.net; Sun, 21 Jun 2015 00:36:59 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.47 as permitted sender) client-ip=209.85.220.47; envelope-from=elombrozo@gmail.com; helo=mail-pa0-f47.google.com; Received: from mail-pa0-f47.google.com ([209.85.220.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z6TFp-0003hM-Oe for bitcoin-development@lists.sourceforge.net; Sun, 21 Jun 2015 00:36:59 +0000 Received: by padev16 with SMTP id ev16so109334002pad.0 for ; Sat, 20 Jun 2015 17:36:52 -0700 (PDT) X-Received: by 10.68.57.130 with SMTP id i2mr45479655pbq.95.1434847012114; Sat, 20 Jun 2015 17:36:52 -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 cp10sm15368509pdb.44.2015.06.20.17.36.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jun 2015 17:36:51 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4FD06163-4F1C-4554-BEEB-6A134E9E4A6C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: <6d025db96e7aec4e6e47a76883a9a1e3@riseup.net> Date: Sat, 20 Jun 2015 17:36:47 -0700 Message-Id: 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> <6d025db96e7aec4e6e47a76883a9a1e3@riseup.net> To: justusranvier@riseup.net X-Mailer: Apple Mail (2.2098) X-Spam-Score: -0.8 (/) 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 1.0 HTML_MESSAGE BODY: HTML included in message -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.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z6TFp-0003hM-Oe 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:36:59 -0000 --Apple-Mail=_4FD06163-4F1C-4554-BEEB-6A134E9E4A6C Content-Type: multipart/alternative; boundary="Apple-Mail=_E55F652E-24DD-489A-9944-787B5DC86156" --Apple-Mail=_E55F652E-24DD-489A-9944-787B5DC86156 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 20, 2015, at 5:27 PM, justusranvier@riseup.net wrote: >=20 > Signed PGP part > On 2015-06-20 19:19, Eric Lombrozo wrote: > >> On Jun 20, 2015, at 4:37 PM, justusranvier@riseup.net wrote: > >> > >> 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 = existence > >> >> 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. > >> > >> > >> Non-repudiation is an intrinsic property of the ECDSA signatures = which > >> Bitcoin uses - it's not a feature that needs to be built. > >> > >> 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. > >> > >> > > > > Justus, > > > > We don=E2=80=99t even have a concept of identity in the Bitcoin = protocol, 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? > > > > 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. > > > > > > Furthermore, in light of the fact that there *are* fully legitimate > > use cases for sending conflicting transactions=E2=80=A6and the fact = that > > 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 >=20 > Bitcoin has no concept of identity, but in any type of commercial > transaction the parties involved must know some minimal amount of > identity information in order to transact at all. >=20 > Except for some identifiable special cases, I think a payee is = perfectly > justified in treating a double spend of a payment sent to them as part > of a commercial transaction as a fraud attempt and employing whatever > non-Bitcoin recourse mechanisms, if any, they have access to. >=20 > =46rom the perspective of the network, the obviously correct action = for > any node or miner is to relay the first version of any transaction = they > see. The primary purpose of mining is to resolve this > otherwise-unresolvable problem of determining which transaction among = a > set of conflicting transactions happened first. >=20 > If a node or miner wants to deviate from the obviously correct > behaviour, and if they want to avoid harming the value of the network, > they should be particularly careful to make sure their deviation from > "first seen" doesn't introduce harmful unintended side effects, like > making fraud easier. >=20 The contract between the buyer and seller is actually outside the = Bitcoin network. Yes, a merchant that gets cheated could seek some other = recourse in such an event=E2=80=A6but the behavior you=E2=80=99re = claiming as =E2=80=9Cobviously correct=E2=80=9D is NOT obviously = correct. In fact, there are arguments against this =E2=80=9Cobviously = correct=E2=80=9D way even if we were to accept the premise that the = signature implies a promise to pay (which I think many reasonable = individuals would also dispute). For instance, by relaying conflicting = transactions it makes it potentially easier for others to discover the = double-spend attempt (of course, this requires wallets to not be lazy = about this=E2=80=A6perhaps such relays could be flagged or placed in a = special message type). - Eric Lombrozo --Apple-Mail=_E55F652E-24DD-489A-9944-787B5DC86156 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 20, 2015, at 5:27 PM, justusranvier@riseup.net wrote:

Signed PGP part
On 2015-06-20 19:19, Eric Lombrozo wrote:
>> On Jun 20, 2015, at 4:37 PM, justusranvier@riseup.net wrote:
>>
>> 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 existence
>> >> = 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.
>>
>>
>> Non-repudiation is an = intrinsic property of the ECDSA signatures which
>> = Bitcoin uses - it's not a feature that needs to be built.
>>
>> 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.
>>
>>
>
> Justus,
>
> We don=E2=80=99t even have a concept of identity in the = Bitcoin protocol, 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?
>
> 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.
>
>
> Furthermore, in light of the fact = that there *are* fully legitimate
> use cases for = sending conflicting transactions=E2=80=A6and the fact that
> 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
transaction the parties involved = must know some minimal amount of
identity information in = order to transact at all.

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

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

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


The contract between the buyer and seller is = actually outside the Bitcoin network. Yes, a merchant that gets cheated = could seek some other recourse in such an event=E2=80=A6but the behavior = you=E2=80=99re claiming as =E2=80=9Cobviously correct=E2=80=9D is NOT = obviously correct.  In fact, there are arguments against this = =E2=80=9Cobviously correct=E2=80=9D way even if we were to accept the = premise that the signature implies a promise to pay (which I think many = reasonable individuals would also dispute). For instance, by relaying = conflicting transactions it makes it potentially easier for others to = discover the double-spend attempt (of course, this requires wallets to = not be lazy about this=E2=80=A6perhaps such relays could be flagged or = placed in a special message type).

- Eric Lombrozo



= --Apple-Mail=_E55F652E-24DD-489A-9944-787B5DC86156-- --Apple-Mail=_4FD06163-4F1C-4554-BEEB-6A134E9E4A6C 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 iQIcBAEBCgAGBQJVhgcfAAoJEJNAI64YFENUk6gQAJ34cbEur/arGUQZUjluZXBu XYxnQLAZ35WjJEVFwZjBaj2KkH9ti2lcIuDJygdvwOc4Fe6+Kq4+rKgLVdQtZpJf b7yVfbkoKIxgcWL/eWMeLslxwLmfWCAcePJBVM/gvUazjpfNlpkyJUvTZpEtTZh0 ppWjdp7K+MON/aSgosJLRIdIkzqUGnd0uXKCoYqZOhJ6ArYYIRSLezj+in1mHpzY muAAXsvb/ezve5wmFiY2JVg2MK0OU/hRGTPtLEWWpsU38mw4VPaYA5ayFw9bYoo2 b/UswMaI2m4WGdU7ezq8GMvSbbllEAA36xCyXaPh1y6sevRyV1SP8PLCE+enD4fh vbNBymvW7D8nAnDWfUMD+bsOYWnDg2vBBbgOLy52NsvR1e6/wrrzZzLI9j9n9KrS F1BYmL2MnvX2MOZPu8RBVSwuv7lT3/7rUYdyQ9qo7cc8NB6h3f6Aaqw76ZqOSbGb gDm3yMCjxS5SAH4ZND8FxsWKOnG1kJDUPLnsG6SLYEunGQp9Jvyv/qeCwmP4EjvA VLxQqHsLUiBXQWLYvGoAEcMPtEy7OrKQBRCwDCRPlDWIudT4ObgJe1XHzaGJOGxj dimGuiTiO+AHD+Aa+ODtucgcciNZ39142awFWn8z+JRH7e65dFldT2XtV7N+4DKk 54nVU6a4PEe32ZcneHJO =LNOZ -----END PGP SIGNATURE----- --Apple-Mail=_4FD06163-4F1C-4554-BEEB-6A134E9E4A6C--