text:
Wouldn't the expected return of a mining pool be no more than solo mining?
I don't understand the advantages of pool mining if you want to maximize your return.  It seems like all it does is even out your return to make it more predictable by paying you smaller amounts more often rather than nothing for long periods punctuated by an occasional 25 BTC.  But in the end won't you end up making the same amount, if not less (considering the pool operator's profit) by joining a pool?

Yes, but it's a similar situation to taking out insurance - many people would rather pay a known regular amount to insure their car than take the chance that they'll have to pay a large amount occasionally. Like pool mining, insurance usually works out in favour of the other party, but it's still valuable in order to reduce your variability.
If you have enough mining hardware operating that your payments are relatively regular, then it would likely earn you more to solo mine. If you would only solve a block very occasionally, you are taking a significant risk you'll get a low reward or nothing at all.
However, you also need to run bitcoind to solo mine, whereas you don't when pool mining. The more mining hashpower you have, the more bandwidth pool mining will use, but running a node will use a roughly constant amount of bandwidth. Update: pools are now available that avoid this problem (Thanks, Dr Haribo).
Back in the days when I mined with my GPU, I would've had to upgrade my internet account if I left the client running 24/7, which would have cancelled out any benefit from solo mining.

"The more mining hashpower you have, the more bandwidth pool mining will use" - that's no longer true with variable difficulty mining and template-based mining (GBT and Stratum) which pools have implemented to prevent them from being overwhelmed by the new ASIC hardware.

@Dr.Haribo, thanks, I've updated my answer.

While correct in principle, consider that mining difficulty has a pretty strong upward trend. This indicates that your relative hashing power (you compared to the difficulty/whole network) is greatest when you first start mining and it decreases over time. With some very rough estimates at the present difficulty of 10 million, 1 gigahash of computing should average one block solution every 16 months or so. But that's if the difficulty doesn't increase, which it will. As the difficulty increases, that extends the number of days it will take, on average, to solve a block.
It is certainly possible that you will solve the first block you attempt. But you also may not solve a block for a year or more. If you're on the unlucky side, you will have nothing to show for the duration of time when your relative hashing power was greatest. Consider somebody who engaged in CPU mining back near the beginning. Once the GPUs came on board, his chance of solving a block became miniscule. With ASICs joining the fray, the CPU miner has a completely unprofitable situation. If he was solo mining and didn't get lucky early on, at this point, he's probably never going to pay for his mining investment.
Bottom line: pool mining is a way to nearly guarantee that you will profit from your mining equipment's most profitable days. If your solo mining setup is such that your average block solution can be measured in days rather than months, you may come out ahead by solo mining.
Another consideration: solo mining involves running a node, which is good for the network. It is also good for the network to have hashing power spread out among many pools, and solo mining is a pool of 1.

Yes, on average the expected return would be the same if not lower while mining in a pool due to fees. However, it greatly reduces the variance.
If you have 0.01% of the total mining speed, you would be expected to generate a block every 10000 blocks at a 50% probability. Reaching 95% probability would be a few times less often, about 1 in 50k. Joining a pool would mean you get smaller payouts more readily, so your income is less of a lottery and more of a steady pay check.


text:
statistics on actual "replacement" of blocks
I'm not sure if I'm using the right terminology but I know that theoretically it's possible for a block to be part of the longest (i.e. "main") blockchain but then be "replaced" by an alternative chain that is longer.  Presumably it would most likely happen that the last block would be replaced in this way but it could also happen that the last 2, 3 or more could be replaced.
Are there any statistics on how often this actually happens?  For example, the last block is replaced on average once a day, the last 2 blocks once every 10 days, etc?
This would have bearing on how confident one should be after a payment has had 2, 3, etc. confirmations.

I believe you're referring to a fork in the block chain.  I believe there's only been one major one, around March 11th.

I'm asking about minor ones

Also https://bitcoin.stackexchange.com/questions/3343/what-is-the-longest-blockchain-fork-that-has-been-orphaned-to-date/4638#4638

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Block loading stuck on 1 year 13 weeks
My parent's have Windows Vista and recently we had a power outage and Bitcoin started from beginning loading blocks however for a week now it doesn't go below 1 year 13 months? As an inexperienced Bitcoiner, I could use some advice. Please help if you can. Thank you.Please make it simple as I'm new and don't understand all the Bitcoin terminology.
David

Are you using the standard Bitcoin Core client?  What version?

I'm using v0.11.0 version. It's been stuck there since yesterday and tells me there are no connections.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
No Dig option in Dogecoin-QT?
I have seen, in numerous screenshots of Dogecoin-QT, a "dig" pane (equivalent to "mine" in some others):

However, my client has no such pane:

Does anyone know where that option has gone? Was it removed in an upgrade?

Dogecoin is on-topic, otherwise we wouldn't have a tag, would we? ;)

Yes, it was removed in an update. The developers have decided to hide it as a way to discourage users from wasting CPU time. CPU mining this big of a coin will get you no where.
It's suggested to mine using an external mining program like CGMiner or practically any miner recommended for Scrypt. Check out Litecoin wiki's Mining Software list and look into Scrypt mining guides such as the Dogecoin wiki's 'Beginners guide'.

Thanks, I am already mining using minerd (cpuminer). I just wondered where the option had gone, that's all.


text:
How to set up a private bitcoin network with mining on a single machine?
I created a testnet for mining using several ports in a single machine. However I see that the source codes [CAddrInfo, CAddr] are based on IP and not IP||port. Is there an easy change to make it do mining across ports [under same IP] or this is simply not possible?

It sounds like what you actually want is regest.

@Something similar, but the problem is regtest does not support peer discovery right exactly as the testnet right ? For eg: If I start nodes A, B, C, D and E on different ports and make A connect to C, D, and E via -addnode and B to A, then will the peer discovery mechanism work to form connections between B and C,D,E and similarly for other nodes ?

I've had to do this, so I'll try to describe exactly what you need to do to get mining on testnet to work in a local setup. For our purposes, we'll have 2 instances of bitcoind running, the first set up to be a miner, the second as a peer.
First, create two directories, one for the miner, the other for the peer:
$ mkdir 1
$ mkdir 2

Now create this file in the 1 directory:
$ <your favorite editor> 1/bitcoin.conf

Here are the contents of the file:
testnet=1
irc=0
dnsseed=0
upnp=0
listen=1
checkpoints=0
server=1
rpcuser=test
rpcpassword=test
rpcallowip=127.0.0.1
port=20000
rpcport=20001

Now go and make the same file for the 2 directory
$ <your favorite editor> 2/bitcoin.conf

Contents:
testnet=1
irc=0
dnsseed=0
upnp=0
listen=0
checkpoints=0
connect=127.0.0.1:20000
rpcuser=test
rpcpassword=test
port=20010
rpcport=20011

Run the first instance:
$ bitcoind -datadir=1 -daemon

Run the second instance:
$ bitcoind -datadir=2 -daemon

You can check to see if everything is up and running by using bitcoin-cli:
$ bitcoin-cli -datadir=1 getinfo

Blocks should be 0 until you mine something.
If you have mining hardware, you can now mine by connecting to 127.0.0.1:20001 with the user/pass of test/test. The actual command to connect will differ based on the mining software you use, but for bfgminer, it would be something like:
$ bfgminer -o http://127.0.0.1:20001 -O test:test --generate-to <a testnet address> --no-longpoll -S all

Note that CPU mining takes several hours to find a block from my experience.


text:
Reset bitcoin blockchain checkpoint to mine 0th block
I want to start a new block chain and mine the 0th block, but I guess the hardcoded checkpoint in chainparams.cpp won't allow that.
I guess I need to reset the checkpoint hardcoded as follows before starting a new blockchain.
    checkpointData = (CCheckpointData){
        boost::assign::map_list_of
        ( 0, uint256S("000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943")),
        0,
        0,
        0
    };


text:
How to spend bitcoins From Account and specify Fee
I am writing an application that uses bitcoin wallet accounts to specify what addresses belong to what user. I have been reading the documentation trying to find a way to spend Bitcoins specifying the account from, address to, and miners fee.
After reading the documentation, I think that is impossible, because there are only two ways:

The first one is using sendFrom, but you can't set the fee with this command. You could use settxfee but that is a changing number depending on the Kb's of the tx.
The second one is using CreateRawTransaction and SendRawTransaction, but in order to specify the inputs, there is no way to get the inputs, other than calling listunspent, but that returns the inputs for all wallets, and there is no way to tell that command to only return the unspent inputs for a specific account.

Is there really no way to send bitcoins from account specifying the fee?

Are you querying the Bitcoin core software?

@WizardOfOzzie sorry but I dont understand your question. Please post it again thanks!!

Please don't use bitcoin cores accounting system anymore (especially for new projects). It has been deprecated (and might be removed in near future).
A way of solving your issue would be by calling getaddressesbyaccount (get addresses of a specific account) and then use listunspent with these addresses.
Then you could create your own coin selection and use createrawtransaction singrawtransaction and sendrawtransaction.


text:
Why does Bitcoin use the input/output system?
Why don't we just use balances? The nodes would verify that balance > 0 before validating the transaction.

I guess SPV is one reason to do so. I'm not 100% sure but I read that some projects use UTXO to be able to have light-clients on low-performance hardware. WHen this is true Ethereum might have a hard time to gain adoption on mobile devices.

Outputs neatly solve a few problems you would encounter with a balance based system.

Transactions using outputs can not be replayed cross network, multiple times, or in different situations than when they were created. In an address based system you must keep a nonce or a record of all past transactions to ensure multiple executions of one transaction does not occur. You don't have the option of re-signing a transaction with a higher miners fee, because the transactions are not atomic and can both exist in the chain at once.

Transactions using outputs can be deployed even years after they have been signed, which is incompatible with an incremented nonce.
An output based system can forget about an output once it is spent, a nonce based system must keep track of all nonces forever.

Verifying that an output exists in a block is trivial by displaying the merkle path to it, and showing the block header is part of the main chain. In an address based system this is substantially harder to prove, if not impossible given the same constraints.

Another one: a balance-based system would give an efficiency benefit to account reuse. In general, you don't want a system that encourages bad privacy.

Right, but all of those problems are easily solved in a balance-based system and using outputs creates a bunch of problems (also easily solved) that balance-based systems don't have. So while this is all true, it's not a reason to prefer an output-based system over a balance-based system.


text:
Can a Trezor seed be used in any other HD wallet?
Trezor FAQ says

If you do not use a passphrase, your recovery seed is all that is needed to access your bitcoins.

If you do not use a passphrase, can the Trezor seed be used to recreate a hierarchical deterministic wallet?

Yes, Trezor uses the BIP0032 standard to derive your keys from the seed. That means you can use any BIP0032-compatible client for recovery, or you can even use them simultaneously (but be aware of the security implications - you don't want it to leak, otherwise it beats the whole Trezor purpose).
For example, Electrum works great with HD wallets, but I'm sure you can find other clients as well.

Sure. Yesterday MultiBitHD committed support for Trezor. I think MulitBitHD is still in Beta, but you could probably still try it out.


text:
What is it about a Trezor that means it can't be infected by malware?
The Trezor testimonials include that

TREZOR ... cannot be infected by malware

What is it about a Trezor that means it cannot be infected?

You simply can't add, insert or install software or any executable stuff into a Trezor. Due to the way the Trezor is set up, it runs fully autonomically.
The only thing that goes into the Trezor is transaction details (addresses, amounts, etc). There's just no opportunity whatsoever to put any malware in there, because whatever you send to the Trezor, it's being interpreted as mere transaction details (i.e. data, not code) which may be valid or not (and if not, it'll say "your details are bogus, I can't create a proper transaction from this"). But it's never being executed.
So by definition it doesn't matter whatever kind of smart sneaky malware you send to the Trezor. It will have no effect.

Thanks again.  Have asked related question  http://bitcoin.stackexchange.com/questions/32544/how-can-trezor-update-firmware-but-never-receive-malware

Trezor is a relatively simple, specialized hardware device. It does not run any OS, just a small program specifically developed for signing Bitcoin transactions and managing the keys. Thus, the attack surface is very small compared to conventional general-purpose computers. You can say it's practically impossible to infect it.
Security is a much more complicated area though and I wouldn't say it's impossible unless I can formally prove it. It is however the safest device I know of (but this is subjective).


text:
How does a Trezor passphrase prevent restoration of a wallet if an attacker knows the seed?
Trezor User Manual says

if you forget the passphrase there will be no way to recover your bitcoins. Not even the Recovery seed.

How is it that you (or an attacker who knows the seed) can't just restore a soft wallet with some other application and recover the bitcoins with the other application?

The sentence you cited is from the Using passphrase encrypted seeds section. As the title suggests, the actual seed is not stored in your Trezor if you're using passphrase protection. Instead, a passphrase-encrypted version of the seed is stored in the device (and also exported as a Recovery seed, if needed).
Obviously, if an attacker were to obtain the unencrypted (plain) seed, he would be able to restore your wallet and steal the coins easily. It is however not feasible to extract the plain seed from the encrypted one, if a sufficiently complex passphrase is used.

The seed is protected with a password or PIN; it precludes the possibility of stolen devices being decrypted whilst online malware/rootkits are precluded by the hardware device being separate from the compromised OS's memory pool.
From Trezor:

TREZOR’s PIN based security system is a powerful tool to keep your
  bitcoin’s safe. If your TREZOR is stolen, the only thing between the
  thief and your bitcoins is your PIN and/or passphrase. It is
  imperative that you choose a good PIN!


text:
after hard fork won't every new transaction go on both chains?
I don't understand why I'm reading that after a hard fork, the existing transactions would be on both chains but the new transactions will only be on one or the other (resulting in 2 different chains, thus an altcoin).  Won't even new transactions eventually end up on both chains?
Transactions don't care about block size, so both versions should accept them.  Even if one chain has already included it, software for the 2nd chain won't care about the first chain, so the 2nd should still have those transactions in its pool, resulting in it being put into the 2nd chain as well.
I don't see how this will result in 2 separate chains... it seems like both chains will always have approximately the same exact transactions, just possibly in a different order and grouped into different blocks.
The only exception to this I can think of is if a double-spend is attempted.  Then it's possible that one of the chains will accept one of the double-spend transactions and the other chain will accept the other.
But otherwise, I don't see how there would be a difference.

This actually happened on Ethereum when they had a hard fork.  If a transaction is valid on both chains (spends outputs from before the fork), and gets propagated to both chains, then yes, there is no reason it won't be added to blocks on both chains.
However, there are still two chains.  When the same transaction gets added to both chains, they are included in two separate blocks; one block from chain A and one block from chain B.  The outputs of such transactions can only be spent on their corresponding chain, even though the transaction that created them was identical.
Lets say that we have a chain that hard forks at block height 100.  We now have chain A and chain B.  A transaction is created using UTXOs from the block at height 90, and propagates on both networks.  Chain A includes it in its block at height 108, and chain B includes it in its block at height 110 (although it could just as well be 108 on its chain too).  Now a new transaction is created spending a UTXO from the first transaction on chain A.  That second transaction can only ever propagate on chain B if it exclusively spends from UTXOs on both chains.  This becomes increasingly less likely over time.
Since most new transactions on a chain are only valid for that chain, it won't take long before the two chains have barely any transactions in common.
It's also important to note that bitcoin clients will drop connections to clients that propagate blocks from the other chain.  This will help to segregate the network, and prevent transactions from propagating on both chains, even when they are valid on both.  There could be malicious entities that "bridge" the two networks, looking for transactions that are valid on both, but there isn't any real incentive for that sort of misbehavior.

This is mostly right, however I believe you're mistaken in the third paragraph. A TXID is deterministically created from the transaction data. It is independent of the block in which it was included. Therefore, the outputs created by the same transaction on the two chains are identical even if the transaction is confirmed in a different block, and any followup transaction is valid on both chains. This is why you either have to doublespend or include funds that are only valid on one chain (e.g. mining reward or previously separated funds) to separate your funds respective to the two chains.

@Murch, yep, you are correct.  I was thinking that TxIn's specify the block ID as well as the TXID.

@Murch, updated the answer.

@Murch Two follow-up questions: (1) How can I separate my funds on the 2 chains via double-spending? (2) How do separate my funds using "mining reward" transactions? I do not own any.

Let's diagram an example hard fork block chain:
A <-- B <-- C  <-- D   (current consensus rules chain, "original chain")
      ^---- C' <-- D'  (new consensus rules chain, "new chain")

If you received a transaction output in block A or B, you could spend it on both the original chain and the new chain[*].  How that would work out depends a lot of whether the new chain includes replay protection.
Replay protection
The new chain may optionally require replay protection, which would most likely be a change in the data used to create the transaction signature.  For example, normally a transaction signature signs a hash of the identifier of the inputs being spent as well as all of the outputs; for a hard fork, this could be changed to require the signature hash additionally include the value "Hard Fork #123".  This would have the following results:

The old chain wouldn't accept any transactions made for the new chain because it wouldn't attempt to calculate the signature hash with the extra "Hard Fork #123" data, so all signatures made for the new chain would look invalid to it.
The new chain wouldn't accept any transactions made for the old chain because they'd be missing the required "Hard Fork #123" data.

For most (probably all) wallets, adding "Hard Fork #123" to the data used to create the signature hash would be technically easy---but it does require the wallet author support the fork and that all users upgrade before the fork.  More difficult (depending on the wallet) would be supporting both signature formats and perhaps allowing the user to choose between them.  Still, I'd imagine it's not too hard.
However, most proposed hard forks for Bitcoin don't include this or any other direct replay protection.  This is probably because their proposers think there will be a lower chance of adoption if developers and users have to take any action to use the hard fork.
Interestingly, the original 0.1 version of the Bitcoin protocol included three opcodes (OP_VER, OP_VERIF, and OP_VERNOTIF) that could be used for replay protection during a hard fork by allowing you to specify what rules had to be followed to spend your transaction on different VERsions of the protocol.
Unfortunately, the design didn't work and Satoshi Nakamoto removed the opcodes from the protocol.  In addition to providing replay protection after a hard fork, they could be used to cause a type of hard fork called a consensus failure.  (And, if you're following along with current drama, it has not escaped the amusement of some people that Bitcoin's earliest protocol allowed a hard fork be triggered by a VER.)
Incompatible transactions
So if replay protection is available, you could spend an output from either block A or block B on either chain, but you'd have to sign the transaction differently for each chain---ensuring that you could send funds on the original chain to Alice and the funds on the new chain to Bob.
Without replay protection, you have to send the funds on both chains at the same time because whatever transaction you create will be valid on both chains[*].  However, there are ways to create transactions that will only be valid on one chain even if replay protection isn't available---they're just harder:

Using coinbase coins: blocks C (original chain) and C' (new chain) have different coinbase transactions.  (A coinbase transaction is the special transaction in a block that pays the miner for creating that block.)  These transactions are only valid on their particular chain, and any transactions that descend from them are also only valid on their particular chain.
So if you're a miner or you know a miner, you just have to mix at least 1 satoshi from them with your spend from block A and your transaction will have ad hoc replay protection.
However, there's two problems with this: (1) you need to know a miner who's willing to help you out and (2) coinbase transactions aren't spendable for 100 blocks[*], so you'd have to wait for a while after the hard fork before you could start spending.
Conflicting transactions: if you create two different transactions and send them to the two different block chains, it's possible (but not guaranteed) that one transaction will be confirmed in block C and one transaction in block C'.
As long as blocks C and C' remain part of their respective block chains then any transactions that spend your transaction can only be part of their respective block chains.
Since there's no guarantee that you can split coins this way, it's usually a good idea to send both separate transactions to yourself so that there's no way you can lose money beyond the transaction fees.  Also, there's a way to increase your chances of the coins being split:

On the chain with the highest block height, spend your coins to yourself using nLockTime to target the current block height.
When the transaction above confirms, spend your coins to yourself on the other chain with no nLockTime.

Assuming the different chains have even a modest difference in height, this works because your nLockTime transaction is only initially valid on the higher-height chain, so it can't immediately be added to the lower-height chain.  (Credit: I first heard of a method like this from Peter Todd; I don't know if he originated it, nor if this is exactly the method he was thinking about---I had to guess at how it would work from him just saying "use nLockTime".)

A warning
Hard forks, especially those without replay protection, break many normal assumptions of Bitcoin wallets.  As such, there's a significant risk that you will lose money if you spend or accept bitcoins during an ongoing hard fork.  Please be careful.

[*] Hard forks can change any part of the system, so the generalizations made in this post may not apply to all cases.  However, I've tried to make them applicable to most proposed hard forks that only change a few things, such as the perpetually-debated maximum block size/weight.

If you don't know how to create a nLockTime transaction, you could just spend the money to yourself on the chain with the lower fees, and then doublespend it with a higher fee on the other chain.

Yep, that would probably work too.  Although the nLockTime trick is pretty easy if you use Bitcoin Core since its anti-fee sniping protection causes it to nLockTime's all of its transactions to the current block height by default.  :-)  (Seriously, all wallets should be doing that.)

Yeah, but if you are using another wallet, it may not be as simple. ;)

authors: Светлана Тихонова


text:
Anti-Transaction malleability patterns
What are the main principles and/or patterns programmers must apply to their code in order to make their programs bulletproof towards transaction malleability attacks?

Use two tables for deposits basically.
insert deposits into one table with a unique hash. store sighash and txid with a unique hash and timestamp in the other. when the txid changes, you update the second table, preventing the duplicate deposit.

@DougPeters no problem. its all about spreading awareness in the community. the stronger the developers, the stronger the economy. i've nver had a problem with it because i don't rely on wallet notify to store transactions, instead i dump an array of the last 100 transactions every 30 seconds iterate through it checking against the db(type receive), only crediting once the confirm > 6. this has performance drawbacks of course, and requires an extra script to periodically check already paid deposits(for changes in txhash and # of confirmations.

i will opensource this solution soon, which is written in php/mysql, and it should be easily ported to other languages/configurations.

Will you handle deposits per address or per transaction? When a transaction pays to multiple addresses in your wallet for example.


text:
Does Bitcoin's SHA256 proof make a 51% attack more likely?
Ethereum's description says that Bitcoin's mining algorithm requires only a simple SHA256 computation, which caused the creation of specialised ASICs, which centralizes mining in the hands of a few actors (ie. ASIC manufacturers), making 51% attacks much more likely.
Is that right?
SHA256 >>> ASIC >>> Centralized mining >>> 51% attack?

The algorithm used proof of work itself doesn't make an attack more likely. The reason why we are seeing SHA-256 ASICs but not scrypt is that Bitcoin has always used SHA-256 until now, and Scrypt and other algo-based coins have not had the value proposition of creating an ASIC make sense yet. This will come with time, but if anything would mean the opposite of a 51% attack.
The more developed mining becomes, the more expensive it is to make an attack happen. At this point an attack would cost millions and have a low chance of success. At the same time, if an attacker is successful, many people will sell their coins (and stop buying), pushing down the price. Depending on the attacker's motive, this may be an issue, but once the attack stops the network can continue to mine as it did before the disruption.
If anything, an attack gets more expensive the more specialized a technology gets, and I would be surprised to find any person/company investing in ASIC technology to want anything bad to happen to the network. After all, they just spent thousands of dollars on something which can ONLY mine SHA-256 currencies such as Bitcoin.

What do you mean by "Bitcoin has always used SHA-256 until now"? Bitcoin still uses SHA-256.

Yes, it still uses SHA-256 but this could change should there be an issue with the security of it.

That's true, but the "until now" will confuse people or even suggest that SHA-256 isn't being used.

I think what most people making the 51% attack argument for memory hardness miss is that the base unit is meaningless when you're talking about percentages. Whether your mining algorithm is implemented with ASICs, consumer hardware or well-trained Rhesus monkeys it matters little - to launch a 51% attack you must amass enough ASICs, consumer hardware or Rhesus monkeys to represent 51% or more of the available power. This, in turn, becomes an economics problem and is far more affected by the scale of mining operations as a whole than by the specifics of how that mining is done. If three networks are mining using $1,000,000 worth of ASICs, CPUs and Rhesus monkeys, including those you control, your portion needs to exceed $500,000 worth of the underlying resource regardless of its nature.
The fear that this will occur automatically as one manufacturer comes to dominate the space is perhaps slightly more realistic, but it's a real fear in memory-hard altcoins as well since most of that consumer hardware is also made by a mere two companies: Intel and AMD. These companies may not care much about the coin you're mining today, but in the sort of world where ASIC manufacturers represent a threat to Bitcoin CPU manufacturers would represent an identical threat.
The article also dismisses the "botnet mining" argument by saying that the botnets would likely not be used to attack the coins and completely ignores the crux of the argument: That people are mining on botnets. If someone is stealing CPU cycles from my system I'm not particularly concerned with the ends, I'm more upset about the means. That Bitcoin's ASIC acceleration has made botnet mining all but impossible is, in this sysadmin's view, a positive thing.
Finally, the entire democratization argument hinges on the entirely false premise that if mining only uses general purpose hardware that people will only mine with the hardware they already have. It also neglects to account for the decreased lifespan of that already-existing hardware due to mining's extraordinarily heavy use of the resource. People can and do build additional computers for the sole purpose of mining and every computer used for mining lives a shorter lifespan than one used for casual browsing and office tasks. Mining power will still centralize because this is the nature of our economy, not of our technology - those with more money will always buy more hardware. Also, Bitcoin ASICs are only expensive because they are new. ASIC cost is almost entirely in the R&D process, which leads to a price curve whereby products become dramatically cheaper with time. The image processing chip that runs the camera in every cell phone was once new, expensive and high-tech too. Give it time.
But in the end, it is the economics, not the technology, that makes a mining algorithm secure. The nature of the hashing algorithm chosen has some interesting effects, certainly, but assuming neither algorithm has an exploitable flaw (which is less likely with widely-implemented algorithms like SHA256) the question inherently boils down to "how much would it cost me to become 51% of this network" and the resulting answer is the same whether you're mining with ASICs, CPUs or GPUs... Or Rhesus monkeys: To represent more than half of the network you must more than match the existing power of all equipment (or primates) used to mine it. If the mining equipment currently on-network is worth a million dollars, you have to spend at least a million and one.

Except one, most ASIC manufacturers are not using the machines they create to mine themselves - they sell them (either for fiat or for BTC) and thus get a rapid return on their investments plus a predefined profit at a low risk. Their clients absorb all the variance and uncertainties of the mining process and theoretically can reap all the rewards as well, which can be either much higher than the manufacturers' or a net loss.
SHA-256 vs. scrypt (and its derivative algorithms) certainly eases the creation of ASICs by about an order of magnitude, so had Bitcoin used scrypt from the very beginning probably (this is speculation on my part) ASICs would've taken some months longer to come to the market in spite of BTC's price increases.
As BTC mining becomes increasingly competitive it'll indeed tend to become much more concentrated, increasing the possibility of mining cartels appearing - I worry about cartels more than 51% attacks.
I'd worry even more should most of the mining move to Iceland for its abundant, cheap geothermal power and frigid air - imagine what could happen should 70% of mining be done over there and the island suddenly loses Internet connection or suffers a massive earthquake/volcanic explosion :(


text:
How can Trezor update firmware but never receive malware?
I understood from What is it about a Trezor that means it can't be infected by malware? that a Trezor would only interpret data as transaction details, but the Trezor also updates firmware.  How is it that an attacker can't hack the firmware update to somehow install malware?

You actually can't update all the firmware. In particular, the portion of the firmware that implements the security logic cannot be modified, it's burned in for good.
If you want to take full control over a Trezor, which would even let you load malware onto it, you can. However, the internal security logic would still wipe all the data in the unit when you did and display a warning each time the unit was started. So you can't use the firmware update path to steal secrets, nor can you trick someone into using a modified Trezor, so long as they watch the startup.
Assuming all this is implemented correctly and has no bugs or defects, that leaves only the possibility of malicious firmware signed by the manufacturer so that it would be accepted by the security firmware without tripping the safeguards. So to some extent, you have to trust the manufacturer. However, if they ever signed "evil firmware", and that firmware got out, their reputation would be ruined.

I emailed them about this:

As for the possibility to get the seed out of the TREZOR:

Official firmware doesn't have any support for exporting the seed
Official firmware is opensource at github and signed by SatoshiLabs so anybody can check that the firmware can't leak the keys. The
signature is checked by the device's bootloader which can't be
changed, because the bootloader fuse is blown on the board after the
board is fleshed with the bootloader.
When anybody wants to flash the device with unofficial bootloader the warning is displayed and user confirmation is needed. During
update with unofficial bootloader (which can have the functionally of
reading the internal device memory) the storage of the device is wiped
first.

They also linked to this article from their FAQ.

Reflashing the TREZOR with evil firmware
Official TREZOR firmware is signed by the SatoshiLabs master key. Installing unofficial firmware on the TREZOR is possible, but doing so will wipe the device storage and TREZOR will show a warning every time it starts. Reprogramming the bootloader is impossible, because all TREZORs ship with their secure programming fuse blown.
What happens if the SatoshiLabs servers are hacked and the firmware signing key is stolen?
First off, this won’t happen ;). The SatoshiLabs master key is kept very safe. However, you don’t need to rely on the SatoshiLabs signature. You can verify the build yourself. Our hope is that a few trusted TREZOR users will make a habit of verifying firmware checksums. If you are concerned about this, we suggest making a habit of checking our blog or social news channels such as reddit before applying any updates. If there ever was a problem with the firmware not matching the source code, you can be sure someone will have written about it.
You don’t need to worry about the firmware being updated by a computer virus. Your TREZOR will ask you to manually confirm the update before anything is written to the TREZOR’s memory.

This link is broken - https://github.com/trezor/trezor-mcu/blob/master/README.rst. Can you please update it with a working link? Thanks @Nick ODell

Given that v1.6.1 claims to update the bootloader (without wiping the device), it seems that the above info is incorrect. Do they take advantage of the vulnerability to apply their fix?


text:
Awarding yourself more than 25 bitcoins
If the reward is actually a made up transaction with no inputs,  what's blocking miners from awarding themselves more than 25 bitcoins?

Every client on the Bitcoin network validates incoming blocks, to check that they conform to all the requirements of the Bitcoin protocol.  One of the checks is that the block reward (coinbase transaction) is for an appropriate amount.  Blocks that fail this are rejected by the client, and conforming miners will not link their own blocks to  them, so such a block will not be incorporated into the block chain.
If you tried to make such a block, and then spend the coins you awarded yourself, those transactions would also be rejected as invalid.  Other participants on the Bitcoin network would not consider those transactions as valid payment, and would not give you goods or services in exchange for them.
It would be roughly as if you were to walk into a coffee shop and try to pay for coffee using a one-dollar bill, on which you had crossed out "One Dollar" with a crayon, and written "Five".  They wouldn't accept it, and they wouldn't give you any coffee for it.

authors: Александр Белич


text:
Is a mining program necessary for mining, or can bitcoind mine by itself?
I'm having a hard time understanding the relationship between daemons (such as bitcoind or litecoind) and mining.  Some things I read make it seem that you need a separate mining app and some things seem to suggest that the daemon itself does mining.  Which is it?  I'm thinking maybe the daemon can do mining but it needs to be enabled and if you don't enable it you can use a separate app instead?  I'm confused.

The daemon can do mining using the -gen command line option, but it's CPU mining and is impractical nowadays.
Using a separate mining app is practical. That separate mining app connects to a running bitcoind via its JSON-RPC API in order to facilitate getwork or getblocktemplate requests necessary for hashing.
The JSON-RPC API is configured in bitcoin.conf or at the command line using these arguments:
-rpcuser=<user>        Username for JSON-RPC connections
-rpcpassword=<pw>      Password for JSON-RPC connections
-rpcport=<port>        Listen for JSON-RPC connections on <port> (default: 8332 or testnet: 18332)
-rpcallowip=<ip>       Allow JSON-RPC connections from specified IP address

Is -gen impractical for litecoin mining?

Not yet, as far as I know. AFAIK, CPU mining is still profitable on Litecoin, but of course decreasingly so.

Note that the mining functionality was removed in Bitcoin Core 0.13.0: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.0.md#removal-of-internal-miner


text:
How can we look at the hidden message in the first block?
This is the first block, how can I see the message?

'The Times 03/Jan/2009 Chancellor on brink of second bailout for banks'

related: How can one embed custom data in block headers?

Click on the sole transaction in that block (4a5e1e4b...) and click Show scripts & coinbase.

how did he do that? I thought OP_RETURN was only added later and that before the only way to do it was to encode data as a fake address in a transaction

@s.matthew.english: See http://bitcoin.stackexchange.com/questions/20721/what-is-the-format-of-the-coinbase-transaction.  Because this is a generation transaction, it has a single input whose script is ignored.  The message takes the place of that script.

How can I get it through bitcoin-cli, I've tried bitcoin-cli getrawtransaction 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b true, and return an error telling me that this is the genesis block and transaction whin it can't be retrieved.

@buzhidao: Yeah, I suspect that you just can't.  This is a special case for backward compatibility: the original release of Bitcoin had a bug where the coinbase transaction of the genesis block was not added to the utxo database, thus making it unspendable.  Every version since had to keep that behavior; otherwise, if Satoshi ever tried to spend those coins, it would cause a hard fork of the blockchain, as some clients would accept the transaction and others would reject it.


text:
clustering addresses, what's the most effective way?
The Fistful of Bitcoins paper by Meiklejohn et al has some nice heuristics. i.e.
HEURISTIC 1. If two (or more) addresses are inputs to the same transaction, they are controlled by the same user; i.e., for any transaction t, all pk ∈ inputs(t) are controlled by the same user.
HEURISTIC 2. The one-time change address is controlled by
the same user as the input addresses; i.e., for any transaction t, the
controller of inputs(t) also controls the one-time change address
pk ∈ outputs(t) (if such an address exists).
Are there any others that are particularly effective?
Is it possible to bootstrap my clustering, for instance, maybe if some people have already associated a certain cluster with Kraken or Satoshi Dice, is this information available?

Are there any others that are particularly effective?

Yes, if you know what wallet was used and if its transactions have distinguishing features. For example, multisig wallets usually use p2sh change, but the recipient rarely uses p2sh, which allows to determine the correct change output with high probability.
Data-Driven De-Anonymization in Bitcoin introduces two new general heuristics:
CONSUMER HEURISTIC. Consumer wallets only create transactions with two outputs. Therefore, if an output is spent by a transaction with 3 outputs it is not change.
OPTIMAL CHANGE HEURISTIC. The assumption is that wallet software does not spend outputs unnecessarily. Therefore the change value is smaller than any of the spent outputs.
Because if the change was larger than one output then this output would be left out and the change would be reduced by the output’s value.
The thesis also evaluates the effectiveness of the heuristics using data captured from Android Bitcoin Wallet with the Bloom filter address leak in late 2014.
It turns out that Multi-Input heuristic is by far the most effective: if applied to one address, in total 68.59% used addresses of the wallet are revealed.
By the way, the Heuristic 2 you mention was first described by Androulaki et al. in Evaluating User Privacy In Bitcoin.

Is it possible to bootstrap my clustering, for instance, maybe if some people have already associated a certain cluster with Kraken or Satoshi Dice, is this information available?

Blockchain.info has a database of tags (https://blockchain.info/tags).

nice answer, also mixers try to match inputs having similar value , which rarely happens in case of ordinary transactions


text:
Are transaction ids always the same length?
Do all bitcoin transaction ids (hashes) have the same length?
I guess it's defined somewhere here: https://en.bitcoin.it/wiki/Protocol_specification but still I couldn't find it.

Yes. The transaction ID is SHA256(SHA256(transaction)) as described here and thus always has a length of 256 bits (32 bytes).


text:
How hard is it to alter a block after it was found?
Once a miner has found a block, how easy it is for him to add or remove a tx included in that very block? Would he have to solve the modified block from the scratch or is there a point he can resume the solving process?

Once a miner has found a block, how easy it is for him to add or remove a tx included in that very block?

It is impossible. The solved block depends on every byte of transaction data, nothing can be changed. It is important that it be this way. What if I could broadcast a solved block but leave out the transaction where I sent coins to someone else, essentially reverting my spend? That would make for an insecure system.

Would he have to solve the modified block from the scratch or is there a point he can resume the solving process?

It is basically like starting over. This is mainly because of the merkle root in the block header. Think of it like a function that depends on every single byte of the transactions, and if any of the transactions change then the function output changes completely.
See this for more info on merkle trees in bitcoin: What is the Merkle root?

EDIT: I wanted to add this mining analogy that I find useful.
Each hash that the miner computes has a chance to solve a block. Mining is basically like taking a video of yourself flipping 256 coins, trying to get a long string of heads. How long the string of heads needs to be is determined by how many other coin flippers you are competing with. If you get a long enough string of heads, you show the proof (video) and get the reward. Otherwise, you just try again. You essentially start over each time you do a new hash (so billions of times), and changing your block data doesn't make you any more or less unlikely to flip the coins successfully.
Notice how it takes a lot of work to flip the heads successfully (it would take you many tries, where each try is really easy), but very little work to verify that a video of coin flips is legitimate.

"It is basically like starting over." Actually, it is indistinguishable from starting over. ;)

From the original Bitcoin paper:

... we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.

SHA256 is a Cryptographic hash function.
Among other traits, it is

infeasible to change the input of a CHF without changing the hash output
there is no discernible pattern between the hashes of two differing messages

As the block hash is the product of applying SHA256 to the block data, and the transaction data is represented in the input through the Merkle Root, it is impossible to change even one bit of a block or transaction without starting over from scratch, and there is no headstart by working from a closely related input.


text:
Conflicted transactions in blockchain reorganizations
When my service detects a conflicted transaction (either sent or received) it rollbacks everything that was logically built upon this transaction. The "problem" is that transactions can go from category conflicted to sent/received if a blockchain reorganization happens, so my question is how long (how many blocks) should my service wait in order to be positive that a conflicted transaction will never  get included into a block?
I have found this question to be helpful: What is the longest blockchain fork that has been orphaned to date?

What probability do you want? In fact there is only one transaction in the blockchain which can not be overwriten by reorganization. It is coinbase transaction in block #0

@amaclin according to http://bitcoin.stackexchange.com/a/4638/14319 there has never been a fork longer than 4 blocks except for the March 12 2013 blockchain fork which was 31 blocks long but according to my understanding it is unlikely to happen again, is that correct? All I'm looking for is a "safe" number of blocks after which a chain reorg is unlikely to happen.

I know you're looking for some magic constant, but it doesn't exist.  Your code needs to deal with reorgs of any depth back to the genesis block.
This may seem like a annoyance of dealing with the block chain, but it's how payments have always worked.  Even if some guy pays you with a suitcase full of verified gold bars, a court order can compel you to return those bars at any later point.  (For example, it's fairly common for the court to order stolen property returned to its previous owner without any compensation to its current owner even if the current owner didn't know it was stolen when he bought it.  This notably happens occasionally with art stolen 70 years ago during WWII.)
If you really want to take a shortcut and leave dealing with long reorgs up to some future programmer or database admin, then any arbitrary constant will do.  This is why many high-value sites require six confirmations---not because six is the correct value, but because approximately one hour of confirmations is a nice arbitrary value.

Thanks David. Do you believe that a grand fork like this one: https://bitcoin.org/en/alert/2013-03-11-chain-fork is likely to ever happen again?

I'd be surprised if it doesn't happen again as we move into an era where miners use alternative full node implementations, block subsidies drop, and new variables like side chains are introduced.  The remarkable thing to me is that we manage to maintain consensus as well as we do---that's really a credit to the hard work of the Bitcoin Core developers.

Definitely we will see long forks. Especially if the difficulty will fall. Lower values of difficulty/hashrate give lower cost for double-spending attacks.


text:
Globally distributed accomplices for improved outcome in race attack
Would it help you to win a race attack if you had accomplices from all over the world, say Berlin, Beijing, Boston, and Buenos Aires all propagate your transaction to the nodes that they're connected to, when trying to execute a double spend?

You're obviously missing Brisbane! ;)


text:
how do I figure out the hash rate of my computer?
My computer has
   AMD A4-5300 APU W/ Radeon(tm)HD  subscore 6.2
   Graphics AMD Radeon HD 7480D              4.7

If any one can help , thank you!

To know for sure: test it!  But which coin were you thinking of mining: Bitcoin. or something else?  Bitcoin mining will not be economical with any general-purpose computer.  Also, can you clean up the formatting of your question?

Also, unless you have some very obscure altcoin in mind, you will be mining with your GPU if at all, so all the other information is irrelevant and you might as well remove it.

Bitminter has a Java test that, among other things, can give you an idea of your hash rate.


text:
Can a shorter chain overcome a longer one?
Could a dominating chain fork actually be shorter (in blocks) than its abandoned predecessor? Under what circumstances could this happen?

Background info:

Strongest vs Longest chain and orphaned blocks
How does a client decide which is the longest block chain if there is a fork?
Where exactly is the "off-by-one" difficulty bug? (timewarp info)

A shorter chain could possibly be considered the correct one, but it would be very hard to make this happen in bitcoin. I can think of two ways this could happen.

1) Go back to the genesis block and use the time warp attack.

