Selfish mining wouldn't change the number of tx confirmed.
One could engage in selfish mining actually make larger blocks and thus have less of a backlog.

The vast majority of significantly delayed tx are free.  The default block rules cap free tx at 27KB or ~60 transactions per block.  That is a mere 0.1 tps.  If people are creating more than 1 free tx every 10 seconds unless a miner decides to miner MORE than the default free tx which increases their orphan rate for exactly 0 BTC more revenue then there is going to be a backlog.  If the rate of free transaction creation rises then the backlog will get longer and longer and longer.

It doesn't.

Here is a the reality (and it applies to just about any legal matter).  It isn't worth 2 craps what you think ... or I think or your neighbor thinks or even your lawyer thinks.  What matters is what that old guy in a robe behind a bench thinks.

At least in the US FinCEN has already told you what their side of the case will look like.  If you convince a judge they are wrong and you are right well it doesn't really matter what FinCEN thinks either.

However if that is the extent of your case well I don't think FinCEN has much to worry about.

nodes relay tx to their peers, eventually tx reach miners, miners place them into blocks and look for a solution (hash below target value).  Nothing will change when the block subsidy goes to zero.

Miners are compensated by block subsidy + transaction fees.  As the block subsidy declines (over the next 100 to 130 years) fees will become more important.


sure however understand it takes a significant amount of hashing power to solve a lock in a reasonable timeframe.  There are 144 blocks per day or 4,320 per month (on average).  You would need be able to solve 3-4 blocks per month to have high chance of ensuring you will solve at least 1 in 30 days (there is an element of luck).  So you would need about 1/1000th of all the hashpower on the network.  Currently the network is ~4 PH/s so we would be talking about 4 TH/s and that number will be higher in the future.  Honestly it probably makes more sense to just pay the tiny tx fee.


Nope as above everything will be the same.


No.  Bitcoin works on the concept out inputs and outputs.  The input for a tx is the output of a prior tx.   Using 3 inputs from a single address takes up exactly the same amount of spaces as 3 inputs from different addresses.

A millie.  Like as Gavin showed me today the orphan cost for a miner is ~3.3 millies per kilobyte of block size.

And you can possibly never show a positive return with the largest possible rig if you pay too much.

The factors for profitability are
price $/GH
efficiency J/GH
electricity cost: $ per kWh
exchange rate: USD per BTC
dificulty: both current and rate of growth

As odolvlobo, said the size of the rig doesn't make any difference.  It would be like saying "you will never show a profit unless you buy a LOT of facebook stock".  No you can profit with a single share, and you could also lose 100% with a million shares.  What matters is the price you buy at the price you sell at.

TL/DR version:  The way to "fix" a decentralized currency is to centralize it.

I hadn't see Help's correction, I wouldn't have corrected it except it was a correction of a correction.  Casual use is one thing but definition should be accurate in clarifications.   

I don't consider client side use of encryption in one or more clients to mean Bitcoin (which is a protocol) uses encryption.  The QT client certainly optionally supports encryption but I would be fine with stating on public record that Bitcoin does not use encryption. 

I do agree with you it was a wasted opportunity to correct the senate and get the proper definition on record.  More important than the misuse of word encryption is the longer context.  The senator said "hiding by encryption" which means it was more than just a wrong word.  The blockchain is the exact opposite of hiding.  It is a public record by definition.  It is closed private ledgers (like PayPal for example) that are hidden from public view.   A horrible waste of an opportunity to get a solid good high level view out in the open and on TV as well.

The first rule of 10001 club is we don't talk about 10001 club.

I haven't seen many problems with "normal" paying tx however:
a) Someone user have reported issues with paying txs and the actual issue is the tx uses as an input the output of a prior tx which hasn't confirmed. Fee or not a tx isn't going to confirm until the inputs confirm.  If the input has no fee it may take a long time.  The issue isn't the paying tx it is the unpaid one that it relies on.  The QT client prevents spending unconfirmed outputs for this reason. If other clients allow this it should probably be disabled by default.  A protocol change to improve this scenario is called "child pays parent".

b) Most clients by default most clients include no fee for high priority txs. That may have been optimal at one time however today that can mean waiting a long time.  I recommend setting the default fee to 0.1 mBTC for ALL transactions if you want timely inclusion in a block.  The days of pay a fee for low priority but get into a block quickly for free if tx is high priority are coming to a close.  Free tx should be considered charity and the time to confirmation may be hours, days, or even weeks.   Clients should probably warn users to expect potentially extended confirmation times if they try.

