text:
Stratum Mining proxy failed to compile on Centos 2.6.32-279.el6.x86_64
I was trying to build stratum mining proxy on a Centos x64 machine. As mentioned below the script is throwing compilation errors, any idea?
[root@host.com slush0-stratum-mining-proxy-7b5c080]# python ./setup.py install
/root/Desktop/mining/slush0-stratum-mining-proxy-7b5c080/distribute_setup.py:139: UserWarning: Module distribute_setup was already imported from /root/Desktop/mining/slush0-stratum-mining-proxy-7b5c080/distribute_setup.pyc, but /usr/lib/python2.6/site-packages/stratum-0.2.12-py2.6.egg is being added to sys.path
  import pkg_resources
running install
running bdist_egg
running egg_info
writing requirements to stratum_mining_proxy.egg-info/requires.txt
writing stratum_mining_proxy.egg-info/PKG-INFO
writing top-level names to stratum_mining_proxy.egg-info/top_level.txt
writing dependency_links to stratum_mining_proxy.egg-info/dependency_links.txt
reading manifest file 'stratum_mining_proxy.egg-info/SOURCES.txt'
writing manifest file 'stratum_mining_proxy.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
creating build/bdist.linux-x86_64/egg
creating build/bdist.linux-x86_64/egg/mining_libs
copying build/lib/mining_libs/client_service.py -> build/bdist.linux-x86_64/egg/mining_libs
copying build/lib/mining_libs/worker_registry.py -> build/bdist.linux-x86_64/egg/mining_libs
copying build/lib/mining_libs/stratum_listener.py -> build/bdist.linux-x86_64/egg/mining_libs
copying build/lib/mining_libs/version.py -> build/bdist.linux-x86_64/egg/mining_libs
copying build/lib/mining_libs/__init__.py -> build/bdist.linux-x86_64/egg/mining_libs
copying build/lib/mining_libs/midstate.py -> build/bdist.linux-x86_64/egg/mining_libs
copying build/lib/mining_libs/getwork_listener.py -> build/bdist.linux-x86_64/egg/mining_libs
copying build/lib/mining_libs/jobs.py -> build/bdist.linux-x86_64/egg/mining_libs
copying build/lib/mining_libs/multicast_responder.py -> build/bdist.linux-x86_64/egg/mining_libs
copying build/lib/mining_libs/utils.py -> build/bdist.linux-x86_64/egg/mining_libs
byte-compiling build/bdist.linux-x86_64/egg/mining_libs/client_service.py to client_service.pyc
byte-compiling build/bdist.linux-x86_64/egg/mining_libs/worker_registry.py to worker_registry.pyc
byte-compiling build/bdist.linux-x86_64/egg/mining_libs/stratum_listener.py to stratum_listener.pyc
byte-compiling build/bdist.linux-x86_64/egg/mining_libs/version.py to version.pyc
byte-compiling build/bdist.linux-x86_64/egg/mining_libs/__init__.py to __init__.pyc
byte-compiling build/bdist.linux-x86_64/egg/mining_libs/midstate.py to midstate.pyc
byte-compiling build/bdist.linux-x86_64/egg/mining_libs/getwork_listener.py to getwork_listener.pyc
byte-compiling build/bdist.linux-x86_64/egg/mining_libs/jobs.py to jobs.pyc
byte-compiling build/bdist.linux-x86_64/egg/mining_libs/multicast_responder.py to multicast_responder.pyc
byte-compiling build/bdist.linux-x86_64/egg/mining_libs/utils.py to utils.pyc
creating build/bdist.linux-x86_64/egg/EGG-INFO
installing scripts to build/bdist.linux-x86_64/egg/EGG-INFO/scripts
running install_scripts
running build_scripts
creating build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.6/mining_proxy.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/mining_proxy.py to 755
copying stratum_mining_proxy.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying stratum_mining_proxy.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying stratum_mining_proxy.egg-info/dependency_links.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying stratum_mining_proxy.egg-info/requires.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying stratum_mining_proxy.egg-info/top_level.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
creating 'dist/stratum_mining_proxy-1.5.2-py2.6.egg' and adding 'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing stratum_mining_proxy-1.5.2-py2.6.egg
removing '/usr/lib/python2.6/site-packages/stratum_mining_proxy-1.5.2-py2.6.egg' (and everything under it)
creating /usr/lib/python2.6/site-packages/stratum_mining_proxy-1.5.2-py2.6.egg
Extracting stratum_mining_proxy-1.5.2-py2.6.egg to /usr/lib/python2.6/site-packages
stratum-mining-proxy 1.5.2 is already the active version in easy-install.pth
Installing mining_proxy.py script to /usr/bin

Installed /usr/lib/python2.6/site-packages/stratum_mining_proxy-1.5.2-py2.6.egg
Processing dependencies for stratum-mining-proxy==1.5.2
Searching for twisted>=12.2.0
Reading http://pypi.python.org/simple/twisted/
Best match: Twisted 13.1.0
Downloading http://pypi.python.org/packages/source/T/Twisted/Twisted-13.1.0.tar.bz2#md5=5609c91ed465f5a7da48d30a0e7b6960
Processing Twisted-13.1.0.tar.bz2
Writing /tmp/easy_install-2jd1TB/Twisted-13.1.0/setup.cfg
Running Twisted-13.1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-2jd1TB/Twisted-13.1.0/egg-dist-tmp-tl_fLs
twisted/runner/portmap.c:10:20: error: Python.h: No such file or directory
twisted/runner/portmap.c:14: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
twisted/runner/portmap.c:31: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
twisted/runner/portmap.c:45: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PortmapMethods’
twisted/runner/portmap.c: In function ‘initportmap’:
twisted/runner/portmap.c:55: warning: implicit declaration of function ‘Py_InitModule’
twisted/runner/portmap.c:55: error: ‘PortmapMethods’ undeclared (first use in this function)
twisted/runner/portmap.c:55: error: (Each undeclared identifier is reported only once
twisted/runner/portmap.c:55: error: for each function it appears in.)
error: Setup script exited with error: command 'gcc' failed with exit status 1

Found the solution, twisted/runner/portmap.c:10:20: error: Python.h: No such file or directory was more than enough to see what was the error. Missing Python developer package!!!
Did yum install python-devel -y and Voila!

You should install dependencies first
yum install python-devel* python-twisted gcc

Good luck ..


text:
How does a share help in the discovery of a new block?
https://en.bitcoin.it/wiki/Pooled_mining:
A share is awarded by the mining pool to the clients who present a valid proof of work of the same type as the proof of work that is used for creating blocks, but of lesser difficulty, so that it requires less time on average to generate.
I would like to know how the proof of work with lesser difficulty will help in calculating the proof of work for a new block.
In other words, why would pools pay for shares? How do they help?

In order to find a Block, one needs to perform A LOT of tries - about 2^32 * the current difficulty. That number is so huge that solo miners rarely would be able to solve a block. A share on the other hand is a block of difficulty 1, which is at the moment a few million times easier to find.
Finding a share does not help in finding a block in any way - each hash is independent of all others. However, a share IS a proof of work done by the miner - they put in the effort to help the pool find the block. Once one miner finds a solution to the block problem, the pool earns money and can pay its miners - logically paying everyone for each share submitted. Those shares did not solve the block, but they were a proof that a miner was trying to solve a block. The more shares, the more work needed to be put.
Without shares, everyone would be essentially solo mining - there would be no way to prove that one put in the work, so there would be no reason to be paying the miners - they might be cheating after all.
A useful analogy would be lottery tickets - it is unlikely you will win, but if you live in a small town and decide to share the potential win with everyone that participates in lottery in proportion to how many tickets they bought, you would essentially have a mining pool. Every ticket, even if it does not win you anything, is worth a slice of the winnings - you had to pay for that ticket, so it's a proof that you put in the effort.

source: Stack Exchange

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

sort: votes


text:
Bitcoin core: boostrap.dat trade-off with "Synchronizing with network..."
Being, now, aware that users of Bitcoin Core (v0.12.1.0-g9779e1e) are no longer to use a torrent download of a bootstrap.dat and, instead, are admonished to simply launch Bitcoin Core and permit "Synchronizing with network...", I nevertheless have a situation that may require a more nuanced decision:

I'm recovering from a backup and it says "50 weeks behind..."
By the time I discovered boostrap.dat was no longer faster I had already torrent downloaded most of boostrat.dat.

Number 1 leads me to believe my use case may be an exceptional use case that may download everything for the last year before becoming operational again -- rather than the minimum amount(?) necessary to begin secure operation.
Number 2 means I may be able to complete the download in about 12 hours to SATA SSD and then be able to load from that file only the minimum amount(?) necessary in a total amount of time much faster than downloading "50 weeks behind" of blockchain.
Should I go ahead with the torrent of bootstrap.dat and load it or should I stop the torrent and just let Bitcoin Core complete "Synchronizing with network..." even though it says "50 weeks behind"?

the minimum amount(?) necessary to begin secure operation

Letting Bitcoin Core synchronize on its own will do the following:

Download block headers in packages of 2,000 and quickly rebuild the chain of headers for a total less than 50 MiB
Request multiple block bodies in parallel from several peer nodes
Validate blocks in order as they finish downloading including all transactions they contain

For the last 50 weeks that would cause Bitcoin Core to download and validate about 35 GiB of data.
Synchronizing from the bootstrap.dat you download the complete blockchain first, then rebuild the blockchain from scratch.
This means that you have to

download more data (78 GiB instead of 35 GiB)
have to validate blocks of more than four years instead of 50 weeks
and delay the validation until after the download is complete instead of validating while downloading already.

It seems to me that unless the download speed from the peers is the bottleneck for you, letting Bitcoin Core synchronize on its own will be quicker. On my fairly new computer the bottleneck is the validation and not the download.

