Per the link ...

Which is pretty close to your estimate.  The hashrate average seems to have declined since then so either the miner has moved to a new pool, split up his hashing power, or is experiencing problems.

Yup.  Absolutely nothing new in v0.9 on this front.  Now low priority tx are still required to pay a fee and that hasn't changed (although the min has been reduced to 0.01 mBTC (from 0.1mBTC).  How long it takes for a miner to include a tx in the next block at 0 BTC, 0.01 mBTC or 0.1 mBTC has always been up to the miner not the client.

What kind of idiot came up with a 50% top down and 50% bottom up system?

It is a pretty simple concept even without lawyers or bankruptcy.  If the company owes 100 BTC and can today pay creditors 1 BTC it pays ALL CREDITORS 1% of their balance.  It now owes everyone 99 BTC and each individual has received 1% of what they are owed.  This continues until either the debt is paid off or the company fails.   An insolvent company paying one creditor ahead of another one (unless there was some seniority of debt) is illegal in most jurisdictions.

If losing the coins didn't prove their incompetence, then their scheme to return them certain does.   Maybe the operators should talk to legal counsel about the fraudulent conveyance act?  Creditors who believe they are in the middle (and thus most likely to receive absolutely nothing) should probable talk to a lawyer too.

These nine pages should be mandatory reading.  For bonus point read it again a couple months later.  Bitcoin is like an onion, lots of layers.  The more you learn, the more you realize you have more to learn.

No other reason.   2^n transactions is the most efficient merkle tree (balanced tree).  By most efficient I mean the ratio between # of transactions and # of hashing operations is the lowest.  Now how much of a real world difference does it make to orphans I can't say but I would guess it would be negligible.

Noted. We will have a few openings in the coming month and all of them will be remote.

And?

Why shouldn't they?  When the bond pays off does the profit go to the taxpayers?  In what universe is private profit but subsidized losses a good idea.  If the bond holder of banks had taken losses, they would be less likely to trust the banks with money in the future.  That is how capitalism works.  You don't just get to keep the profits and pretend away the losses.

Come on you are a smart guy, you know that is a load of crap.  There already IS a safety mechanisms for depositors called FDIC.  The banks didn't "need" to profit from the problems they caused so how about this instead.

The banks fail. FDIC puts them into receivership (like they do hundreds of banks a year).  In receivership:
a) shareholders are annihilated, as in stock is wiped out.  100% complete loss.  Shareholders get the profits, they should take the loss like in any other business.
b) CEO are tried for fraud and gross negligence.  Clawback of bonuses and other executive compensation occurs.  Shareholders sue and pierce the corporate veil for violation of fiduciary duty and fraud.  Personal assets seized in bankruptcy court.
c) Those responsible are sentenced to significant prison sentences.  No leniency is granted.  Something on the order of 25-50 years in prison would be a solid deterrent for future malfeasance.
d) FDIC puts sufficient capital into damaged banks, writes off worthless assets and then returns the banks to public sector.

Cost to taxpayer is essentially zero.
Losses to depositors is essentially zero.
Losses for the owners and operators is total.
Economy recovers much quicker and the moral hazard of "too big to fail" is avoided.

All of that could have been done under existing law and authority, yet you really believe the ONLY solution was to hand the banks trillions upon trillions of taxpayer dollars, then keep the borrowing rate at the fed discount window at 0% (borrow at 0% lend at 20% kinda hard to not make a profit) for years, keep all the bad actors in place and then allow them to receive billions in compensation?  Really?

You either a) don't believe the nonsense that banks can't be allowed to fail and are just pushing an agenda or b) are simply naive and swallowed a lie told to you by the very people who profited on a scale you can't possibly imagine.  The worst part if the profit was at your (and mine and everyone else not in the 0.01% club) expense.  They profitted, you lost and you are trying to convince everyone it was a good thing and the only way it could be done.

Want a concrete example.
http://www.bloomberg.com/news/2014-01-27/let-banks-fail-becomes-iceland-mantra-as-2-joblessness-in-sight.html

The banks in Iceland were wiped out, restored by the equivelent of FDIC and taxpayer funds, and then returned to public sector.  The cost to taxpayers was negligible and they are now at under 4% unemployment (and falling).  How well did bailing the too big to fail banks work out for the US?

Probably not or at least not any pool of significant size.  Left you some friendly feedback.

Probably not.

1) The client won't intentionally double spend so you will need to delete the the first tx from the wallet "history".  The client provides no mechanism to do this natively although tools like pywallet can be used. 

2) All nodes will drop double spends in favor of the first tx they saw.  So in your example you sent tx#1 to all your peers.  When you send tx#2 to the same peers they will immediately recognize it as a double spend and simply "drop" (delete) it.   Changing to new peers is unlikely to work as your peers relayed tx#1 to their peers who relayed it to their peers, etc, etc, etc, and within a few seconds every node on the planet is aware of tx#1 and will see any attempt to double spend it as invalid and just drop tx#2 without relaying.

The network is intentionally designed to make double spending difficult.  
The client is intentionally designed to make creating tx that have a very high probability of being "stuck" (never relayed to included in a block by most clients) difficult.

