Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

[Mark Friedenbach <mark@monetize.io>]

I've advocated for this in the past, and reasonable counter-arguments I
was presented with are: (1) bittorrent is horribly insecure - it would
be easy to DoS the initial block download if that were the goal, and (2)
there's a reasonable pathway to doing this all in-protocol, so there's
no reason to introduce external dependencies.

On 04/09/2014 01:31 PM, slush wrote:
> Another idea: Integrate torrent download of bootstrap.dat into bitcoind.
> Normal user (especially a beginner) won't learn how to download
> bootstrap separately and import it into bitcoind; he simply give up the
> synchronization once he realize it takes too much time. From my
> experience downloading the bootstrap significantly improves catching the
> blockchain, which may attract some more users to run bitcoind.
> 
> Not sure about C++, but simple torrent client in python is like 30 lines
> of code (using libtorrent).
> 
> Marek
> 
> 
> On Wed, Apr 9, 2014 at 10:12 PM, slush <slush@centrum.cz
> <mailto: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
>     <mailto:gmaxwell@gmail.com>> wrote:
> 
>         On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier
>         <justusranvier@gmail.com <mailto: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
>         <mailto: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
>