The downside is that increased rate of orphans means reduced effective security and increased orphan cost.  The later is more of an issue while the block subsidy is relatively high.  Reducing the orphan cost should be a high priority.  A reduction in the orphan cost of 90%+ is possible with some small non-forking changes to the protocol (the message format used for relaying blocks).

Oprhans reduce the effective security of the network.  Any hashpower spent on orphaned blocks is essentially wasted, reducing the potential cost to an attacker.  As an example a network with 100 TH and 10% orphan rate can be 51% attacked with only 90 TH/s.

The orphan cost is the cost to the miner to add one more tx to the block.  A shorter block interval increases that cost.  If the compensation for the miner is less than the orphan cost then it doesn't make direct economic sense for the miner to include the transactions.  Miners may include the transaction "anyways" to support the network but we should be aware of the risk of designing a system which requires miners to accept a reduction in reward to "help the network".

It is possible that the benefits outweigh the cost but those are the downsides.  I think achieving a consensus is pretty much impossible but improving the efficiency of the protocol should be done first.  Any change should likely be small (2 to 6 minutes as target).  I would need to see a lot of solid modeling on a robust test net simulation to be convinced it is viable.

"Encrypted doesn't tell us much".   If the encryption is properly implemented (including using salt in the key derivation function) and the passphrase is sufficiently strong then there is no practical risk.

If you don't know the exact details of how blockchain.info encrypts the wallet you shouldn't assume it is done properly.   Have they made the encryption/decryption process open source?

You (like most people) have difficulty grasping how large 2^256 is (or even 2^128 which is the effective security of 256 bit ECDSA keys).   The 128 bit or 256 bit seems deceptively small.   Nobody credible is saying classical computers could brute force keys in thousands of years..... it would be billions of years using all the energy of our sun.  That also assumes you have a perfect computer.


None of those (except QC) would do anything more than switching from a teaspoon to a bucket when trying to empty an ocean.  

The only way a ECDSA private key will be successfully attacked is:
a) The private key isn't random enough (insufficient entropy due to flaw in PRNG)
b) ECDSA is cryptographically weakened/broken.
c) It becomes possible to build a QC with the tens of thousands of qubits necessary to implement Shor's algorithm against a 256 bit ECDSA public key (and public key is known).

This is a false statement.  Miners are not the only security mechanism in the Bitcoin network.  All nodes (every single one of the 100,000+) on the network independently validate transactions before they include them in the memory pool or relay them.

A transaction spending "nothing" would instantly be dropped by all peers on the network.  You would never even see it in your client.  It is very likely that your node wouldn't even see the tx to drop it, as every node between you and the sender dropped it and thus never relayed it on.

As for changing Bitcoin target interval.  In theory any change to Bitcoin is possible, as a practical matter it will never happen as it requires a consensus and a hard fork.  It is unknown if a shorter interval will be optimal as the network, transactions volume, and block sizes gets larger.  There is no free lunch.  Shorter block interval means higher orphan rates.  That means less effective security and the orphan cost rises.  With a higher orphan cost miners will be reluctant to make blocks larger, tx fees will rise, and lower paying or free txs will wait much longer to be included in a block.

That isn't exactly true.  As a simplistic answer the way QC work is they aren't "faster" they make the problem shorter/simpler.  So while thermodynamics can't be bypassed, finding a solution will require less "work" than in classical computing.   Still IIRC the larger number which has been factored using QC was something like 117 and it took nine days.  Wake me up when someone can factor 32 bit numbers much less 2048 bit ones.

Sure and 99.999999999999999999999999999999% of Bitcoin clients would simply see those as invalid blocks.  Miners which mine on that fork will end up with worthless coins and miners which remain on the real Bitcoin network will get more coins.

Np.  If you want to see it yourself I recommend mining either for Eligius or p2pool.  Their rewards are directly in the coinbase so it will appear in your wallet just like a solo mine would be.  The only difference between those pools and solo mining is that the coinbase is paid to multiple people and you only get a "portion".  Other than that they are identical so it is a good way to see what to expect with solo mining without potentially having to wait years or decades for a solo block.

It will show on the transactions tab instantly.  It will also show in listtransactions.  It may also show elsewhere but I have never cared to look.


It will show instantly.  It will be spendable and added to the confirmed balance after exactly 120 blocks (the protocol only requires 100 but the QT client adds an extra 20 blocks).

There are no transaction logs after Nov 2013.  It is possible the transactions you are looking for are the redacted ones.

If you solved a block the reward would show in your wallet instantly.

Yeah maybe in 1990.

http://finance.yahoo.com/q?s=GOOG
http://finance.yahoo.com/q?s=AAPL
http://finance.yahoo.com/q?s=IBM
http://finance.yahoo.com/q?s=BRK-A