c) Some users mistakenly think that a very low fee (say 1 satoshi) helps but by default miners consider fees below 0.1mBTC (10,000 sat) to be free so really there is no point to pay a fee below 0.1 mBTC you are just wasting money the tx isn't going to confirm any faster than a no fee one will.  Clients should probably warn users about this behavior if user tries to pay a fee below the default threshold.

In my experience baring those scenarios most paying tx due confirm very quick, at most they may be delayed a block or two.  So it isn't an issue for all tx all the time.

Probably not.  28nm is very likely as good as it gets for 2014.   Even if a new 28nm chip was 2x more efficient than any other spec on paper it would still mean about 400W per TH, or 4 MW (as in a small power plant) for 10 PH/s.  In 2015 we may see 20nm chips but the days of 1000x the peformance are over.  20nm chips is going to offer maybe 30% higher efficiency for the same cost, or 20% higher speed for the same cost. 

Miners will get cheaper (maybe) and rigs will get larger but you really are limited to 2 TH/s on a "normal" US 120V outlet with current chips.  Even a break through chip would be lucky to triple that.  Prices may fall but they can only fall so far.   At $0.30 per GH/s (90% cheaper than anything offered) a 10 PH/s rig would be ~$3M USD.

True however China's price in USD equivelent is still higher than any USD exchange (4200 CNY is ~$690 USD).  

What is interesting is the spread between exchanges has narrowed.
From the bottom China rose the least and Bitstamp rose the most.  The gap between all three exchanges is now smaller than at the peak.
Not sure what that means (if anything) but I thought it interesting.

It may seem like a techincal distinction but it matters.  Bitcoins don't "go to your wallet" Bitcoins are on the blockchain.  So the only thing that matters is do you have that address and private key in your wallet.dat file.  Simple version is if the answer is yes you have the coins, and if the answer is no you don't.

Longer version:
The 14.9 BTC was sent to address 12Yim3HLs3vtpNonkSNN8WP6SiRL5svDeg, they haven't been spent so the person who has the private key for 12Yim3HLs3vtpNonkSNN8WP6SiRL5svDeg is the only person who can spend them.
So lets start at the beginning.  Is 12Yim3HLs3vtpNonkSNN8WP6SiRL5svDegin your wallet?


DC provided a good way for you to determine if that is the case

If it provides you the private key then you are good.  If it provides an error then this wallet.dat file doesn't contain that address and thus doesn't have the private key necessary to spend those coins.

So if you get the error some long shots:
Are you sure you copied the backup wallet.dat to proper folder (is the client looking at the correct wallet.dat)?
Is it possible you created this address after you made a backup (100 future keys are stored but if the backup is very old relative to the date of the transaction it may not contain this private key) and maybe you made another backup after this transaction?  
Do you have any other wallet.dat files anywhere on any drive (hdd, usb, etc)?  If you have more than one wallet.dat files I would check them all.
Is it possible this address wasn't part of your wallet?  Maybe it was for an online account like another exchange or eWallet?

If you don't have this address in any wallet.dat file anywhere and it isn't the deposit address for an online service then there is no there is nothing to recover.  No private key = no coins.  I hope that isn't the case.

True but selfish mining actually means a net reduction in current income.  The attack is that an attacker would lose money today to generate a larger than fair share of revenue in the future.  I don't find it a particularly viable attack method as if you want to expend massive amounts of cost today to hurt the Bitcoin network you could just do a traditional 51% attack.

Simple version if a pool has 20% of the hashing power and due to longer propagation another miner wins the race to all other miners then the pool has a 20% chance of winning both blocks but an 80% chance of losing the already solved block.   In reality that type of simplified race outcome is very unlikely it is more likely that a pool broadcast a block and it reaches some % of miners first (including itself) and a competing block reaches some % of miners first and for the next block the network is split.  How split really depends on how close the race was and how different in size the blocks are.

Black and white thinking.  The world is full of shades of gray.  When the requirements become high enough that is has a real cost many users will not run full nodes but many still will.  It doesn't have to be everyone is a full node or the network is reduced to a half dozen nodes.  The reality is inbetween those extremes.


Well no.  SPV clients have methods of protecting privacy called bloom filters.


Having several altcoins wouldn't reduce the load.   If there are x tx on Bitcoin network and Bitcoin is replaced by a number of smaller altcoins, to have the same tx volume would mean the requirements to run all of them is the same.  To exchange coins between chains or mine all the chains would require the same amount of resources.  If you feel that amount of resources will reduce the network to a handful of nodes then the same thing would happen.   If all the mining and exchanging is done by a handful of nodes then you are in the same scenario.

