No you just lack the knowledge to understand what you are reading.

As pointed out the wiki is simply public docs.  It is one possible way to deal with scalability.  Anything in the wiki which goes beyond the actual current protocol should be treated as an opinon.

However even if the cited section was implemented it would still be trustless.   Full nodes would still maintain a pruned copy of the blockchain going all the way back to the genesis block.  An unpruned copy (the archive node) is not required to validation transactions or create new blocks.   Nobody needs to trust the archive nodes.  

Your "solution" (and I use the term lightly) would break that trustless relationship between nodes.  

So either you are trolling for trolling sake or you are genuinely interested but lack the basic knowledge.  It would be like someone without any higher mathematics trying to understand how public key cryptography works and coming up with "enhancements".   If you aren't trolling, or just looking to debate to feel important ... then stop trying to fix Bitcoin before you undertstand Bitcoin.  Take a couple weeks starting with the whitepaper, the wiki and then the source code.  

Nobody is saying a ledger type system is impossible but it a non-trivial problem.  If you think you found a trivial solution to a non-trivial problem in a few minutes ... you haven't.


You haven't provided a proposal.

It is debt.  It isn't a loan but it is a liability.  Optimally the assets and liabilities balance but when the thief (or insider) takes the assets all that is left is the liabilities.  If the company can repay that liability out of its own pocket well they can make you whole but more times then not the loss is far greater than their ability to repay and depositors are left holding worthless IOUs.

PayPal disputes are 45 days however the customer go above PayPal to the CC issuer and they have 180 days.  You will almost certainly lose everything, end up with a negative balance, a frozen paypal account, and friendly phone calls from PayPal's collection department.

Scammers may be crooks but they aren't dumb.  Once they find a mark they aren't going to chase him (you) off by opening a dispute right away.  They will let you create multiple transactions and then all the chargebacks will come in almost all at once.  You go to sleep feeling good about your business skills and wake up in the morning to find out 90%+ of the transactions are all being disputed.   Scammers don't want a single small sale they want to get you for every single coin you own before pulling the trigger on the scam.

It is a road to ruin but as long as you go in with eyes wide open.

No it is irrelevant.  Difficulty doesn't affect the time between block changes.



Share difficulty, min pool share difficulty, and block difficulty all have nothing to do with intensity (batch size).

Intensity defines how long the card will run (in hashes) before it ends the batch, drops off results, and picks up new instructions.

You are right (but using wrong words) in that pools pay based on the total difficulty of the shares accepted not the raw number of shares.  A miner with lower difficulty will produce more shares but each share is worth less and a miner running at higher difficulty will produce less shares but each share is worth more.   As an analogy someone depositing one $100 bill into the register gets no more credit than someone else depositing one hundred $1 bills in the register. This has nothing to do with intensity though. 

How would it cause a problem?  If you don't have the ability to operate using https you simply shouldn't be operating (this goes for any site which needs to secure communication between server and client).   If something results in you losing your TLS cert for a period of time it would be better to not operate the site until it is restored.   If anything the only useful value for HSTS would be infinite (i.e. NEVER UNTIL THE END OF TIME CONNECT TO THIS DOMAIN INSECURELY) but since that is not an option a very long HSTS value is used as a proxy.

Bitcoin isn't experiencing a sharp drop in hashing power.   Bitcoin is a network of anonymous peers.  There is no method to compute the exact hashrate, none.  It is impossible.  The hashrate shown is an ESTIMATE and the margin of error on the 8 hour moving average is huge (something on the order of 20%+).  

You are simply looking at noise.  


At most the hashrate declined by maybe 0.5%.  In reality that is still within the margin of error on the 3 day average so it is far more likely the network is still growing at 1% to 1.5% per day.

The only scenario where a change in the difficulty function would be of any value, is a scenario where Bitcoin is likely dead anyways. If the hashrate drops 80%+ in a two week period there probably is a larger macro economic reason, one that can't be solved by simply adjusting the difficulty faster.   

You are proposing a hard fork on a core element of the protocol for something which isn't required.  The chance of it happening is ~0%.  Hard forks simply don't happen in a consensus network for all but the most critical of changes.   If ECDSA is compromised we may see a hard fork, if there is a bug which allows someone to make a billion bitcoins out of thin air we may see a hard fork.  Anything less severe than that just has no chance of reaching a consensus.  Still if you want to beat your head against the wall you wouldn't be the first.  

