Right, because Bitcoin has only survived until now because the media has been 100% supportive and behind us all the way, 

I know.

Just because people say things on the Internet doesn't make it true.

An alternate proposal: https://bitcointalk.org/index.php?topic=430476.0

Because there's still a chance it won't be Bitcoin specifically that does it.

I don't understand why this thread does not belong in the Altcoin section.

In addition there would be a window of vulnerability starting at the time when a transaction was broadcast and ending when it accumulated enough confirmations where an attacker who was quick, and well connected in the network, and probably had enough hashing power to orphan a block or two could steal coins.

Problems to be sure, but not exactly the end of the world.

Yes, and what have the results of that been?

Instead of letting newbies graduate based on post count and/or time, why not instead let them pass some kind of exam that proves they at least know some of the basics about bitcoin before they are set loose on the forum at large?

It's possible for them to cheat on any test but then if they start stupid threads about issues they should have been clear on in order to pass it, then you can ban them for being obvious trolls who are disrupting the forum instead of engaging in bone fide discussion.

What is necessary is to reduce or eliminate the ability of any developer, no matter who they are, to do evil.

This is necessary because some of the developers actually want to do evil, and some of them might be pressured or forced into doing it regardless of what they want.

I'll accept a description of the exact threat posed by trivial method for breaking ECDSA in terms of how it affects network operation.

Start like this:

"If somebody invents a computationally cheap method of deriving ECDSA private keys from either cyphertext or public keys, the effect on Bitcoin will be: X"

Just explain what X is.

Economists are never going to accept Bitcoin any more than buggy whip makers accepted the automobile.

They only have a profession at all in a world in which governments control the money. A Bitcoin world means their experience and their fancy degrees might qualify them for a job flipping burgers, assuming that job hasn't already been given to robots by then.

 https://www.youtube.com/watch?v=JvebxYILfZQ#t=9m5s

I will as soon as you can explain in specific terms exactly what the NSA can do to Bitcoin with a quantum computer.

I don't know.

As far as I know only Multibit and bitcoinj do that, so presumably there is some missing functionality that the other wallets want that SPV doesn't provide.

I'm not sure why a protocol that tries to be safe while connecting to random nodes on the Internet is the best way to connect to a known trusted node operated by the same person/organization as the wallet owner, but maybe it is.

As a user I just want a modular stack where I can pick from several different node implementations and several different wallet implementations and combine them in any combination, whatever protocols it takes to make that happen.

Define "legitimate". Or maybe "legitament". Whichever.

That's a good point. Shouting incoherently is not useful and distracts from more relevant criticisms.

Agreed.

What would be a great start is if all the projects which have done full reimplementations, Bits of Proof, btcd, and libbitcoin, all got together and standardized the method they use to allow a wallet to talk to a node. That would make wallets and node implementations fully interchangeable.

I asked and none of them are interested in doing that.

Wallets should really have absolutely nothing to do at all with full node implementations. The reference code is like that because it kinda had to start out that way, but that's not the right way to engineer a clean slate solution.

There's no reason to have more than one node per site (home network or business LAN) with one copy the blockchain. That node should run 24/7/365.

Wallets, on the other hand, are one per user, per device and only need to run on demand. Wallets need to be smart about synchronizing across multiple devices because it's not 1994 any more and we all have multiple computing devices, and sometimes even use more than one at the same time.

Moving forward by building solutions that look like Bitcoin-Qt is exactly the wrong way to go.

That's why I suggested to btcd they needed to be first to market in terms of integrating turnkey P2Pool functionality...

I don't have the skills to do anything remotely like re-implement Bitcoin.  I'm able to recognize that the Conformal people have their shit together, and I recognize that the network is more robust when no single dev team controls its fate. Bitcoin does need the ability to adapt, but the process of introducing changes should be fully transparent and the best way to make sure that happens is if by necessity, a bunch of independent projects from all over the globe have to come together and agree on and coordinate protocol changes.


I won't be in Miami because I'm too busy getting ready for this conference: http://texasbitcoinconference.com

We actually received a proposal yesterday for someone wanting to give a talk about exactly what you're talking about.

Not that it's on topic or anything but never expect an objective answer about Bitcoin from an economist, any more than you'd expect to hear objective criticism of IP from a RIAA employee. Bitcoin was invented to bring their entire world crashing down.

 https://www.youtube.com/watch?v=JvebxYILfZQ#t=9m5s