Great answer!  It is precisely what I wanted to find out.  Fortunately, I had decided to stop the torrent and start bitcoin core -- I'm down to 18 weeks behind now.

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


text:
How does the "failover" setting in cgminer work?
I have been messing with a p2pool which I like (no fee) but has latency about every week causing the miner to stop mining altogether. I would like to employ some kind of failover strategy so that the miner will mine somewhere else if unable to connect to this free p2pool, but I would like to be mining on the primary pool as often as possible.
I have tried looking at the multipool settings, but they weren't very informative in terms of what happens when. If I set failover does that mean that it will only connect to the second if it can't connect to the first? If not, is there any way to set up cgminer this way?

Yes, the failover setting will tell cgminer to mine on a secondary pool when the first pool is unavailable.
Run cgminer with the following:

cgminer.exe --scrypt -o http://p2pool.org:9327 -u username -p password
  --failover-only -o http://backuppool.org -u username -p password

This example mines LTC  at p2pool and will mine at another pool of your choice when p2pool is unavailable.

Asking for tips in posts is not allowed, but you may post your addresses in your profile. See the meta question here: Is it okay to ask for money donations in an answer?

After failing-over to the backup, does it occasionally check that the primary pool is available again and then switch back to the primary?

It checks for the main pool very often and reconnects almost instantaneously once the main pool is back online.


text:
How are bitcoins put in to circulation?
I'm excited because I bought my first bitcoins today! (0.41 bitcoins at that!)
I'm wondering how they are put in to circulation? From my understanding it seems that the algorithm generates x bitcoins every hour, where x is a diminishing value, until eventually zero coins are being created... so let's say an hour from now 5 bitcoins are created... Where are they created and how are they put into circulation? Or are they created evenly throughout everyone's wallets and just distributed evenly (in which case I might receive 0.000001 bitcoins in the next hour?) And what is a bitcoin miner?
Also, what happens if my computer is destroyed and my wallet file with my bitcoins is lost? Are those bitcoins gone forever? Wouldn't this cause the supply of bitcoins to go down overtime until eventually there are very few bitcoins left?
Thanks! God bless!
(I bolded my 3 questions so that they are easy to find and answer).

Let me answer your questions out of order:

What's the point of bitcoin mining / how they are put in to circulation?

https://bitcoin.stackexchange.com/a/3201/2306

what happens if my computer is destroyed. Are those bit coins gone forever?

Yes.

Wouldn't this cause the supply of bit coins to go down overtime until eventually there are very few bit coins left?

Yes.

So as far as mining goes, how many bit coins could I mine every hour? Is it worth it or is it just pennies... 0.0001 bit coins or something.

@AlbertRenshaw CPU/GPU mining will cost you more in electricity than you will get from mining. FPGAs/ASICs are the only things that are profitable right now.


text:
Why guiminer is using different amount of GPU each time I restart my copmuter?
Why guiminer is using different amount of GPU each time I restart my computer?
I'm running guiminer-20121203, NVIDIA GeForce GTX 670M, poclbm.exe with flags  -s 0.005 -f 60
What I noticed was, it was 35Mgash/s with 75% GPU usage. And after I restart my computer, it became  50Mgash/s with 100% GPU usage with the same flag settings.
Also, before when I tried only with flag -s 0.010 it utilized 100% GPU, but without restarting computer, using flag -s 0.011 reduced GPU usage to 60%.
What's going on??

Other applications can alter your GPU settings not just guiminer.
If you take a read over this question here it may reflect a similar circumstance which is causing a variable hash rate on your hardware. Without knowing your exact usage of your computer though I cant say for sure.

I swear god I tested this, with exactly the same condition. Ok, just to be sure let's test this again... And.. I can't reproduce the situation I described above... Now same flags gives same hash rate and GPU usage. So I guess I was wrong.


text:
Mine BitCoins on a Mac?
Ok, so I can mine BitCoins on my Mac... using my Windows Partition.
Like a lot of people I hate Windows.
I'd use Linux first (I have a WUBi partition), but I'd like a BitCoin miner for Mac that does not use OpenCL!
I'm using

a Mid 2012 MacBook Pro
with integrated Graphics,
2.5GHz processor Core i5
4GB RAM.

My laptop does not support OpenCL. I know of MacMiner, but I believe that needs OpenCL. Using my CPU to mine (on Windows) I get 1.7MHz, but on the GPU (on Windows) I get 4.7 and sometimes 5MHz.
I'm getting an iMac this Christmas, so maybe it'll be a little better for this.
So yeah, how can I start mining BitCoins on my Mac? Any software?

Keep your profitability in mind. You aren't likely to be profitable mining on such a device.

You can use your Mac to mine with ASIC devices. The BitMinter client works fine for this.

Your hardware is useless for mining. You'd spend more money on power than you could ever make back mining on a rig that isn't built for mining.

So would you recommend waiting for my iMac? It'll be the cheapest 21" model. I've heard people saying they get 100GHz on it, and the ButterFly Labs machine can get about 2.5Billion GHz. That's about 10 minutes for 250 BTC, if I remember right!

You won't be happy mining bitcoins on the same computer that you use for work, because it will slow the computer down significantly. Instead, buy an asic, or build a cheap computer with some video cards off ebay. http://thegenesisblock.com/asicminer-lowers-usb-miner-price-to-0-89-bitcoins/

I completely agree that the mining is impractical and will result in charges, not profits.  However, unless I am mistaken, the question was not "Is this a good set-up or choice?" but rather "how does he or she accomplish the objective of mining with the above hardware?"  Personally, I think there is a lot to be learned about mining bitcoin by configuring the impractical options like OpenCL, GPU, CPU, set generate true, delving into the .conf file, etc., and then should one's interest be piqued, going further later.  Thus, I recommend the @John answer below as a great way of learning.

@oemb1905 When reading the question, I didn't get the sense that it was exploratory or experimental.

You might be right ...

You can use your CPU to mine in the main bfgminer window that opens when MacMiner starts, or you can use the view menu to get to CPU Miner window, if you're interested in mining LTC or some other scrypt currency.
http://macminer.fabulouspanda.com/
as an aside, the CPU is actually detected as an OpenCL device, so it may be appropriate to change the question to 'How can I CPU Mine BTC on a Mac?'


text:
Online Mining Calculators using prebuilt machines data
I've read many comments that mining is not profitable, or barely.
Using the machines' data at Hardware Comparison in online mining calculators do show some with good profits. Am I missing something or misunderstanding the data? I only used the Mhash/s, watts, and price.

The problem is that the difficulty rating is going up, and going up significantly.  This happens for two reasons.  First, the number of mining rigs increases as people try to get involved with Bitcoin mining.  Second, ASIC-based miners which can run over 60GH/s using around 600W are just arriving in the market and once more generally available will cause a big leap in the difficulty.

Thanks. That makes sense. Is there any way to guess what the difficulty will increase to in order to input that into a calculator?

@cookyjar It requires you to predict the rate at which ASICs will come out and how fast those ASICs will be. Another factor is the change in the value of Bitcoins -- good luck predicting that.

As David said it is hard to predict, however the current total network rate is around 55TH/s, so just 1,000 of these ASIC-based miners will double the rate and more likely it's going to go up 10-fold to 100-fold.

@David Schwartz I see. There are a number of factors. How efficient and how much profit will they still be with more difficulty... value of coins, etc. I keep thinking of those old hair dryers with "1200 Watts" prominently stamped on the sides.

@jgm That is interesting. Any idea what this may have, if anything, on the value of the coins?

Shouldn't have any impact on the value of the coins themselves.  The network self-adjusts so that 1 block is solved roughly every 10 minutes regardless of the hash rate.


text:
What happens to extinct blockchains, and transactions inside of them?
While understanding the concept of block chain and proof of work, few things are confusing me. Miners always consider the longest chain(by difficulty) and work on expanding it. Now, lets say two miners (Miner A and Miner B) come up with the solution at the same time (almost same time) for a block, and they publicly announces their solution. Then, some miners get first the solution of A , later they see B has the solution as well (just opposite happens to some other miners, they get B first). So, the miners who saw A first starts working over A's solution for next block and saves other branch of B if it becomes longer. Now , tie will be broken when next proof of work found, and miners were working on other branch will switch to the longer one. Now, I have few questions:

What will happen to transaction records which were stored in the rejected branch?
Will there be any transaction records at all for both block branches?
(then I suppose, new transaction records will be stored on last
block before the branch).
What will be the scenario of coinbase generation? if A wins, A gets the coinbase, later transactions
should be stored in A's generated block. But, already solution of
next block(Proof of Work) on the branch A is found. So, new
transactions will be stored on next block (lets say generated by
C..C gets the next coinbase). Is that means, there will be only one
transaction record (coinbase) in the block generated by A?

This process, generally know as forking, creates two parallel chains that are incompatible, that is, there will be some transactions that will be valid against one chain but are not valid against the other.

If there are parallel branches, a miner might keep track of both of them. Once a chain is rejected, transactions in that chain are checked against the accepted one. Incompatible or duplicate transactions are simply discarded, while the remaining can be held over to go in the next block (or blocks as there might be too many transactions for just one).
Transaction records will remain in-tact for the accepted chain, but records for the rejected chain will be merged in to the old branch as described above. It would be impossible to attach these transactions to the final block before the branch, so, they are kept around by miners and put into the block chain as normal.
There might be a bit of confusion here... once a block is mined, it can't be changed, so it's impossible to store further transactions in that block. Furthermore, this block will have exactly one coin-base transaction. Any transactions that happen after it is mined will each be stored in subsequent blocks that follow it, but each of these blocks will have exactly one coin-base transaction, as is specified by the bitcoin protocol. So yes, there will only be one coinbase transaction in the block generated by A.

