Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WYDBF-0006Gq-Pj for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 11:30:05 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.179 as permitted sender) client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f179.google.com; Received: from mail-ob0-f179.google.com ([209.85.214.179]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WYDBE-0006Xl-W7 for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 11:30:05 +0000 Received: by mail-ob0-f179.google.com with SMTP id va2so4262628obc.10 for ; Thu, 10 Apr 2014 04:29:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.233.201 with SMTP id ty9mr13647699obc.29.1397129399422; Thu, 10 Apr 2014 04:29:59 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Thu, 10 Apr 2014 04:29:59 -0700 (PDT) In-Reply-To: References: <534570A2.9090502@gmx.de> <0B038624-8861-438E-B7B1-566B4A8E126B@bitsofproof.com> Date: Thu, 10 Apr 2014 13:29:59 +0200 X-Google-Sender-Auth: TgnIPudutjaxGcBxXUv5wXciWN8 Message-ID: From: Mike Hearn To: Wladimir Content-Type: multipart/alternative; boundary=001a11c1c5088ed66904f6ae8978 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: 1WYDBE-0006Xl-W7 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets 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: Thu, 10 Apr 2014 11:30:05 -0000 --001a11c1c5088ed66904f6ae8978 Content-Type: text/plain; charset=UTF-8 > > What would this involve? > > Do you know of any previous work towards this? > Chain pruning is a fairly complicated project, partly because it spans codebases. For instance if you try and implement it *just* by changing Bitcoin Core, you will break all the SPV clients based on bitcoinj (i.e. all of them). Big changes to the P2P network like this require upgrading both codebases simultaneously. I think things like this may be why Gavin is now just "chief scientist" instead of Core maintainer - in future, the changes people need will span projects and require fairly significant planning. From a technical perspective, it means extending addr broadcasts so nodes broadcast how much of the chain they have, and teaching both Core and bitcoinj how to search for nodes that have enough of the chain for them to use. Currently bitcoinj still doesn't use addr broadcasts at all, there's an incomplete patch available but it was never finished or merged. So that has to be fixed first. And that probably implies improving Bitcoin Core so the results of getaddr are more usable, ideally as high quality as what the DNS seeds provide, because if lots of bad addresses are returned this will slow down initial connect time, which is an important performance metric. --001a11c1c5088ed66904f6ae8978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What would this involve?

Do you know of any previous= work towards this?

Chain pruning is a fairly complicated project, partly because it spans cod= ebases. For instance if you try and implement it just=C2=A0by changi= ng Bitcoin Core, you will break all the SPV clients based on bitcoinj (i.e.= all of them). Big changes to the P2P network like this require upgrading b= oth codebases simultaneously.

I think things like this may be why Gavin is now just &= quot;chief scientist" instead of Core maintainer - in future, the chan= ges people need will span projects and require fairly significant planning.=

From a technical perspective, it means extending addr b= roadcasts so nodes broadcast how much of the chain they have, and teaching = both Core and bitcoinj how to search for nodes that have enough of the chai= n for them to use. Currently bitcoinj still doesn't use addr broadcasts= at all, there's an incomplete patch available but it was never finishe= d or merged. So that has to be fixed first. And that probably implies impro= ving Bitcoin Core so the results of getaddr are more usable, ideally as hig= h quality as what the DNS seeds provide, because if lots of bad addresses a= re returned this will slow down initial connect time, which is an important= performance metric.


--001a11c1c5088ed66904f6ae8978--