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
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <elombrozo@gmail.com>) id 1Z6Syk-0004hG-Pc
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Jun 2015 00:19:18 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.178 as permitted sender)
client-ip=209.85.192.178; envelope-from=elombrozo@gmail.com;
helo=mail-pd0-f178.google.com;
Received: from mail-pd0-f178.google.com ([209.85.192.178])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z6Syj-0004GG-Jz
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Jun 2015 00:19:18 +0000
Received: by pdbci14 with SMTP id ci14so55845603pdb.2
for <bitcoin-development@lists.sourceforge.net>;
Sat, 20 Jun 2015 17:19:12 -0700 (PDT)
X-Received: by 10.68.191.229 with SMTP id hb5mr45297066pbc.126.1434845951974;
Sat, 20 Jun 2015 17:19:11 -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
kk6sm15326906pdb.94.2015.06.20.17.19.09
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 20 Jun 2015 17:19:10 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_662DD05E-826F-4A21-9B92-A3CD3128D3F4";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <8a49c53a032503eeca4f51cdef725fe1@riseup.net>
Date: Sat, 20 Jun 2015 17:19:08 -0700
Message-Id: <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>
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: 1Z6Syj-0004GG-Jz
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:19:18 -0000
--Apple-Mail=_662DD05E-826F-4A21-9B92-A3CD3128D3F4
Content-Type: multipart/alternative;
boundary="Apple-Mail=_BBEDAE13-DF98-4C94-B7CF-60EA84F15161"
--Apple-Mail=_BBEDAE13-DF98-4C94-B7CF-60EA84F15161
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> 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 =
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.
>=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
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
- Eric Lombrozo
--Apple-Mail=_BBEDAE13-DF98-4C94-B7CF-60EA84F15161
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jun 20, 2015, at 4:37 PM, <a =
href=3D"mailto:justusranvier@riseup.net" =
class=3D"">justusranvier@riseup.net</a> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><fieldset =
style=3D"padding-top:10px; border:0px; border: 3px solid #CCC; =
padding-left: 20px;" class=3D""><legend style=3D"font-weight:bold" =
class=3D"">Signed PGP part</legend><div style=3D"padding-left:3px;" =
class=3D"">On 2015-06-20 18:20, Jorge Tim=C3=B3n wrote:<br class=3D"">>=
On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <<a =
href=3D"mailto:elombrozo@gmail.com" =
class=3D"">elombrozo@gmail.com</a>><br class=3D"">> wrote:<br =
class=3D"">>> If we want a non-repudiation mechanism in the =
protocol, we should<br class=3D"">>> explicitly define one rather =
than relying on =E2=80=9Cprima facie=E2=80=9D<br class=3D"">>> =
assumptions. Otherwise, I would recommend not relying on the =
existence<br class=3D"">>> of a signed transaction as proof of =
intent to pay=E2=80=A6<br class=3D"">><br class=3D"">> =
Non-repudiation can be built on top of the payment protocol layer.<br =
class=3D""><br class=3D""><br class=3D"">Non-repudiation is an intrinsic =
property of the ECDSA signatures which<br class=3D"">Bitcoin uses - it's =
not a feature that needs to be built.<br class=3D""><br class=3D"">There's=
no way to accidentally sign a transaction and accidentally<br =
class=3D"">announce it publicly. There is no form of third-party error =
that can<br class=3D"">result in a payee receiving an erroneous =
contract.<br class=3D""></div></fieldset><br class=3D""><br =
class=3D""></div></blockquote></div><br class=3D""><div =
class=3D"">Justus,</div><div class=3D""><br class=3D""></div><div =
class=3D"">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?</div><div class=3D""><br class=3D""></div><div =
class=3D"">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.</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">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</div><div class=3D""><br class=3D""></div><div =
class=3D"">- Eric Lombrozo</div></body></html>=
--Apple-Mail=_BBEDAE13-DF98-4C94-B7CF-60EA84F15161--
--Apple-Mail=_662DD05E-826F-4A21-9B92-A3CD3128D3F4
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
iQIcBAEBCgAGBQJVhgL8AAoJEJNAI64YFENUB+MP+wZPGXO1Ph77RCKVMFrVoyZY
nEa5fRHPMvRqlygf9E+r60hSPDHtjnjeUQoGfslrHizppyJ/3U4O+qTWFyjcad/B
bFzZVgvsB9zrT+F8Y6DmApd7QKxDSxb2GlKNcovY5B7wTsrjcyiu/eZT2sxZtBM2
GQyUKeqUyGp1lR3t8px3mEToAe46y0E/lVICVeYfDDpPIswSpxa2CBxDCuoWklSH
R5rQww6xiovWwkmF8aLEfsXHVQ/Z/I6FMoV28wyZQ6JbsITr3aaNDmCOr02b2F3X
VdPu5h1JjsI6DVJALRllFemQGHSM0l8DMk2reK0R0RogfNQwKPKlq6mxP4hng+9y
3Jje1s5jmSVQHfs8wzM9B4pRUSqK2uVJNjPKO0IczRR5TxYZLt/2IE/7vqPp5F5d
8JW/aiTiuZAqf5ikegzbeq/x7kMblKBEY/WAkgBg6ibLXTSABWhh1SqH3VIo2HwM
3OUiLC0KL3n/SSguoZnBVars1U4IB3HFHyhIo1NzKI0lG1CnMX82QC0hNSLK3YXm
tGlZsVaKZ6NxfgpSl/heB/sGzFtwcJboPQ4wfLSDL4QWf78RCDCYxes/TEg9WWfe
go3crpeKHpAHBfu2uD5elAmhPcFHPTHje+cx9FqwtH0gfilFLaDO9khsfpL1vDg6
51M+ORUHqEcLvH1t8y6B
=9odg
-----END PGP SIGNATURE-----
--Apple-Mail=_662DD05E-826F-4A21-9B92-A3CD3128D3F4--
|
