summaryrefslogtreecommitdiff
path: root/b8/ee621e01da3fa528404bc64a46dad67f1d8c5f
blob: bfa8c652102adef0c95eb48bc6f376d50fc7ac9b (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <laanwj@gmail.com>) id 1TPpJr-0008AP-Sd
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Oct 2012 06:47:31 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.175 as permitted sender)
	client-ip=209.85.217.175; envelope-from=laanwj@gmail.com;
	helo=mail-lb0-f175.google.com; 
Received: from mail-lb0-f175.google.com ([209.85.217.175])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1TPpJr-0001rK-2T
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Oct 2012 06:47:31 +0000
Received: by mail-lb0-f175.google.com with SMTP id y2so1086899lbk.34
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 20 Oct 2012 23:47:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.110.42 with SMTP id hx10mr5086350lab.0.1350802044480; Sat,
	20 Oct 2012 23:47:24 -0700 (PDT)
Received: by 10.112.43.138 with HTTP; Sat, 20 Oct 2012 23:47:24 -0700 (PDT)
In-Reply-To: <CAPg+sBgBtYUHtHq1MnKuFJHc=NGZ4t+SxHDs0TLKmzf8bSig=g@mail.gmail.com>
References: <CAPg+sBgBtYUHtHq1MnKuFJHc=NGZ4t+SxHDs0TLKmzf8bSig=g@mail.gmail.com>
Date: Sun, 21 Oct 2012 08:47:24 +0200
Message-ID: <CA+s+GJCouT-ehBtJsAKCUPYgiCJYJ-vh1ysNwENRrSAsANyEJw@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=UTF-8
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
	(laanwj[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
	0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TPpJr-0001rK-2T
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Public key and signature malleability
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 Oct 2012 06:47:32 -0000

On Sat, Oct 20, 2012 at 7:55 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> In order to make the Bitcoin network rules more well-defined, I'd like
> to propose strict rules about what is acceptable, and which do not
> depend on OpenSSL's implementation.

I strongly support this too. It is good to make the protocol as
well-defined as possible in a self-contained way, ie define all the
parsing and processing without referring to specific current
implementations of other libraries such as OpenSSL.

What always bothered me is that OpenSSL can change their API to accept
new obscure key encodings at some point, or change their
interpretation, and bitcoin will automatically change with it. As
bitcoin happily links against any OpenSSL version you provide it, in
worst case, this can result in forks and unexpected behavior
completely out of our control.

Wladimir