See this for information on how the timewarp attack works.
This would let the attacker create a very long chain very quickly, because the difficulty could be artificially kept low even though blocks were solved very quickly. However, this chain would not have nearly as much work as the main chain, and so even if it were longer, it would not be accepted by the network as the correct chain. It would also fail most wallets' checkpoints.

2) Two blocks are solved at the last height in a difficulty period and a network fork ensues.

If there happened to be a fork in the last block of a difficulty period, then the new difficulty for the next period would be different depending on which side of the fork you were on. In this case, blocks solved on top of one side of the fork would have precedence over the other.
This isn't a case of a shorter chain being chosen over a longer chain (unless the fork gets really long), but rather two chains of the same length and one of them being chosen by the network as the correct one even if it gets seen second.

It could also happen in a successful longterm 51% attack.


text:
By whom and when can transaction malleability be applied?
Once I create a transaction and relay it to the network, who can alter the transaction id? Can the transaction id change at any time or only when the transaction is confirmed or unconfirmed?


text:
green addresses are "generally considered a bad idea and not advisable to implement."?
Why does the wiki say that green addresses are "generally considered a bad idea and not advisable to implement."?

Green addresses has receivers trusting the owners of the green address to not perform a double spend. However trusting anyone to not double spend in Bitcoin is inadvisable, regardless of whether they are actually trustworthy or are a corporation. Even if you do trust that the owner of a green address will not perform a double spend, double spends can occur by accident due to implementation failures (writing a wallet is hard).
There is also no guarantee that a transaction "from" a green address (note that there really is no such thing as a "from address" in Bitcoin, you don't actually send from addresses) is not guaranteed to confirm, even if no double spend occurs. The transaction may have too low of a fee to be confirmed in a reasonable time, and may even be low enough to be evicted from nodes' mempools if it remains unconfirmed for too long. There may be third parties performing transaction malleation attacks on those transactions resulting in malleated transactions being confirmed instead of the one that you expect.
In general, using green addresses means that you are trusting unconfirmed transactions which are not guaranteed to confirm. Double spends are not the only risks with accepting unconfirmed transactions, there are a variety of other things that could result in an unconfirmed transaction never confirming which the owner of the green address cannot control. As such, it is inadvisable to use green addresses.

If the transaction is using segwit then malleability is not possible
Replace by fee can prevent the transaction from being rejected from having a too low fee

The whole point of "accept unconfirmed transactions" is consider the outputs of the unconfirmed transactions safe to spend. If the fee is too low and RBF has to be used, any transactions that were chained off of the original unconfirmed one will be instantly invalidated.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Bitcoin (and other crypto-coins) nonce loop
I recently started to pay attention to what's going on at crypto-markets and, being developer for a long time, decided to take a look at the software we have out there in public access.
So I have a question to all crypto-guru here:
As it seems from Bitcoin protocol specification, bitcoin will accept ANY nonce that satisfies target (block) bits condition. Every single miner I've seen made public is using sequential loop over nonce1 and nonce2.
actual question: why do people implement +1 for the nonce in every thread, instead, let's say, having 2 thread one is going +1 from the beginning; second one is counting -1 from the end of nonces interval?
In my humble opinion, it would be faster if you're running several threads on the same interval...or, in the perfect world, split the entire interval in N subintervals leaving every thread do its own piece. From the mathematical point of view it seems like we gonna get higher probability of hitting 'golden nonce' using this approach, as opposed to +1 over the entire interval. Am I wrong here?
having all that said, I've downloaded the blockchain and ran couple of tests to see nonce distribution in uint32_t interval. results didn't surprise me...I've got pretty much uniform nonce distribution like:
odd nonce: 49.997
even nonce: 50.003
split uint32_t into 1024 identical intervals and see how many nonces from existing blockchain are sitting in every interval. results are the same: uniform distribution.
again, why is it +1 in the miner loop? even though, (+3), (-2) would have yielded (in theory) better chances (faster) finding golden nonce vs others doing (+1).

Why would that be faster than giving every thread its own block header to mine?

Which is quicker to guess a PIN?: randomly guessing or starting at 0000 all the way to 9999?

depends on your luck. but in theory, if you're using uniform random, you will most likely find a PIN faster. give it a try. simple software app will show it to you. Keeping in mind that you need to find new PINs over and over again, random gives you some advantages

@NickODell, try it yourself: run cpuminer with 64 threads. thread speed will go down, but amount of accepted nonces will go up over limited amount of time.

I think you're confused, thinking all miners are computing the same thing therefore doing +2 might give you headway. Every miner is running on a different random piece of work. The next point you need to know is that the PoW algorithm is progress free: every single number has the same chance, it doesn't matter if you start at the beginning or the end or middle. It doesn't matter whether you do +1 or +2 or +random. So everyone picks the simplest.

@Jannes, thanks for your input! that makes sense

PoW is not an answer. it is giving you intervals. the pool, the task givers, they don't care if you can do it faster. if you can, they'll adjust your bits/diff... which is, in my opinion again, a red flag to the 'fuzzy-logic' high-speed approach, if I may say that :)

