Sure, and nothing interesting or fancy is required for that to work.  Our blockchain space is _well defined_, not some effectively infinite sparse state space. The access patterns to it are also well defined:  All historical data is access with equal/flat small probability, and accessed sequentially. Recent blocks are accessed with an an approximately exponential decay.  Data needed to validate a new block or transaction is always available from the party that gave you that block or transaction.

So, a very nice load-balancing architecture falls right out of that.  Everyone keeps recent blocks with a exponentially distributed window size. Everyone selects a uniform random hunk of the history, size determined by their contributed storage and available bandwidth.  This should result in nearly optimal traffic distribution and is highly attack resistant in a way seriously stronger than freenet's node swapping and without the big bandwidth overheads of having to route traffic through many homes to pick up data thats ended up far from its correct specialization as IDs have drifted.

Arguing "Does it not make sense to plan ahead" here sounds like some kind of cargo cult engineering:  "Planing ahead must be done. This is a plan. Then it must be done."

Any proposed actions need to be connected to solving actual problems (or at least ones that are reasonably and justifiably anticipated).   What you're suggesting— to the extent that its even concrete enough to talk about the benefits or costs—, would likely _decrease_ the scaling over the current and/or most obvious designs by at least constant factor, and more probably a constant plus a logarithmic factor. Worse, it would move costs from storage, which appears to have the best scaling 'law', to bandwidth which has the worst empirical scaling.

If you scale things based on the scaling laws your assuming there nothing further is required. If you strap on all the nice and pretty empirically observed exponential trends then everything all gets faster and everything automatically scales up no worse than the most limiting scaling factor (which has been bandwidth historically and looks like it will continue to be)—  assuming no worse than linear performance. There are already no worse than linear behavior in the Bitcoin protocol that I'm aware of. Any in the implementations are just that, and can be happily hammered out asynchronously over time. Given computers and bandwidth that are ~10e6 better (upto a factor of 4 or so in either direction), you can have your 10e6 transactions/s. Now— I'm skeptical that these exponential technology trends will hold even just in my lifetime. But assuming they don't, then that results in a ceiling in what you can do in a decentralized system that twiddling around the protocols can't save without tossing the security model/decentralization.

Maybe people will want to toss the decentralization of Bitcoin in order to scale it further than the technology supports. If so, I would find that regrettable, since if you want to do that you could just do it in an external system.  But until I'm the boss of everything I suspect some people will continue to do things I find regrettable from time to time— I don't, however, see much point in participating in discussions about those things, since I certainly won't be participating in them.
 

I've changed the thread title because it's been pretty well established down thread that this isn't BFL's unit, it belongs to a forum member— something some pretty trivial googling could have revealed.

I'm getting a little fed up with Phinnaeus Gage's approach.  I'm super glad that we've got skeptics here keeping people on their toes,  but the shark has been jumped— if you will— so many times now that it's having the opposite effect. The constant over the top allegations have created a sea of disinformation and its actually become hard for people to find or believe genuine concerning information about any of the mining companies. Please stop this BS.

Uh. The whole point of the discussion here is providing historic transactions in order to autonomously validate the state.

There is absolutely no reason to use a DHT like system to provide UTXO data: Even if you've chosen to make a storage/bandwidth trade-off where you do not store the UTXO yourself, you would simply fetch them from the party providing you with the transaction/block as they must already have that information in order to have to validated and/or produced the transaction.

Yes, freenet's alpha and omega is its privacy model, but again, thats why its architecture probably teaches us relatively little of value for the Bitcoin ecosystem.

Why not specify 10e60000 transactions per second while you're making up random numbers?   Bitcoin is a decentralized system, thats its whole reason for existence.  There aren't non-linear costs that inhibit its scaling at least not in the system itself, just linear ones— but they're significant.  Positing 10e6 transaction per second directly inside Bitcoin is _ludicrous_ (you're talking about every full node needing to transfer 80 tbytes per day just to validate, with a peak data in excess of 10gbit/sec require to obtain reliable convergence) and not possible without completely abandoning decentralization— unless you also assume a comparable increase in bandwidth/computing power, in which case it's trivial. Or if you're willing to abandon decentralization, again it's trivial. Or if you move that volume into an external system— its a question of the design of that system and not Bitcoin.