The reality is that won't happen.  Higher resource requirements, and many users opting for the cheaper SPV option doesn't mean nobody will run full nodes.  IMHO there will always be that critical mass.  Enthusiasts, users with large amounts of Bitcoins, merchants, service providers, developers, and just "hardcore" believers will provide enough nodes for that critical mass of full nodes.

In other words right now the estimate on the number of full nodes in the Bitcoin network is probably on the order of tens of thousands of nodes.  Lets say 50,000 full nodes and lets imagine the number of users is 500,000.  That means 1 in 10 users is running a full node.  That ratio will drop if we jump to 1M users we probably won't see a mangnitude increase in number of full nodes, it might still be ~50,000.  The ratio of users to full nodes is now 100:1 but we still have 50,000 full nodes in 200 or so countries to provide decentralization.   Jump further in the future 10M users, 100M users, etc the ratio between users and full nodes is almost guaranteed to drop but that doesn't mean the number of full nodes will drop from 50,000 to 50.

On a long enough timeline, the average user will probably not run a full node.  That is just the reality.  A full node is an equal peer on a global payment network.  You can't have "global" and low requirements in the same sentence.  Most people don't really think about that aspect but a full node is a full and equal peer (no less or more important than any other peer) on what potentially could be the largest payment network in the history of the human race.   That is always going to have a cost.  Alternative solutions may reduce that cost to some degree but you can't have a massive network with millions of users and billions of transaction and expect the PEERS (as in PEER TO PEER) to have negligible requirements.

The good news is Satoshi envisioned a solution before the genesis block was even created.  Most users don't need to be full nodes, Bitcoin protocol supports a type of client called SPV (Simplified Payment Verification).  SPV nodes/clients download in realtime, only the parts of the blockchain that are related to their transactions.  They still validate information received from full nodes (the use of merkle trees and blockheaders allows SPV nodes to ensure the information they receive is accurate).  More importantly they keep their private keys secret, and sign their own transactions so they provide a higher level of security than eWallets.  The resource requirements are negligible compared to a full node.   So it comes down to a choice.  Do I want to be a user on the network at negligible cost or do I want to BE a part of the network as a full node with the costs that will require?  Many (probably most) users will opt for the former but Bitcoin doesn't need every user to be a full node, it only needs a critical mass.  IMHO there will always be that critical mass.  Enthusiasts, users with large amounts of Bitcoins, merchants, service providers, developers, and just "hardcore" believers will provide enough nodes for that critical mass.

Altcoins are not a solution.  They only have lower requirements because they have less users, less transaction volume, and less history.  If they ever reached Bitcoin scales the some requirements would apply.

This.  You don't "download" Bitcoins.   The Bitcoins were sent to an address.  You either have the private key for that address or you don't.  If you have that address in your wallet, you have that private key in your wallet as well.  If you don't have that address and private key in your wallet then your coins are lost or were never yours (potentially you sent them to an address you have NEVER had control of).

Another post shows how you can check if the address and private key are in your wallet.
https://bitcointalk.org/index.php?topic=340948.msg3656457#msg3656457

If you post that address we can help you a little more by providing specific instructions but the concept is still the same.
To spend from Address X requires private key Y.  If Address X is yours and is part of this wallet.dat then private key Y should be also.

That is why CC fraud is such a problem for merchants.  They are put in an impossible situation.  There is no consequence for CC users (oh I didn't make that chargeback) and the problem simply can't be solved by merchants.  Merchants can't force users to be more secure with their cards, not fall for phishing sites, and treat a CC number like cash.  At best merchants can hope to reduce the fraud losses below their profit margin and raise prices.  

I am not saying it is a good thing but if there was no fraud liability on CC, users would be a lot more careful.  It is just human nature.


This is one reason why I am long term bullish on the VALUE (not be confused with current price, speculators) of Bitcoin.   CC costs as much as 10% for certain types of businesses.   It isn't just the 3% (or whatever) discount rate, but also the gateway fees, the swipe fee ($0.30 adds up on $5 purchases), the legit CC fraud, the so called friendly fraud (I don't like want to pay for this so let me pretend I didn't purchase it), the chargeback fees from the bank, the capital cost of the reserves they need to maintain (you can't use money being held the CC companies), and the cost of the anti-fraud systems which both have significant cost and sometimes drive away legit business.

If merchants can see that Bitcoin improves their bottom line then they hopefully will offer discounts for Bitcoin.  If they offer discounts for Bitcoin then more users will be attracted to Bitcoin for everyday purchases which means more merchants interested ....