There was an edit that added that coinbase transactions can't be spent until after 100 confirmations. I don't believe this to be true, nor can I find any evidence. Also, this information seemed extraneous to the actual answer. Thanks for the spelling correction on "mined"; however.

Coinbase transactions indeed produce "immature coins" which can only be spent after 100 confirmations. You can read about it here: What was the goal of creating the feature of immature coins?

What will happen to transaction records which were stored in the rejected branch?

It depends. Other nodes will look at the rejected branch and try to include the transactions in future blocks, according to these rules:

Duplicate transactions are discarded.
Transactions that conflict (i.e. because of a double-spend attack) are discarded.
The coinbase is never kept.
The transactions must meet normal fee requirements.


text:
How to move Bitcoins from desktop wallet to mobile wallet?
I have Bitcoins on my desktop wallet client.
And i now have the Bitcoin Wallet by Andreas Schildbach installed on my Android device.
IS it possible to move the desktop wallet to Android wallet?

If you want to move Bitcoins in the sense of a wallet command it would require some more technical integration.
However, the easiest thing is to scan the QR-code of your Android mobile wallet with your webcam. I use QuickMark for the scanning. Then you can simply copy paste the Bitcoin address to your desktop wallet and send Bitcoins to your phone via the network.

Just to be clear, when you send bitcoin from one address to another via the network, you will also pay a transaction fee.

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


text:
What are the most popular CPU/GPU miners with scrypt-jane support
There are a few github projects, but it doesn't look as though there's a 'mainstream' option with good support for varying protocol. Is there any one most popular?

There is a working version of cgminer that supports both scrypt and scryp-jane, available here:
https://sites.google.com/site/rmdavidson/

This could be more useful as a comment.


text:
Who gets Bitcoin transaction fees?
Whenever I send bitcoins from one wallet or one exchange to the next there is always a fee. This makes sense with the exchange sites, they are just collecting the fee so they can make a living. What about the open source wallets that I've installed on my computer?
Surely, nobody is collecting my bitcoins because my transactions are too long! So, is the "fee" part of the Bitcoin algorithm? Do the coins that are confiscated in the fee go to Bitcoin miners?
Also, when does the fee start? I noticed, if I send like 0.05 bitcoins there is no fee, but if I send 0.1 bitcoins there is a fee.
What if I just sent 0.05 bit coins twice? Or is it if they are in the same block I will get a fee, so I'd have to send them twice (and 10 minutes apart)?

Reading this now is a hoot, back in 2013 you could actually do no-fee transactions when transacting small enough amounts... miners were just generous I suppose? Lol (Was probably in reality the GUI of the wallet I was using just truncating to 0, no way to really 'go back' and check now though...)

The fee goes to the miner who mines the block that includes your transaction. The fee is based on the size (in bytes) of the transaction and the age of its inputs (how long ago the coins spent were received).
Transactions get big if they have to "pull in" a lot of outputs from previous transactions and that raises the fee. So if you got a lot of small payments and then try to make a large payment, the transaction will be expensive because it needs to gather all those small payments.

Ah! Cool! Makes a lot of sense now! Now as for the "blocks" I heard that it's like x bit coins are given every 10 minutes, and then it will be a halved every 4 years until it runs out... I'm assuming that's talking about new bit coins being created? Once fit runs out in 2038 or whatever the date is will miners still be mining the fees that transactioners are charged?

@AlbertRenshaw: Assuming nothing changes between now and then, miners will continue to mine after 2038 for the transaction fees. There's a chance this will be changed by then, but it's very small. (Basically, pretty much everyone would have to agree to change it, and that would only happen if things were somehow very broken in ways we don't expect.)

So does mining actually accomplish something other than distributing the currency while it's still being created? What exactly is the purpose of mining after 2038? I like I know that you can mine for the transaction fee coins but why would bit coins be programmed to do that? Why not just make mining obsolete by then and get rid of transaction fees? Or does mining have a greater hidden purpose than just getting people to collect coins in a fair manner?

@AlbertRenshaw: Without mining, there would be no way to know which transactions were valid. There would be nothing to stop someone from spending the same bitcoins more than once.

I'm a bit confused by this answer. Plz help me understand :) So if I'm not mistaken current block reward is 12 BTC per block. Transactions are not required for mining. So if there were no transactions miner would still get his 12 BTC. Does the miner get 12 BTC + transactions?

@AlexVPerl That's correct.

From the Bitcoin.it wiki:

Transaction fees are voluntary on the part of the person making the
  bitcoin transaction, as the person attempting to make a transaction
  can include any fee or none at all in the transaction. On the other
  hand, nobody mining new bitcoins necessarily needs to accept the
  transactions and include them in the new block being created. The
  transaction fee is therefore an incentive on the part of the bitcoin
  user to make sure that a particular transaction will get included into
  the next block which is generated.

http://en.bitcoin.it/wiki/Transaction_fees

The client might send one transaction for free but then for the next transaction (even if it is for a smaller amount) the client might show that a fee is required.  This is likely due to the makeup of the remaining coins in the wallet.  After your first transaction, any change that was made gets sent back to you but that becomes a "newly received" coin.
To the network, if that second transaction includes this newly received coin that would look the same as a transaction made by someone trying to harm the network.  That type of harmful action tries to re-spend the same funds over and over but without paying a fee.
So just like how there might be a candy dish on a receptionists desk and you are free to take one doesn't mean you are free to take all the candy from the dish.
That's the same approach here.  The client will let you spend coins that have some time passed (i.e., were not just received) without having to pay a fee.
If your coins are instead being re-spent within a short amount of time (i.e,. same day), then the presumption is that you could be harming the network therefore a fee is required to prevent that activity.  If it was a transaction being made without the intent to harm the network, then requiring a small fee shouldn't be that much of a restriction.

I do think, however, that the above quote can be confusing to users. Yes, the protocol says that fees are entirely optional. However, the standard client does enforce minimum fees on transactions that are unlikely to confirmed otherwise. (For all of the characteristics you point out: small amounts, many inputs, new inputs, low priority.)

However, the longer the transaction waited to be confirmed, the higher its priority will get, right?

But the client will eventually drop a transaction that doesn't confirm and a certain amount of time has passed, regardless of its priority.  So if a transaction hasn't confirmed within a day, for example, it will likely get dropped.  That's why the client will re-broadcast a transaction if it sees that it isn't getting a confirmation.

It is also important to note that if the inputs you are sending in your transaction are older then there is a greater chance they won’t require a fee. Old coins means coins that haven’t been moved for a long time.
Additionally, most times you won’t have that much control over whether your transaction requires fees or not. Your Bitcoin wallet will usually make the optimization of inputs for you so you will avoid fees when possible.

Hey, sorry to be the one to disagree again, but selection by priority had been losing ground to selection by fee for a while, and has practically been discontinued since Bitcoin Core v0.12.0 turned it off by default in February this year.

No worries. I welcome corrections so that the community if not given incorrect information.  I thought that this selection by priority is still in existence, and is rumored to be defunk in Bitcoin Core 0.13?

As far as I remember 0.12.1 and 0.13.0 didn't change anything in the default behavior of the miner's transaction selection, except for adding the Child-pays-for-parent policy. While the code wasn't completely removed in 0.12.0, I'm almost certain that miners have stopped using priority by now. I've asked a follow-up question here though: Are any miners still considering priority in their transaction selection?


text:
How can I use Bitcoin to send a remittance payment to someone non-technical?
The existing remittance methods such as Western Union are pretty straight forward for the recipient ... after being notified, show up at any agent location, show ID and/or give a secret code and collect the cash.
Assuming the remittance recipient is not technical and today needs only cash, not bitcoins, is there still a role for Bitcoin with this type of need?

One way to do this is to perform a three-way transaction where the person sending the remittance (the bitcoin seller) transacts directly with the person buying bitcoins in the remittance destination country.  The cash being paid for the bitcoin transaction is simply just being handed over to the family member rather than to the party selling the coins.
Because there are a number of risks with person-to-person trading, those risks can become even greater when the two parties are trading remotely.  For this reason, a trust history will help lessen the risk.
LocalBitcoins maintains a directory of those willing to meet face-to-face and pay cash for bitcoins.  They also have a method called "LocalBitcoins Transactions" which is simply an account-to-account (A2A) transfer method so that the buyer of the coins doesn't need to wait for a Bitcoin payment transfer
to receive confirmations.  Additionally, those bitcoins can be released and the buyer doesn't need wi-fi or any other network communications other than mobile phone or SMS/text messaging when completing the in-person transaction.
Here would be the steps:
1.) Bob, located in the U.S., wants to send $200 worth of value to his mother who is located in Cape Town, South Africa.  Bob looks through the ads on LocalBitcoins and finds a buyer offering to pay a fair price and has no complaints showing in the trading history. Bob places a sell request in response to the buyer's ad and funds the transaction with the amount of bitcoins.
These coins are not sent to the buyer, but simply are reserved for this specific transaction.  Either Bob or the buyer can cancel the transaction and the Bitcoin funds are returned to Bob.
2.) Buyer contacts Bob and arranges the time and place to meet.  Bob explains the three-way transaction and how the cash will be picked up his mother.  Buyer agrees to this approach.
3.) Bob provides instructions to his mother to meet the buyer at a certain location and time.  Bob's mother needs to only bring her mobile phone.
4.) Bob's mother arrives at the buyer's location and notifies Bob that she has arrived and that the buyer is there and has the $200 worth or Rand in cash to pay for the transaction.
5.) Bob releases the bitcoins that were reserved for the transaction.  In return, Bob is given a "verification code".
6.) Bob tells the buyer (either in a text message or by voice) the verification code.  The buyer now can trust that the bitcoins were transferred and hands over the cash to Bob's mother.
7.) Bob's mother notifies Bob that the $200 worth of Rand in cash was received.  Bob uses the LocalBitcoins reputation tracking to leave favorable feedback for the buyer, and the buyer does the same in return for Bob.
The transaction has then concluded.  This transaction can be concluded at a lesser cost than the Western Union transaction.
Some buyers will even offer to do the traveling to deliver the funds in-person directly to the remittance recipient, without having to arrange a meeting.

