Here is another quote:

and

This is a good question even if they are considered engineering samples possibly at a higher price (and optimally that price could be used as a deposit towards a full reel purchase).

They "could" but LL method of profit is through the issuance of currency.  A new L$ cost them nothing yet they can exchange it with real currency.  I do expect virtual worlds to use Bitcoin eventually although I am not sure if LL will have the vision needed to break from their (until recently) highly profitable make money from nothing and profit business plan.

Hashing isn't encryption.

Hashing, digital signatures, and encryption are all forms of cryptography.

All hashing involves cryptography.  Not all cryptography involves hashing.
All encryption involves cryptography.  Not all cryptography involves encryption.
All digital signatures involve cryptography.  Not all cryptography involves digital signatures.

Your correction of my correct seems to confusing cryptopgraphy with encryption. 

First given the title of this thread you might want to create a new thread.  Technical support would be the appropriate forum.

Are you sure this is the tx you created?  Is 1CLsCcmoiYJiYm7feS3pkpE6Ea94EEA4M5 your address?  If so the simplest solution is just to wait.  The reason I asked is there is a downstream tx so wanted to make sure we are looking at the tx you created not the tx which funded the tx you created.

It that is your tx, it does appear it sent it without a fee.  Due to dust prevention the client will give the rounding error left over (below 5430 satoshis) when creating a tx to miners as a "fee" rather than create a dust output as change (which can't be spent) but 6438 is above the dust threshold so that is also confusing, I would expect instead to see 0 BTC as fee and the 6438 going to a change address.   If all that was to technical yes this tx has no effective fee, any fee less than 0.1 mBTC per KB (so 0.5 mBTC in this case) is viewed by default nodes as no fee.  It is strange the client would "ignore" the acceptance of the fee and even stranger it would send it at all because it appears to be a low priority tx and thus the "proper" fee of 0.5 mBTC would be mandatory to be relayed.

I got no explanation other than it is weird.

What client are you using?  If it is the QT client can you go to the debug window and type

look for the line "paytxfee" what does it say?

STOP (and relax, no need to rush).
Make sure you make a backup of your wallet.dat.  Don't work on the only copy you have.
Also don't share the private key with ANYONE.

If you aren't concerned about privacy sharing the PUBLIC ADDRESS in question can help people help you.  There is no security risk by doing so but it does give up some privacy (personally I wouldn't be too worried but you need to judge that for yourself).

