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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Public key and signature malleability
Precedence: list

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