Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TfyIR-00028z-Fm for bitcoin-development@lists.sourceforge.net; Tue, 04 Dec 2012 19:36:47 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.169 as permitted sender) client-ip=209.85.210.169; envelope-from=gmaxwell@gmail.com; helo=mail-ia0-f169.google.com; Received: from mail-ia0-f169.google.com ([209.85.210.169]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TfyIO-0006Ei-Ps for bitcoin-development@lists.sourceforge.net; Tue, 04 Dec 2012 19:36:47 +0000 Received: by mail-ia0-f169.google.com with SMTP id r4so3907623iaj.14 for ; Tue, 04 Dec 2012 11:36:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.57.200 with SMTP id k8mr3960276igq.29.1354649799418; Tue, 04 Dec 2012 11:36:39 -0800 (PST) Received: by 10.64.171.73 with HTTP; Tue, 4 Dec 2012 11:36:39 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Dec 2012 14:36:39 -0500 Message-ID: From: Gregory Maxwell To: Mark Friedenbach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 (gmaxwell[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: 1TfyIO-0006Ei-Ps Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients 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: Tue, 04 Dec 2012 19:36:47 -0000 On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach wrote: > Alan's :( > UTxO meta-chain proposal becomes vastly easier to do now that > ultraprune is merged. No, not really. Somewhat easier due to some structural changes, but it still needs to invent and get consensus on a normative data structure and people need to write implementations of the required operations on it (implementations probably required to prove performance for consensus). We still have to sort through the tradeoff of making a _single_ data structure the normative merkle tree representation for the UTxO set to the preclusion of other implementations=E2=80=94 including ones which are asymptotically faster, such as a straight hash table. There are also issues that need to be sorted out like key structure=E2=80= =94 the most useful index for validation is txid:vout keyed, but Alan wanted 'address' prefixed, which is not friendly for validation but enables robust query by address=E2=80=94 a query that the referce normal bitcoin software doesn't even optionally support right now. Any disagreements on this point must be hammed out because the structure would be normative. > That would allow the Satoshi client to know it's > wallet balance and operate with a >=3DSPV level of security during the in= itial > block download, and keep them on the path of becoming a full node. If use= rs > can see their balances, send and receive transactions, and otherwise go > about their business (except for mining) during the initial block downloa= d, > would that not address your concerns? The above said, that is all good stuff too. And I do thing starting fast with reduced security (be it to SPV+ or SPV) is a good idea.