sorry for the confusion, I meant 'green flag' for the fuzzy logic and red for the brutforce/rainbow kinda thing

The distribution of wining nonces is skewed toward 0 because this is a selection effect: most everyone starts searching for nonces starting at 0, so the lower nonces are found first, even though there may be also higher nonces that could produce a winning block:

This illustrates very well that the distribution of nonces is uniform:

source: https://en.bitcoin.it/wiki/Distribution_of_nonces_and_hashes
Thus, +1 in the miner loop is the simplest way of changing the nonce, and it works because the valid nonce distribution is uniform. ASICs often deal with nonces very differently. Also, ASICs can scan the entire nonce range very quickly, so it doesn't really matter where you start looking for a valid nonce.

Even in ASIC world, keeping in mind that they can scan the whole interval that fast, wouldn't it be faster to use random or another algorithm?

@AlexD You can't get simpler than nonce++. ☺ Anything more than that (e.g., a pseudo-"random [number generator] or another algorithm") would just slow things down. People have explored SAT solving as an alternative to brute force bitcoin mining, but brute force is still faster.

I didn't mention any random so far :) pseudo random is the way to nowhere in brutforce attacks :) but I'm pretty sure there's a better way of brut-forcing things in more efficient way! :)

@AlexD If anyone discovers a better way, Bitcoin will have to adopt a different proof-of-work method.