Regardless: Achieving high scale by first dramatically _increasing_ the bandwidth required but interposing a multihop DHT in the middle— when generally bandwidth has been scaling much slower than computation and storage— isn't a good start.

I'm sure quite a few do— since there are many with just a couple outputs beyond the coinbase.  But why do you care?

The freenet model does not provide for reliability, however. My past experience was that individual keys in freenet were fairly unreliable, especially if they were just community of interest keys and not linked from the main directories. It also lacked any kind of sibyl resistance on opennet, and darknet has the unfortunate bootstrapping usability issues.  Perhaps things have changed in the last couple years? (If so— anyone have any citations I can read about whats changed in freenet land?).   An obvious proof of concept would be to insert the bitcoin blockchain as is and to provide a tool to fetch the blocks that way. If nothing else another alternative transport is always good.

In any case, this is serious overkill.  We already have an address rumoring mechanism that works quite well, and the protocol already handles fetching and validation in an attack resistant manner.  If we supplement it with additional fields on what range(s) nodes are willing to serve, with some authentication to prevent flag malleability that should be adequate for our needs from a protocol perspective... and considerably simpler than a multihop DHT.

Our effort to use a trackerless torrent was a failure— it was basically unusable. So you'd be introducing a critical path point of failure both at the trackers and in the torrent files.  Beyond that, even with the infrequently updated bootstrap we only get a handful of seeds, I can't imagine _more_ frequent torrents improving that.  Now multiply that with the fact that bittorrent is another network facing protocol with similar software complexity to the whole of the Bitcoin reference software, and one with a less impressive security history, so anyone that participates in that is increasing their security critical surface area. Then exponentiate that by the fact that bittorrent is _forbidden_ on many networks both because massively parallel TCP connections are hostile to the network (use an unfair share of capacity) and the associations with illicit file transfer, and even where it isn't outright forbidden it often gets detected by IDS and can draw unwanted adverse attention. The association of IRC and Botnets (and the resulting blocking and confused "you've been hacked" warnings from network admins) is one of the reasons we removed the original IRC introduction method.

Providing the data necessary for the operation of the network is something the network ought to do. It provides a 1:1 mapping between interesting parties and available parties. It also makes some kind of attack resistance easier because Bitcoin software can actually validate the information without any centrally controlled official torrents, whereas using torrent would ignore all the special structure our data has that makes dos attacking difficult.

I believe that using bittorrent for this is unnecessary, that using it as a primary method (as opposed to a backup or alternative option) would be bad and dangerous.  Also, you're a bad bad person for proposing it, and you smell too. (no, not really. But I'm finding it a little difficult to state how throughly bad I think that idea is without being gratuitously insulting— it's not intended that way, and it's nothing personal. Perhaps some awkward humor will help? ).

Prior to UPNP being integrated and enabled by default the network was beginning to fail from a lack of listening peers, this was remedied by the deployment of UPNP. Your assumptions seem to have been previously proven incorrect.

If you don't want UPNP you can easily disable it (and/or disable listening for incoming connections entirely).

The substance of your complaint appears to be a  password allegation which was incorrect and misleading and explained as such in the very thread you link to...

And the fact that he's opposed to Ripple.

Okay. Well I think that Ripple is a risky system, which is deceptively marketed, created and constructed in a way which can be reasonably expected to generate finical losses for its users and wealth transference to it operator. As it is currently stands it is a centralized system and on the basis of the system as described in public I have serious concerns that it is technically viable as a decentralized system. The centralization creates substantial regulatory and plain-boring security risks, and more simply is inconsistent with how they've advertised it. The operators of ripple may freely adjust balances at will and may be required to do so by any coercive power with authority over them. The same is true of services like mtgox, but they aren't advertised as anything else— and presumably people have some idea what risks they are taking when they leave funds with a service. These centralization risks combined with the incorrect notion that ripple is something else may be creating an elevated extensional risk for Bitcoin: If ripple suffers a massive failure it may (unfairly) cast a shadow on Bitcoin.