IF the private key for the address which has funds is in your wallet.dat then you have funds.  Don't lose it, don't share it.  The client may be "confused" or you may have done something unusual/unexpected (like have a different wallet.dat being loaded but regardless if you have the private key you have the funds*.  Everything else can be fixed.

See DC post above for some next steps ^


*To any noobs following along.  This is often a common misconception.  A wallet files doesn't ever contain ANY Bitcoins.  All the Bitcoins are on all nodes all over the world that make up the Bitcoin network.  Yes "your coins" are on tens of thousands of strangers computers.   The wallet file contains the KEYS which let you and only you spend those coins.  If you have the key you have access to the coins.  If you don't have the key you don't have access to the coins.  All other issues, weirdness, software errors can be fixed other than losing the private key.  That can never be fixed.  No key, no way to ever spend the coins.  They are still there, you can look at them, you can wave but nobody can ever spend them.


This is a non-issue see above.  Lets make sure you actually have the correct wallet.dat installed and that wallet.dat has the private key for the address which has funds.   See DC post above ^.

If you do then GREAT NEWS there are a lot of ways to recover your funds.  Make sure you keep a backup (hint: the copy you are actively working with isn't a backup) and don't share the private key.

The two easiest ways is to try to either resync your client or export the private key into another wallet (blockchain.info would be simplest) but do what DC suggested first.

Your correct the inclusion of tx in a block is pretty trivial.  Sure it is a non zero time but a CPU can validate about 15,000 tps.  If the UXTO is kept in memory (UXTO = unspent portion of blockchain and much smaller) there is no reason that including even thosands of tx in a block should take more than a fraction of a second.  Pools also use various tricks to speed up work generation when a block change occurs (send work to faster workers first, build a 0 tx block to get all miners working rapidly and then go back and build the larger block).  So for all intents and purposes we can consider this to be zero cost.

The prior poster misstates the "cost".  The real cost that miners (pools) are worried about is increased orphan losses.  For a given pool if they do something different which increases their orphan rate by 1% they lose ~0.25 BTC, if that changes produces less than 0.25 BTC in additional revenue they are net-net losing revenue.  The larger the block is, the longer it takes to propagate through the network for a given amount of bandwidth.  Those peers then need to validate it, and relay it to their peers, who validate it and relay it to their peers.  Eventually all nodes (and more importantly miners) have the new block and work to build off it.

The time between when a miners finds a block and all miners are building off that block can be considered the "critical window".  If another miners finds a competing block (same height) in that critical window one of those blocks will be orphaned.   The larger the block the longer the propagation delay, and the greater the losses due to orphans.  You can consider the chance of an orphan relative to the value of the block the "cost" (in lost revenue) for a miner adding another tx to the block.   Smaller block = less gross revenue but less chance of orphaned block, larger block = higher gross revenue (except for free tx which is why I believe they will die off) but higher chance of losing the whole block.

Gavin corrected me (in another thread) that the best estimate for the "orphan cost" is ~3.3 mBTC per kB, which is pretty huge.  This is why miners are reluctant to build larger blocks.  If you look at it from game theory perspective, they get 25 BTC for "free" (baseline orphan risk), The average paying tx is ~0.1 to 0.3 mBTC per kB but it costs them about 3.3 mBTC in orphan losses to include that tx.   There is "good news" though.  The current method of relaying blocks is relatively inefficient.  It likely with some small soft (no hard fork necessary) changes reduce the orphan cost by 80% (a more controversial change could cut that to 99% or more).  Also as bandwidth becomes cheaper and more available the orphan cost also falls, so Moore's law is on ourside.  Miners can also reduce the orphan cost by making sure other miners are direct peers.  The faster other miners learn of "your block" the faster the critical window closes.  It doesn't really matter how long it takes the whole network to know about a new block just how long it take for all (well most) miners to know about a new block.  Non-mining nodes learning about a block a few seconds later is fine for their needs.

Remember Bitcoin is an experiment, it is in beta.  For those who want a perfectly polished protocol with no rough edges check back in a decade.

I found it hard to believe and assumed initially that "refund in BTC" means USD amount converted to current exchange rate" but in thread I was corrected with multiple quotes from HF indicated refunds will be the EXACT currency and amount paid (i.e. if you paid 60 BTC the refund owed would be 60 BTC).  It is possible they didn't convert BTC to USD or at least not all of it. HashFast indicated they had venture funding and bitpay does offer the ability to accept BTC payments and keep some or all of it in BTC.

I am not speculating on what this means but like you I was skeptical and even incorrectly, corrected others (yeah D&T is sometimes wrong it happens, even got corrected by Gavin today).  I don't have the time now to find it but I was corrected with multiple quotes from HashFast.

No addresses are public knowledge.  Anyone can lookup any address from the blockchain.  Anyone could spend anyone's coins if all that is necessary is the address (hash of public key).  The private key is the secret. 

True but this isn't a months worth of work.  A simple solution would be export all private keys.  Import 5,000 keys into new wallet.  Send all funds to a single address in a third wallet.  Repeat with another batch.  Eventually you end up with all coins in a single address with a few very high value outputs.

My larger point was the explanation for the delay doesn't make much sense.  So either there is something much more complex going on or it is non-technical bad (coins lost, coins stolen, coins lost in speculation by operator, coins taken by operator).

That is a good point I believe the default is AES.  I guess it all depends on how paranoid you are.

Correct just like you can right now.  Start up your client.  You can see your balances, addresses, and tx history.  You only need to decrypt to send funds.


The QT client doesn't use a seed.  All the keys are randomly created so your wallet is a bucket of keys.  You need the wallet file plus passcode to recover funds.   Deterministic wallets like armory use a seed and all keys are computed from the seed.  With the seed you can recreate the whole wallet.    Yes if you are wondering, the QT wallet likely should use deterministic seeds but it just hasn't been done.


You could transfer the balance from your current wallet to that wallet, make a then a backup of your wallet seed is all that is needed to reconstruct your wallet.  You can even print this out and recreate the wallet without any wallet "file" by using the seed.  If you wanted to you could encrypt the seed and give copies to a friend(s) the encrypted seed could simply be a piece of paper as there is no longer a need to backup the actual wallet file.


Then you should be fine.  Against long passphrases (15+ charecters) the only real threat is a dictionary attack. If your passphrase is known (for example a common phrase from a book) then it may be weaker than you think.  Otherwise long passphrases simply can't be brute forced.  The QT wallet makes it harder for attackers in that the passphrase is hashed tens of thousands of times to produce the encryption key.   This means the number of passphrases an attacker can try per second is significantly reduced.  Simple version if your passphrase is long (15+ char) it is beyond pure brute force attacks so the largest risk factor is picking a weak passphrase (like a phrase from a movie, book, or song).


You can change the passphrase in the client. 
The backups will still be encrypted with the old passphrase.

So new passphrase unlocks the updated wallet.dat
Old passphrase unlocks the backup wallet.dat.

You could give your friends new backups but you can never be sure they didn't make a secret copy.   If you are really concerned you could make a brand new wallet, encrypt it with a new passphrase, send all your funds to that wallet, and give your friend(s) the new backup.  The old backup no longer has any value.

Truecrypt, winzip (newever versions but use open source 7zip instead) and the wallet itself all use AES.  If AES is broken triple security isn't going to help.  Remember the extra wrapper really isn't making it more secure it is about protecting privacy.

If you don't care about privacy a single encryption is fine.  If you want to protect privacy I would use the same passphrase for the wrapper to avoid losing funds by forgetting one of the two passphrases.  Essentially you are gaining privacy not security.

I wish the client had an option to encrypt private keys only (Security) or encrypt entire wallet (security + privacy).

It should be safe.  Strong password (even one that was only 20 char would be fine) is secure from brute force.  As long as you moderately trust the friend you will be ok.  A lot depends on what you do, how much and what type of "heat" might be coming your way.  If you think a FBI strike team is going to go after your friend for the wallet well maybe that is expecting too much from your friend.

As noted in the post above an encrypted wallet only encrypts the private keys.  The transaction history, the addresses, and thus the total balance are also visible even with wallet encrypted.  If you want privacy as well as security you should encrypt the wallet using pgp or some other option.  Winzip with same password as the wallet is likely fine if you are worried about losing PGP key as the goal of the encryption wrapped is just to prevent "read access".

Another option is to use a system like Shamir's shared secret.  You can encrypt the file in such a way that is produces multiple outputs and needs some or all of them to reconstruct the original.  For example you could break the wallet into 3 pieces and give them to 3 friends where 2 of the 3 pieces are needed to reconstruct the wallet.  No single friend could conspire against you and even if one of the three friends loses their copy you secret is still safe.

What innovation has occurred in successful alts?  The Bitcoin devs don't have control over the network.  THAT IS THE WHOLE POINT.  There has been very little innovation in altcoins but some of the radical concepts like proof of stake are unlikely to EVER be implemented in Bitcoin.  Bitcoin is a consensus system.  It is more likely (and this very unlikely) you could see a fork to a "new coin" that uses the existing Bitcoin ledger in order to incorporate radical changes.


Still I think you give Vlad too much credit.  He has never claimed the successful alts will be successful.  He has actually claimed innovation, features, merchants, developer support is stupid.  His champion is IXC which is a complete clone of Bitcoin except the block subsidy drops to zero in a year.  Case in point in the very post above this one, he is advocating people buy $50 in IXC because the left for dead clone coin is going to jump 15,000% this year.  Due to innovation, features, superior development team, usability, community?  No of course not those are all stupid.  "The banks" are going to buy up IXC and then somehow kill Bitcoin (but not before they Bitcoin into the millions and the world government takes it over and chips everyone) or something insane like that.

It happens.  Sometimes the whole network gets unlucky.  Sometimes it gets lucky too but most people don't notice that.

The odds of >40 minutes between blocks is roughly ~2%.  On average it will happen roughly once a day.
The odds of >60 minutes between blocks is roughly ~0.2%.  On average it will happen roughly once a month.
The odds of >90 minutes between blocks is roughly ~0.01%.  On average it will happen roughly once a year.
The odds of >120 minutes between blocks is roughly ~0% (tiny number).  On average it will happen roughly once every decade.
The odds of >150 minutes between blocks is roughly ~0% (tiny number).  On average it will happen roughly once every century.

Note the ranges are rounded to nearest full unit (day, month, etc) to make it easier to understand/relate on relative rarity.  I sacrificed a small amount of accuracy to come up with ranges that are easy to understand.


Of course all that also assumes the network isn't under attack and the actual hashrate is roughly equal to the hashrate required for current difficulty.

Yeah they are calling you insane .... FOR ALL YOUR INSANE SHIT.  Not for the sane (but highly dubious) examples you posted.

Saying "the banks" are going to buy up IXC for billions = insane
Saying the world government is going to take over Bitcoin = insane
Saying IXC is going to kill off Bitcoin = insane (and also a contradiction to the prior two claims).

Lots of people call you insane.  I have called you an idiot and a sleazy used car salesman trying to pump IXC.  

I never said nobody has called you insane.  I said nobody has called you insane for saying Bitcoin will go up in price or that the ETF will be sucessful.  Find a QUOTE from anyone disproving that.  TRY READING A POST BEFORE YOU RESPOND.

Correction, the ledger is not encrypted.  Cryptography in the form of digital signatures and the proof of work hashing function authenticate transactions and make retroactive changes to the ledger difficulty to accomplish.  There is no encryption in the Bitcoin protocol but yes the larger context is right.  The question was in the right ballpark but all the details incorrect and nobody corrected it.  An opportunity lost.  If nothing else correcting DECENTRALIZED is kinda important.  It is the decentralized ledger which is the heart of what makes Bitcoin well Bitcoin.

My dartboard. 

http://www.theguardian.com/books/2013/nov/19/selfie-word-of-the-year-oed-olinguito-twerk

Well at least Bitcoin made it to the short list.  The pick of "selfie" seems downright stupid to me.  Even if Bitcoin hadn't "won" there are far better choices with staying power.  I will punch myself in the face and take a self portrait if people are still using "selfie" in ten years.