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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UXGu3-00033c-4G for bitcoin-development@lists.sourceforge.net; Tue, 30 Apr 2013 20:11:55 +0000 X-ACL-Warn: Received: from mail-pa0-f42.google.com ([209.85.220.42]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UXGu1-0005XH-NJ for bitcoin-development@lists.sourceforge.net; Tue, 30 Apr 2013 20:11:55 +0000 Received: by mail-pa0-f42.google.com with SMTP id kl13so537174pab.29 for ; Tue, 30 Apr 2013 13:11:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=eO6OoYRrcKtXeQd/bcSLM10raywROjCRt65Y2QvKfq4=; b=mMCg1xYnHw9raEPtef9kKf4scp6QpUeF+wSwa6o7xaTQVnP1LHkaHOvhfsC8Qjiu1H xuoIJW4sTYC/prPNDsAE8G+ICnrVJGJOXx8K+1TqIVI2N+eAb8ne4JpxGrjZGAVHOhZT 6ZIGPV5lZ/HWLIbT8amKwpey2fW8bwg7LFiuzT55/jJ//9Z6mshbyLZh/aNnD8VC+0d+ 7zalz2yIRCmn+luVdmLpEbeBVCrxBDaaHSEiY+y35wErtWQBigMcGQDQv98r0wCKvQ2D Xh5ilgK8M504yVAC2MDAZ6Ag/f0743dBYlO8SD8BGlgfzZG17mZ0oHVzS6/OUIzLtOnO 2GXw== MIME-Version: 1.0 X-Received: by 10.68.231.65 with SMTP id te1mr12649815pbc.98.1367352707731; Tue, 30 Apr 2013 13:11:47 -0700 (PDT) Received: by 10.68.240.106 with HTTP; Tue, 30 Apr 2013 13:11:47 -0700 (PDT) X-Originating-IP: [99.43.178.25] In-Reply-To: <201304302027.10247.andyparkins@gmail.com> References: <201304302027.10247.andyparkins@gmail.com> Date: Tue, 30 Apr 2013 16:11:47 -0400 Message-ID: From: Jeff Garzik To: Andy Parkins Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlA2kfzzX2/29KHKk1ORcP1AKSQam2AgKmWxgJh3y0N3cGT8L5V/pj5E74NCrwVFWbvm1S8 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1UXGu1-0005XH-NJ Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Fwd: Service bits for pruned nodes 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, 30 Apr 2013 20:11:55 -0000 On Tue, Apr 30, 2013 at 3:27 PM, Andy Parkins wrote: > On Tuesday 30 April 2013 19:04:59 Jeff Garzik wrote: > >> The format currently used by bitcoind would be just fine -- >> blocks/blkNNNN.dat for raw data, size-limited well below 1GB. Just >> need to add a small metadata download, and serve the raw block files. > > That doesn't seem very generic. It's tied far too much to the current storage > format of bitcoind. Hardly. The storage format is bitcoin protocol wire format, plus a tiny header. It is supported in multiple applications already, and is the most efficient storage format for bitcoin protocol blocks. > Wouldn't it be better to add support for more bitcoin-protocol-oriented HTTP > requests? Then any client can supply the same interface, rather than being > forced to create blkNNNN.dat on the fly? You don't have to create anything on the fly, if you store blocks in their native P2P wire protocol format. > http://bitcoind.example.com/block/BBBBBBBBBBBBBBBBBBBBBBB > http://bitcoind.example.com/tx/TTTTTTTTTTTTTTTTTTTTTTTT > http://bitcoind.example.com/block/oftx/TTTTTTTTTTTTTTTTTTT > http://bitcoind.example.com/peers > http://bitcoind.example.com/peer/nnn > > Essentially: block explorer's raw mode but in every bitcoind. The hardest > operation for light clients is finding out the block that contains a > particular transaction -- something that bitcoind already knows. This is a whole new client interface. It's fun to dream this up, but it is far outside the scope of an efficient HTTP protocol that downloads blocks. Your proposal is closer to a full P2P rewrite over HTTP (or a proxy thereof). -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com