Bitcoin supports versioning of tx and blocks.  If there are future breaking changes they would be new versions.   ver1 transactions and ver2 blocks (the current right now) will never have a breaking change.  It is possible that at some point in the future ver 1 transactions and ver 2 blocks will no longer be supported but they will remain EXACTLY as they are now until the day (block) they are no longer supported.  Bitcoin is a network of consensus it simply can't work any other way.

Transaction and block formats supporting versioning.

The current version for transactions is ver 1.   When creating a tx the wallet has to specifically set the version number.   If the the tx format was changed it would have a new version.   If the change was backwards compatible then ver1 transactions would still be valid (i.e. wallets can create either version 1 or version 2 addresses).  If the change was not backwards compatible then a version 1 transaction would simply be invalid and dropped by the network (i.e. after block X only ver2 transactions are valid).

In the former your device would continue to work although it could not take advantage of the newer ver2 transactions.  In the later scenario your device would be obsolete if it couldn't be reprogrammed.


The scary thing is you don't already know this.   This (and knowing that the network records values in integers as satoshis) is kinda Bitcoin Developer 101 level stuff.

Hilarious.  My wife can never see this because she is going to say "that is so you, especially the part at the end".

True VISA scale (i.e 5,000 tps on blockchain)?

Figure 5,000 transactions per second.  Average tx is 400 bytes that is maybe 2MB/s (16 Mbps) sustained to write to the disk.  Average block would be 600 * 5,000 * 400 / 1024^3 = 1.2 GB.  So pretty much nothing.  Now to validate txs requires reading the outputs from the UXTO so maybe double that in terms of random reads.  Still we are talking a tiny fraction of the IO that even high end disks (to say nothing of SANs) can handle today.

Everyone thinks of disk first because it is the most obvious but in my analysis of the resource requirements I see it as the least critical bottleneck for full nodes.  If I had to rank them it would be node bandwidth (especially for residential connections), then memory, then computing power, and way back in last place would be disk capacity and speed.

To give you an example of why memory would be more of an issue, is that latency for UXTO lookups will start to become excessive.  It may be less of an issue for non-miners (who can take 5 to 10 seconds to validate a block) but miners will want to validate potential blocks very rapidly.  To avoid the slow expensive pulls from disk, if possible one would want the entire UXTO and memory pool (list of unconfirmed transactions) in memory.  The only thing being written to disk would be the blocks.  The memory pool shouldn't be a problem even if it grew to 30x the size of the average block we are talking <64GB (which sounds like a lot but consider the doubling effect of Moores law for a decade or two).  The UXTO would be larger however the good news is the UXTO grows more linearly than the blockchain or tx volume.  

However eventually it may not be possible to have the entire UXTO in memory.  What I would consider an interesting project would be to design a probabilistic model which determines how likely an output would be involved in a transaction in the near future.   For example spam outputs which are uneconomical to spend would be less likely to be included and could be dropped from the UXTO in-memory cache (if they are used it would just need pulled from disk).  Other examples of low probability outputs would be "coins" with very old age, outputs to addresses which have a large number of other older outputs but few spends (probably paper or storage wallet).  Some true statistical modeling of the blockchain could provide better insight those were just some examples.  The client could score outputs on the likelihood it would be spent soon and the highest tx kept in the in-memory cache.

I am not convinced Bitcoin (at least on blockchain) will ever become that large but if it does clients will adapt to meet the needs of full nodes.  The protocol currently is rather inefficient in terms of resources (other than disk).  Tx are double verified, block messages include the full transaction (which most nodes already have) there will be a lot of room for optimization as transaction volume grows.

You can add #0 to your list.

Nothing about that post made any sense but go ahead and have fun.

Bitcoin the currency and protocol has never been attacked.  I mean it is like saying I saw a 7-11 get robbed so obviously there is a critical flaw in the dollar.  People like to point out that banks are insured however the cash in your wallet isn't insured.   The dollars you give to a ponzi operator aren't insured either (dollar based ponzi schemes defrauded investors of $50B last year).  

MFGlobal defrauded investors of roughly the same amount as MTGox.  Both were bad companies where depositors misplaced their trust.  Don't put your Bitcoins in the hands of someone else and then be surprised when they "disappear".

The solution isn't in an improved protocol because the problem isn't with the protocol.  The problem is human both bad humans and humans who make bad (risky) decisions.   The solution is in better education and users demanding more from service providers and merchants.

As for your grandma ... give it twenty years.  