Depending on which country you are situated in there are a few options which would require no effort from the non-technical side.
1) Services like Bitwala- You pay them in Bitcoin and they will make an ordinary local bank payment to the receiver
2) Purchase Bitcoin yourself and use a peer-to-peer trading platform such as LocalBitcoins to sell the Bitcoins in the receivers country and send the funds straight to their bank account.


text:
How are offers matched up on Ripple trades?
I'm trying to better understand how buy and sell offers work on the Ripple network.
Let's say Alice creates a new Ripple currency, calls it XYZ, and describes it to her friends Bob and Carol.
Bob loves the new XYZ currency.  He submits an offer to buy 1 XYZ for 3 XRP.
Carol merely likes XYZ.  She offers to buy 1 XYZ for just 1 XRP.
That's the set up.  I'm wondering what happens in the following cases...
What if Alice offers to sell 2 XYZ for 4 XRP?  Will the ripple network transfer 1 XYZ each to Bob and Carol?  Or, must Alice wait until someone offers to buy exactly the number of XYZ she is selling?
What if instead Alice offers to sell just 1 XYZ for 2 XRP?  Only Bob's offer of 3 XRP meets the price. But will Bob spend just 2 XRP (what Alice asked) or 3 XRP (what he offered)?
Finally, what if Alice offers to sell just 1 XYZ for 1 XRP? Will she end up with 3 XRP from Bob, 1 XRP from Bob, or 1 XRP from Carol?

Offers are always filled best first. Among tying offers, the one placed first is taken first.
Once they're placed, offers are always taken at the rate they were placed. Offers are always placed at their original rate, regardless of what crossing offers they take.
When an offer is placed, any crossing offers (existing offers in the other direction that can satisfy all or part of the new offer) are taken. It is up to the person who placed the offer whether counter-offers that tie their rate are taken.
The difference between a "buy" offer and a "sell" offer is only how the offer is placed after crossing offers are taken. For example:
If there are no crossing offers, there is no difference between an offer to buy 1 XYZ for 1 XRP and an offer to sell 1 XRP for 1 XYZ. But ...
If you place an offer to buy 1 XYZ for 1 XRP and crossing offers allow you to buy .5 XYZ for .1 XRP, the remaining offer will be to buy .5 XYZ for .5 XRP. (So, when/if your offer is fully consumed, you will buy 1 XYZ for .6 XRP.)
If you place an offer to sell 1 XRP for 1 XYZ and crossing offers allow you to sell .1 XRP for .5 XYZ, the remaining offer will be to sell .9 XRP for .9 XYZ. (So when/if your offer is fully consumed, you will sell 1 XRP for 1.4 XYZ.)

Wow.  I'm sure the answer to my question is in there somewhere.  I'm trying to grok.  What exactly is a "crossing offer"?  Is it one that's already in the ledger when my offer is placed?

A "crossing offer" is an existing offer in the other direction that can satisfy all or part of the offer you are placing.

Forgive my density.  You said "...offers are always taken at the rate they were placed. Offers are always placed at their original rate, regardless of what crossing offers they take." Later, you describe a scenario in which a buy offer is consumed for a more advantageous rate, and then same for a sell offer.  What am I missing here?

In those cases, the offers aren't being taken, they're being placed. They are taking existing offers, which they take at the rate at which those offers were placed. "Once they're placed, offers are always taken at the rate they were placed.

OK. I think I see the light.  A crossing offer is chronologically first, right?  So when I ask " will Bob spend just 2 XRP (what Alice asked) or 3 XRP (what he offered)?"  It is the person who offers last who gets the most advantageous rate.  Please correct me if I'm wrong.  And thanks for the explanations.

Correct. Crossing offers must already be on the books when your offer is placed and they affect the way your offer is placed. (If they can consume the whole offer, then no offer will be placed.) If they permit you to consume part of your offer at a more advantageous rate, then you get to do that. But once your offer is placed, it can only be taken at the placed rate.


text:
Is there a chart that shows the breakdown of the protocol versions in use?
Modern clients broadcast the protocol version.
A snapshot of the data summarizing the numbers per-client occasionally will appear, but I'm wondering if this info is published periodically or is otherwise publicly available on-demand.


text:
Are there any pools or large miners running "child pays for parent" patch?
A feature available through pull #1647 gives the recipient of a transaction a method to help get a transaction to confirm.
This feature is called "child pays for parent", and what it means is that the recipient of a transaction can create a new transaction using funds from the unconfirmed transaction, but any fee paid would help get both transactions confirmed.
A scenario where this is useful is where a merchant requires that a transaction have three or six confirmations before the item will be shipped out, but the payment the customer made ended up being a low-priority transaction due to it including many Bitcoin "dust" inputs.  The merchant then creates a spend transaction using the funds received but pays a fee that will encourage miners to include both transactions.
Since this feature is not in the Bitcoin-Qt/bitcoind client, only miner pools that have a custom client that includes this pull will consider the fee paid by any child transactions when determining if a transaction should get included into a block.
Are there any miner pools or large solo miners who are running with this feature?

"Replace by fee" is another method increasing the priority of a transaction, but in this instance it would be the sender who submits a later transaction with a greater fee.  No miners or pools have claimed that they have implemented this patch.  More info: http://bitcoin.stackexchange.com/questions/10733/what-is-replace-by-fee

According to an offshoot reply in bitcoin-talk it appears that the only mention of this protocol comes from Luke-Jr on Github.  Another topic on bitcoin-talk mentioned that his pool, elegeius, implements this patch.
https://bitcointalk.org/index.php?topic=173169.0
On the eligius FAQ page http://eligius.st/~gateway/faq/following-applies-transactions-being-processed-our-blocks
It mentions specifically = Transaction processing/priority contracts are available (talk to Luke-Jr).


text:
Why is the hashrate getting so high?
The Bitcoin hash rate is MASSIVE right now.
What exactly causes the hashrate to increase?

The hash rate doesn't really change how fast transactions are processed.

@NickODell Thanks! It seems I have misunderstood how processing speed works then. What does a higher difficulty do then? I was under the impression it makes blocks harder to process and therefor transactions take longer.

Blocks are created every 10 minutes on average. If blocks are found faster than that then the difficulty of increased to get the average back to 10 minutes. For practical purposes the 10 minutes average can be considered a constant.

Hey Albert, as the above commenters have explained, the title of this question and the topic asked about in its body are completely unrelated. Could you please edit the question to clarify which of the two topics you would like to get answered here? Please ask the other question as another post instead! I'm putting this on hold as "Unclear what you're asking". This doesn't mean that we don't want the question, just that it isn't clear in its current state. Please edit it and then flag it for reopening.

@Murch Thanks for the respect. I've edited the question

Miners are competing to find valid blocks because each block allows the successful miner to collect a mining reward. The mining reward consists of an amount of newly generated coins as defined by the reward schedule (currently 25 BTC per block) as well as any transaction fees attached to transactions they confirmed with the block.
At ~$400 per BTC, this values a block reward at approximately $10,000. Blocks are found at about 10 minute intervals, valuing the block rewards each day at about $1.4 million.
 As the hashpower of your equipment in relation to the network's total hashpower determines the likelihood of you succeeding at finding the next block, miners invest in better equipment, which in turn creates a market for manufacturers to produce such.
Over the past years, mining hardware has progressed from CPU, to GPU, to application specific chips (ASIC) that can exclusively perform the computations required in Bitcoin mining. Back in 2015 this specialized mining equipment pretty much caught up to the technological state of the art, as the first 14nm chips were produced.
Altogether, the race of ASIC manufacturers to provide the fastest mining equipment and the miners to deploy the same has built up the networks hashrate to an impressive 1.4 exahashes per second, which is about a 50,000x increase since the about 21.6 terahashes per second when the first ASICs were delivered in January 2013.


text:
What happens if your transaction is never confirmed?
If I have a low amount and don't include a fee, the transaction takes forever to get confirmed. What happens if it never gets confirmed? Can the wallet that I sent it to still spend the money?

If a transaction goes unconfirmed for too long, it will eventually disappear from the network.
Most clients will remove it from their pool of unconfirmed transactions at some point. When most clients have removed it, you can go ahead and send the transaction again, this time with a higher fee. There's not a precise time when the transaction will disappear from the network, it could be days or up to a week. This is why it's always recommended to set a transaction fee.
The wallet that you sent it to cannot spend it because it's not confirmed. So you have to wait until it disappears from the network and send an entirely new transaction.

reason i'm being downvoted?

My bad, it wasn't intentional. Managed to hit the down arrow instead of the up arrow. :(

In my case, the transaction I have: 783c97edc537be3302a0860ac4da00e3291c5d4b44fc03c25023f3b6794d40f3 will never be accepted by the payee because I used Replace-By-Fee and for security reasons they don't accept payments of this sort.  Does this mean that the fate of my transaction is as outlined in the above answer?

Will you get your coins back to your wallet if the transaction "disappears"?

Your client will have this marked as spent and will prevent you from sending any unspent coins included in the transaction while continuing to try to broadcast the original transaction. There is an easy solution, though.
You simply need to dumpprivkey and add it to another client, where you can send the coins from this address to another, effectively creating a double-spend permanently nullifying the original transaction.
Instructions on how to export and import private keys can be found here: Using dumpprivkey to make a paper backup
Additionally, blockchain.info (and mtgox) allow you to import private keys which you can spend from your web wallet.