I used to think that for a given block a valid nonce would eventually be found by +1 until success - is it actually the case that sometimes no nonce is found and the miner then has to abandon the block and try a different collection of transactions?

@PrinceM Yes, that could occur.

Why is the number of possible nonces finite? Why cant you just keep incrementing until one is found? Is this a "rule" or part of protocol? Or is it just faster?

@PrinceM "Why is the number of possible nonces finite?" The nonce field in a Bitcoin block is a 32-bit (4-byte) number, so there are 2³² ≈ 4.3 billion possible numbers that it can represent. ASICs are so fast  that they can scan the entire nonce range (do ~4.3 billion hashes) almost instantly. That's why extraNonce is useful for finding a "winning" block.

@Geremia interesting, so there may be a nonce that makes that block work, it just doesn’t necessarily “fit” into the block. Got it!

If you use four threads and split the range over the four threads, that means each thread finishes its range and starts a new one four times as often. That's clearly a losing proposition over giving each thread its own full range.

I wish I could do '-1' on you. your answer doesn't make any sense in terms my question. Please read it again. every thread is doing the same like: +1 at the bottom; next step would be -1 at the top. would that increase the entropy?

@AlexD I don't understand what you're saying, I guess. Since every nonce has the same chance, all that matters is how many nonces per second you can try. What would the benefit to this complexity be?


