From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vrabx-0006XX-9o for bitcoin-development@lists.sourceforge.net; Fri, 13 Dec 2013 21:49:29 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.51 as permitted sender) client-ip=209.85.219.51; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f51.google.com; Received: from mail-oa0-f51.google.com ([209.85.219.51]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Vrabw-0007Zj-Gh for bitcoin-development@lists.sourceforge.net; Fri, 13 Dec 2013 21:49:29 +0000 Received: by mail-oa0-f51.google.com with SMTP id i7so2730429oag.24 for ; Fri, 13 Dec 2013 13:49:23 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.219.167 with SMTP id pp7mr10145obc.85.1386971363125; Fri, 13 Dec 2013 13:49:23 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.92.72 with HTTP; Fri, 13 Dec 2013 13:49:23 -0800 (PST) In-Reply-To: <52AB5DA9.1060701@monetize.io> References: <52AB5DA9.1060701@monetize.io> Date: Fri, 13 Dec 2013 13:49:23 -0800 X-Google-Sender-Auth: 9Gk20SCOy3dt7AtrCd1N99xP1Ak Message-ID: From: Mike Hearn To: Mark Friedenbach Content-Type: multipart/alternative; boundary=089e0141ab8269fa0504ed716f26 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1Vrabw-0007Zj-Gh Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Merge avoidance and P2P connection encryption X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 21:49:29 -0000 --089e0141ab8269fa0504ed716f26 Content-Type: text/plain; charset=UTF-8 > > Or alternatively, the user-signed payment request without iteration > count is enclosed within a payr.com-signed envelope that contains the > iteration count. But how does that show up in the user interface? I don't know how you would explain what the signature means or implies, or what you do if the signature is broken/missing. The only thing that a maliciously modified iteration count can do is cause money to be sent to an address that's beyond the recipients gap limit, meaning they won't receive it (unless they reconfigure their software and rescan). But you can't steal money that way. --089e0141ab8269fa0504ed716f26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Or alternatively, the user-signed payment reques= t without iteration
count is enclosed within a payr.com-signed envelope that contains the
iteration count.

But how does that show up = in the user interface? I don't know how you would explain what the sign= ature means or implies, or what you do if the signature is broken/missing.<= /div>

The only thing that a maliciously modified iteration co= unt can do is cause money to be sent to an address that's beyond the re= cipients gap limit, meaning they won't receive it (unless they reconfig= ure their software and rescan). But you can't steal money that way.
--089e0141ab8269fa0504ed716f26--