Whether a sender and recipient can rely on a transaction is a probabilistic matter, but a transaction's state is binary in regard to the current chain tip. Either, the transaction is confirmed and the money has changed hands, or it's unconfirmed and the money still belongs to the sender's wallet.
Thus, if a transaction is never confirmed, the money is still the sender's. Since this question was asked, the block space demand has increased, and most wallets have improved their tooling to deal with stuck transactions. For example Bitcoin Core added the rpc call -abandontransaction and the startup option -zapwallettxes. Bitcoin Core 0.14.0 added opt-in full replace-by-fee (RBF) support, which is used by default since 0.16.0. Electrum had added Opt-in RBF even earlier.
However, one thing that you need to keep in mind is that any signed transaction remains valid until at least one of its inputs is spent. When the fee levels eventually drop back to lower levels, your transaction would still get confirmed if anyone rebroadcasts it. Therefore, after abandoning a transaction, you must make sure that you spend at least one of the abandoned transaction's UTXOs to invalidate it.
Also see this related question: Why is my transaction not getting confirmed and what can I do about it?

No need to worry.
I made 2 consecutive transactions (real network 'mainnet') of values 0.04BTC each. The fee for these transactions were 10 Sat/kb avg.
The transaction was never confirmed and after a week, I started to work on regtest mode, I saw those transactions were removed from blockchain and the main account has all the funds.
I do appreciate blockchain, and now I play around only with regtest well before going to mainnet.
Average transaction fee can be found here
https://statoshi.info/dashboard/db/fee-estimates

This is bad advice. "Not worrying" about a transaction that never confirmed means that the recipient can potentially collect it after the sender repeated their payment using other inputs. Please see my answer for an explanation of the issue.


text:
How does the rate of getwork requests correlate with the hashrate of a miner?
In a setup where a standard bitcoind serves full difficulty targets to some mining nodes, how can I calculate the hashrate of a mining node from looking at the rate of getwork requests? Does this depend on the used mining program or the used mining extensions?

Why would you want to do something like that? If you want to minimize the amount of shares sent, you can just increase the difficulty by some factor, rather than giving full difficulty and using getworks as a measurement. Your solution could potentially lead to exploits where the miner would send more getwork requests while not processing them all.

Thank you for pointing that out. I understand that this question is of little importance for practical implementations. It does however help to better understand the getwork mechanism. I was experimenting with a local setup and was wondering about the exact relationship.

The standard getwork protocol forces the miner to send a new request every second. This means that if a miner takes longer than 1 second to check all nonces in a given getwork (2^32), it will be making a new request before it checks all values in a given request, thus giving you 1 getwork request per second regardless of the hashrate.
If the miner can solve the getwork faster than that, it would be making requests more often. In theory, you could use this formula to calculate the hashrate:
Hashrate = noncemax/time
Where time is the interval between the getwork requests and noncemax is the size of nonce field (2^32). However, this assumes no time delay due to the network lag and so forth, so it's an ideal scenario. Moreover, some miners discard unfinished work after submitting a share, so it would appear they are doing more work in your configuration than they actually are.
If you intend on using getwork extensions, specifically noncerange and rollntime, you could calculate the hashrate more accurately. Noncerange would change your noncemax to whatever size you set, and rollntime would allow you to measure time intervals greater than one second. However, not all miners support the extensions.

Thank you for this explanation. In case anybody wonders about the same thing: in my local setup your formula results in hashrates which are consistently about 36% above the values I get displayed by cgminer. I am looking at various hashrates, ranging from (according to cgminer) about 600Mh/s at 5.23 seconds between getworks to 1700Mh/s at 1.86 seconds between getworks. I'm assuming this is due to the effects you mentioned. Thanks again!

Getwork is old. Could you discuss getblocktemplate? thanks

@Geremia Create a separate question and someone might elaborate.


text:
How long does it take to propagate a newly created block to the entire Bitcoin network and why?
Once a new block has been created, it is propagated to the entire network. I’d like to know how long this would take “on average”.
The propagation delay can be from several causes, and I’d additionally like to understand which one is the most significant:

As I understand, blocks are not propagated before being verified and accepted, so this should contribute to propagation time.
Network latency adds delay regardless of the block size.
Bandwidth limitations: large blocks will take longer to transmit, and nodes with many outgoing links will take longer to transmit the block to all their neighbors.
The network’s diameter.

If there are other causes of delay I’d love to hear about them.
Also, is anyone monitoring the network’s propagation delay, or any of the other network measurements I mentioned, and if so, where can I find statistics?

Possibly related - http://bitcoin.stackexchange.com/questions/1557/speed-of-operations-in-the-bitcoin-network .

If you know it's a matter of seconds and not minutes, does that answer your question? Or do you require a more accurate answer?

I think that your reasons for latency are correct, but it's really hard to figure out exactly how long it takes on average. Maybe a calculation involving the rate of orphan blocks and the Poisson distribution of a block being made during the time that a block is propagating around the network?

I think the time scale matters most, but I would be happiest to have it backed by actual figures.

lurf : that would require knowing things about the number of hashes each node is capable of. Wouldn't it?

In 2013, a paper by Decker and Wattenhofer answered the question with detailed measurements:
Decker, Wattenhofer: "Information Propagation in the Bitcoin Network" (2013)
At current block sizes, the size of the block (via transmission and validation) matters more than the delay in requesting or propagating packets through the internet.

According the paper 'Information propagation in the bitcoin network.' by Decker and Wattenhofer. The mean time for a node to see a block is 12.6 seconds, after 40 seconds 95% of the nodes have seen that block. This paper goes into some of the causes of propagation speed.
Block size is a dominating factor:

"For blocks, whose size is larger than 20kB, each kilobyte costs an
  additional 80ms delay until a majority knows about the block." -'Information propagation in the bitcoin network.'

Network Diameter does not appear to be that important as there are some very long shortest paths in bitcoin, but those paths only represent a tiny faction of the overlay network.
The bitcoin network appears to be extremely well connected for most of the nodes and with a long narrow tail very very poor connections. A block may take a long time, possibly minutes to reach the last 0.0001 percent.
Bitcoin Stats have a nice website that measures block propagation speed, it is based on the research of Decker and Wattenhofer.
It doesn't entirely agree with the Decker and Wattenhofer paper but it is important to understand that the bitcoin network is evolving at a breakneck pace. The bitcoin overlay network like the weather or the stock market, has the property that what was true yesterday might not be true tomorrow.
Bitcoin Stats says that for today, the mean was 5.1 seconds and 90th percentile was 22.4 seconds.

Unfortunately, Bitcoin Stats on 2017/04/05 stopped to provide daily snapshots on  Bitcoin block propagation speed. Is anyone aware of a new resource for this information?

Since the introduction of BIP152: Compact Block Relay, peers announce new blocks to each other in a shorthand that provides the header and only the list of transactions included in the block. Since nodes should have already learned about the majority of unconfirmed transactions, the receivers can rebuild the block from their mempool after retrieving the remaining few missing transactions. Compact Block Relay and other relay improvements have significantly sped up the block propagation, so that it now (June 2022) takes about 0.5 s for 50% and 2.5 s for 90% of the listening nodes to announce inventory of a new block.

via dsn.kastel.kit.edu/bitcoin/

In regards to monitoring the block propagation, you could deploy a largish number of nodes and log new blocks and a time-stamp to a DB as they come in.  There is probably some network size estimation requirements, but even a naive implementation should give you a good rough guess.

That's a possible way to go, but I'm guessing it would be hard to pinpoint the block creation time accurately enough. Most of the nodes you deploy will hear about the new block relatively late (assuming distribution is an exponentially growing branching process)

I was commenting in regards to the network measurements part of your question.  If you wanted such metrics, this might be a good way to go about measuring it.  It would not tell you exact block creation time, but it would give you upper/lower bounds on the network graph.  I assumed you wanted to measure the graph, not creation times.


text:
attempting to decipher a cgminer share.log
Here is 1 entry from a share processed in a feathercoin mine pool:
1367788723,accept,ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff070000,http://mining-foreman.org:11341,GPU1,1,b8641194d4b41e5dbc3fb6c68477f4754e01c6ef9b6f37a84d18807cd8060000,00000001579070dc02677a4a1a5f5cbe4bec71d2788472bf5d246f341124c04e9177b2ebc8b00d25c4c8245a44c6410eba2e122101ea1e4e1b1475ebebb8c0b25f3b74ec5186ccb21c0217a29b665700000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000

The cgminer readme describes the format as thus:
 timestamp,disposition,target,pool,dev,thr,sharehash,sharedata
Now as I understand it, there is a difficulty reported on the cgminer screen of 8.02M. A share that solves for higher than that qualifies as successful mine.

Question 1: How is that 8.02M number arrived at (current network difficulty 122.35060749)?
Q2: using the above data, how can I see what I did solve for?

You're making an assumption that your interpretation of 8.02M is even correct...? I can't make sense of share.log - have you looked at the source code? That might help you understand how the log is created.


text:
How could recurring payments be implemented?
I pay for some things on a regular basis. They generally fall into two categories:

Things I pay for or lose, eg a variety of online services (Spotify for example)
Things I'm legally obliged to pay because I've signed a contract (my mobile bill, for example)

In the first case, I suspect recurring payments could be handled relatively easily with upgrades to the original client interface. (Maybe it would be complicated by the desire to have a new address per transaction.)
In the second case, the other party has a stronger vested interest in knowing they will receive the money. Currently, with bank standing orders and direct debits, nothing stops me cancelling regular payments on my end. But companies who receive the payments rely in part on knowing I have to go out of my way to do that. They also rely on knowing that my wages likely go into the same bank account that their payment comes out of.
With Bitcoin, the situation is reversed. I have to go out of my way to make a recurring payment. Even I was using some online service ("Bitcoin bank"?) to make the payments, I'd still have to go out of my way to top up the balance.
With no changes to Bitcoin, if it became a dominant currency, I would predict an increase in the use of debt collection agencies to recover missed contract payments. Good for debt collection agencies, but it would drive up the cost of the services proportionately.
How could recurring payments be implemented in a mutually satisfactory way? Or is the current system inherently impossible to recreate with Bitcoin?