text:
Server requirements & optimal configuration for Testnet
My friend and I are interested in running some experiments using a blockchain and accordingly we're interested in setting up our own Testnet.
We're a bit light on experience, i.e. we've never set up or configured a Testnet environment before, so we're looking for any advice or recommendations on the proper procedure or important implementation details that anyone might be able to offer.
From our university we have the ability to have allocated to our project a server, and we've been asked what are the requirements that our project would need- does anyone know what are the necessary specifications?

We're a bit light on experience, i.e. we've never set up or configured a Testnet environment before, so we're looking for any advice or recommendations on the proper procedure or important implementation details that anyone might be able to offer.

There's Testnet3 (the current public testnet) and Regtest (a private, locally generated, proof-of-work-less network. If you want to experiment with consensus changes you can't be using the public network because those changes will be rejected. Regtest is good for quickly testing things, and Testnet3 is more real world and has a small number of other network participants.

From our university we have the ability to have allocated to our project a server, and we've been asked what are the requirements that our project would need- does anyone know what are the necessary specifications?

Ideally you'll have as much capacity as you can, but you'll get away with any modern Intel CPU and a few gigabytes of memory. The more memory you have the more you can allocate to caching (dbcache defaults to 100MB, but can be set far higher for performance). Testnet is not a great reflection of how the real network operates, the requirements for the full network to run with good performance are higher.


