From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WXzSH-0004Yt-Eb for bitcoin-development@lists.sourceforge.net; Wed, 09 Apr 2014 20:50:45 +0000 X-ACL-Warn: Received: from mail-ve0-f171.google.com ([209.85.128.171]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WXzSG-0003rX-Ds for bitcoin-development@lists.sourceforge.net; Wed, 09 Apr 2014 20:50:45 +0000 Received: by mail-ve0-f171.google.com with SMTP id jy13so2556683veb.2 for ; Wed, 09 Apr 2014 13:50:38 -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:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=5o54QI6yamSPPrwWqG3TVkasjVpgfZwFZym1F9oloDc=; b=ZUUf2yBpturiDw7Pl2mtQy/W7/Pu+tne2QjSlnq59A37Pfoq1fm2DlbnKNX9/I5LFG u3CG5gpXMTBlmOHTM6Ya4Xr7elcArU/K+bcNy0422bAexNFzzw/OcRypJpQsCCd8Er9Q JYwYRo3/OripH4Y6JYvIcFkln3FTfd/sP/672qC+HsKvy3XmmH8HtNmkiG9uNWmOGejW qOKNFo7I1lKiDd1Crf0afESXhdt/LhSEMIM2MIH0G1VWKOIY/zw4fokovZlMyxHuquLw 6v7SpynHcNNYXtlkBue5SHC9952ZAW0sdhgVPNx6s7S7n9kWCVDdgZu5h4x4gEbQj4UM 3XOQ== X-Gm-Message-State: ALoCoQl7T+p+gGND9hnorCn/mKwkvipRLRZs+Baerc/LL76S56Rghs8XEyZ8DdEGsM7HAchNOlu/ X-Received: by 10.58.230.103 with SMTP id sx7mr2423528vec.28.1397076638694; Wed, 09 Apr 2014 13:50:38 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.58.234.100 with HTTP; Wed, 9 Apr 2014 13:50:08 -0700 (PDT) In-Reply-To: References: <53456B99.9010207@monetize.io> <00b77560-d7ed-4ed4-a4e5-eb1f00467a06@email.android.com> <0509477C-89F9-47C7-8820-29ACAD4A4A8E@bitsofproof.com> <534592E2.7040800@gmail.com> <5345986C.3040901@gmail.com> From: slush Date: Wed, 9 Apr 2014 22:50:08 +0200 X-Google-Sender-Auth: v3EevFhAn-GPI_fRuolk3udVmmw Message-ID: To: Wladimir Content-Type: multipart/alternative; boundary=047d7bea3606c727ac04f6a24082 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WXzSG-0003rX-Ds Cc: Bitcoin Development 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: Wed, 09 Apr 2014 20:50:45 -0000 --047d7bea3606c727ac04f6a24082 Content-Type: text/plain; charset=ISO-8859-1 We definitely *need* lightweight bitcoin router / "core" which can be easily deployed anywhere. No disagreement here. I just wanted to remind that there're actually much more running nodes *already* and maybe converting those hidden nodes to publicly reachable nodes may be way easier than attracting fresh instances. To the idea of bundled core with SPV clients - it won't improve anything, in my opinion. SPV wallets are not running long-term (maybe Multibit team has any better stats) so blockchain catching will turn the computer to be unusable everytime user starts the wallet; that's exactly the reason why people choose SPV wallets over full blockchain wallets. Not saying that SPV clients usually aren't reachable from outside, which turns the topic back to my ideas about motivating users to expose their existing instances over Internet. Marek On Wed, Apr 9, 2014 at 10:35 PM, Wladimir wrote: > > > On Wed, Apr 9, 2014 at 10:12 PM, slush wrote: > >> Maybe there're other ideas how to improve current situation without needs >> of reworking the architecture. >> > > Nothing I've proposed here would require larger changes to the > architecture then were already planned. After SPV lands we are going to > split off the wallet, and that will need an interface to an bitcoind to > allow 'running with full node'. If that can be generalized to be useful for > other (SPV) clients as well, that would be useful, hence I asked for input. > > It of course doesn't preclude also looking for other solutions. > > Wladimir > > --047d7bea3606c727ac04f6a24082 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We definitely *need* lightweight bitcoin router / "co= re" which can be easily deployed anywhere. No disagreement here.
<= br>
I just wanted to remind that there're actually much more = running nodes *already* and maybe converting those hidden nodes to publicly= reachable nodes may be way easier than attracting fresh instances.

To the idea of bundled core with SPV clients - it won&#= 39;t improve anything, in my opinion. SPV wallets are not running long-term= (maybe Multibit team has any better stats) so blockchain catching will tur= n the computer to be unusable everytime user starts the wallet; that's = exactly the reason why people choose SPV wallets over full blockchain walle= ts.

Not saying that SPV clients usually aren't reachabl= e from outside, which turns the topic back to my ideas about motivating use= rs to expose their existing instances over Internet.

Marek

On Wed, Apr 9, 2014 at 10:35 PM, Wladimir <laanwj@gmail.com>= ; wrote:


On Wed, Apr 9, 2014 at 1= 0:12 PM, slush <slush@centrum.cz> wrote:
Maybe= there're other ideas how to improve current situation without needs of= reworking the architecture.

Nothing I've proposed here would= require larger changes to the architecture then were already planned. Afte= r SPV lands we are going to split off the wallet, and that will need an int= erface to an bitcoind to allow 'running with full node'. If that ca= n be generalized to be useful for other (SPV) clients as well, that would b= e useful, hence I asked for input.

It of course doesn't preclude also looking for other sol= utions.

Wladi= mir


--047d7bea3606c727ac04f6a24082--