rich1.0npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uhttps://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0unjumphttps://nostr.ae📅 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 >