text:
How can I withdraw my bitcoins from my blockchain wallet and convert them into cash?
I tried to withdraw from my blockchain wallet from blockchain, but I don't understand how to convert to cash and withdraw to the financial establishment available in my country.


text:
creating a fork of bitcoin, how to modify core to create my own network
I'd like to make a fork of Bitcoin, since it's the new trend ;)
The first thing I did was to create a docker image of ubuntu with all the dependencies, then I wanted to run the core software- but the first thing it did after I built it and booted it up was start trying to connect itself to the real-world bitcoin network- not what I want!
What I'd like to do is define my own network, that I can just run on some machines that are under my own personal control- pass around coins- all the typical stuff- check out the wallet- really basic
but I'm at a loss for how to do that.
I've been told that I need to modify chainparams.cpp, is it so? If yes, then what do I need to do to it?
Is that the only thing I need to change? if there are other things what are they?

I've also told you to start with regtest first, as that will do everything you're asking for without needing any code changes. Once you want to have some sort of public network with whatever changes you want, you can add a definition to chainparams.

Regtest should really suffice for your basic testing. If you really want to modify chainparams, you would first start with the DNS seed data in the file; these are hard coded.

I know that regtest is cool for testing, but I don't want to just test it I want to make something deployable. so this DNS seed is for peer discovery- what if at first it's just me on the network- and so- does that mean I need to manually add all new peers on the network? can't it just discover peers that are near?

It would still need to know one peer before it can start discovering more peers on the network. Hence the hard coded list.

what if the peers are docker containers on my own machine, that will also work right?

I have not used docker so can't confirm , but honestly i see no difference as long as they are listening to different ports. I'd still go with Pieter Wuille's suggestion with starting in regtest, adding nodes manually.

what does that mean- start in regtest and add nodes manually- this is just for practice? to understand how to add nodes? so- for adding them it still means hard coding them into that file? but anyway- yeah sure I mean_ practice is also cool- but when I want to deploy for real I can't use regtest- like- I can't transition from reg test to real world deploy- isn't it?

You can pass a -connect=IP command to bitcoind to make it connect only to ip address IP. That way you can create your own private network. You can even run multiple bitcoind on the same machine.


text:
GitHub won't let me fork Hivemind, maybe something about sidechain repos
On my GitHub page I have a fork of bitcoin/bitcoin.
The project Hivemind seems interesting, and I want to check it out.
When I try to fork it GitHub tells me that I already have a fork of it, and it references s-matthew-english/bitcoin, which is my fork of bitcoin/bitcoin.
Why is this happening? How can I circumvent this?

You're trying to fork bitcoin-hivemind/hivemind, which is a fork of truthcoin/truthcoin-cpp, which is itself a fork of bitcoin/bitcoin. So, your hivemind repository would end up being a fork of Bitcoin too, which is not allowed due to a GitHub limitation.
The various workarounds suggested in the Stackoverflow page include:

Creating an organization to fork hivemind
Creating a second GitHub account
Deleting the bitcoin fork, forking hivemind, and creating a bitcoin branch that is even with bitcoin/bitcoin. That way you can still make pull requests to Bitcoin, as that repository is still in the fork graph of bitcoin/bitcoin.

So then no one who maintains a fork of bitcoin/bitcoin can simultaneously maintain a fork of hivemind on their account?

@s.matthew.english: No, you could do that with a variation of the third suggestion provided here: A repository can manage multiple branches of the same code. You could check out hivemind into a new branch of the bitcoin repository.


text:
How many people own crypto currencies?
Is there an estimate on how many people in total own some cryptocurrencies?
How is this distributed among bitcoin and altcoins?

nobody knows really and it would be really hard to measure because an individual can have multiple bitcoin addresses.

@LucaMatteis true, I was wondering if there is another way apart from analyzing the addresses?

There must be a way to estimate this.  There is so much data on # of transactions, # of wallets, # of hashes per second (miners could possibly indicate popularity or adoption), publicly disclosed data from Bitcoin companies and online sales.  Do some crazy math, average, and combined with real time monitoring like mapping bitcoin addresses to IP addresses (thanks somesh), I bet you could get a good estimate.

Very similar to http://bitcoin.stackexchange.com/questions/731/how-can-you-tell-how-many-users-bitcoin-has

I've removed the tag [tag:estimate], as it described the type of question instead of the topic of the question.

As Luca mentioned it is really difficult to measure, but there is a way to map Bitcoin addresses to IP address under certain conditions.
Refer this paper
Title : An Analysis of Anonymity in Bitcoin using P2P Network Traffic.
Authors : Philip Koshy, Diana Koshy, and Patrick McDaniel.
Note: It analyses relay pattern of transactions. It cannot analyse transactions that are already confirmed in blocks.
Some companies publicly disclose their data and it might be possible to come up with a ballpark estimate.  Blockchain.info shares the number of wallets used in their My Wallet service.

It is next to impossible to estimate.
Consider this scenario:
You live in a deserted place with just phones/post offices. Using just pen & paper/calculator you derive a fresh new bitcoin address and its private key. You call any of your friends, who could be anywhere in the world, who have internet and you give them this address. They make a transaction sending satoshis worth buying milk and relay it to the network.
You could then go give away your privatekey to a milkman for buying milk. If he doubts you he can call any of his friends in the world who have internet and can confirm that that address holds balance.
You and the milkman are untraceable unless your friends decide to give you up. No technology can do it. Well, maybe some neuro-tech can scan their brains but ..
I could travel across borders holding my money in my mind.

Note that the milkman (or his friends) must transact the funds to a new address otherwise you, or someone else you might have given the private key to, can do it instead. This makes the milkman somewhat traceable (or his friends, at least).

As of Today, BlockChain's MyWallet has about 3.75M users. Adding this with CoinBase's user base of 2M and Multibit's 1.5M. That makes about 7.25M Bitcoin users. Note that actual number of users may be much above this figure as you can figure out all that is needed to encrypt the data is just a key!

Notice that there might be considerable overlap among these sets of users, which might put the actual number of users quite a bit lower.

Exactly! Nothing can be exactly measured.

authors: Алексей Зубов


text:
disregard power costs for mining in the winter?
My theory is that if you are mining in the winter you should discount power costs completely, since the heat generated by your miner will contribute to the heating of your home and thus cause your heating system to run less.  Is this valid?  The profitability calculators don't seem to take this into account.

This would be approximately true, if:

Your regular heating system is a resistive electrical heater.  (Not gas or oil, not a heat pump.)
Your mining rig produces no more heat than is needed to heat your house at any given time.  (This may be false for people with lots of hardware, or living in warm climates.  Note also that your heating needs may be much less some times of day; for instance, you probably turn down your heat when you're away from home or asleep.)
Your heating system is controlled by a thermostat in your own living space (some people in multi-unit buildings have a single thermostat for the building, or some open-loop system)
You normally pay for the electricity used by your heating system (rather than having it included in rent, for instance) and at the same price as domestic electricity use
The heat from your mining rig is circulated through your house just as efficiently as your heating system does it.

I suspect that users for whom all of these are true are in the minority.  But in general, it is true that the electricity cost can be offset to some extent by reduced heating costs; to what extent depends on each individual's situation, so it's not clear how a general-purpose calculator should account for it.  Therefore, they don't.
Note that by the same token, running your mining rig in the summer may incur additional cooling costs.  Mining calculators typically don't consider that, either.

authors: พระนรค ฟิล์ม จัดให้


text:
How do I start accepting bitcoins legally in Canada?
I own a business and I want to know how to accept bitcoins for payment and whether it is legal to accept them in Canada?  For example, if someone pays me 2 bitcoins for a computer, do I need to charge taxes? If yes, do I need to charge 2 bitcoins and 50$ in Canadian money so I can give the taxes to the government?

possible duplicate of How can I accept bitcoins on my website?

This wikipedia article tells me Bitcoin is legal as long as you pay taxes on it. http://en.wikipedia.org/wiki/Legality_of_Bitcoins_by_country

IANAL. Yet, I am baffled, why a different payment method should exempt you from paying taxes. I'd just treat Bitcoin in that regard like another fiat currency or different payment method. E.g. a shop at the border to the US taking US dollars in exchange for goods certainly wouldn't be legally exempt from paying taxes on that sale just because of it being paid in USD instead of CAD.
So, in my experience the flow would be something like:

Calculate your customers bill just as you would in any other case in Canadian dollars.
Add shipping fee and similar.
Apply VAT based on CAD value. (1)
Present the bill stating the amount in CAD, "payable in X Bitcoin to address 1xyz".
Put the transaction into your bookkeeping with the CAD value, including a remark "payment method: Bitcoin, X BTC".
Keep Bitcoin/Sell Bitcoin/Whatever floats your boat.
When paying taxes for your business, include amount of CAD in height of (1) for the transaction just as you would with any other sale.

I am not a lawyer, I have never lived in Canada, the above is solely based on my experience of how the world works. ;)

