1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
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 <justusranvier@riseup.net>) 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 <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>
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 <bitcoin-development@lists.sourceforge.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: 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 <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-----
|