Either way will work but if you can I would just leave the client running.   You can't control other nodes all you can do is "talk to them" through your client (happens automatically).  Right now the majority of the network believes your old tx is valid and will reject the new one.  37 nodes believe the new tx is valid and will reject the old one.  So the network is "split" eventually one of those tx will end up in a block.   Since other nodes know about your tx and will continue to try and relay it you probably can close your client but having your client broadcasting is one more node "on your side". 

IF all that was excessive.  Simple version:
If you can leave the client running, do so as it can help spread the new tx faster.  
If you can't leave the client running you should be fine as 37 peers know of the new tx however if they all went offline your tx might not confirm until you start your client up again.

Hell at this point I would settle for just having it out in the open. 

What ARE the parameters you use for a block?
How many free txs?
How many paid txs?
What is the threshold for paying vs fee? (by default it is 0.1 mBTC).

If you can start a thread and get 10 pool admins to provide that kind of insight the community can start making better decisions.  The nice thing is the blockchain keeps them honest.  If pool xyz claims they allocate 27KB per block for free tx and there is a backlog and they produce multiple blocks with <27KB we can prove they are not being honest.  Likewise if pool abc claims they will include up to 500KB of paying txs with theshold of 0.1 mBTC per KB and they produce multiple blocks smaller than 500 KB while paying tx are waiting it can be proven they also are being dishonest.

If we KNOW what all the major pools (and major solo miners with more than say 5% of global hashrate) have as their transactions selection parameters we an put that together and start to get a better view of how long various tx are going to take.  If you know combined all the pools on average only devote an average of 27KB (the default) of space for free transactions that is ~60 free transactions per block.  If there are 2000 waiting it is going to take 50 blocks (assumming no new tx) to confirm all of them.

Danny as usual is always right.


BTW "Oh you're bruteforcing a SHA encryption"  SHA isn't encryption.  It is a hashing algorithm, the output of a hashing algorithm is essentially random.  It is a number between 0 and 2^256-1.  Bitcoin just uses it as a "proof" that a certain amount of work has been attempted.  We can do this because if you have a provably random event which occurs for example one in 1 billion attempts while someone may get lucky or unlucky over the long run (thousands of events) we can prove that it took on average 1 billion attempts of work per event.  The difficulty for solving a block however isn't static, the network sets a target which is simply a number between 0 and 2^256-1.  To solve a block the output hash has to be smaller than the target.   The lower the target number the harder it is to "solve" a block and on average it will take more attempts.  As the network gets faster (more attempts per second) the network makes the target smaller (more attempts needed to "win"), when the network gets slower, the network makes the target higher (less attempts needed to "win").   This target balances the computing power on the network with the goal of on average 600 seconds between blocks.  No matter how slow or fast the network becomes the blocks will be find in a relatively consistent manner because the computing power is balanced with difficulty.

If the network combined is able to produce 10x as many hashes per second, then it takes on average 10x as many hash attempts to solve a block.
If the network combined is able to produce 1,000,000 as many hashes per second, then it takes on average 1,000,000 times as many hashes to solve a block.
Right now the network difficulty is roughly 700 million so it takes on average 700,000,000 times as many hashes to solve a block as it did when Bitcoin first started (the actual number is difficulty * 2^32 because the starting difficulty of 1 requires 2^32 attempts).


If you want an analogy, imagine a game where you randomly generate a number between 1 and 100 (say using a pair of ten sided dice).  You get 1 roll per minute and on average I only want a winner every 10 minutes.  I would make the target 10 or less.  There are 10 numbers below the target and 90 above it, your chance of winning on each roll is 10%. You might get lucky or unlucky in the short term but on average you will win once every 10 minutes.  If you have won 100 times we have been playing for 1000 minutes and there is "proof of the work" we know that it would have taken you roughly 1000 rolls to win 100 times.  Now imagine a second player joins but I still only want 1 winner every 10 minutes.  I could simply reduce the target to 5.  The chance of winning is now 5% per roll and there are 20 rolls per minute so there is still only one winner every 10 minutes.  Now imagine a third player joins but he gets is able to roll three times a minute.   In total there will be 5 rolls per minute and I want one winner every 10 minutes (50 total rolls) so the chance should be 2% per roll and I lower the target to 2.   Regardless of how many players join or leave, or how fast or slow they can roll (maybe some people have more than 1 set of dice) I can set a target so there is on average only one "winner" every 10 minutes.

Rather than roll dice we use SHA-256 to be the source for random values because it is provable and compare them to the target.