Vault of Satoshi is an exchange located in Canada.
VoS seems to be rather meticulous when it comes to operating legally.  They are delaying even non-fiat, coin to coin trades for people in the US until robust, state-by-state licensure is in place.
I have found their support staff to be highly responsive.
https://vaultofsatoshi.zendesk.com/hc/en-us
Try dropping them a line and explain your particular business circumstance.  They might even be able to offer you some reporting services akin to CoinBase's tax reports.

At first I read your answer to mean, that Vault of Satoshi is "buttoned-up", but I take it now that the Canadian government is? You might want to clarify that.

Good call Murch.  VoS was the entity to which I intended to refer. I've edited to clarify.

Actually, I must admit that your edit confused me more at first: From the term I had assumed that "to be buttoned up" was to mean that one was taciturn about something, yet from the context I'd deduce that it probably means rather something along the lines of "doing something by the book"? Considering that only about 5.4% of the world's population speak English as their native language, your answer might be more accessible if you tried to put it in a less idiomatic fashion. ;)

Idioms cleansed.  I deeply enjoy etymologies and linguistics; as a result my writing tends to be overwrought.  While there is a time and a place for such writing, technical discussions are neither.  Fair criticisms; keep them coming :)

Last year, Bitcoin was declared to be a form of barter in Canada--not a currency. I suspect it has something to do with the MintChip, which was supposed to launch in February 2013.
CaVirtEx is Canada's largest Bitcoin Exchange, and is proactive when it comes to regulations. (ie. they go beyond the bare minimum). CaVirtEx would be my first choice for accepting Bitcoin in Canada.
As I understand barter & taxes in Canada, taxes are owed on the value of the bartered item, so there really isn't much difference when it comes to sales tax & GST/HST.

I dont personally live in Canada, but its my understanding that they are one of the most liberal countries in regards to bitcoin business's. When I have ordered from
http://www.wtcr.ca/
I have always had the tax added on at the end but in bitcoin, I surmise from this that WTCR then sell the 'tax' portion of the sale to fiat, and use that to pay the government.
Hope this helps


text:
Why did my transaction not include the fee?
I moved 0.30 BTC from Bitcoin Wallet for Android to a new Coinbase wallet I had created, I have waited and waited – now it’s been 29 hours.
It turns out the transaction doesn’t include a fee, which was why it’s taking so long. I was surprised, because Bitcoin Wallet for Android doesn't have a feature to opt out of sending a fee. I don’t think any android based application wallet has? I checked right through the app and the fee is automatically taken every transaction (as it should be IMHO).
So, how come this one transaction did not include a fee, while each of the past 50,000 transactions I've done have, including two since this incident using the exact same wallet to the exact same Coinbase wallet in an attempt to force my other one to be confirmed.
I've spoke with the Bitcoin devs and it’s not a bug with the wallet, or if it is, then this is literally the only case this has happened in.
Why and what could cause this? How long do I wait? Is my 0.30 coins in limbo never to be seen again? Is there any way I can just cancel this transaction and try again? Is there any way to manually pay the fee? Or confirm it myself somehow?
Coinbase says my 0.30 BTC is pending and will be confirmed in 30 minutes; it has said that the whole time.

I don't know why your wallet didn't include a fee, and it would probably require a fair amount of debugging to figure out what went wrong.  Here are my suggestions for following up on this problem:

Make sure your transaction really didn't include a fee.  Open your wallet, find the transaction is the list of outgoing transactions, and press-and-hold on it to get the extra menu, and open it in the block chain explorer (BitEasy in Bitcoin Wallet For Android).
In the block chain explorer, look at the details and make sure it didn't really include a transaction fee.  If there is a fee, Coinbase support got something wrong---so contact them again.  If there really is no fee, go to the next step.
See what wallet you use.  From your description, it sounds like you use Bitcoin Wallet For Android, developed by Andreas Schildbach and based on BitcoinJ by Mike Hearn.  I've worked with both of them, and they're both very responsive to user problems.
If that is in fact the wallet you use, open a new issue on their issue tracker.  Here is the information you should provide them:

