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 ) id 1X7Q9W-0000ZB-FF for bitcoin-development@lists.sourceforge.net; Wed, 16 Jul 2014 14:25:50 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.212.173 as permitted sender) client-ip=209.85.212.173; envelope-from=jgarzik@bitpay.com; helo=mail-wi0-f173.google.com; Received: from mail-wi0-f173.google.com ([209.85.212.173]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1X7Q9V-00030F-B0 for bitcoin-development@lists.sourceforge.net; Wed, 16 Jul 2014 14:25:50 +0000 Received: by mail-wi0-f173.google.com with SMTP id f8so5318119wiw.6 for ; Wed, 16 Jul 2014 07:25:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=D22R4sCSdZUbMeVMbhG1ttFtHxWxZglJrB/LBlnPXGg=; b=Vn6jYHdk2AsXvqMgYtkE200nVx/GWhX9JiFhv8SIXJEM7P2wG38vhGHd8EuXa7sCYa pC43BCRCr3SJu4HILd84FHipSDsShgt56QgJ7+buyaj5l+mmZje78sgHhCwNDYlCZLzR Gu1rzW77S0Z5kln+j78LobtNMZbeYWCKwSJiUsSGIg3Jqh5mFgxwF7ynlO2MQyI5tH4L 1v0snqiBEEVIKsFcXe8s4frKf3sPCn6nh56QnyId1EYnrEBZCdMExTvdlFVv1BHvpE1/ //bptvEVtjnZiI21VTQy1s/jVf0cxA3wNy1WYo7cGp1/q3Snl7qJBbKL42N9CrlW81/x zGjg== X-Gm-Message-State: ALoCoQkTbsjcQCHeltGTOl/oDRBWhNO9nqtgfmFykXf+/nOMslXD2RdWpZgb6kZHdO6i0bQy+djc X-Received: by 10.181.13.44 with SMTP id ev12mr14351644wid.57.1405520737754; Wed, 16 Jul 2014 07:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.5.67 with HTTP; Wed, 16 Jul 2014 07:25:17 -0700 (PDT) In-Reply-To: References: From: Jeff Garzik Date: Wed, 16 Jul 2014 10:25:17 -0400 Message-ID: To: Mike Hearn 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 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: 1X7Q9V-00030F-B0 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 14:25:50 -0000 On the specific issue I raised, the BIP only says "Querying multiple nodes and combining their answers can be a partial solution to this" which is not very helpful advice. That's a partial answer to my question #2 with zero response for question #3. This sort of thing really needs a warning label like "use only if you don't have a trusted solution" and discussion of that choice is completely absent (question #1). On Wed, Jul 16, 2014 at 8:37 AM, Mike Hearn wrote: > 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. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/