The "current system" has no support for recurring payments. How could paper notes be brought out of my physical wallet and driven to the store? This is the current system.

I think the most obvious way, though perhaps not the best way, is precisely the same way as is done with other currencies. If Bitcoins are adopted as a primary currency, they'll probably be used the same way other primary currencies are.
I am paid in dollars, but no actual dollars transfer unless that is absolutely required. Instead, I have a bank account denominated in dollars from which I can withdraw actual dollars any time I need. These same mechanisms could be implemented with Bitcoins. I could have an account denominated in Bitcoins, I could be paid in Bitcoins, I could pay bills in Bitcoins, but no actual Bitcoins need change hands except where the benefits of doing things that way outweigh the costs.

Does this rely on the customer's employer, the customer and the customer's service provider all using the same "Bitcoin bank"? If so, what about the possibility of people operating fractional reserve schemes if bitcoins are not actually transferred? And given the ease of making Bitcoin transactions, why would the end recipient not alway withdraw actual bitcoins?

It doesn't rely on the using the same bank, only on the bank's interoperating through a clearing house or the like. Yes, it does enable fractional reserve schemes, though that only works if there are people willing to buy shorts (because of the risk their value goes up, as I explained in the question on shorts). Why would the end recipient not always withdraw actual Bitcoins? The same reason people don't withdraw dollars -- that puts the obligation of managing and securing the funds on them, and it makes it harder to transfer them. So why would they?

I think the best way to implement this, without modifying the original bitcoin client, is running a separate server that constantly listens to billing requests sent through HTTP. The said server authenticates the requests and talks to bitcoin client to send the payment to destination address. I'm not sure yet if that can be totally secured and if someone has worked on it or not.
Furthermore, that additional server can be run on a local computer along with the bitcoin client so that users can broadcast "debit addresses" on their own, from their own computers, without relying on any hosted third party service.


text:
Is there a wallet app for iPhones?
I have an android phone as I can not afford an iPhone, but my friend has an iPhone. I am using Bitcoin Wallet from Andreas Schildbach and it's really easy. Is there something like that for the iPhone as we can't seem to find it?

related: What is a good resource to help newbies choose their first wallet/s?

A bit late, but you may find this article informative. Or look for others on the same subject, there was actually a news frenzy when this happened.
http://readwrite.com/2014/02/06/apple-blockchain-last-bitcoin-wallet-ios-app-store-iphone

Apple does not allow Bitcoin wallet applications on its devices.

Theoretically, a jail-broken iPhone should still be able to use any of the old wallets now kicked-off the app-store, right?

@JoePineda: I have no idea myself.

Unfortunately no apps are allowed. Best you can do is just use a web browser.


text:
Where can I see the "official" texts of BIP 100 and 102?
I only see BIP 101 officially at https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki.  Is there a reason that 100 and 102 don't show up here as well?  Couldn't they all just be listed as drafts?

BIP 102 was submitted as Pull Request, which you can see here: https://github.com/bitcoin/bitcoin/pull/6451
The latest draft of BIP 100 that I could find was here:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
but it might be out of date.


text:
Is it worth mining Litecoins?
Is it worth mining Litecoins and then exchange them for Bitcoins (because I am not sure if there will be space for more crypto currencies in the future)?
I can get about 25k hash/sec by CPU mining on my laptop, so this turns in something about 0.1 LTC per day which is 0.06 BTC per month (current exchange rate is 1:50). Does my approach make any sense or is there nowadays even any way to mine with everage/above average hardware?

I wouldn't suggest to mine with your laptop further more I wouldn't mine with a CPU any more. Your laptop can damage quite fast, because mining is very hardware intensive and it can overheat your components. After some time they will get damaged because they are not build to hold that power over a long period of time.
Your hashrate is quite low. With litecoins you are not going to come very far. You better use a graphics card (GPU) to mine litecoins or if you can't afford one, switch to another coin. See the links below for other coins and hardware comparison.

Cryptocoins
Mining hardware comparison

Thanks for answer, but still - is mining other currencies makes sense or is it a dead end?

@Petr it depends on your hardware. I would say it makes sense for some time, but when competition gets to high it doesn't. Electricity cost is the most important factor. If you don't make break even it doen't make sense

yes, I get this from technical perspective but I men rather market perspective - that means if I will let's say 1000 LTC next year, will there somebody who is going buy them?

@PetrMensik you never know. But the probability that LTCs rise in value is high I guess. It depends on the public exposure. The more people need it the more value it will have.

I think that is an excellent idea since the exchange rate between Dollar and Bitcoin is not as stable as the one between Litecoin and Bitcoin.
Many people have stated that Bitcoin will not be the only player in the future and I believe so. Some crypto-currencies might apply better for different markets in the future (Litecoin or Feathercoin might be more viable in 3rd world countries)

http://coinpolice.com/coin-comparison/   shows you which coin is currently the most profitable to mine. This is based off it's exchange rate to BTC. I highly recommend you try out some alt coins and dump them on exchanges. It's also fun :)

Hi Easycoind! Is this your site? If it is, please mention it, it is probably downvoted because people consider it spam.


text:
Why can't just any hash be used for a block?
disclaimer: I'm completely new at this, basic computer skills limited to GUI point-&-click

I took a look at how difficulty was explained, that it is "increased" by requiring the SHA-256 generation of blocks with more leading 0 bits, thus a string of 0s at the start of the hash which is more and more rare. Unless this has not been explained in a way I understand properly I think this means that you can cheat the Bitcoin difficulty and make blocks whenever you want? You simply need a custom SHA-256 hash generation program which non-randomly generates the specified number of 0s followed by a random SHA-256 hash shortened by the number of digits equal to the number of 0s in front, or simply generates a SHA-256 hash and then replaces the leading bits with 0 bits to meet the difficulty target thus forging a block hash. So from what I'm told it's A) easy to cheat; OR B) not well enough explained.
Isn't higher difficulty less and less secure a block hash because it is less and less random? Like if the difficulty were theoretically to rise high enough wouldn't it require the entire hash to be ONLY 0 bits instead of just the first part? Doesn't that ruin the security of Bitcoin the harder it gets? Hashes are seemingly easier to crack the higher difficulty is, easier to guess randomly and easier to forge. Couldn't I or someone else just spam strings of 0 and be rewarded with blocks just as fast as they could spam enough 0s to complete a hash?

I realize the answer to both questions is probably "no it's not like that" but that is the way it's been explained on the wiki and wikipedia and various other places.
I think it's more like, miners actually process transactions, not just (or maybe not even because those could be coming from both parties of the transaction) randomly generate hashes. Also there is probably some encryption involved which has not been properly explained and which when difficulty rises is added in many more multiple layers, encrypting and re-encrypting the already encrypted data.
The explanation about 0 strings also doesn't allow for a infinitely variable difficulty above 1 and for this reason it also doesn't seem to make sense.
I'd like more transparency in how the actual technical process is explained even if it's so long that I don't care to read it. It'd also be great to find links to the full publicly released SHA standards and documentation.
The more transparent the security is the more likely it is that someone will find a way to break or breach it if this is possible and while it is not desirable for that to happen it's better that it happen sooner rather than later if it can happen at all. Thus more robust standards blocking that sort of breach can be implemented.

ELI5: http://www.reddit.com/r/Bitcoin/comments/1ayf2d

Related: http://bitcoin.stackexchange.com/q/4775/153

As you expected, the answer to both is no :-)
For the generation of hashes: the miner attempts to find an input that, fed into a specified function, gives an output that satisfies certain properties. In Bitcoin the property is that the output is required to have a given number of zeroes. As your peers will recalculate the hash from the input you provide them with (the block) they will notice that the hash does not match the property and discard it. In fact the hash is not even directly relayed, but only the block from which the hash can be calculated.
For the target being unreachable, this question has been asked a number of times before. The gist of it is that H(block) < target. An increase in difficulty  reduces the number of possible solutions, but not the set in which you have to look for them, making it harder to find one.

Hashes are one-way functions.  sha256("DataGoesHere") --> HashResult
but given just a HashResult, you cannot then determine what was the value of the data that got hashed.
If you change even one bit of that HashResult (e.g., prefix it with a zero) then that data it corresponds to will be completely different.   So it is easy to get the HashResult.  It is essentially impossible to go the other direction and determine the value of the data.

A hash function is a mathematical function that is easy to perform in one direction, but for which there is no known way to easily perform in the other direction.
So, why don't you generate a SHA-256 hash and replace the beginning of the hash with zeroes? Because then it wouldn't be the hash anymore. It is (by definition of a hash function) easy for anyone to verify the hash.
Why don't you write a custom SHA-256 program that generates a hash that starts with the prerequisite number of zeros? Because (again, by definition) a hash function means that there is no way to perform the function in the reverse direction: you can't predict the result of the hash (or even part of the hash, such as the leading zeroes.) There's no way to write such a program, otherwise SHA-256 would be considered "broken" and wouldn't be used as a hash.
Essentially what mining is (as described in the linked article) is repeatedly hashing the block, varying only one field called the "nonce". A miner will try millions of possible nonces, hoping that the resulting has the required number of zeroes at the beginning.