A link to this question.
The link to the page on BitEasy that shows your transaction had no fee.  Note: this may reduce your privacy (but it won't put your bitcoins directly at risk); if you uncomfortable with that, ask them if you can send them that link by email---I'm sure they'll accept.
What version of Android you use (Settings→Device Information→Version) and whether you use the latest version of Bitcoin Wallet For Android from the Google Play store.
Whether or not you completely emptied the balance of your wallet.  I think there's some special code that gets run when that happens.
Anything else unusual that you noticed.
You may also want to provide a copy of the text from the email Coinbase support sent you after removing any personal information.

If you use a different wallet, you'll need to follow the same basic steps but at a different URL.  Let me know the full name of your wallet in a comment below, and I'll find the most appropriate link.
Read the response from the developers closely and respond as best you can.  Please note that Andreas, Mike, and everyone else who works on Bitcoin Wallet For Android are all volunteers, so it sometimes takes them a while to get to new issues---please be patient.

This may seem like a fair amount of work, but filing issues is one of the ways you can support great open source software like Bitcoin Wallet For Android.

Sorry I missed this reply. It's still a mystery as why the transaction fee was not included in this transaction. I will take some of your suggestions on board and look into it. I will post any thing I find. Cheers


text:
Who do i see the commissions taken by miners?
I'm a bit confused by the commissions. My understanding is there should be none in Bitcoin.
But a friend of mine told me miners get a cut. What does this mean? I want to learn how much commission I pay to the miners. Could you please tell it in detail and tell me where I can see it?

From Transaction fees on the Bitcoin wiki:

The transaction fee is processed by and received by the bitcoin miner. When a new bitcoin block is generated with a successful hash, the information for all of the transactions is included with the block and all transaction fees are collected by that user creating the block, who is free to assign those fees to himself.

So yes, the fee is collected by the miner of the discovered block. If you look to a random block on the blockchain site you see that the fees are 0.03334571 BTC (in that specific block).
The transaction fee you pay could be different depending on which wallet software you use. For example the fee from multibit is 0.0001 BTC. You can also pay no fees, but then there is a chance that your transaction takes a lot of blocks to be included in the blockchain.


text:
How do you install Bitcoin Daemon using Yum package manager?
I have a Centos setup with the Yum package manager. How do you install Bitcoin Daemon using Yum? Or is it even possible right now?

This page has instruction on how to install Bitcoin using yum:
http://linux.ringingliberty.com/bitcoin/


text:
Why don't any of the SHA-256 vulnerabilities matter for mining?
Wikipedia lists several vulnerabilities in SHA-256. Presumably, none of them can be used to mine faster, or it would be done already. Why don't these vulnerabilities lead to a problem for mining?

The attacks are against a "poor man's" version of SHA-256, where less rounds are performed than in the real SHA-256. They are useless for breaking SHA-256 itself, and more so for the double SHA-256 used in Bitcoin mining.
Also, what would be most useful for mining is a preimage attack, and those are much harder than collision attacks. You can see in the table on Wikipedia that the proposed preimage attacks, though faster than pure brute force, are still impossibly complex.

Sha256 has no known vulnerabilities as of yet. As Meni Rosenfeld mentioned, the mentioned attacks only concern part of the rounds of Sha256, in order to have an actuall effective attack you'd have to fully break all rounds (64 in case of Sha256).
Even if Sha256 was broken, it still wouldn't directly affect mining, as Bitcoin uses double Sha256 hashing:Sha256d(x) = Sha256(Sha256(x))
Even if a full preimage attack on Sha256 was found, it still most likely would not affect Bitcoin, as in the mining process there is very little freedom to forge the input data. You can shuffle around some txs, vary the nonce, but not much else. It is extremely unlikely that whatever means the preimage attack uses to construct input data (to match the required hash value) is compatible with the way Bitcoin blocks are built up.

This gives us more than enough time to migrate to another hashing algorithm, if regular Sha256 were ever to be compromised.

Assuming whoever discovers it is nice enough not to pick the millions they could get by mining ... Also, why couldn't you apply a preimage twice to undo a double hash?

If it was compromised in terms of a full preimage attack, then yes. But then still there's another factor at play, added it as nr.3


text:
How often does a block have only one transaction?
I was looking at blocks on blockchain.info, and came across this one with only one transaction in it: (the mining reward one)
https://blockchain.info/block-index/512049/00000000000000000429a0c4fbe735b2d8b493daedf0207728543f748c262437
Is that at all suspicious? Does it mean someone was trying to block some transactions from going through? How common are single-transaction blocks?

Note that these "empty" blocks are NOT useless for the bitcoin network, because they add more proof-of-work on top of previous blocks, making transactions in those blocks more secure. Mining fee for "empty" blocks motivates miners to generate that proof-of-work. And transaction fees motivate them to include transactions in generated blocks.

It's possible that this could happen just because there aren't any transactions to be mined. Early on in the bitcoin block chain, this was often the case. This could also happen if two blocks are solved on top of each other in a very short amount of time, with not much time for new transactions to be broadcasted in between. Today, however, more often than not this is due to a miner trying to get his/her block out to the rest of the peers on the network as soon as possible.
A miner would want to do this because bigger blocks take longer to propagate to the rest of the network. Nodes have to download and verify the validity of a block before they can relay them to their peers, because if they don't verify before sending and they send an invalid block, then their peers may ban them and the node will have no one to connect with on the network.
Think of it this way. If your block takes 50 seconds to get out to 90% of the peers on the network, and someone else mines a block 1 second later than you but can get their block out to 90% of the network in 9 seconds, who do you think will have the greater chance of getting their block accepted by more peers?
It may also be worthwhile to note that while this seems like it has a better pay off, it also sends a message to everyone on the network that the miner who mined the block doesn't really actually care about the bitcoin network's transactions, it just cares about its reward. And if the miners don't support the system, then why should investors or anyone else have confidence in it? I guess what I'm trying to say is that if a lot of miners did this, then the price of bitcoin would likely drop as it would show a lack of faith in the system.
There's a more mathematical analysis of orphan rates and payoffs here: http://organofcorti.blogspot.com/2013/10/161-network-orphaned-blocks-part-1.html\
In addition, it may interest you to know that there is a new proposal to enable faster propagation of blocks even if they are very large. See here for more info: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2.

A different way of explaining this would be that, for a block to be accepted by the network, it has to be propagated out and checked by everyone. While blocks are spreading through the network, any miners who don't know about the new block will just keep mining on the block they have. In most cases, probably, this is just wasted work since there is already a block that is on it's way to being accepted. But if your block is much smaller (i.e. very few txs), then it gives other miners less time to solve a block while yours is propagating, and it also increases your chance that your block will get accepted by the majority of the miners even if someone else solved a block slightly before you.

To answer this question with a bit of data, I made a script that processed the last 1 month of blocks (4,464 blocks before and including block 338,782), and gathered data about the number of transactions in each block. These were the results.

From this data, it seems that roughly

1.3% of blocks are solved with just the reward transaction
1.6% of blocks are solved with fewer than 10 transactions.

# Transactions  # Blocks with transaction count in MIN-MAX range
MIN     MAX     COUNT
0       9       73
10      19      31
20      29      22
30      39      74
40      49      52
50      59      43
60      69      107
70      79      50
80      89      41
90      99      56
100     109     55
110     119     50
120     129     86
130     139     46
140     149     54
150     159     57
160     169     51
170     179     62
180     189     49
190     199     53
200     209     46
210     219     45
220     229     64
230     239     42
240     249     45
250     259     69
260     269     58
270     279     39
280     289     41
290     299     41
300     309     44
310     319     45
320     329     37
330     339     35
340     349     45
350     359     42
360     369     40
370     379     42
380     389     41
390     399     37
400     409     48
410     419     47
420     429     42
430     439     40
440     449     40
450     459     46
460     469     42
470     479     32
480     489     33
490     499     40
500     509     38
510     519     68
520     529     44
530     539     28
540     549     32
550     559     28
560     569     35
570     579     27
580     589     29
590     599     28
600     609     19
610     619     31
620     629     20
630     639     27
640     649     38
650     659     28
660     669     27
670     679     25
680     689     18
690     699     21
700     709     27
710     719     28
720     729     23
730     739     25
740     749     25
750     759     19
760     769     21
770     779     24
780     789     27
790     799     23
800     809     16
810     819     18
820     829     19
830     839     18
840     849     16
850     859     19
860     869     20
870     879     16
880     889     18
890     899     16
900     909     24
910     919     24
920     929     14
930     939     18
940     949     20
950     959     12
960     969     13
970     979     15
980     989     15
990     999     21
1000    1009    15
1010    1019    15
1020    1029    18
1030    1039    14
1040    1049    13
1050    1059    13
1060    1069    9
1070    1079    16
1080    1089    16
1090    1099    8
1100    1109    17
1110    1119    10
1120    1129    12
1130    1139    8
1140    1149    8
1150    1159    22
1160    1169    10
1170    1179    14
1180    1189    17
1190    1199    10
1200    1209    11
1210    1219    14
1220    1229    9
1230    1239    9
1240    1249    12
1250    1259    9
1260    1269    8
1270    1279    7
1280    1289    7
1290    1299    9
1300    1309    8
1310    1319    12
1320    1329    8
1330    1339    7
1340    1349    12
1350    1359    10
1360    1369    13
1370    1379    10
1380    1389    10
1390    1399    9
1400    1409    10
1410    1419    8
1420    1429    14
1430    1439    10
1440    1449    6
1450    1459    6
1460    1469    6
1470    1479    9
1480    1489    7
1490    1499    4
1500    1509    5
1510    1519    8
1520    1529    5
1530    1539    12
1540    1549    3
1550    1559    7
1560    1569    8
1570    1579    3
1580    1589    7
1590    1599    2
1600    1609    12
1610    1619    5
1620    1629    10
1630    1639    3
1640    1649    4
1650    1659    5
1660    1669    6
1670    1679    5
1680    1689    3
1690    1699    5
1700    1709    2
1710    1719    1
1720    1729    10
1730    1739    4
1740    1749    5
1750    1759    4
1760    1769    4
1770    1779    2
1780    1789    3
1790    1799    6
1800    1809    3
1810    1819    2
1820    1829    4
1830    1839    5
1840    1849    4
1850    1859    3
1860    1869    3
1870    1879    3
1880    1889    5
1890    1899    3
1900    1909    3
1910    1919    4
1920    1929    1
1930    1939    0
1940    1949    3
1950    1959    0
1960    1969    0
1970    1979    3
1980    1989    2
1990    1999    2
2000    2009    3
2010    2019    3
2020    2029    3
2030    2039    3
2040    2049    7
2050    2059    3
2060    2069    1
2070    2079    4
2080    2089    2
2090    2099    1
2100    2109    1
2110    2119    3
2120    2129    2
2130    2139    2
2140    2149    4
2150    2159    1
2160    2169    2
2170    2179    1
2180    2189    2
2190    2199    3
2200    2209    0
2210    2219    0
2220    2229    1
2230    2239    0
2240    2249    3
2250    2259    0
2260    2269    1
2270    2279    2
2280    2289    1
2290    2299    3
2300    2309    0
2310    2319    1
2320    2329    0
2330    2339    1
2340    2349    1
2350    2359    1
2360    2369    1
2370    2379    1
2380    2389    0
2390    2399    0
2400    2409    1
2410    2419    1
2420    2429    1
2430    2439    0
2440    2449    0
2450    2459    0
2460    2469    1
2470    2479    0
2480    2489    0
2490    2499    2
2500    2509    0
2510    2519    0
2520    2529    1
2530    2539    2
2540    2549    2
2550    2559    1
2560    2569    0
2570    2579    1
2580    2589    1
2590    2599    0
2600    2609    0
2610    2619    0
2620    2629    0
2630    2639    0
2640    2649    2
2650    2659    0
2660    2669    0
2670    2679    0
2680    2689    0
2690    2699    0
2700    2709    0
2710    2719    0
2720    2729    0
2730    2739    0
2740    2749    0
2750    2759    0
2760    2769    0
2770    2779    0
2780    2789    0
2790    2799    0
2800    2809    0
2810    2819    1
2820    2829    0
2830    2839    0
2840    2849    0
2850    2859    1
2860    2869    0
2870    2879    0
2880    2889    0
2890    2899    0
2900    2909    0
2910    2919    0
2920    2929    0
2930    2939    0
2940    2949    0
2950    2959    0
2960    2969    0
2970    2979    0
2980    2989    0
2990    2999    0
3000    3009    0
3010    3019    0
3020    3029    0
3030    3039    1
3040    3049    0
3050    3059    0
3060    3069    0
3070    3079    0
3080    3089    0
3090    3099    0
3100    3109    0
3110    3119    0
3120    3129    0
3130    3139    1

The x-axis here (it may be hard to read) is the transaction range (each MIN-MAX pair in data above represents one column). The y-axis shows the number of blocks in the last month that had a transaction count within the range.

+1 for the references. Can you elaborate on how orphans relate to blocks with no transactions (except the coinbase one)?

Appended a paragraph to my post, since it was too long for a comment.

What do your axes mean?

@NickODell, I changed it to have a linear scale on the x-axis and added a short paragraph describing the axes.

It is fairly normal and there 2 common reasons for this.
The first reason is when 2 blocks are solved relatively close to each other in time.  The second of these blocks may not have any transactions to include.
The second reason is that bigger blocks take longer to propagate across the network.  It is often in the interest of the block solver to transmit a block without any transactions as it is less likely that another block might be solved in the time it takes the block to propagate across the network.  This makes it less likely that the solved block will become orphaned.

In this case, there were at least five minutes between this block and the previous one. Also, is there any detailed analysis of the expected gain/loss of following a strategy given % of hashrate and other factors?

Also, this one appeared to come from a pool, which may be a problem if they do that always.

BTC.com has done this 5 times in the last 6 days.  With the number of unconfirmed transactions been larger than 2-3 full blocks, clearly lack of available transactions is not the problem.  It is also interesting that is coming from the same miner pool.
https://blockchain.info/blocks/BTC.com


text:
My Multibit wallet stops updating and says another program has changed files. How can I solve this?
I am running Multibit on Windows 7. When I open it, the synchronization will initially start, but then stop after a while due to "another program attempting to change files".
I didn't move any files while it was running. I have also tried updating MultiBit, but the same error occurred again.
What could cause this error and how can I resolve it?

I don't think that this question can be answered from the information you have provided. What operating system are you running? What were you doing when the problem occurred? What have you tried to resolve the problem? Have you tried closing MultiBit and reopening it? Did you move the MultiBit folder while it was running? - I have also removed the Bitcoin-Qt tag, as there is no indication in your question that it is relevant.

I am running Windows 7.  The problem occurs when I open the wallet.  It syncs for a while and then gives the error message.  I tried updating multibit but it did the same thing.  I didn't move the folder while it was running.  Thanks for the edit.

I have edited your question to include the additional information. Comments are considered transient on Stackexchange, everything useful should be put into the questions and answers. ;) Lemme see: Are you running another Bitcoin software from the same blockchain data, such as for example Bitcoin-Qt or Bitcoin-Core? Is there other software you are running that may be changing files, e.g. Anti-Virus, backup-processes?

I am running maxcoin-qt.  I set the processes in my anti-virus to allow multibit.

Running low on ideas here. Could it be related to user rights? We do have a MultiBit-Dev checking the MultiBit tag sometimes, perhaps he will know. shrug