Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM˜<div class="post">I have mixed feelings about this.&nbsp; Part of the problem is that there is perceived to be a free good, a network hosting service in the form of Source Forge, which will certainly allow those performing software releases to include considerably more data than is currently the case for Bitcoins.&nbsp; If somehow we were paying for this service as a community in terms of $$$ per MiB, I think it would be a no brainer that this should stay out of the distribution.&nbsp; Unfortunately for this consideration, it is a free good from the perspective of most users.<br/><br/>The other issue is that the network bandwidth between nodes is also a free good.&nbsp; I've suggested in <a href="http://bitcointalk.org/index.php?topic=1764.0">this thread</a> that perhaps the presumption of network bandwidth may also not be considered a free good either.&nbsp; In fact, I believe that it shouldn't be the case, but that is a completely separate issue entirely.<br/><br/>The network bandwidth for downloading the blocks is to me a wash either way, although a new client coming "on-line" trying to get the full block chain does suck up a whole bunch of blocks through the Bitcoin network and that impacts anybody who happens to be connected to those nodes.&nbsp; BTW, this is one of the reasons I think it would be incredibly useful to start "charging" for bandwidth as a means to discourage this behavior... and of course to earn a few extra Bitcoins on the side.&nbsp; If you can obtain blocks "free" from another source, some people might get more creative on how to get that accomplished including downloading a second package on some free file hosting service (perhaps included with the main client distributions) or coming up with a scheme on how to bootstrap new clients that impacts the network in a less obtrusive fashion.<br/><br/>I guess what I'm saying is that while this is a simple solution to a complex problem, it doesn't solve all of the problems including perhaps clients which may store the block data in another format.&nbsp; There also isn't any apparent reason to necessarily encourage other software client distros to include this kind of data or for that matter to put in more than the most minimum number of blocks.&nbsp; Still, raising the issue is useful here and I hope it raises a discussion about the problem.<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=1931.msg24352#msg24352">Quote from: witchspace on November 25, 2010, 01:37:13 PM</a></div><div class="quote">Huh, isn't P2P supposed to be faster because you can download from many users at once instead of one source?<br/>(also the reason why some gaming companies use bittorrent to distribute updates)<br/><br/></div><br/>I agree it seems very odd that you would take something which is by its nature distributed through P2P channels and instead put it into a conventional client-server distribution model.&nbsp; Part of why I'm saying that perhaps more thought ought to go into this is perhaps to encourage a bittorrent distribution connection of some sort for a large collection of blocks if somebody has had their client off for awhile or some other kind of experimentation on how to solve this same problem.&nbsp; The problem is that new clients are demanding the whole block chain and really can't get into "mining" or confirming new transactions until they have that chain.&nbsp; Let's solve that problem, which is a larger issue.<br/><br/>The other issue is that it seems like a waste of bandwidth to include these blocks in a client when all you are doing is updating the software.&nbsp; I would be just as worried that the block chain might get wiped out by the installation software with this "older" version of the chain, forcing older clients to update to the current block all over again, although this is certainly an installation bug.&nbsp; Just because it is a free good doesn't imply there are no other consequences to going this route.</div> text/html