text:
If Bitcoin is not stolen from an address for some months does it suggest that malware did not capture the key?
Some months ago, using bitaddress.org (offline but using my normal operating system), I made a key pair, copied the key and address to paper and stored a small quantity of Bitcoin at the address. Later, of course, the computer was again connected to the Internet, but the money has not been stolen.
Does the fact that probably no malware captured my private key those months ago suggest that the key is safe? Is it credible that malware would capture an address with small amounts of Bitcoin, but not extract it in the hope that later more would be paid into the same address?

There is nothing useful to be said about this. Not all malware searches for Bitcoin private keys, your computer may or may not be effected by malware which we do not know, indeed people could wait for a larger sum of money to become available at that address? Why just not use a new one and make sure that you do not have any malware installed?

I haven't mastered yet how to boot my computer with Ubuntu, so until I have done that the question is HOW insecure my existing storage is. With the present stored amount it would be a nuisance rather than a catastrophe if the money were stolen.

Ubuntu does not guarantee some magical safety. You can be fine on Windows too, and you can be hacked on *nix systems.

Well, I thought the idea was that if you booted up your PC from Ubuntu from a disk or USB, i.e. a system which has never been connected to the net, there is no chance of malware recording your keys. Am I wrong?

That seems reasonable. I don't think much can happen if you boot from something like TAILS, but then you have to redownload the whole chain every time you want to interact with your money. I think you'll need the files (at least the chain) on a USB storage device or something to prevent that.

It is a fallacy of the alternative disjunct to assume that your private key is in fact private, just because a potential other party has not used it: The two events "somebody has gained access to my private key" and "nobody has used my private key" are not disjunct.
If you are uncertain whether your private key has been compromised, you should move your bitcoins to a securely created new address.

I had a Blockchain.info account without 2fa accessed 5 months ago and the password changed. I'm still dealing with malware on that computer (which is offline) but strangely the BTC stays unspent. It's strange to say the least


text:
Are Bitcoin transactions really "frictionless" given confirmation time?
One of the big selling points for Bitcoin is that transactions are frictionless.  I understand this to mean that there is no middleman to take a cut.  However, there are 2 major frictions I see.
1) Clients are difficult to use for "non-techies".  This can easily be solved with better clients.
2) Transaction confirmation times can take 10 to 60 minutes.  This seems like major "friction" in that it prevents fast transactions - something most people are really used to with cash and plastic.
So is Bitcoin really frictionless?

Given that Bitcoin does have transaction fees (a middleman taking a cut), it certainly seems odd to call it frictionless. Who's saying it is?

related: How secure is zero confirmations?

Maybe because I'm a techie ... but i.e. mycellium seems very easy to use to me, I don't understand how it can be considered difficult to use for a non-techie.

I agree that better client software will inevitably emerge with broader adoption.
Concerning the amount of time it takes for a transaction to confirm, I think that you have to distinguish different scenarios in which Bitcoin is taking the place of the previous solution:

Payment in a store:

0-confirmation is acceptable for tiny payments like getting a sandwich/coffee.
Shops offering bigger purchases, say a jewellery shop or car dealership would probably use a payment processor that assumes the double-spend risk or wait for the first confirmation, not a big issue as there is more stuff to talk about anyway.

Webshopping (some examples)

To read an article for five cents or to pay to watch a movie ~> 0-confirmation is not an issue
Ordering food: Delivery will probably take longer than confirmation time anyway, so they will be sure you paid by the time they hand over the food.
Ordering physical goods: It's asynchronous anyway, a 10 minute confirmation time is irrelevant. So, you'll receive a confirmation of your order after ten minutes instead of immediately.

Then one should also mention other applications like (international) wire transfers, where 10 minutes for the first confirmation is magnitudes faster than current systems.
Altogether, the only point where I see any friction at all is "big purchases in a physical store", but even for most of those I would assess the friction to be negligible by just shifting the payment a bit ahead in the whole process, or there being a contract which could be used to follow-up on a failed payment.

For small amounts it's fine to accept unconfirmed transactions. You must really understand how the protocol works to be able to double-spend an unconfirmed transaction. I'm sure in the future hackers will build tools to allow for these sort of scenarios to benefit them, but also bitcoin clients will grow more secure and be able to diminish the propagation of a double-spend in the network, perhaps using trusted central entities that can propagate your transaction much quicker than the attacker could propagate their double-spend.
If I'm selling something for lots of bitcoins, yes I'd wait at least 10 minutes. But if you compare this to selling something for cash, you'd still need the time to sit down and count the money and make sure it's real and that you're not being scammed. This could take you more than 10 minutes and you'd probably need to do it in a private area. With bitcoin you can do it in any public place using your phone, and instead of using the 10 minutes to check whether you're being scammed, you can have a friendly conversation with the person you're doing business with.

I never think I heard "frictionless" - but I've heard "low friction" and "less friction".  Of course, your mileage may vary, but compared i.e. to credit cards (typically 2% transaction fee, chargeback risk many months after the transaction) or remittance businesses charging up to 10%, wire transfers taking several days ...
Due to the scalability issues I'm quite concerned the level of friction will grow a lot in the not so far future.  We're really privileged to be able to put a coffee transaction on the public blockchain, that probably won't make any sense in ten years time.  Then again, I'm sure other technologies (most likely bitcoin-based) like the lightning network will fix those issues, so we'll have really low friction again.


text:
Is it sufficient to backup the private keys of my android Dogecoin Wallet?
I installed the langhans Dogecoin Wallet on my android device and backed up my private keys.
Is it sufficient to backup the wallet to avert loss in case of loss of or damage to the phone?

Are you asking if backing up your private keys is sufficient enough?

I have removed your unrelated second question "I have also read about maximum amount of addresses - it looks I currently have one. Do I need more or what are the addresses good for?" Please ask only one question per post. Please feel free to re-post it as its own question.

Concerning your "number of addresses question" you might be interested in this post: Why does Bitcoin send the “change” to a different address?

The private keys are the critical thing and are in the wallet backup.  They're what is needed to transfer coins. If they become public (i.e. stolen), whoever has them can transfer your coins to themselves. If you lose/forget your private keys, you can't make transfers, the coins are worthless to you, effectively lost.
You can create multiple addresses for bookkeeping. For example you can create an address for client X and an address for client Y, your wallet will show how much each address has received.  Also, creating a new address for every transaction can somewhat anonymize the transactions.

so if I backup the wallet, import it on another pc, let the wallet sync again network this wallet should then also have the same state as the other wallet and have the coins. If something in this wallet changes, I have to make sure myself to keep the other wallet in sync. correct?

@stefan - yes and yes. The actual accounting is "out there" in the block chain. Wallets must sync to (read) the block chain in order to show you how much money you have.  It's not super critical that your wallets are always in sync, but understand they're only going to give you an accurate accounting when they are in sync.

and do I need to backup regularly? As I understand having the backup containing my private key would be enough. import it anywhere and let it sync and i have the coins there. So no need to backup every transaction or so because its in the chain. (just skip that having 2 different backup locations may be "safer")

@Stefan - you can have more than 1 private key, so whenever a private key is created the wallet should be backed up. Perhaps start another question to ask how/when private keys are created, different wallets do it differently.

If you already possessed some Dogecoins before the backup, restore it on another device and verify the amount displayed is the same. Else, get some coins, backup again and try restoring it elsewhere.
What exactly have you read about max. amount of addresses? Theoretically you can have as many addresses as you wish, though in practice the performance of the wallet will degrade the more addresses you have - the exchange Cryptsy was bitten recently by this and they had to create another wallet.
The point of having multiple addresses, in Dogecoin as in every other crypto-coin, is to be able to more easily track who payed you: you can have one address to receive payments for your services, another for the goods you sell, yet other one for tips you may collect (from Reddit, or a blog or whatever), the coins you mine, the ones you buy, etc. Most vendors actually generate a new address for each customer to be able to easily tell each payment's origin appart, some even use a new one for each transaction.

authors: Михаил Карпухин


text:
A full/multi nonce range search or just a partial range search?
In a work, there are only two elements in the block header change between hash attempts. That is, NTime and Nonce. The miner starts the nonce search to get a valid share, and there are several possibilities:
1) In a single nonce range (0~2^32-1), the miner find a nonce which meets the requirement of the valid share, so the miner exits the nonce search for this work and submit the nonce instantly, and then get another work from the pool.
2) In a single nonce range (0~2^32-1), the miner find a nonce which meets the requirement of the valid share, then the miner record it, and go on the nonce search until the complete of the nonce range search, and after this full range search the miner submit the recorded nonces  and get another work from the pool.
3) The miner can't find a valid nonce after a full nonce range attempts, so it performs NTime rolling, and then start a new nonce range search, and also there are also some possibilities just like the above statements for the miner to finish this work and get another work from the pool.
Actually, my question implies another question, for a fixed work(except for the nonce), is it possible that more than one nonce can be found to get a valid diff 1 share?

1) In a single nonce range (0~2^32-1), the miner find a nonce which meets the requirement of the valid share, so the miner exits the nonce search for this work and submit the nonce instantly, and then get another work from the pool.

It doesn't, because the fact that you found a valid share doesn't mean that there's not another nonce that creates a share.

Actually, my question implies another question, for a fixed work(except for the nonce), is it possible that more than one nonce can be found to get a valid diff 1 share?

Between 0 and 2^32 shares/blocks will be found for every nonce range.


text:
Has anyone gotten rich mining bitcoins?
A number of questions on this site ask whether it's possible to make money mining bitcoins and the expected profits.  However, I'd like to know if there are real-life stories of people becoming wealthy solely from mining bitcoins.
It seems like mining bitcoins is, at best, a hobby that cannot make someone wealthy.

Perhaps define rich.

Good point. I suppose "rich" starts around being a millionaire, but I'd also be interested in hearing how common it is to make more than $100K USD.

It's way too late now though. It's awfully hard to make any profit at all mining these days because it's so popular.

