Mark Friedenbach [ARCHIVE] on Nostr: š Original date posted:2014-04-09 š Original message:I've advocated for this in ...
š
Original date posted:2014-04-09
š Original message: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 at centrum.cz
> <mailto:slush at 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 at gmail.com
> <mailto:gmaxwell at gmail.com>> wrote:
>
> On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier
> <justusranvier at gmail.com <mailto:justusranvier at 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 at lists.sourceforge.net
> <mailto:Bitcoin-development at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
š Original message: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 at centrum.cz
> <mailto:slush at 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 at gmail.com
> <mailto:gmaxwell at gmail.com>> wrote:
>
> On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier
> <justusranvier at gmail.com <mailto:justusranvier at 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 at lists.sourceforge.net
> <mailto:Bitcoin-development at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>