diff options
| author | Mike Hearn <mike@plan99.net> | 2014-04-10 08:38:49 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-04-10 06:38:56 +0000 |
| commit | 2823d5ff858d23d4bc594b025f45f1ff01800cdb (patch) | |
| tree | 66f66a69941b3d42dacf1136412b919b60fe578b | |
| parent | c411a669557a97f2edbeb5b08ab58275ba015a86 (diff) | |
| download | pi-bitcoindev-2823d5ff858d23d4bc594b025f45f1ff01800cdb.tar.gz pi-bitcoindev-2823d5ff858d23d4bc594b025f45f1ff01800cdb.zip | |
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
| -rw-r--r-- | 87/c7f600ee5a3a8bc0d08ad85f4b1d8450e6720f | 305 |
1 files changed, 305 insertions, 0 deletions
diff --git a/87/c7f600ee5a3a8bc0d08ad85f4b1d8450e6720f b/87/c7f600ee5a3a8bc0d08ad85f4b1d8450e6720f new file mode 100644 index 000000000..f4dc2fb46 --- /dev/null +++ b/87/c7f600ee5a3a8bc0d08ad85f4b1d8450e6720f @@ -0,0 +1,305 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1WY8dU-0001Rk-Q4 + for bitcoin-development@lists.sourceforge.net; + Thu, 10 Apr 2014 06:38:56 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.214.182 as permitted sender) + client-ip=209.85.214.182; envelope-from=mh.in.england@gmail.com; + helo=mail-ob0-f182.google.com; +Received: from mail-ob0-f182.google.com ([209.85.214.182]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WY8dT-0000Qg-Ck + for bitcoin-development@lists.sourceforge.net; + Thu, 10 Apr 2014 06:38:56 +0000 +Received: by mail-ob0-f182.google.com with SMTP id uz6so3963954obc.27 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 09 Apr 2014 23:38:50 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.60.58.7 with SMTP id m7mr337104oeq.59.1397111930054; Wed, 09 + Apr 2014 23:38:50 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.96.180 with HTTP; Wed, 9 Apr 2014 23:38:49 -0700 (PDT) +Received: by 10.76.96.180 with HTTP; Wed, 9 Apr 2014 23:38:49 -0700 (PDT) +In-Reply-To: <CAJna-Hj1U5cQ22bSXoNB-4ck_urCuS9xCk+iEHsbh+yv17MP7A@mail.gmail.com> +References: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com> + <CAADm4BCEFCiOpNzUThPPHUamP2256izU8pwD3nerLCxks0wENA@mail.gmail.com> + <CAAS2fgTx40XSLhiygnJMrSbOC=iJ2YMVLNK7-AMt3ifvAHDZUA@mail.gmail.com> + <E9BAD633-3B6A-4A2C-AA06-DB591973DF66@bitsofproof.com> + <53456B99.9010207@monetize.io> + <B2FEC170-7214-4E46-8830-153995870B62@bitsofproof.com> + <00b77560-d7ed-4ed4-a4e5-eb1f00467a06@email.android.com> + <0509477C-89F9-47C7-8820-29ACAD4A4A8E@bitsofproof.com> + <CANEZrP2Q=TG+jejEVFFh5FhjzDDkySHNSTfwtKueLcHu=pB6Kw@mail.gmail.com> + <CA+s+GJBRvDFgktTgW2sCvAVahrjxcGqfgHw0BVNPvwUupotVrg@mail.gmail.com> + <534592E2.7040800@gmail.com> + <CAAS2fgS3q6N9go-NSKdjLwgU_5bFwa8YE88DcjNYHQTwzPCn3Q@mail.gmail.com> + <5345986C.3040901@gmail.com> + <CAAS2fgQyXHNnBDKoUMd_=-=1irGJ6cFKwi59enLJvFJiWBv50A@mail.gmail.com> + <CAJna-Hj1U5cQ22bSXoNB-4ck_urCuS9xCk+iEHsbh+yv17MP7A@mail.gmail.com> +Date: Thu, 10 Apr 2014 08:38:49 +0200 +X-Google-Sender-Auth: KX53sQXS2XPYikyseMUtp_1s6-w +Message-ID: <CANEZrP2w2b28qnYd7q=fo=VL0FzVE1R15s5Entuy+fK9x+V8Kg@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: slush <slush@centrum.cz> +Content-Type: multipart/alternative; boundary=089e01538c564d6e7a04f6aa78d4 +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: 1WY8dT-0000Qg-Ck +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Thu, 10 Apr 2014 06:38:56 -0000 + +--089e01538c564d6e7a04f6aa78d4 +Content-Type: text/plain; charset=UTF-8 + +I tend to agree with slush here - counting the IPs in addr broadcasts often +gives a number like 100,000 vs just 10,000 for actually reachable nodes (or +less). It seems like optimising the NAT tunneling code would help. Starting +by adding more diagnostic stuff to the GUI. STUN support may also help. + +The main constraint with home devices is not IMHO their actual power but +rather that a lot of people no longer keep computers switched on all the +time. If you don't do that then spv with bundled Core can't help your +security because the spv wallet would always be syncing from the p2p +network for performance reasons. +On 9 Apr 2014 22:13, "slush" <slush@centrum.cz> wrote: + +> I believe there're plenty bitcoind instances running, but they don't have +> configured port forwarding properly.There's uPNP support in bitcoind, but +> it works only on simple setups. +> +> Maybe there're some not yet considered way how to expose these *existing* +> instances to Internet, to strenghten the network. Maybe just self-test +> indicating the node is not reachable from outside (together with short +> howto like in some torrent clients). +> +> These days IPv6 is slowly deploying to server environments, but maybe +> there's some simple way how to bundle ipv6 tunnelling into bitcoind so any +> instance will become ipv6-reachable automatically? +> +> Maybe there're other ideas how to improve current situation without needs +> of reworking the architecture. +> +> Marek +> +> +> On Wed, Apr 9, 2014 at 9:33 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote: +> +>> On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier <justusranvier@gmail.com> +>> wrote: +>> > Anyone reading the archives of the list will see about triple the +>> > number of people independently confirming the resource usage problem +>> > than they will see denying it, so I'm not particularly worried. +>> +>> The list has open membership, there is no particular qualification or +>> background required to post here. Optimal use of an information source +>> requires critical reading and understanding the limitations of the +>> medium. Counting comments is usually not a great way to assess +>> technical considerations on an open public forum. Doubly so because +>> those comments were not actually talking about the same thing I am +>> talking about. +>> +>> Existing implementations are inefficient in many known ways (and, no +>> doubt, some unknown ones). This list is about developing protocol and +>> implementations including improving their efficiency. When talking +>> about incentives the costs you need to consider are the costs of the +>> best realistic option. As far as I know there is no doubt from anyone +>> technically experienced that under the current network rules full +>> nodes can be operated with vastly less resources than current +>> implementations use, it's just a question of the relatively modest +>> implementation improvements. +>> +>> When you argue that Bitcoin doesn't have the right incentives (and +>> thus something??) I retort that the actual resource _requirements_ are +>> for the protocol very low. I gave specific example numbers to enable +>> correction or clarification if I've said something wrong or +>> controversial. Pointing out that existing implementations are not that +>> currently as efficient as the underlying requirements and that some +>> large number of users do not like the efficiency of existing +>> implementations doesn't tell me anything I disagree with or didn't +>> already know. Whats being discussed around here contributes to +>> prioritizing improvements over the existing implementations. +>> +>> I hope this clarifies something. +>> +>> +>> ------------------------------------------------------------------------------ +>> Put Bad Developers to Shame +>> Dominate Development with Jenkins Continuous Integration +>> Continuously Automate Build, Test & Deployment +>> Start a new project now. Try Jenkins in the cloud. +>> http://p.sf.net/sfu/13600_Cloudbees +>> _______________________________________________ +>> Bitcoin-development mailing list +>> Bitcoin-development@lists.sourceforge.net +>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>> +> +> +> +> ------------------------------------------------------------------------------ +> Put Bad Developers to Shame +> Dominate Development with Jenkins Continuous Integration +> Continuously Automate Build, Test & Deployment +> Start a new project now. Try Jenkins in the cloud. +> http://p.sf.net/sfu/13600_Cloudbees +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> +> + +--089e01538c564d6e7a04f6aa78d4 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<p dir=3D"ltr">I tend to agree with slush here - counting the IPs in addr b= +roadcasts often gives a number like 100,000 vs just 10,000 for actually rea= +chable nodes (or less). It seems like optimising the NAT tunneling code wou= +ld help. Starting by adding more diagnostic stuff to the GUI. STUN support = +may also help.</p> + +<p dir=3D"ltr">The main constraint with home devices is not IMHO their actu= +al power but rather that a lot of people no longer keep computers switched = +on all the time. If you don't do that then spv with bundled Core can= +9;t help your security because the spv wallet would always be syncing from = +the p2p network for performance reasons.</p> + +<div class=3D"gmail_quote">On 9 Apr 2014 22:13, "slush" <<a hr= +ef=3D"mailto:slush@centrum.cz">slush@centrum.cz</a>> wrote:<br type=3D"a= +ttribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= +rder-left:1px #ccc solid;padding-left:1ex"> +<div dir=3D"ltr">I believe there're plenty bitcoind instances running, = +but they don't have configured port forwarding properly.There's uPN= +P support in bitcoind, but it works only on simple setups.<div><br></div> +<div> + +Maybe there're some not yet considered way how to expose these *existin= +g* instances to Internet, to strenghten the network. Maybe just self-test i= +ndicating the node is not reachable from outside (together with short howto= + like in some torrent clients).</div> + + +<div><br></div><div>These days IPv6 is slowly deploying to server environme= +nts, but maybe there's some simple way how to bundle ipv6 tunnelling in= +to bitcoind so any instance will become ipv6-reachable automatically?</div> + + +<div><br></div><div>Maybe there're other ideas how to improve current s= +ituation without needs of reworking the architecture.</div><div><br></div><= +div>Marek</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail= +_quote"> + + +On Wed, Apr 9, 2014 at 9:33 PM, Gregory Maxwell <span dir=3D"ltr"><<a hr= +ef=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>&g= +t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= + .8ex;border-left:1px #ccc solid;padding-left:1ex"> + + +<div>On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier <<a href=3D"mailto:= +justusranvier@gmail.com" target=3D"_blank">justusranvier@gmail.com</a>> = +wrote:<br> +> Anyone reading the archives of the list will see about triple the<br> +> number of people independently confirming the resource usage problem<b= +r> +> than they will see denying it, so I'm not particularly worried.<br= +> +<br> +</div>The list has open membership, there is no particular qualification or= +<br> +background required to post here. Optimal use of an information source<br> +requires critical reading and understanding the limitations of the<br> +medium. Counting comments is usually not a great way to assess<br> +technical considerations on an open public forum. =C2=A0Doubly so because<b= +r> +those comments were not actually talking about the same thing I am<br> +talking about.<br> +<br> +Existing implementations are inefficient in many known ways (and, no<br> +doubt, some unknown ones). This list is about developing protocol and<br> +implementations including improving their efficiency. =C2=A0When talking<br= +> +about incentives the costs you need to consider are the costs of the<br> +best realistic option. =C2=A0As far as I know there is no doubt from anyone= +<br> +technically experienced that under the current network rules full<br> +nodes can be operated with vastly less resources than current<br> +implementations use, it's just a question of the relatively modest<br> +implementation improvements.<br> +<br> +When you argue that Bitcoin doesn't have the right incentives (and<br> +thus something??) I retort that the actual resource _requirements_ are<br> +for the protocol very low. I gave specific example numbers to enable<br> +correction or clarification if I've said something wrong or<br> +controversial. Pointing out that existing implementations are not that<br> +currently as efficient as the underlying requirements and that some<br> +large number of users do not like the efficiency of existing<br> +implementations doesn't tell me anything I disagree with or didn't<= +br> +already know. Whats being discussed around here contributes to<br> +prioritizing improvements over the existing implementations.<br> +<br> +I hope this clarifies something.<br> +<div><div><br> +---------------------------------------------------------------------------= +---<br> +Put Bad Developers to Shame<br> +Dominate Development with Jenkins Continuous Integration<br> +Continuously Automate Build, Test & Deployment<br> +Start a new project now. Try Jenkins in the cloud.<br> +<a href=3D"http://p.sf.net/sfu/13600_Cloudbees" target=3D"_blank">http://p.= +sf.net/sfu/13600_Cloudbees</a><br> +_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla= +nk">Bitcoin-development@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +</div></div></blockquote></div><br></div> +<br>-----------------------------------------------------------------------= +-------<br> +Put Bad Developers to Shame<br> +Dominate Development with Jenkins Continuous Integration<br> +Continuously Automate Build, Test & Deployment<br> +Start a new project now. Try Jenkins in the cloud.<br> +<a href=3D"http://p.sf.net/sfu/13600_Cloudbees" target=3D"_blank">http://p.= +sf.net/sfu/13600_Cloudbees</a><br>_________________________________________= +______<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +<br></blockquote></div> + +--089e01538c564d6e7a04f6aa78d4-- + + |