Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1WfDSe-0007Tk-Pe
	for bitcoin-development@lists.sourceforge.net;
	Tue, 29 Apr 2014 19:13:00 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.54 as permitted sender)
	client-ip=209.85.220.54; envelope-from=gavinandresen@gmail.com;
	helo=mail-pa0-f54.google.com; 
Received: from mail-pa0-f54.google.com ([209.85.220.54])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WfDSd-0007Qk-Q3
	for bitcoin-development@lists.sourceforge.net;
	Tue, 29 Apr 2014 19:13:00 +0000
Received: by mail-pa0-f54.google.com with SMTP id lf10so678618pab.13
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 29 Apr 2014 12:12:53 -0700 (PDT)
X-Received: by 10.66.65.169 with SMTP id y9mr1737618pas.145.1398798773682;
	Tue, 29 Apr 2014 12:12:53 -0700 (PDT)
Received: from [10.185.252.215] (98.sub-70-197-12.myvzw.com. [70.197.12.98])
	by mx.google.com with ESMTPSA id
	ey5sm116699810pab.22.2014.04.29.12.12.52 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 29 Apr 2014 12:12:52 -0700 (PDT)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Gavin <gavinandresen@gmail.com>
X-Mailer: iPhone Mail (11D167)
In-Reply-To: <535FD6DC.8000002@bitonic.nl>
Date: Tue, 29 Apr 2014 12:12:49 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <91F405F1-7F82-42EA-8517-7E2A9444D91A@gmail.com>
References: <CABsx9T2v=oX5eR9yoBULPVceZFD2_d+xMF7jQJACHYP=FgWK-A@mail.gmail.com>
	<535FD6DC.8000002@bitonic.nl>
To: Jouke Hofman <jouke@bitonic.nl>
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
	(gavinandresen[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: 1WfDSd-0007Qk-Q3
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal to change payment protocol
	signing
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: Tue, 29 Apr 2014 19:13:00 -0000

Consensus is the spec should be clarified to match current behavior, so it w=
on't change.

--
Gavin Andresen


> On Apr 29, 2014, at 9:44 AM, Jouke Hofman <jouke@bitonic.nl> wrote:
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> We have BIP70 already in use (over a hundred paid requests).
>=20
> Could you elaborate on why this needs changing?
>=20
>=20
>=20
>> On 28-04-14 14:39, Gavin Andresen wrote:
>> There is a discussion about clarifying how BIP70 signs payment
>> requests here: https://github.com/bitcoin/bips/pull/41
>>=20
>> The issue is what to do with the signature field before signing.
>> The code Mike and I initially wrote does this:
>>=20
>> request.set_signature(string(""));
>>=20
>> (sets signature to the empty string)
>>=20
>> I think that is a mistake; it should be:
>>=20
>> request.clear_signature();
>>=20
>> (clears signature field, so it is not serialized at all).
>>=20
>> So: if you are implementing, or have implemented, the payment
>> protocol, please chime in. I'd like to change the spec and the
>> reference implementation NOW, while BIP70 is still a 'Draft'.
>>=20
>> Because this type of "hey, I'm implementing your standard and it
>> doesn't work the way I think it should" mistake is exactly why BIPs
>> take a while before being declared 'Final.'
>>=20
>>=20
>>=20
>>=20
>> ---------------------------------------