Server you control physically is sufficient in most cases.  Most companies don't have the resources to build a datacenter to house their server.  Going with a tier 1 datacenter, purchasing a locked cage or cabinet, and starting with bare metal server(s) provides a high barrier.  Now if you service grows to the point you are processing billions a year well then moving servers (or at least hot wallet hardware) "in house" might be something to consider.  

We use a private locked cabinet with access control in a major datacenter.  No datacenter employees have need or ability to login to our hardware.  The OS was installed clean onto bare metal we own so there are no "super admin" accounts that we don't know about.  IPMI and power cycle PDUs have made it possible to do a lot more remotely these days (even BIOS access and remote media for installing OS is possible).  Good secure chassis with intrusion detection are a good secondary line of defense to ensure the employees don't have access to the hardware internals.  We disable USB in BIOS.  Since disks are designed to be hotswapped, encrypted disks (and backups) are a requirement to ensure information isn't physically stolen by datacenter employee.    A good datacenter should have no problems shipping replaced/dead disks back to you to verify serial numbers against inventory control.

The one bad thing about IPMI, is it is usually very poorly implemented from a security standpoint.  It doesn't really matter the vendor, most have dozens of long running vulnerabilities.  The IPMI ports should never be public facing and instead be behind a dedicated vpn hardware firewall (i.e establish vpn tunnel to firewall, authenticate, and then gain access to the IPMI network).

The web server is going to be the most vulnerable point of any system; it is by definition public facing with open access.  For that reason that server should only be used as a webserver.  The database, bitcoind connectivity (even for just listening wallets), remote WAN login access, backups, etc should be on a different server which has no public access.  Most datacenter can provide a VLAN on a switch for private connectivity but switches are cheap so I like to buy and install our own switch in the cabinet.  Of course all this is just the outer wall, intrusion detection software, monitoring, and vulnerability scanning should be part of the picture too.

If all that sounds hard well that is why the service is operating for a profit.  Users should start to demand more from their bitcoin service companies and not accept that they are uncompensated investors (if exchange does good real owners profit, if exchange does bad depositors lose everything).

That is the least of your problems.  Some very large bitcoin services have lost some very large amounts of bitcoins because they were running on a VPS.  Google Bitcoin linode hack.

The operator is stupid enough to run a hot wallet on a VPS.  The attacker may not have access to the wallet.dat or file system but can monitor the CPU and manipulate its operation from the hypervisor.

This is a side channel attack.  There is no flaw to find or fix in the protocol.  It says that if the attacker can monitor and manipulate the CPU then they can steal the private key.  The fix is to make sure the attacker can't monitor or manipulate the CPU.  If almost all circumstances if the attacker can do this he can simply steal the wallet.dat (which is much easier).  

The one exception would be idiot service operators running bitcoin services in "the cloud" or on VPS.  Of course there have been at least two dozen thefts in the past related to compromises of VPS (including linode).  Virtual environment will NEVER be secure for bitcoin services.  OpenSSL may eventually make this attacker harder to pull off but even then the VPS will remain a source of hundreds of attack vectors.

If you use a bitcoin related service (exchange, eWallet, mining pool, etc) ask the service operator if they are stupid enough to run it on a VPS? If the answer is yes run, run, run for the exits because it is only a matter of when not if they eventually lose all your bitcoins.  This technical vulnerability is the least of your worries.  There are attacks which are a magnitude easier (including simply logging in with the super admin/root account and stealing the coins).

You do realize this requires the attacker to have access to the CPU.  If the attacker has access to do the low level hardware you system is likely rooted, and he is reading your passphrase as you type it.

The one noteable exception is this makes VPS even less secure.  They already were a horrible idea for Bitcoin security but I guarantee you at least one "professional" bitcoin site is running on a VPS right now. Information security begins with physical security and you can't have physical security inside another persons vault (your VPS running on their hardware).  Title should be changed to "Using a VPS means you can be hacked (by this and countless other attack vectors)".

Bitcoin isn't a website, it is a protocol.   Facebook, myspace, and twitter are still running on the flawed and ancient protocol that was around at the start of the internet.  

The internet circa 1969


The internet circa 1977


That is right it took almost a decade to build it out to just a couple dozen nodes.

The internet circa 2000
http://mountpeaks.files.wordpress.com/2012/03/1069646562-lgl-2d-4096x40962.png

TCP/IP will never go mainstream.  It is just a prototype.  The idea that a protocol which was state of the art in the 1970s, will still be used by billions of people in the 2010s is just stupid.  By 1979 the internet hadn't become mainstream so obviously it was never going to happen.  Something more efficient (and totally incompatible) will come along and we will use that instead.