[josephagoss]

> Bitcoin was not the work of a skilled team.

This is refreshing to hear, however the Government does not have a history of writing good code (excluding NASA) I still feel like the Government argument could be correct.

> I'd go close to calling that one a myth

Well the limit is based on size, and 7tx/sec assumes an average transaction I think.

> in fact it's intended to be tight for block space in order to create a market in which people battle for transaction fees

I remember reading Satoshi did not intend for limited blockchain space and envisioned 500GB blocks.

> 1MB is just arbitrary at the moment.

A hard fork will be required, this will not be an issue if no one complains.

[bunderbunder]

> the Government does not have a history of writing good code

I'd love to hear more about that, because it goes against my own experience. (And I'll go ahead and disclaim that I'm obviously speaking anecdotally here.)

Whenever I've run into software that was developed by the US government it's generally been pretty competent. No worse, and maybe a little better, than what I'm used to seeing come out of the companies I've worked with. Certainly better than the stream of epic fails that seems to characterize what results from outsourcing to private contractors.

[gknoy]

Partly that may be because they can (in theory) work closer to the true customer, rather than having an additional contract/specification-based interface to getting things made. When you don't find out for six months that you completely misunderstood the client's needs, it's hard to build good stuff -- frustrating for the client, and for the developers.

If, however, you ARE your own client, such as writing research code or simulation/test code, you likely have a clearer idea of what needs to be done.

[celticninja]

it depends on who does what, if the people that want/need/use the code are responsible for writing it then I woudl agree, if you have a different department/wing/group writing the code then what you end up with may not be useable by the end user or may not be as useful anyway. If you add in another step where lots of disparate groups have input i.e. impse a set of requirements, usually indepdent of one another, then what you get left with is an expensive, unworkable, useless piece of spftware that everyone is forced to use until someone else decide to have a crack at improving it.

source: i have worked for govt.

[josephagoss]

Sorry it was just an assumption I made. Over the years all the stuff I have read point towards bad code from the Government. I guess the NSA would be of higher caliber though, similar to NASA embedded code.

[ufmace]

I don't think you can really argue either way on Government code quality. It depends entirely on how the project was set up and who did it.

There's plenty of Government software projects with the usual lists of WTF-generators like lowest-bid contractors, poor requirements communication, incompetent managers mostly concerned with covering their own asses, etc.

And there's plenty of other Government software projects made by a tight-knit core of highly skilled hackers with good goals under good management. See Stuxnet, etc.

[dagw]

the Government does not have a history of writing good code

How much NSA code have you seen? SELinux is one of the few pieces available and seems reasonably competent.

[krenoten]

I can't say how this applies within the NSA, but (security) hackers tend to write better publicly released code than academic mathematicians, as the constraints imposed on them tend to encourage soundness of implementation over soundness of concept. I have no idea how applicable this trend is to NSA security engineers vs whoever inside the NSA might have been tasked with this. I just think it's possible that if this were an NSA project, that doesn't necessarily imply good code.

[nwh]

> This is refreshing to hear, however the Government does not have a history of writing good code (excluding NASA) I still feel like the Government argument could be correct.

My point was more that if it was set up to be a honeypot, they'd want to do quite a good job to ensure that it was picked up by a community. The Satoshi client was anything but, and in itself would have had quite a high risk at completely bombing out. Developers are still battling with some of the less sensible bits of the design.

> Well the limit is based on size, and 7tx/sec assumes average transaction I think.

More clients moving to compressed keys would help with that, but yes, I think that's where the 7tx/second number comes from.

> envisioned 500GB blocks

I still think everybody would struggle with that. It's not a small amount of data to move around. I don't think I could even write 500GB to a hard disk in under 10 minutes, let alone the 6 or so minutes between blocks at the moment. It'll be a long time until that's even possible on a network-wide scale, my current node is under heavy enough load responding to it's peers as it is.

[consonants]

If Bitcoin is truly a covert operation led by the government to attract criminals, they would be funding this through a completely unrelated subsidiary who either provides grants to research institutions or contracts the work out.

In either case the code will be shit. The problem with this argument is that it is incredibly hard to prove without knowing the circumstances behind bitcoins inception.