If everyone reading this put $1000 into bitcoin when this question was asked, we'd all be rich by now.

I suspect that it is hard to find real life stories because the miners would like to remain anonymous. If you had a few million dollars in largely untraceable BTC, would you want to publicize your story and make it easy for the government to tax you?
But there's some very strong evidence to indicate that "getting rich" was very possible. One story that comes to mind is "allinvain" who posted a reasonable amount of evidence that 25,000 BTC that he had mined was stolen from him. So, even though allinvain didn't "get rich" in this story, it certainly showed that a solo miner in 2011 could be making tens of thousands of BTC, easily worth millions of USD in 2013.
If you look at the blockchain it is easy to find addresses used by miners in 2010 that have thousands of bitcoins in them. Just find a block reward and trace where it went to. Here is one: 1AvLeBnWbiBeCNHwLGtWEK9GSVug3RWWxt It appears to be an address where the miner collected his block rewards over six weeks or so. (I'll substitute a blockchain.info link when it is back up.) Perhaps this private key was lost, so we can't say for sure. But it's reasonably to think that this one account (worth about $400,000) represents only a few weeks of work for this miner. If he kept all of the BTC he mined in 2010, he is likely a millionaire. At least on paper.
In short, since mining was much less difficult several years ago, and the exchange rate has gone up so much in that same time period, it seems very reasonable to assume at least some of the serious miners from those early days have made a considerable amount of profit.

The 25kBTC theft is questionable and doubted by many - please make sure people know the whole story (and thanks for linking directly to the thread instead of a news "summary").

or they could just pay the taxes and have peace of mind and liquidity?

Here is a story published on Bloomberg Businessweek about "the millionaires of Bitcoin":

“I’ve got a friend who forgot he had his computer mining Bitcoins in
  his garage—he checked and it’s worth about $12 million today,” says
  Kenna, 30, who is chief executive officer of Tradehill.

The same article also mentions Yifu Guo, the founder of Avalon ASICs:

Yifu Guo was a digital media student at New York University when he
  began mining some of the first coins, occasionally cashing in a few to
  help pay his rent. After he recognized Bitcoin’s potential, he quit
  school and founded a company called Avalon, which sells hardware built
  solely for the purpose of mining Bitcoins.

(Not an answer to your question, but the article also mentions other people that made big money doing other business related to Bitcoin other than mining.)

The early bot-miners and current major pool owners are those with the major share beside those who stole or ponied significant amounts of bitcoin..

A botherder (see mariposa botnet for imagination)who mined back in 2011 and pushed ASIC like hashrates will indeed sit on a decent stack of coins and if solo mined the transaction fees. Dont need rocket science to figure that.
A pool owner who owns a major pool maybe makes a load off the transaction fees if kept.

My guess those are the guys with the big bucks.

Yes, many people became rich mining Bitcoin, but years ago. Today mining is for those with the resources to operate huge mining farms. Transaction fees are supposed to keep miners motivated, but I think significantly increasing transaction fees would kill the main advantage of Bitcoin (which is cheap transactions). I wrote an article about that a few months ago:
https://www.cryptocoinsnews.com/post-mining-bitcoin-collapse-sustainable-growth/

Yes. The problem is if one will remain rich. You can make money of the bitcoin speculation but you should sell it when production is getting near the end.

Yes, there are. Yesterday there was a story in Dutch newspapers about a Norwegian student who bought bitcoins in 2009 for 18 Euro, he forgot it then and recently found out that his investment has accumulated to 615.000 Euro. With much effort he found back his password. He sold 20 percent of it and from that amount of real money, he bought an apartment in Oslo

While accurate, the OP is asking for people mining. The Norwegian in the story has bought his.


text:
Can I earn transaction fees by running as a full node, verifying transactions, but not mining?
As I understand it, by running a full node (i.e. Bitcoin-QT) , I am helping confirm transactions and contributing to the Bitcoin network.
When transaction fees are offered, do I receive these, and if so, how? Or do I need to be a fully fledged miner?

possible duplicate of How do I set up my machine to process transactions and earn the transaction fees?

Nope, transaction fees of a transaction can only be collected by including it into a valid block. And to be able to include a transaction in a valid block you have to mine a valid block.

While running Bitcoin-qt it is true you are contributing to the Bitcoin network, but only in the sense that other peers can now download the blockchain using your bandwidth.  There are no transaction fees sent to anyone that is not mining.  Mining is the process which helps the network transact and thus sending balances from one account to another.


text:
Is it possible for more than 21 million bitcoins to exist if 51% agree?
One of the commonly cited advantages of bitcoin is that there's guaranteed to be only 21 million bitcoins.
However, my understanding is that the bitcoin protocol is patched by an opensource community, is it possible that the bitcoin miners could start using code that allows for more than 21m bitcoin?

It's funny how the three answers seem to disagree entirely: Maybe, yes, no. Semantics, really, though

Maybe. It would require a split in bitcoin users. Those who wanted the change could switch to a new version of the bitcoin software with the code changed to allow it. The problem comes from the fact that it would have to be a voluntary change. Some would want to change, others wouldn't, and this would split the bitcoin community. Any transactions that occur in the either chain wouldn't be reflected in the other. But any balance you had at the time of the split would be reflected in both chains.
It would be a matter of semantics on whether the new, modified bitcoin would even be considered the real 'bitcoin'. If the majority of the community thought it was an invalid change, then the new would take the role of just another altcoin and people probably wouldn't even call it bitcoin. If the majority liked the change, it's possible that the old bitcoin would lose value and be considered just another altcoin while the new version takes it's place (or even cease to be used at all). Or, it could be even and they could coexist, but that seems unlikely to me.
I don't think such a fork is something that the BTC developers would do to the community. Open source communities are generally afraid of forks anyway because they tend to kill projects by splitting the development team. Beyond that, doing so has the power to really lower the confidence in BTC as a currency. The people who already have coins would feel mistreated because the protocol change would mean the minimum value of their coins would be lower. It would essentially be equivalent to the gold conversion being lowered on the dollar during the gold standard.

Yes, and then bitcoin blockchain will have fork. Then the old bitcoin wallet (I use only wallet here because miners or pools have to run the wallet software and it is both a server and a client) won't accept the block generated from the new wallet. New wallets also won't accept blocks generated from the old one. And if the protocol is not upgraded or changed, such that blocks continue to be broadcasted to all bitcoin clients, but each side does not accept the blocks generated from opposite side of wallets. The transaction to a address of different wallet of opposite side will become un-spendable. For example, when you send money from a old wallet to a new patched wallet, the designated BTC address is valid so the transaction is allowed. But in the new patched wallet, the receiver won't never get the money because his wallet does not accept the block which contains the transaction. Even < 51%, this also occurs and transactions are allowed only in the same side of wallets.

No, because standard clients would reject these blocks, regardless of which chain is longest. Only miners and clients operating under these other rules would accept this blockchain. This is likely to never change with the standard Bitcoin client (and would have to be accepted, by clients upgrading to the new protocol), so the 21 million limit is secure against a 51% attack.

If >51% of miners accept new changes to the protocol, "official" bitcoin client can either implement their changes (>21 mln coins) or cease to exist.

@MaciejMączko not true. Those mining according to the old/"official" rules could continue with their own blockchain indefinitely. If only a few miners (say, 1%) stay on that chain, it could be terribly slow until the difficulty adjusts a few times, but it would not cease to exist.

Yes, I have exaggerated a little, but the official client will not be used anymore, since it will not be compatible with other clients in the network (majority rules, you know?)

Is answer actually 'Yes, for those clients and miners that are using the new version.'?

Yes, it is. However, like my link says, if you made such a change, it'd be so different from Bitcoin as we know it that I wouldn't call it Bitcoin.


text:
Is there a bitcoin robot?
Is there a bitcoin robot that can automatically trade bitcoin for USD?
I see that bitcoin rates fluctuate every day and has different rates at different exchanges, and it could be easily traded like other currencies.
So, is there a bitcoin robot, similar like forex robots?

I tried writing one in 2011-12.  I ended up doing a lot of volume, but I only broke even because of the commission.  I generated a lot of money for Mt. Gox though!
In general, writing an automated trading program is always going to be a difficult task, because anyone who can write a superior program can cut into the profits of the inferior program, which leads to a development arms race.  This is what some hedge funds do (not with Bitcoins), but any models they develop are only expected to make money for a short amount of time.
Even if someone released a high-quality open-source program, it would be difficult to make money by using it because so many people would run it.


text:
Can ripple currency units be integers?
I understand with Ripple that anyone on the network can offer their own currency.  Someone cited the example of airline frequent flier miles.
Airline miles, in my experience, come in whole numbers.  I.e. 2000 miles, not 1999.5 miles.
If I start trading miles on Ripple, someone could easily offer to buy or sell in fractional units.  So balances in ripple wallets could be 1999.5 miles, right?
Is there any way in Ripple to force the units of a particular currency to be integers?
I'm asking about what appears in the wallets.  I know that within the system the units are integers.  I.e. 1 XRP = 1,000,000 drops.  I'm asking about the balances shown to users in their wallets.

You can round down when processing orders and let your users know this.

As @JacobTorba says, this is what TTBit does with his DYM currency.

Instead of integers it would be better if each currency could specify their divisibility. I.e 1.0 for airline miles, 0.01 for USD, 10.0 for XAU from a gateway with only 10 oz bars, etc. However, I for one like the ability to have sub-cent accounting for my USD and other currencies. Probably better if it was an option on trade offers themselves for someone not wanting to get or give a fractional amount for a specific offer.

Gateways can refuse to issue or redeem fractional amounts and users can refuse to pay them. But there is no authority to say to someone "you may not hold a fractional amount of this currency". Nobody can stop you from holding fractional amounts if you wish to.