You can hack around these design constraints but don't expect it to be easy.  This is why Danny indicated you need to wait a few days.   If a particular node NEVER dropped tx#1 then it would never store or relay tx#2 however to avoid a memory exhaustion attack eventually nodes will drop the oldest tx from the memory pool.  You can't control when your tx#1 will be dropped by other nodes.  It will occur as needed with each node acting independently.  Until tx#1 is dropped from a particular node any attempt to broadcast tx#2 will mean it is simply dropped by that node.  Until tx#1 is dropped by a majority of nodes the probability that it will be able to propogate the network and find one or more miners is very low. 

In theory you could bypass all that by sending the tx directly to a miners however most miners don't make their processing nodes known or accept inbound connections.  Those that do don't allow replacement of txs in memory pool for obvious reasons (malicious double spend).

The uninstall and install does not remove or modify the existing wallet.dat.

However you should ALWAYS have an up to date backup (this is money we are talking about).  This is especially true when upgrading, installing, uninstalling, etc.

Make periodic backups even when you aren't upgrading.

AFAIK starting in v0.9 the RPC client has been separated out.  So to send RPC command to bitcoind using the command line the bitcoin-cli is used.  


That would include stop.  Not sure how/why
does anything (shouldn't it be bitcoin-cli stop)?  
On edit: it looks like the stop all RPC calls can be made from bitcoind (no idea why?).


There should be no difference between bitcoind stop and bitcoin-cli stop at this point.  It looks like bitcoind failed stop cleanly on the first attempt.  Taking a look at debug.log might provide some insight.

There are no blockchain (forward) incompatibilities between v0.8.6 and v0.9.0.  If when starting bitcoind it is attempting to recreate the blockchain from the genesis block that would indicate some type of corruption.  Taking a look at debug.log might provide some insight.

Ridiculous? No.

Utterly incompetent that they don't understand the concept of using database transactions to ensure changes to the DB are atomic?  100% yes.

You aren't.

Of course it is very easy to prove.

Supply the tx id and YOUR public key (PubKey) for the address in question.  If there is a PubKeyHash collision the tx will be signed by a pubkey which is different than yours (i.e spending tx signed with PubKey A and you provide PubKey B and both of them hash to the same PubKeyHash.

Since a 160 bit hash collision would be incredible news (beyond just bitcoin) and you have all the information to prove it publicly you of course will do so promptly right?

Hint: here is the part where you makeup reasons as to why you can't do that.

Yes.  It is showing the balance as of the block it is currently on.   It won't necessarily reflect your current balance until the block height reflects the current block (or more specifically the last block which contains a tx involving one of your addresses).  If you think about it, there is no way it could.  The client is scanning the blockchain looking for unspent outputs.  When it shows you have 1.2 BTC what it means is the sum of the value of all your unspent outputs is 1.2 BTC.  If it is on block X and you have an unspent output worth 0.3 BTC in block Y (where Y>X) it doesn't "know" about it yet.  When it reaches block Y that unspent output will be added to the wallet balance and the client will be updated to reflect 1.5 BTC.

and?  A majority of people are NOT using Bitcoin today and it still has value.  If a majority of people decide to use inflatacoin it doesn't erase the existing Bitcoin network.

Nothing.  Except they don't control the blockchain.  You can do decide on higher monetary inflation right now with a single miner and modified source code.  Just modify the client to produce a 50 BTC rewards and start mining.   Of course all existing nodes will simply drop your blocks as invalid.  The fact that you have produced an alternate chain doesn't prevents anyone else from just ignoring your fork and continuing to use the "real" Bitcoin.  The reality is that unless they update their client (or look in the debug log) they will never even know your fork exists.  Having 51% of the hashrate doesn't change that dynamic.

You can't change Bitcoin all you can do is fork it.  The hard part is convincing people to use your fork.  

There is no such thing as a "false address".  If they provided you that address then it was a valid address.  Period.  If later through incompetence or malfesence they "lost" the private key for that address it doesn't change the fact that they provided you that valid address.  

The network did exactly what you (and indirectly CryptoRush) asked it to.  It sent coins to the valid address provided.   Your issue is with CryptoRush (not BTCe or the bitcoin network).

It would be no different than CryptoRush providing you a PO BOX and telling you to mail some cash.  You mail the cash to the PO Box they provided, and you have delivery confirmation that the cash was delivered. When you ask about it they say "oh sorry that isn't the valid CryptoRush PO Box" and then blaming the US mail for properly delivering the cash exactly where they told you to.

You can't send coins to an invalid address.  You can send coins to a WRONG but valid address.  The network has no way of knowing you don't mean to send coins to valid address A when you create a tx sending coins to valid address A.

This.

A private key is only private if only you know it.  There is no such thing as a private key that everyone knows (but promises not to use because it doesn't belong to them).

The super simplified version is that there is a mathematical relationship between private key and public key such that a message signed with a private key can be verified with the public key.



Just replace email with bitcoin transaction and the process (at a high level) is similar.