Why did your hosting provider have root access to a server with wallets?  If your hosting provider has super admin you have no security.  An attacker or employee you rob you at will.

1) You can use a smaller PDU.  Understand no PDU uses the same plug as a dryer so you will need to change the outlet.   Also most dryer plugs in the use are actually split voltage 240 & 120 in a single plug you are only intersted in the two "hots".

2) No.  A 240V PDU outputs 240V.

A bitcoin is  1E8 satoshis.  Bitpay isn't considering renaming a bitcoin and they shouldn't.  Adding a new name is a different scenario than redefining an existing name.  IF not everyone uses "bits" it may cause the user to say "hey what is bits" but when some people use Bitcoin to mean one value and some use it to mean another value it creates a different type of confusion.


A government is an example of an absolute central authority.  There is nothing like that in the Bitcoin world.  You will never have absolute consensus so redefining an existing word means a period of time where two competing camps call different things "a bitcoin".  Can you imagine a user paying $400+ thinking they are getting "one bitcoin" as described by Satoshi and instead getting 1/1,000,000 of that by some scammer?

Actually in most countries that is untrue.

A corporation can have assets and liabilities independent of its owners.  A sole prop can't.  The business liabilities are personal liabilities because the owner IS personally liable for the business.

Was inputs.io organized as a corporation (or other independent legal entity) and registered with one or more state?  If not then there is no distinction between business losses and personal losses, not one that any court of law would see.

But for every "solution" there is another problem.  The alternate DOES change the difficulty adjustment frequency to every block.  This now means miners have more direct access to manipulating timestamps and suppressing difficulty for financial gain.

Add to that the 95% miners would have a very vested interest in ensuring this imposter dies in the cradle. This is even more likely if the imposter tries to use the bitcoin brand because it creates user confusion and negative PR. So say 6% of those miners could temporarily take a small paycut and 51% attack the imposter.  Exchanges accepting the imposter coins could potentially go bankrupt, merchant adoption would essentially be zero.  In all these scenarios what the person proposing it usually fails to consider is the application of risk.

It is interesting to note that as the last subsidy cut approached some predicted the same thing happening then.  Of course it didn't; miners tend to be pragmatic.  1 bitcoin in the wallet is worth more than a scheme to have two.

There is nothing to dissect it is completely nonsense. Yes difficulty lags actual hashing power, this isn't some secret revelation.  The decision to adjust difficulty every 2016 blocks keeps the system simple and reduces the ability for miners to suppress mining difficulty.  Validating timestamps in a decentralized system is very difficult (I would say probably impossible).  Bitcoin sidesteps that very hard to solve problem by making timestamps (almost) irrelevant.  The one place timestamps are used is to compute changes in difficulty.  This is necessary because difficulty, at an abstract level is computer power divided by time.  Time needs to be recorded in some fashion but it is also easy to fake and hard to prove.  By only relying on timestamps in the one place where they are necessary, it limits the material effect of false timestamps to just difficulty computations.

The magnitude of any manipulation is limited by two factors.  The first is that miners can only fake timestamps by so much (~2 hours) because blocks which deviate from the network average time will be considered invalid.  Since the expected time for 2016 blocks is 336 hours (2016*10/60) at most a miner could suppress difficulty by ~0.5% (1% if both the first and last block are manipulated).  This small reward is problematic to obtain as no miner can be assured they will mine the critical blocks.  The manipulation must also be maintained forever just to keep (not increase) the reduction in difficulty.

Simply put:
* Verifying timestamps is nearly impossible in a decentralized network
* Bitcoin wisely bypasses the need to trust timestamps by only using them where they are needed (computing difficulty).
* The 2016 block period ensures that while miners can manipulate timestamps to suppress difficulty it is both difficulty and limited in scope.

Well there can always be more leading zeroes due to "luck".  Case in point, the genesis block has ten leading zeroes, 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f.

A couple years back I donated a 2GB SD card made by SanDisk to science.  I setup a simple loop which continually wrote to the card with pseudo random sequences until it filled the card.  It would then read it back, verify it was correct, erase the card, and start over.  I got 11TB worth of writes before the card started showing failures.  I have no idea if this is typical but lets assume it is.  A 64GB SD card would be more like 700 TB of writes, which should be sufficient for a decade of blockchain usage even if the tx volume increases by a factor of ten or more.  

Of course one advantage of a dedicated device is you can strike a compromise between storage writes and memory usage.  One example would be to only write confirmed tx to the memory "disk", the memory pool would remain in memory.  Blocks are occasionally orphaned so with enough memory you could delay writing the block to storage until it is x blocks deep in the blockchain (each block deeper becomes exponentially less likely to be orphaned).  Other temporary less critical data like information on current peers, can be batch updated to storage.  If the node goes offline between updates it isn't a critical that the stored information about peers is slightly stale.  The fact that Bitcoin is a decentralized network makes it easier to implement delayed writing.  You can always request recent information from peers again.

The main scenario to avoid with flash is using it as a high throughput "RAM", but even a memory constrained device, will have some memory so there is no need to write everything to flash.

That is a good point.  For a set consisting of 10 million objects 256 bits is not necessary to avoid excessive collisions.  Taking the left x bits should be sufficient as this isn't being used for cryptographic purposes (and NIST certifies SHA-2 to be used for truncated hashes in some applications anyways).  The index on the other hand requires a little more thinking.  The protocol allows more than 256 outputs per transaction and is stored as a VarInt which can potentially be up to 8 bytes long (but realistically I couldn't more than 3 is probably never going to happen).  I guess one option would be to to use x bytes for the lookup hash where x = (8 - VarIntSize).  Worse case scenario you could use a full 8 bytes for the hash and full 8 bytes for the index but that would double the memory requirements.

