public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mark Friedenbach <mark@monetize.io>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
Date: Wed, 09 Apr 2014 13:36:35 -0700	[thread overview]
Message-ID: <5345AF53.8070700@monetize.io> (raw)
In-Reply-To: <CAJna-HiwRcvY1xPg5pkZDyjQhimnNiLM9a16YHOPu+ggod6A5A@mail.gmail.com>

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
> 



  reply	other threads:[~2014-04-09 20:57 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-09 15:29 [Bitcoin-development] Bitcoind-in-background mode for SPV wallets Wladimir
2014-04-09 15:37 ` Tamas Blummer
2014-04-09 15:41 ` Natanael
2014-04-09 15:54   ` Gregory Maxwell
2014-04-09 16:09     ` Thomas Voegtlin
2014-04-09 19:25       ` Wladimir
2014-04-10  6:04         ` Tamas Blummer
2014-04-10 11:09           ` Wladimir
2014-04-10 11:29             ` Mike Hearn
2014-04-10 11:32             ` Pieter Wuille
2014-04-10 11:43               ` Peter Todd
2014-04-10 11:50               ` Gregory Maxwell
2014-04-10 11:54                 ` Peter Todd
2014-04-10 17:30                   ` Tier Nolan
2014-04-11 16:54                     ` Gregory Maxwell
2014-05-04 21:11                       ` Tier Nolan
2014-04-09 17:31   ` Wladimir
2014-04-09 15:42 ` Brian Hoffman
2014-04-09 15:57   ` Gregory Maxwell
2014-04-09 16:09     ` Tamas Blummer
2014-04-09 15:47       ` Mark Friedenbach
2014-04-09 16:27         ` Tamas Blummer
2014-04-09 17:46           ` Peter Todd
2014-04-09 17:50             ` Tamas Blummer
2014-04-09 18:00               ` Mike Hearn
2014-04-09 18:19                 ` Wladimir
2014-04-09 18:35                   ` Justus Ranvier
2014-04-09 18:46                     ` Wladimir
2014-04-09 18:50                     ` Gregory Maxwell
2014-04-09 18:58                       ` Justus Ranvier
2014-04-09 19:33                         ` Gregory Maxwell
2014-04-09 20:12                           ` slush
2014-04-09 20:31                             ` slush
2014-04-09 20:36                               ` Mark Friedenbach [this message]
2014-04-09 21:04                                 ` Gregory Maxwell
2014-04-09 20:37                               ` Wladimir
2014-04-09 20:35                             ` Wladimir
2014-04-09 20:50                               ` slush
2014-04-09 20:55                             ` Laszlo Hanyecz
2014-04-10  6:38                             ` Mike Hearn
2014-04-10  6:50                               ` Wladimir
2014-04-10  7:09                                 ` Mike Hearn
2014-04-10  9:33                                   ` Peter Todd
2014-04-10  7:10                                 ` Tamas Blummer
2014-04-10  9:17                                   ` Mike Hearn
2014-04-10  9:39                                     ` Tamas Blummer
2014-04-10 10:40                                       ` Mike Hearn
2014-04-10 10:44                                         ` Tamas Blummer
2014-04-10 11:36                                           ` Peter Todd
2014-04-10 11:45                                             ` Mike Hearn
2014-04-10 11:52                                               ` Peter Todd
2014-04-10  9:47                                     ` Peter Todd
2014-04-09 18:04               ` Peter Todd
     [not found]   ` <CA+s+GJBpvqqu=XEojyekx5su+JfYLwz+zsbo8L0=5t6s-_b33w@mail.gmail.com>
2014-04-09 17:35     ` [Bitcoin-development] Fwd: " Wladimir
2014-04-09 16:03 ` [Bitcoin-development] " Peter Todd
2014-04-09 17:33   ` Alex Mizrahi
2014-04-09 17:38     ` Wladimir
2014-04-09 17:38     ` Peter Todd
2014-04-09 18:35 ` Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5345AF53.8070700@monetize.io \
    --to=mark@monetize.io \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox