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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1WmUmi-0006hS-JB
for bitcoin-development@lists.sourceforge.net;
Mon, 19 May 2014 21:07:48 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.48 as permitted sender)
client-ip=209.85.215.48; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f48.google.com;
Received: from mail-la0-f48.google.com ([209.85.215.48])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WmUmh-0001RP-Ha
for bitcoin-development@lists.sourceforge.net;
Mon, 19 May 2014 21:07:48 +0000
Received: by mail-la0-f48.google.com with SMTP id mc6so4556690lab.35
for <bitcoin-development@lists.sourceforge.net>;
Mon, 19 May 2014 14:07:38 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.6.3 with SMTP id w3mr13159289law.34.1400533658758; Mon,
19 May 2014 14:07:38 -0700 (PDT)
Received: by 10.112.89.68 with HTTP; Mon, 19 May 2014 14:07:38 -0700 (PDT)
In-Reply-To: <537A630D.104@localhost.local>
References: <CABsx9T2=nE1c-WOGnQiBqfFQqM0qtPiCcBsWN8pew6JhdpBNOA@mail.gmail.com>
<537A630D.104@localhost.local>
Date: Mon, 19 May 2014 14:07:38 -0700
Message-ID: <CAAS2fgQADU27NABcP1r52YTgDUy+PX7OZfT5H7XSsecjy1dmQg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Justus Ranvier <justusranvier@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
X-Headers-End: 1WmUmh-0001RP-Ha
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Working on social contracts (was: Paper
Currency)
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: Mon, 19 May 2014 21:07:48 -0000
On Mon, May 19, 2014 at 1:01 PM, Justus Ranvier <justusranvier@gmail.com> w=
rote:
> YOU can make promises about YOUR future behavior. So can everyone else.
>
> The rest of the community can keep track of which developers will and
> will not make promises about what changes they will and will not
> attempt to implement in Bitcoin, and they can use that information to
> make informed decisions about which software they will choose to support.
I promise that if bad people show up with a sufficient pointy gun that
I'll do whatever they tell me to do. I'll make bad proposals, submit
backdoors, and argue with querulous folks on mailing lists, diverting
them from real development and review work, all as commanded. Maybe
I'll try to sneak out a warning of some kind, maybe... but with my
life or my families or friends lives on the line=E2=80=94 probably not.
... and I think that anyone who tells you otherwise probably just
hasn't really thought it through. So what is the point of commitments
like that? People change, people go crazy, people are coerced. Crap
happens, justifications are made, life goes on=E2=80=94 or so we hope.
What matters is building infrastructure=E2=80=94 both social and technical=
=E2=80=94
that is robust against those sorts of failures. If you're depending on
individual developers (including anonymous parties and volunteers) to
be somehow made more trustworthy by some promises on a mailing list
you've already lost.
If you care about this you could instead tell us about how much time
you promise to spend reviewing technical work to make sure such
attacks cannot be successful, regardless of their origins. Where are
your gitian signatures? I think thats a lot more meaningful, and it
also improves security for everyone involved since knowing that such
attacks can not succeeded removes the motivation for ever trying.
A lot of what Bitcoin is about, for me at least, is building systems
which are as trustless as possible=E2=80=94 ruled by unbreakable rules
embodied in the software people chose to use out of their own free
will and understanding. Or at least thats the ideal we should try to
approximate. If we're successful the adhomenim you've thrown on this
list will be completely pointless=E2=80=94 not because people are trusted t=
o
not do evil but because Bitcoin users won't accept technology that
makes it possible.
So please go ahead and assume I'm constantly being evil and trying to
sneak something in... the technology and security can only be better
for it, but please leave the overt attacks at the door. Think
gentleman spies, not a street fighting death match. The rude attacks
and characterizations just turn people off and don't uncover actual
attacks. Maybe the informal guideline should be one flame-out
personal attack per cryptosystem you break, serious bug you uncover,
or impossible problem you solve. :)
|