No it wouldn't.  Miners connect to the node (just like they do any node running p2pool) over TCP/IP.  The mining software is on the miner.   Instead of pointing it at a pool wallet you point it at your p2pool node, exactly as you do now if p2pool is running on a desktop.

As for not useful well that depends.  Just as a hardware which runs a full node for the network and does nothing for the user well your right that is beyond stupid.  Why would one buy one?  However how about this.   Your wallet is on your computer, you don't want to run bitcoind locally for a couple of reasons such as you have multiple computers running bitcoind on all of them it excessive, or you don't use your wallet everyday and hate the fact that when it syncs up you need to wait.

So instead you use a light wallet which connects to your local bitcoin node (running on that <1W device connected to your local network).  Got 8 wallets spread across multiple computers no problem they can all point to the same local bitcoind.  Now you could use a SPV client but maybe you don't like the security compromise and the fact that it doesn't strengthen the network.

True but it could be useful to have high power ASIC miners connect to the node which is connected to p2pool.

If the flash (and controller) is sufficiently fast it may be possible to use that as the UXTO lookup storage.  This would drop the memory requirements to near negligible amounts (enough to hold memory pool, current block, and if used as a wallet the user's personal pubkeys).  A lot would come down to how long lookup of a random output from the UXTO would take.  A good place to start would be getting a development board.  Instead of working with a ARM CPU directly you could work with a microcontroller which is based on an ARM CPU.

I am a big fan of STI Micro.  This is their STM32F4 series. 
http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577/LN1806

The 429/439 is the most powerful microcontroller they offer.  It gives you 256KB SRAM, 2MB of flash, ethernet & usb connectivity, plus a hot of other stuff you probably won't need.  The 439 is the 429 with hardware crypto acceleration but sadly does not support the scep256k1 curve (I called to make sure ).  The main differences between the pin packages is the larger ones support more analog and digital IO pins. 

There is a development board available for rapid prototyping
http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090

That is incorrect.  Difficulty 1 represents that it will require on average 1 full nonce range, which is 2^32 attempted hashes to solve a block, not 1 attempted hash (or 16 which is what a single zero would represent).

The initial target at difficulty 1 (2^256 / 2^32) is computed as 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF to store this however would require 256 bits.  Bitcoin uses a truncated target to save space in the blockchain which means the actual target for difficulty 1 is 0x00000000FFFF0000000000000000000000000000000000000000000000000000

Note the leading eight zeroes.  There are no block hashes in the blockchain which have less than eight zeroes.

As an example here is block #1
https://blockchain.info/block/00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048

Yes Satoshi made some things a little more complex than they need to be.  There is no requirement that difficulty 1 equal 2^32 attempts.  Difficulty is just for us humans anyways the network works off the raw target and difficulty is computed from that.  So Satoshi could have made Difficulty x = x attempted hash (on average) per block.  If that were the case the original difficulty would have been 4.2 billion and today it would be 34,363,484,163,461,100,000.  Yes that is 34,363 quadrillion.  It means that on average to solve a block means computing 34,363 quadrillion hashes.  We probably would just shorthand difficulty to "quads".  "Damn difficulty is now more than 30,000 quads, it is getting insane".

Difficulty 1 is just as arbitrary as any other difficulty.  The probability of any individual hash solving a block is (2^32)*(difficulty).  On average is requires (2^32)*(difficulty) attempted hashes before one is found which is smaller than the target (and thus valid for solving the block).  So at difficulty 1 it took about 4.2 billion hashes on average to solve a block.

2^32 = 32 bits.  Expressed as hex one digit = 4 bits.  32/4 = 8.  At difficulty 1 a block would need eight zeroes.  

While looking at number of leading zeroes can be useful it is important to understand the network doesn't look just at the leading number of zeroes.  If it did then difficulty increases (or decreases) would be limited to a factor of 16x (when difficulty changes it could only stay the same, go up 16x, or be reduced to 1/16th) that is beacause each additional leading zero, make the target 16x less likely.

A block is valid if the hash is smaller than the target.  Right now that is: 0000000000000000896C00000000000000000000000000000000000000000000

So a hash with the value 0000000000000000912300000000000000000000000000000000000000000000 would not be valid despite "having the right number of zeroes".

The memory usage is primarily storing the UXTO in memory.  The memory pool is also kept in memory but it is much smaller than the UXTO. You could probably reduce the memory footprint with some "intelligent" caching system scoring each output based on the likelihood it will be in the next transaction (i.e. the unspent output from the coinbase of block2 is probably not going to be used in the next tx so dropping it from the in memory cache won't be an issue).

Remember reads from disk are very slow (compared to memory) and you can't validate a transaction until you lookup the outputs.  If none of the unspent outputs are in memory well you have now made 100% of tx validations requiring a round trip to the disk.  Right now throughput of the network is slow enough that you won't fall behind however for bootstraping a new node it is going to be painfully slow.

Well most of that memory usage is the db cache.  It probably can be done on a custom ARM based board however it isn't going to be a trivial project and you probably want the board to have a gig of memory.  The UXTO is only going to get larger over time.

Use BitSimple and withdraw by ACH (no fee)..  Banks do not normally charge a fee for receiving an ACH deposit.

Honest question (not trying to hit you when you are down) by why would you reuse an existing address to receive new funds?

Thanks.  Updated my post.  That is a particularly awful "gotcha".  The limit should be raised to 34 * 20 =680 bytes to be inline with the OP_CHECKMULTISIG limit.