Moreover, the ripple of today was created by purchasing the name of a prior system which the current system is largely unrelated to in order to exploit the positive reputation of the name, further creating confusion about what what ripple is and isn't.

So now that I've also expressed concerns (see also) about ripple will the pro-ripple troll and shill army now start spreading spurious scam accusations about me?

In every interaction I've had with him he's been a kind, sincere, and intelligent person.  My personal observation is that many people on the forum have treated him like utter shit— with varying degrees of "justification"— and it's hardly surprising that he has no tolerance remaining especially for folks like Phinnaeus who have been so persistently aggressive.

This could also be used to reduce the damage from deanonymization attacks, like this appears to be: https://bitcointalk.org/index.php?topic=254615.40

If people who have some of these want to get together and jointly spend them, ala  https://bitcointalk.org/index.php?topic=139581.0  that might sound fun.

That would be _really_ _really_ expensive, there are much less expensive ways to create disruption. Plus, markets have a fun way of absorbing that kind of crap and laughing all the way to the bank, it's very risky that it could have the opposite.

I think the whole premise of attack from parties like that is a bit thin. Part of the reason that Bitcoin could even be argued to be some kind of threat to them is that it represents something so foreign to them.  It's an outside context problem, if you will. If it weren't they'd just adapt and then it wouldn't be much of a threat. But if they don't then it really is an OCP and they probably won't respond at all until it's too big for them to do so successfully.   (Or alternatively, I would argue that the only times such forces could successfully disrupt it would be during the "then they ignore you" and "then they laugh at you" stages, simply because it is such a weird and far out idea).

Sure, thats how luke generated that 3P14159 address... but kinda lame in that it makes your spending transactions bigger (= higher costs and extra crap added to the blockchain).

Both are kinda awful: the kind of person who might care about your distinction would recognize that either form tells the whole world the party to go after to learn more about those funds, and would presumably prefer to deal with someone not screwing up everyone's privacy.

There have been plenty of DoS bugs you didn't spot.   (And some of the other ones have also been used against the network)  But indeed, your help is greatly appreciated.  As always, it would be even more appreciated if you did even _MORE_, for the obvious reasons,  some of your reports haven't been quite correct and they take time to validate, a PoC or a least a walk through would be nice— but that doesn't reduce the fact that you've been helpful indeed and I'm happy you've been able to contribute what you can.

I do generally think that most attacks go unmade— or at least, we've managed to discuss serious and easily exploited "knock the whole network out" DoS bugs in open forums (because the conversation started in an open forum before we realized the severity) many times without anyone actually exploiting them. I'm not entirely sure why some DoS attacks get made but not most of the ones that could be made.  Part of this probably comes from the fact that its fairly hard to profit from them, though with more altcoins being promoted as an alternative to Bitcoin perhaps thats changing... although at the same time I expect anyone technical enough to make an attack knows that few if any of the altcoins would survive a dirty-business technical war against the Bitcoin community.

No, ... and arguing with Pieter about such things is usually not advisable.

What you're describing is how a soft-forking or backwards compatible change can be safely made. But this change is not backwards compatible. Doesn't matter if most— or even 80% of the miners are happy with it, the blocks would be rejected by all full nodes no matter how many miners are on it. Such a change can not be made safe by having mining on it.

Unfortunately, "emergency" is pretty incompatible with "informed consent" and "public debate"

This isn't mining related…

I don't consider blockchain "voting" for a hard-fork to be especially sane.

Please edit your posts and remove the trojan links. In the future please avoid providing a clickable link to something that is probably malicious.  Some people's automatic reflexes are maladaptive... those people are probably doomed anyways, but we don't need to help them along to their demise.

Ah, I thought you were talking about the party creating 0.001 value txouts to (presumably) deanonymize people. I don't see what your concern is with the 300 BTC party. Their transactions are handled in priority order, and higher priority free transactions still have first dibs on the limited free space.  That they're moving a large amount just means that they meet the minimum threshold after one block— but it doesn't give them a particularly high priority.

The resulting load is all prunable and doesn't hurt the privacy of third parties, so I don't see a reason to be especially concerned by it.