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 ) id 1X7OSs-00012I-9d for bitcoin-development@lists.sourceforge.net; Wed, 16 Jul 2014 12:37:42 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.43 as permitted sender) client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f43.google.com; Received: from mail-oa0-f43.google.com ([209.85.219.43]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1X7OSr-0004HA-3t for bitcoin-development@lists.sourceforge.net; Wed, 16 Jul 2014 12:37:42 +0000 Received: by mail-oa0-f43.google.com with SMTP id i7so871727oag.16 for ; Wed, 16 Jul 2014 05:37:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.125.195 with SMTP id ms3mr35019688oeb.40.1405514255626; Wed, 16 Jul 2014 05:37:35 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.35.234 with HTTP; Wed, 16 Jul 2014 05:37:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Jul 2014 14:37:35 +0200 X-Google-Sender-Auth: W8a0ef-OzqtTaF_oWhNicGV-30Y Message-ID: From: Mike Hearn To: Jeff Garzik Content-Type: multipart/alternative; boundary=047d7b33cf28eefb2804fe4ec9dc 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: 1X7OSr-0004HA-3t Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Draft BIP for geutxos message 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: Wed, 16 Jul 2014 12:37:42 -0000 --047d7b33cf28eefb2804fe4ec9dc Content-Type: text/plain; charset=UTF-8 Thanks Jeff. I do feel like a lot of this is covered in the writeup I attached to the implementation pull request, and I went over it again in the ensuing discussion, and also in the BIP. The discussion of how to make it secure is covered in the "Upgrade" section of the writeup and in the "Authentication" section of the BIP. Please do let me know if these sections are missing something. The ideas discussed there are not implemented in this pull request because outside of some special cases, it is a very large project that involves a chain fork. You can see the start of a solution here: https://github.com/bitcoin/bitcoin/pull/3977 > If one implements your BIP in a naive manner -- simply find a node, and > issue a single query -- they are dangerously exposed to malicious > information. The BIP should describe this major security issue, and > describe at least one method of solving it (ditto implementation, if > lighthouse has not already solved this). > The BIP already does discuss this, in the authentication section. Suggestions for how to make it better are welcome. > Comparison between this and BIP 35 (mempool command) are not apt, as > miners and full nodes treat "mempool" returned data just like any other > randomly solicited "tx" command on the network. Unlike "mempool" cmd, this > "getutxos" cmd proffers post-verification trusted data. > I don't think it does proffer that, but if a part of the BIP could be read as doing so, let me know which part and I'll fix it. --047d7b33cf28eefb2804fe4ec9dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Jeff.

I do feel like a lot of this is cove= red in the writeup I attached to the implementation pull request, and I wen= t over it again in the ensuing discussion, and also in the BIP.

The discussion of how to make it secure is covered in t= he "Upgrade" section of the writeup and in the "Authenticati= on" section of the BIP. Please do let me know if these sections are mi= ssing something. The ideas discussed there are not implemented in this pull= request because outside of some special cases, it is a very large project = that involves a chain fork. You can see the start of a solution here:

=C2=A0
If one implements your = BIP in a naive manner -- simply find a node, and issue a single query -- th= ey are dangerously exposed to malicious information.=C2=A0 The BIP should d= escribe this major security issue, and describe at least one method of solv= ing it (ditto implementation, if lighthouse has not already solved this).

The BIP already does discuss this, in the authentication section. Sug= gestions for how to make it better are welcome.
=C2=A0
Comparison between this and BIP 35 (mempool command) are not apt, as = miners and full nodes treat "mempool" returned data just like any= other randomly solicited "tx" command on the network.=C2=A0 Unli= ke "mempool" cmd, this "getutxos" cmd proffers post-ver= ification trusted data.

I don't think it does prof= fer that, but if a part of the BIP could be read as doing so, let me know w= hich part and I'll fix it.
--047d7b33cf28eefb2804fe4ec9dc--