He used hashing function to protect the pubkey (we send funds to an address which is the pubkeyhash) providing a measure of security in the event ECDSA is compromised by crypto analysis or quantum computing (as long as the address is no re-used).

He designed the system such that SPV nodes were capable even though the need didn't exist until five years after the whitepaper.

He used the block reward (subsidy) to solve three problems simultaneously, providing a fair initial distribution of money, subsidizing the cost of the network security, ensuring that those with hashpower are economically incentivized to "do the right thing").

The picture is of the sun.  It is not known if a quantum computer capable of implementing shor's algorithm on 256 bit ECDSA keys will ever be possible.  Even with a quantum computer if the pubkey is unknown Shor's algorithm can't be used.

So just use the single password you have memorized.  Write nothing down, and there is no need to a dubious second encryption.

If the operator was interested in truly doing the right thing, he would take the whole thing offline and spend a couple months learning what he should have known before he started.  The spend a couple months building it right from the ground up.  Before the launch he could launch a test site with dummy accounts and data and offer a security challenge ( https://www.crowdcurity.com/ )*.  


As for where to start, based on the responses given by the operator himself he lacks even the basic knowledge on proper database design and operation.  Sorry if that is "harsh" but it is the reality.  This isn't a "one wrong line of code" issue.  He should start with a book which teaches fundamental concepts about how relational databases work.  Normally I would recommend a freshman computer science book on database design and operation but honestly they are way overpriced (as all academic books are) and excessively wordy.  

Something like the following would be a good proxy:
http://www.amazon.com/Database-Design-Mere-Mortals-Relational/dp/0321884493/

The idea that an experienced developer should either "shut up and stop being mean" or help the guy build it right for free is a false dichotomy.  Top developers generally make $150K to $200K a year.  If the site operator is willing to offer $80 a hour I am sure someone qualified would be willing to mentor him.  However based on his responses to the problem that money would likely be wasted at this point. You can't just slap some additional code on a flawed design and expect it to be secure.  The entire transaction processing engine probably needs to be rebuilt from the ground up to be ACID compliant.  Due to the scope of the problem we don't know what other problems exist but I doubt the code in other critical areas (authentication and authorization) is better.

For the record I am not saying "don't use the site" or "you are an idiot for using the site".  I am a libertarian, I don't really feel it is my business what you do with your money.  However please don't be surprised when it happens again.

* Before I get accused of "do as I say not as I do, BitSimple will be launching a challenge soon.

This isn't a "bug", it is a fundamental flaw in how financial data should be processed.  Mike was being truthful when he said it is "database 101".  It wasn't that the site used transactions to ensure that withdraws were ACID compliant and there was bug on an edge case which resulted in them not being so.  There was no transactions used at all.   The proposed solution was more broken design (as opposed to just broken code) to check existing broken design.

The exchange WILL be robbed again.  It is merely a matter of when not if.

Encrypting multiple times is likely useless.  It is like installing two bank vault doors as the front door for your house because one isn't safe enough.  Then forgetting a thief can come in through a window, right through a wall with a car.

If you use an encrypted QT wallet file the most likely reasons you lose your coins is:
1) inside theft (roommate, guest in house, etc).
2) you lose the wallet and/or passphrase (it is really hard to break into).
3) your password is weak/insecure
4) you system is compromised with malware or key logger.

Double encryption doesn't help you in any of those scenarios and makes it more likely for #2 and possibly more likely for #3 (you use two weaker passwords instead of one stronger one).

http://world.std.com/~reinhold/diceware.html

Generate a random 6 word passphrase all lower case, no special symbols or numbers (far easier to remember over longer period of time and it can't be brute forced especially with the PBKDF2 key hardening that the QT wallet uses).

example:

That is my understanding.  Even w/ all Satoshi's hashpower the entire network didn't have enough hashrate to sustain 10 minutes per block @ difficulty 1.  The average time between blocks in the first year was closer to 14 minutes.


Possibly although the original miner never stored the extranonce to disk so a miner shutting down (reboot, needing computing resources) would reset back to an extra nonce of zero.


IIRC Hal reported his first block was 78 but it is possible he was mistaken and that entire chain is his?  Also the overlap could simply be coincidence.  Hal mined through 78 extra nonces before solving a block.  His block is unrelated to another miner who solved the earlier blocks w/ lower extra nonce value.  I don't know just throwing ideas out there.

One thing to understand is that the early miner was very conservative with use of extra nonce.  Technically on any block change you could reset the extra nonce as the rest of the header has changed but the software didn't.  It simply incremented the extra nonce on every nonce range attempted.

Since the data seems to have been stolen around the time MtGox shutdown or later the question would be ... why would you keep this information on a webserver if you aren't actively using it anymore?  

Correct me if I am wrong but P2SH replaced OpEval and thus BIP 11 is "obsolete".