text:
What is a good mining pool/payout model for infrequent mining?
I usually mine only, when I do stuff using my PC so it is on anyway. So far I used Slushs Pool but they have a score based reward system, which seem to punish casual mining. If a long round ends >15 minutes after leaving the pool (due to shutdown the system) you'll probably get nothing at all. What are better payout models for the casual miner and what pools can be used?

There are multiple approaches to pooled mining, each with its own benefits and detriments. Assuming you are a dedicated miner who does not pool hop then the scenario you describe should be an "edge case" that should rarely if ever occur. That said, common payout schemes include:

PPS - Pay Per Share. Each submitted share is worth certain amount of BTC. Since finding a block requires  shares on average, a PPS method with 0% fee would be 50 BTC divided by . It is risky for pool operators, hence the fee is highest.
SMPPS - Shared Maximum Pay Per Share. Like Pay Per Share, but never pays more than the pool earns.
ESMPPS - Equalized Shared Maximum Pay Per Share. Like SMPPS, but equalizes payments fairly among all those who are owed.
CPPSRB - Capped Pay Per Share with Recent Backpay.
Prop. - Proportional. When block is found, the reward is distributed among all workers proportionally to how much shares each of them has found.
PPLNS - Pay Per Last N Shares. Similar to proportional, but instead of looking at the number of shares in the round, instead looks at the last N shares, regardless of round boundaries.
Score - Score based system: a proportional reward, but weighed by time submitted. Each submitted share is worth more in the function of time t since start of current round. For each share score is updated by: score += exp(t/C). This makes later shares worth much more than earlier shares, thus the miner's score quickly diminishes when they stop mining on the pool. Rewards are calculated proportionally to scores (and not to shares). (at slush's pool C=300 seconds, and every hour scores are normalized)

The important factor is that you avoid Proportional payout systems as they are vulnerable to pool-hopping so you will probably lose some portion of your revenues to hoppers on those pools. For your concerns, SMPPS, ESMPPS or PPLNS would be good choices, but there are other factors to consider and it is ultimately up to you to choose a payout scheme and pool that best fits your needs.

Having only an 5670, I received 0.0+0.0+0.0004 btc for mining 2.5, 3 and 4.5 hours. With increased difficulty this can be even worse. So much for the "edge case".

True, I hadn't considered miners so slow (or rounds so fast) that they may not submit any shares in a given round. Mr. Schwartz may be correct in choosing PPS for such a scenario. I suppose as someone pushing 3 GH/s I need to revisit my definition of "casual miner" before making a judgement call. Still, for anyone with even a single 5830 or higher my advice still holds.

See answer below--size of miner doesn't actually impact the fairness of score-based mining, only the variance.

It does if the size is extremely small. While CPU miners are almost nonexistent these days, mining at 1-10 MH/s only submits a share every several minutes. If a user has only a few shares per round their placement can make or break profits in any scoring method that involves time in its calculations. With a 5670 the OP should be pulling ~70 MH/s which is obviously above this threshold, but the lower your hashrate the more noticeable the effect can become. Better for low-hashrate miners to move to something like PPS and take luck out of the equation entirely.

Wow, I never imagined the models to be this complicated. I thought you're just ... getting paid your fair share of hashing power per X blocks.

@ripper234 Unfortunately the simpler models were also vulnerable to various forms of abuse, so they've evolved into more complex models to prevent such abuse.

@David - interesting. could you elaborate? Or should I open a new question?

@ripper234 It's more complicated than should be explained in a comment but if you'd like to open a new question I'll be glad to answer it.

I got ~80Mhash/s with XP, now it's ~75Mhash/s.

@David - here you go: http://bitcoin.stackexchange.com/questions/461/what-are-the-problems-with-naive-pool-sharing-mechanisms

I mine very slowly, faster than a GPU, but only about 26Mhash/s so I very much prefer the PPS method, however even that is luck based as all mining is.. as some times i might go 20 minutes without finding a share, while other times i get one every 5 seconds.

It's a common misunderstanding that score based reward systems like Slush's underpay infrequent miners.  While it's true that shares in a given round devalue if you mine towards the beginning of a round and then leave long before it finishes, you have to also take into account the fact that the length of a round is random.  So you have equal chances of arriving late in a round and having your shares worth more than they would have been by straight proportion, or starting out a round and having it find a block right at the beginning (making each share worth a lot more because there were fewer of them).  In the long run, these all average out perfectly.
The only circumstance in which you will be receiving less from a score based pool is if you consistently start out rounds but then switch to other pools when the rounds "take too long" for your liking.  You can't do this by accident.  It's a specific attack that we identified and analysed back in January, and unless you specifically program a miner that does this it's not going to happen consistently by random chance.
That said, there is a slight difference with the score based system for very low-capacity, infrequent miners:  increased variance in your payouts.  Sometimes they will be bigger than normal, and sometimes smaller.  Mathematically, it all ends up coming down to the fee you pay, but psychologically this might be hard to take as sometimes you will feel ripped off, while you might not notice that you also get lucky just as much.  So it might be easier on your brain to go with a pay-per-share system or similar, it just won't be easier on your pocketbook.
The biggest underlying problem with this is that you probably shouldn't be mining at all.  Even if you only use it when your computer is on anyways, a 5670 almost certainly draws more power when mining than you earn back in bitcoins, unless you're paying very low electricity prices (5 cents or less per kilowatt-hour) or using someone else's electricity (in which case all you're doing is taking money from them, not earning it).  Probably it's time to leave the mining to high-efficiency rigs located in very low-cost electricity zones.
For a complete analysis of different mining pool schemes, Meni Rosenfeld has written an excellent paper.

Flat pay-per-share may be best. These tend to have the highest percentage fees, but the payout is 100% predictable. There are a few PPS pools, such as abcpool.co and btcserv.net with no fee. The only thing they keep are the transaction fees, so your payout per submitted share is 50 divided by the current difficulty.


text:
Cryptocurrency with less deflationary properties
I wonder what is the benefit of having Bitcoin reduce the coins mined per block over time?
Suppose a slightly less deflationary growth scheme was possible (and keep other properties that make Bitcoin desirable), that might encourage more people to use it as an actual currency and less as a hoarding item.
For instance, can another blockchain-network be created that increases 0.5% the coins mined per X number of mined blocks?.

possible duplicate of What are the advantages/disadvantages of a continuously decreasing block reward compared to the current method?

I disagree, A duplicate should be a perfect duplicate. It's good with a big variety of similair questions for searchabillity.

sorry @ThePiachu but that is absolutely not a duplicate, if you read that question is about abrupt discontinuities in the deflation rate, not at all about the benefit of a deflationary mining rate itself

I believe that it's by design.
As others have stated, several other crypto-currencies have different inflation rules. I believe, however, that Bitcoin was designed with a fixed money supply to motivate early adopters to adopt the currency, thus bootstrapping it into existance.
One could argue that "it's not fair to late comers", but if it works (= it eventually gets millions of people to use the currency), then it was a good design choice.
It makes it relatively easy to reason about potential worth of BTC. The argument goes like this: "If there will only ever be 21,000,000 BTC, and some day 1% of the entire world be using it, then 1 BTC will be worth 1/2,100,000,000 of the world's 'value'. I better get me some of that BTC". This calculation does not depend on when exactly is "some day" - be it 10 or 100 years in the future.

It's technically possible to have a blockchain with any generation schedule, such as X% inflation per year or constant reward per block.
The main reasons for a schedule with an upper bound is:

The Austrian economics school, to which apparently Satoshi and a large part of Bitcoin's early adopters subscribe, says that the optimal situation is that the monetary supply is bounded.
If you want to have some long-term inflation you will need to choose what it is, and any choice will be arbitrary. "0% inflation" is a bit less arbitrary option to anchor on.
One of Bitcoin's key properties is that the monetary is supply is not manipulable, and it's perceptually easier to sell it on this point by saying "The protocol guarantees there will never be more than 21M bitcoins" than "The protocol guarantees that in the long term, there will not be more than 3% monetary inflation per year".

GeistGeld and SolidCoin offer block rewards that don't decrease over time, I believe. Bear in mind they also have other major differences to the design of Bitcoin though, especially SolidCoin (because it's not a community driven open source project).
The advantage of having a limited number of units is that it is a better store of value. On average, a unit of currency should only increase in value over time. Because we can break one bitcoin down to 8 decimal places (and further if necessary), there's no need to have it any other way.
When it comes to hoarding, the current exchange rate takes into account likely future increases in value (as well as potential risk of things like a collapse in value).
These questions examine the impact of hoarding/speculation on Bitcoin:

Does hoarding really hurt Bitcoin?
Does speculation hurt bitcoin?

It is hard to say what SolidCoin does "over time". They have been twisting around the rules quite a bit already.

Agreed. The FAQ does say "No maximum coin generation", but I don't find it to be very well written. It also says it has "a small inflation amount at the end which will increase value of each coin over time whilst providing economic liquidity". That doesn't make sense because inflation decreases the value of each coin over time.

source: Stack Exchange

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

authors: แล้วแต่จะคิด ชีวิตคนละเเบบ

sort: votes


text:
P2Pool crashes the Bitcoin client
I wanted to try out P2Pool mining, so I installed the newest Bitcoin (0.5.2, also tried it with 0.5.1).
Unfortunately when I start run_p2pool.exe it immediately crashes my Bitcoin!
My OS: Win7 x64
Any ideas?

Please drop by #p2pool channel on freenode IRC and the friendly folks there will try to help you out.

Could you post the specific error(s) you get? It's very difficult to troubleshoot via telepathy ;)

Before my edit, I read the title as "Something that P2Pool did made the Bitcoin market crash" :)

It seems I had to wait for my Bitcoin to fully synchronize with the network. After that it didn't crash any more.
IMHO bitcoin-qt.exe should not just crash in a case like this.

Did you report this as a bug in the Bitcoin bug tracker?  ( https://github.com/bitcoin/bitcoin/issues/new ).  p2pool shouldn't be able to make bitcoind crash, whatever it tries to do.  Rather than working around this by using a weird configuration we should attempt to fix the underlying problem.

If I try running p2pool while bitcoin-qt 0.5.2 is downloading blocks on linux, I see an exception in the p2pool output, ending with "p2pool.util.jsonrpc.Error: -10 Bitcoin is downloading blocks...".  If I run "bitcoind getwork" on the command line, I see: 'error: {"code":-10,"message":"Bitcoin is downloading blocks..."}'.  I guess the first thing I'd try if any of my computers had Windows on them would be to run "bitcoind.exe getwork" while bitcoin-qt.exe is downloading blocks and see if that causes it to crash too.

I wrote a solution to this problem two days ago:
How to use p2pool with an accompanying standalone bitcoind
(since the windows gui version of bitcoin 0.5.1 crashes frequently when used with p2pool)
Assumptions:
OS: Windows 7
Bitcoin: Latest stable release installed and working - http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/bitcoin-0.5.1-win32-setup.exe/download
p2pool: you'll be slightly off the beaten path with this
   configuration as you're specifying the bitcoin address to send
   generated bitcoins and not using the second bitcoin processes wallet

Download latest current p2pool code and extract to
"%programfiles%\p2pool" -
https://github.com/forrestv/p2pool/zipball/master
Download and install latest Python 2.7 (if you get 64bit, you'll need
64bit versions of the packages below) -
http://www.python.org/download/
Download and install python extension package twisted -
http://www.lfd.uci.edu/~gohlke/pythonlibs/#twisted
Download and install python extension package zope.interface -
http://www.lfd.uci.edu/~gohlke/pythonlibs/#zope.interface
Download and install python extension package pil -
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pil
Download and install python extension package pygame -
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pil
Open your Bitcoin GUI client if it is not running and generate a new
address, take note of the generated address and close your Bitcoin
GUI client
Edit your existing "%appdata%\bitcoin\bitcoin.conf" and unless you
know what you're doing, change what ever is there to this and if the
file does not exist - create it:
logtimestamps=1

Create the folder "%programfiles%\p2pool\bitcoind-data"
Create "%programfiles%\p2pool\bitcoind-data\bitcoin.conf" with your
 favorite text editor and populate it with this:
server=1
logtimestamps=1
port=18333
rpcport=18332
rpcuser=bitcoinusername
rpcpassword=bitcoinpassword
rpcallowip=*

Take note of the folder name of the latest current p2pool code - it
 is in "%programfiles%\p2pool"
Create "%programfiles%\p2pool\p2pool.cmd" with your favorite text
 editor and populate it with this:
@echo off
title p2pool
echo.
echo running p2pool ...
echo.
C:\Python27\python.exe "%programfiles%\p2pool\folder-name-of-the-latest-current-p2pool-code\run_p2pool.py" --net bitcoin --address yourbitcoinaddresshere --bitcoind-address 127.0.0.1 --bitcoind-rpc-port 18332 --bitcoind-p2p-port 18333 bitcoinusername bitcoinpassword
echo.
echo p2pool stopped.
echo.
pause

eg.
@echo off
title p2pool
echo.
echo running p2pool ...
echo.
C:\Python27\python.exe "%programfiles%\p2pool\forrestv-p2pool-4f6c2e2\run_p2pool.py" --net bitcoin --address 12uN6G1uAtn7G29qfTdLD9des4y63Whr61 --bitcoind-address 127.0.0.1 --bitcoind-rpc-port 18332 --bitcoind-p2p-port 18333 bitcoinusername bitcoinpassword
echo.
echo p2pool stopped.
echo.
pause

Create "%programfiles%\p2pool\bitcoind.cmd" with your favorite text
editor and populate it with this:
@echo off
title bitcoind
echo.
if exist "%programfiles%\bitcoin\daemon\bitcoind.exe" (set programfilesx86=0)
if exist "%programfiles(x86)%\bitcoin\daemon\bitcoind.exe" (set programfilesx86=1)
if %programfilesx86%==0 (goto :programfiles)
if %programfilesx86%==1 (goto :programfilesx86)
echo ERROR! bitcoind.exe not found in either "%programfiles%\bitcoin\daemon\" or "%programfiles(x86)%\bitcoin\daemon\" - giving up!
echo.
pause
goto:eof
:programfiles
echo running bitcoind.exe from "%programfiles%\Bitcoin\daemon\" ...
"%programfiles%\Bitcoin\daemon\bitcoind.exe" -datadir="%programfiles%\p2pool\bitcoind-data"
echo.
echo bitcoind stopped.
echo.
pause
goto:eof
:programfilesx86
echo running bitcoind.exe from "%programfiles(x86)%\Bitcoin\daemon\" ...
"%programfiles(x86)%\Bitcoin\daemon\bitcoind.exe" -datadir="%programfiles%\p2pool\bitcoind-data"
echo.
echo bitcoind stopped.
echo.
pause

List item
Copy blk*.dat from %appdata%\bitcoin to
 %programfiles%\p2pool\bitcoind-data
Run "%programfiles%\p2pool\bitcoind.cmd"
Run "%programfiles%\p2pool\p2pool.cmd"

You should now be able to mine on your machine to 127.0.0.1:9332 or to your machines IP on port 9332 on your LAN :)

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


text:
Why are companies selling mining hardware instead of using it themselves?
I'm not (yet) using Bitcoin, and I'm just approaching this world as of now.
I stumbled upon some merchants that sell mining hardware (with some GH/s). But I've yet to understand what they gain, apart from the upfront cash.
The reason one should buy mining hardware is, if i'm not mistaken, to "generate bitcoins", i.e. "generate money"; so, one expects to be able to have a return of the investment sometime in the future, so I guess that in some way my claim is correct (about "generating money").
But then, why don't the companies simply use their own hardware?

It's all about risk management.

It is not guaranteed that purchasing mining equipment will generate in its lifetime more than it cost to purchase. That depends on the future of BTC price and the difficulty, both of which are hard to predict.
Those who believe, for whatever reason, that it will indeed be profitable, will purchase devices. But most companies selling mining hardware are in the business of designing hardware, not of speculation and running datacenters - in terms of both risk profile and expertise. So long-term they should just sell the hardware.
It's worth noting that some companies do develop ASIC devices with the intention to use them themselves rather than sell them.

Companies that manufacture mining equipment don't just mine with their own hardware for a variety of reasons:

They may not be able to obtain low prices on electricity, making it more profitable for others to mine than for them to mine.
They may not be able to make use of the heat generated, making it more profitable for others to mine than for them to mine.
It's easier to get financing if you're going to make something you can sell.
They may prefer not to take the risk that mining will remain profitable.
The value of mining equipment depends on the value of bitcoins, which would be negatively affected by mining becoming too consolidated. So mining is more profitable if it's distributed.
It may be virtually impossible to mine profitably and they may be too smart to think otherwise.

http://arstechnica.com/gadgets/2013/06/how-a-total-n00b-mined-700-in-bitcoins/3/

In fact, if it's so profitable, why on earth is Butterfly Labs selling these devices? Why not rent a warehouse, fill it with miners, and make infinity bitcoins?
The answer is two-fold. First, BFL required a great deal of capital in order to design and manufacture the ASICs that power its boxes and then to assemble the miners themselves. This capital was provided in no small part by pre-selling the miners; hanging onto them to do some BTC mining with them is sketchy at best and at worst illegal. Plus, there are practical considerations: a giant BTC warehouse adds overhead costs, and I can't even begin to take a guess at the bookkeeping implications of warehousing capital like that.
However, the second reason is far more practical: bitcoins, for all their current value, are still speculative. A large amount of US dollars is a large amount of US dollars no matter which way you cut it. It can be readily exchanged for goods and services. Bitcoins themselves don't necessarily hold value, and it's difficult to exchange them in large quantities for an equivalent amount of dollars. So selling Bitcoin miners for dollars guarantees a certain number of dollars; investing capital into mining a truly large number of bitcoins might work well as a short-term hedge, but the value of the trade is utterly impossible to predict.
This, I suppose, is part of the nature of high-risk investments. But in this case, Butterfly Labs can simply charge whatever it wants for its gear in order to make whatever margin it deems is sufficient. Why bet on the future of a relatively new virtual currency that may go up or down when you can simply get a bunch of real US dollars?

In the gold rush the people who made the most safe/constant returns where not the miners but the people who sold them the shovels
i.e
BFL
AVALON
bASIC
The mining process for Bitcoin is going through a large upheavl/transition to a new tech platform due to the ASIC mining equipment
Everybody has been promised a lot of things with large sums of $$ paid up front with many a missed delivery time ranging in 3-6+ months late on what was promised
ASIC chips are refered to as unicorn blood..having said that the next 4-6 weeks will reveal a lot.
You must understand that BTC mining calculators
http://www.alloscomp.com/bitcoin/calculator
are based on GPU (or current tech platform) difficulty factors. If you put ASIC chips specs into these calculators expect to divide that figure by a factor of 20-40 due to what i believe an over capitalization of the mining process (IMHO)
I would wait at least 3 months until the market settles and the big questions regarding these products have been at least partly answered (It would take at least this long until we see 2nd batch's coming through of these units :D )


text:
Mining on Amazon EC2
Was there ever a time when mining on Amazon EC2 was profitable? When the difficulty was low, so was the exchange rate, so I'm not sure.

Sure there was, when mining-difficulty was very low. And the miners did not have yet implemented mining on GPUs.

Now, no. In the past before GPU mining when everyone was mining with CPUs the more CPU power you had the faster you could mine. The problem was that the exchange rate was so low that it wasn't profitable at the time.
If you had mined then and lost money you would have made up the difference at current market prices.

Yeah, but was it ever profitable at the current exchange rates?


text:
Hashrate required for Finney attack on SatoshiDICE
Say I have an address with 1000 different 0.01BTC outputs. I send all of the outputs (in separate transactions) to the 48% SatoshiDICE address. At the same time, I craft a transaction for each of the outputs that sends the money back to myself. Once I find out which of the bets succeeded, I start mining. I include the SatoshiDICE bets where I won, and I cancel the ones where I lost (using the conflicting transaction I generated earlier). So basically if I mine the next block, I cancel all the bets where I lost, and only keep the ones where I won. My question is, what percent of the network hashrate do I need to make this profitable?

I seem to recall hearing that mining clients may refuse to build on blocks that include a lot of transactions they haven't seen.  If that's true, then you risk having your block rejected and losing your reward.

The question is closely related, but this one focuses more on the hash-rate required.

There is no magic barrier above which you will make a profit, it's a tradeoff. The larger your hashrate the higher your chances of successfully completing the finney attack. The odds at SatoshiDice are a bit at your disadvantage, but in a system where you'd get back what you wagered in expectation you'd always make a profit.

Sorry, I meant over time, I should have been more clear. I know that for each individual one, it's random, like flipping a coin. However if you attempt this repeatedly, what hashrate that you need to make a profit?


text:
What is the longest firstbits?
What is the longest used firstbits? How could I find out? I think it would be two vanity addresses with the same prefix, yes? Anything longer than about seven characters for a firstbits would require a lot of computation.

No easy way to find the shortest, so it's not clear why you expect there was an easy way to find the longest, instead.

@Lohoris The largest problem is that if you say "the longest firstbits is 1aaaaaaaaaaa" then somebody with vanitygen will just try to make two vanity addresses that have more characters in common.

@NickODell: Unless the longest firstbits is already so long that finding a longer one will be computationally prohibitive.

Finding the shortest one unused is rather different than finding the longest one used, IMO.

related: https://bitcoin.stackexchange.com/q/3730/5406

I think I found the one with the longest firstbits
http://blockchain.info/fb/1234567891234567891234567891w

"Sorry this is is not a valid bitcoin address"

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


text:
How can I code a Bitcoin JSON-RPC "getwork" request in Java?
I'm not entirely sure whether to ask this question on Bitcoin-SE or Stack Overflow, but I decided to post it here due to the direct relevancy of the question to Bitcoin and the general prominence of programming experience I have observed on Bitcoin-SE. If Bitcoin-SE is the incorrect place to post it, I apologize in advance; I'm new to SE and this was my best guess.
I'm attempting, in order to better understand how Bitcoin mining works, to code a simple Bitcoin CPU miner in Java, which I have some but not much experience with. All the online resources on JSON-RPC implementation in Java I have found have either been out of date and no longer functional or incomprehensible for someone with limited Java experience. How, in the most simplistic way possible, would I code a JSON-RPC getwork request (to a pool server) in Java and correctly parse the output into the variables required for mining?

+1 This is the right forum to ask. (And bitcoinj would be a good place to implement this feature, not sure if they have it already).

@Thilo Thanks, glad I posted it in the right place. BitcoinJ implements a client-only node; it won't process RPC requests of any sort. Good idea, but I'm afraid it won't do the job.

It won't right now, but (at least) for an RPC client it should offer support one day (IMHO).

Sorry if the "client-only node" was misleading; that's just what's stated on their Google Code page. I looked through the documentation and found nothing whatsoever on RPC. I agree it should implement RPC client support, but that doesn't mean it will. In any case, it doesn't currently.

Yes, we can agree on that ;-) Please update this post with an answer of your own if you find out how to do RPC with Java (even if you have to hand-roll it with just the JDK libs).

Or you could use BitCoinJ.

The JSON-RPC protocol is very simple.  You POST to the mining pool (or the bitcoind client):
{"method": "getwork", "params": [], "id": "anything"}

and get back:
{"result": {"data": "hex bytes....", "target": "hex bytes...", ...}, ... }

You just need the first 80 bytes from result.data - you change the last 4 bytes (nonce) and compute the hashes.  Then, when you find a hash that is less than "target" (generally a hash with the high order 32 bits equal to zero), you call getwork again to report your hash (and earn a share in the pool):
{"method": "getwork", "params": ["hex-header"], "id": "anything"}

There a bunch on wonky byte-order encoding in the standard getwork call.  You'll generally want to reverse the bytes is each long integer (4 bytes) before hashing it, and do the same before reporting your found block back to the pool.  See the sample pyminer for a simple reference implementation of a miner (in python). Inside the Miner.work() function is where the magic happens. The work function takes two parameters: datastr, this is the value stored inside result.data and targetstr this is the value stored inside result.target.
One other thing - most pools require that you use Basic Authentication when you POST, so you'll need to include your username and password in the header of your request.

Take a look at the DiabloMiner source code (Java): https://github.com/Diablo-D3/DiabloMiner
It's a GPU miner, but it has the JSON-RPC getwork stuff you need.
After you get basic getwork going you may want to look at implementing extensions: https://en.bitcoin.it/wiki/Getwork

I have looked Diablo's code over; I was looking for something easier to understand. (Diablo doesn't comment at all, and I have little Java experience) If no one else pipes up, I'll go over that more closely and try to simplify it myself. Thanks for the suggestion in any case.

For everyone else, who stumble upon this question :
I've written a Java wrapper around the JSON-RPC provided by bitcoin/litecoin.
https://github.com/coding-idiot/Litecoin-Bitcoin-RPC-Java-Connector
It uses Htmlunit & GoogleGson and quite easy to understand and extend.

Looks good. Will be testing it


text:
Why does pool latency matter?
I often read about latency and ping.
I am programmer and I understand what latency and ping is.
But I do not understand why miner can't process block with certain delay.
Why do 10ms or 100ms matter?

Latency of connections between nodes matters when mining because, essentially, a valid block found that reaches the highest number of peers first wins that block height.
For example, if miners Alpha and Beta both find within a few milliseconds of each other, their incentive to push that block around to connected clients as quickly as possible is that they get their block on the chain first and thus are able to claim the reward.
More technically, if we're currently at block height 10, and miners are hashing to find a solution that will become block 11, and Alpha and Beta both find a block, they can both claim it to be block 11. However, it only actually becomes block 11 when 51% of nodes believe that a certain block is the 11^th block. The other block, the valid block that lost the exposure contest, becomes an orphaned block, and gets pruned when the height 12 blocks start coming in.

I thought every miner process its own small sub block. Or you mean that when I find solution then when I ask to confirm it then someone will tell that it is his own block (to steal it) and if he will be on faster network then he has chance to reach 51% faster then I.

When your miner mines a block, you embed your reward address inside the block (and that is included in the data that is hashed). So other miners can easily verify the block, but they can't change the reward address without mining the whole block again.

So there are 2 miners that do exactly same job? I thought every miner has its own sub-block.

There is no such thing as a "sub-block". When mining in a pool, the pool lies about the real difficulty and makes it easier, to give all the workers a chance to find something (that way, the pool can estimate the amount of work your worker is doing). All workers mine complete blocks.


text:
Is mining the unfair part of bitcoin in the same way banks (or rather, fractionary reserve systems) are to current monetary system?
I've been reading a lot about bitcoin lately and I'm very interested.
Especially, when it comes to making a currency that is way more fair, because it avoids a centralized control of it.
However, in the same way today's banks/centralbanks/FED/regulators benefit from how the current monetary system works, wouldn't an economy solely based on bitcoin make the big IT corporations take advantage of everyone due to their computing (mining) power?
Cannot we build a currency that is decentralized like bitcoin, but that doesn't have the "mining" part of it? (I know that mining concept is very tied to cryptography, but maybe a less cryptographic-centric system can be built, like one based on trust/untrust between nodes?)
Thanks very much, and sorry if this has already been asked, but it's difficult to look for a question like this.

Hello and welcome to BitcoinSE. Please note that this is not a forum and soliciting opinion or asking broad questions is generally frowned upon. Please edit your submission to clearly ask an answerable question.

there are 2 clear questions in my post

@knocte The second question is not answerable at all. It asks, in essence, "What would bitcoin look like if it didn't use proof-of-work?" Well, it would be something entirely different, like TimeKoin.

@NickODell: it is answerable, you just answered it! if you put that back as an answer instead of a comment, I will vote it up.

Question: Cannot we build a currency that is decentralized like bitcoin, but that doesn't have the "mining" part of it?
No need to, one was already created years ago and is still up and running today. Bitcoin depends on currency creation to record transactions, you can't get around this because that is the design of it and how it works. The only one that approaches this in a different way is Timekoin. Transactions and Currency Creation are separate. Transactions can be processed like clockwork every 5 minutes with no currency being created, provided some currency already exist to spend. Currency Creation is also produced like clockwork in very small amounts. So anyone running the server software can create currency, but in a very gradual, controlled amounts as long as the strict rules are being followed.

The goal of Bitcoin is to provide an online currency system with various neat properties, and block rewards for mining was considered to be the best possible (but far from perfect) way of getting users to initially buy in to the concept and make it popular enough to survive. It seems to be working.
Block rewards are decreasing over time, and actually it doesn't really matter who gets them as long as nobody can pull off a 51% attack. The great thing about Bitcoin is that we get a new currency out of it that can provide online transactions far cheaper than credit cards and without the risk of reversal (and there are a whole lot of other advantages too).

I'm sorry but this question doesn't make much sense, I guess you need to read more about Bitcoin, since you have no idea what mining is and why it is the core of Bitcoin.
Hints:

Anyone can mine, if they bother to get the proper equipment: this can't happen with traditional banks
Mining is the core of Bitcoin and can't be taken out of the equation, you would need to invent everything from scratch, good luck

I know that anyone can mine, but I guess that enterprises that build GPUs would have more chances to be the top miners, no?

I know that mining is the core of bitcoin, I don't want to modify bitcoin, I want to know if it would be possible to build something similar with its advantages but without this downside

no. As I said, anyone can buy the proper equipment, which by the way very soon will be ASICs instead of GPUs

I'm sorry to repeat myself, but as I said no, "you would need to invent everything from scratch"

buying means again a barrier of entry, corporations can buy more stuff than you. 2) I'm not saying I would not need to invent everything from scratch. Don't know what part you don't understand.

you are comparing a barrier of entry of a few hundred dollars, to millions? really?

what's your point? what exactly are you asking? can you build an airplane without wings and without fuel? Yeah, maybe. So?

is bitcoin a religion for you already? WTF

@knocte: It doesn't matter how the bitcoins are generated, someone with resources can just buy them all. Bitcoin mining is fair in that what you get is proportional to what you put in, nobody has special power.

The bitcoin is indeed unfair.  How are all to participate when the economically challemged do not have the resources to mine?   I suggested a virtual currency backed by the top 20 commodities excluding gold.  Gold only hold intrinsic value and can be manipulated very easily.  Silver however is is higher demand for manufacturing and would be acceptable.   I am planning on actually forming such a currency.  It will intially cost about 87 million dollars to initiate the network security and have the necessary holding facilities for such commodities as with any other commodity.  Paper contracts are just that paper.  they can worthless.  To physically have holdings is the only way.  Of course loans and other financial instruments will come into play to cover future costs and operations.  However.  Certain minimum levels must be kept in the 30 commodities although trading between them would be permitted so the realization of profits can be obtained.
  An oversight panel of shareholders will be in place and they will be charged with reviewing the financial records, along with professional accountants.  The panel of 12 will be drawn from the pool of shareholders and the only requirement is they are the age of 18.  Each year new oversight committees will be drawn.  This will help in avoiding any concerns of formations of lets say unwanted actors from taking any control or not stating facts.
  Since the United States Government does not allow the printing of money then it will all be virtual.  The security system to preveny hacking will ber contracted and most importantly insured by the same company.  They must have holdings in the new currency as the dollar will not be permitted in the overall theme of the currency.  They fail to do there job and system is hacked.  Whatever is lost must be replaced.  I believe that employers and consumers would swarm to be involved.  It would be global.  I am 53. unemployed.  Male, white and told by many a bit crazy.  I look around the globe and I am surrounded by the insane.  Shoot me an email and give me your feedback.  Trolls stay home.

you should listen to the people that tell you that you're crazy


text:
How much internet traffic does a 3.5GH/sec pooled miner use?
The question is clear I think. I used 3.5GH/s because that's what the upcoming ButterflyLabs Jalapeno will run. Assume it's mining for an average mining pool with 3.5GH/s (only bitcoins).
I'm interested in maintaining one on a spot where I can get electricity for free, but I have limited internet access.

Related: http://bitcoin.stackexchange.com/q/360/516

The internet traffic for any miner is generally minimal and in most cases the miner speed is irrelevant. The Getwork protocol would at most make a small request every second, but with extensions such as rollntime, one can make the request less frequently. You can roughly see how much data is being sent from the examples provided here. Generally, you shouldn't worry about the internet speed or bandwidth.

Isn't there any estimate per 24h available or so?

Well under 100MB per day.  http://bitcointalk.org/index.php?topic=82865.msg913908#msg913908


text:
Hash rate for litecoind is way below the one I get for bitcoind, is this normal?
I'm running bitcoind on an Ubuntu EC2 image in the Amazon cloud; on another identical image I'm running litecoind. I compiled both of these on the bitcoind instance. According to the getmininginfo command, my hashes per second for litecoind ranges around 300, while for bitcoind it is over 300000; 3 orders of magnitude greater. Is this normal, or have I botched something?

You might want to edit the title - it makes it sound like you're not getting any hashes in litecoin.

how to check if litecoind daemon is actually hashing? Is this the 'networkkhashps' figure in getmininginfo?

Mining in Litecoin uses a significantly different algorithmic pattern which takes substantially longer to complete a "round".
Litecoin uses scrypt while Bitcoin uses SHA256. Usually devices are measured in Khash/Mhash for Litecoin and Mhash/Ghash for Bitcoin.
The initial concept behind this is that it would be GPU proof so everyone could use their PC. GPUs can still perform substantially well.

thanks! I suppose I could have found that out with more Googling but my first tries were fruitless.


text:
Is it useful to have miners work on the same block instead of parallel solo mining?
While mining with multiple devices GPU, FPGA, etc. at home/work/school, does each device work on its own block or can you combine the resources of each mining device into 1? Say if each device can mine at 1GHash/s, 5 devices for an overall 5GHash/s between all devices. Can you set it up to where that 5GH/s is used on 1 block instead of 5 blocks? As it would reduce the block validation time?
If you can combine the resources of the solo mining operation, I assume setting up a private/solo btc pool is inorder. Would you use long polling in this instance or not?

Think of minining like flipping 50 coins at once and trying to get them to all come up heads. They almost never do, so you just flip them again. Mining with multiple devices is like multiple people doing this at once. There's no way to usefully "combine resources".

It doesn't really matter all that much. A set of workers working for the same block or each working for an individual block yields you the same profit on average. The only downside is that in order to mine for blocks you either need to have bitcoind running, or join a pool. If you want to mine a few blocks at once, you will need to be running a couple bitcoind instances. The easier setup is to just have one bitcoind running and have all your miners connect to it.
Well, that's the ideal situation anyway. Realistically, you won't ever mine a block this way. You can check out my mining calculator and plug in your numbers. How long is your time to generate one block? Can you wait 5 times that? Probably not. You ought to join a mining pool to get smaller rewards more often. But do it fast, as soon ASIC miners will go in and make your profits really small.
When you'll be joining a pool, logically you'd have all your workers connected to the same pool. Connecting to multiple pools wouldn't change your profits, perhaps it would smooth out your earnings a bit, but the change would be insignificant if you are using big pools.


text:
How OP_EQUALVERIFY works in a standard transaction?
3 weeks ago I began learning about Bitcoins, and now I'm analyzing how it works internally. My problem is that I can't understand what two public key hashes are compare to use de OP_EQUALVERIFY, because I understand that sender's public key is compare with receiver's public key, but they aren't the same hash.
Here is an example:
A script is: the scriptSig of your tx + the scriptPubkey of the tx you spent
In the same example:
The scriptSig of your tx is: Sig + your pubkey
The scriptPubkey of the tx you spent is (according to blockexplorer):
OP_DUP OP_HASH160 fc88853163ab2a9646908a82e8a87b6f185c2047 OP_EQUALVERIFY OP_CHECKSIG

I hope
ripemd160(sha256('0x0457d7d7af586aaad529b5770bb43295051e7090e2bc884181d608dae2517c7812b25e326753cbe0b767f579bbcb5cffe492d22b93f2ff5501074eb9e8f8547c4a'))
 = fc88853163ab2a9646908a82e8a87b6f185c2047...

I read that but I can't understand that the stack and scripts function.
The stack is empty. On the first step the Sender’s Signature and Public Key are combined. Then these two constants are added in the stack. Then the Public Key is duplicated. After that this duplicated item is hashed. Now the Receiver´s Public Key Hash is added to the stack. The script compares the equality between the two slack items and finally the signature is checked for two slack items.
Is that correct? I think that i'm wrong with something.
If it is posible to someone answer or reply me
Thanks.

The script in the output is created first. Its form is typically:
OP_DUP, OP_HASH160, pubKeyHash, OP_EQUALVERIFY, OP_CHECKSIG
pubKeyHash is the hash contained in the address being sent to. So it is the hash of the public key of the receiver.
When this receiver wants to spend this output, he must construct an input to claim it, and provide the actual public key that corresponded to his hash, and signature using it:
signature, pubKey
Twice, the same public key data is used. Once by the sender, stating the hash of the public key of the receiver, and when the receiver becomes a sender himself, he provides his full public key.

Thanks Pieter. Then the OP_EQUALVERIFY it's only when the receiver's become in sender and he needs to construct an input no? This is a little confusing. Sorry for my incomprehension.

I see that in the wiki:
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.
The OP_EQUALVERIFY checked the previous ScriptPubKey of this transaction with the ScriptSig of the new transaction no? Because the previous transaction's receiver is a new transaction sender, and in this form I can understand if you compare the whole public key of the new transaction (ScriptSig) with the previous transaction PubKeyHash it must be the same.
I'm right now?
Thanks

That is correct.

I think I got confused in the same manner, probably due to how the current bitcoin wiki on Transactions is written, so I think I can explain.
In every Bitcoin transaction, there is an input and output. The output contains the Bitcoin script (instructions for sending) so it contains the receiver's Bitcoin address. Input contains a reference to the previous output where the Bitcoins will be sent from, along with a signature to prove that the sender owns that address.  So let's say we have two transactions. A and B.
[Input A / Output A] -> [Input B (referencing Output A) / Output B]
When a Bitcoin nodes receives transaction B, it runs a script using output A and Input B (input B is put on the top of the stack, and output A on the bottom). It seems that you are thinking that the script gets run on Input B and Output B, but this would clearly fail when running OP_EQUALVERIFY.


text:
Is this a good time to enter mining?
This is a question that has been on my mind for a while. I was going to buy a server farm to mine Bitcoins and I was wondering if it would be practical to jump on the mining bandwagon at the current time.

What recent crash are you referring to?

What is your cost of electricity?   What is your experience in Bitcoin mining?

possible duplicate of Is mining still profitable?

Also related: http://bitcoin.stackexchange.com/questions/485/how-can-i-compute-mining-profitability

If you want to calculate your farm's profitability, you can use various online calculators to do that, like mine for example. You should take into consideration such scenarios as the reward for blocks halving soon, difficulty increasing, price going down and so forth and see whether or not it's worth your investment.
Generally, GPU mining might not be the best choice at the moment, its profit margins are narrow. FPGA miners are more effective, but are generally pretty costly at the start. The new trend appears to be ASIC miners which can also be quite costly but are extremely good at mining.


text:
Why should a miner choose the longest blockchain if another chain has a higher expected reward?
Why did miners/pools choose the longest chain for continuing it?
Because with this strategy they have the highest expected bitcoin reward.
The expected bitcoin reward is (new generated bitcoin (b) + transaction fees (t)) * probability (p) the block will not become orphaned.
Since today b + t is clearly dominated by b and b is kind of constant, today miners maximize p by mining for the longest blockchain. But what about the days when b gets close to 0? Then, right after a completed block, b and t are 0. Thus, a clever miner should ignore the latest block, since even with a small p he will end up with a higher expected reward.
But once miners become aware of transaction fees and will not build on the longest chain this could cause serious trouble? Did I forget something or are these assumptions right?

The assumption that t starts out as 0 is wrong. Not all transactions will be included in every block.

I think it's conceivable that this could happen. But under realistic cases, I don't think it actually will. If you don't mine on the longest block, the probability that your block will ever be part of the longest block drops drastically. Unless a block you mine becomes part of the longest chain and stays that way, you never get any fees or reward at all.

ok, 5 seconds after a new block new t is 5/10*60 = 0.008333 (assuming 10 minutes blocks and an even distribution of transaction) of the old t or in other words the old t is 120 times bigger. So does it hold, that after 5 seconds the two p's also differ by a factor 120? This is for example not true if you hold more than 1/120 of the hash rate, is it?

You have to find a block just to be tied with the other chain in length but behind it because everyone saw the other block first. The odds that you'd find two in a row before the rest of the world finds one are so low that you'd need an incredibly lucrative transaction to make it matter. (Though it might matter occasionally in the future when the block reward is dwarfed by transaction fees.) The situation will resolve in a confirmation or two anyway.

You don't have to just find a block, but the blocks building on your block must reach a greater height than competing blockchain tips for others to reorganize their blockchain. In the easiest case that means you have to find two blocks before the whole network only finds one.
This is highly unlikely to happen, unless you have a) a significant portion of the network's hashrate at your disposal, or b) you find a block sufficiently near in time to the other block that each block reaches parts of the network first, and there are miners working on either to create a successor.

If he doesn't choose the longest chain he would get nothing unless the next miners choose his block and not the latest, wich seems unlikely.
Also by the time that b = 0 if Bitcoin is not dead it will always be pending transactions with fees to be included on the next block (low priority transactions with small fees).


text:
Developments to prevent 51% hack
How might Bitcoin be made impervious from attack by large monied interests that could atttack with a brute force majority hashrate hack?

@Lohoris this question may be slightly different because it asks if there is any theoretical way to make such a P2P system impervious, not only to block rewrites but forward control in general. The prior question was phrased to focus on rewrites.

I really don't think you can ever prevent a "51% attack" without compromising some anonymity or decentralization.
Imagine you walk into a room, you don't know anybody (anonymity) and you don't trust anybody (decentralization). In this case, you can only trust the majority. If the majority is lying ("51% attack") then you are going to be fooled.
You can "solve" this by creating some kind of trust chain (e.g. I trust "guy A" who trust "guy B" who trust "guy C" .. so I trust guy C. However in this case, I must know guy A and guy A must know guy B .. etc and it wouldn't be as anonymous as bitcoin.
Or you could "solve" it by creating some kind of authority, who we all trust, but in this case it wouldn't be as decentralized as bitcoin.

FYI, the trust approach is the one used by Ripple.

@Lohoris, Do you think that's a better model?

@Pacerier I think it's different and well-thought enough to be worth considering.

A brute force hack would not work. Image a computer capable of expelling the lowest amount of energy conceivable to record a change in a bit from 1-0 or 0-1. Now take this computer and make it on the scale of our sun. Also imagine we can cool this computer to near zero kelvin with no other energy input. All input energy goes into changing bits and that's it.
Now take all the power our sun will make in its lifetime, and power the computer with it. It will take longer than imaginable to even just simple count to 2^256 let alone try to brute force attack a sha-256 algorithm. So brute force will never work.
--
You must gain more computing power than 50% of the network. This means on average you will create more block solvers than the <50%.
But wait again you need to account for the blockchain to date, so once you get this computer power you must now create a new fake blockchain which will take time; (Currently it take 8 hours to download the full chain, imagine how long it would take to compute it!) your new blockchain must be made (this is the whole point of the attack change the blockchain so you have more btc).
So assuming you have time to create this new blockchain, no everyone must accept it. It is in the bitcoin protocol to accept the longest blockchain to date, because it has the most transactions the most knowledge of the entire system.
So you create this blockchain and send it to everyone, they all then proceed to take their 8 hours to get the new blockchain, but wait.... why is there a new blockchain everyone would say!?
It would be obvious someone has made a new one because you are downloading it as if this is the first time on the network. And the real smart people who write bitcoin protocol would be very privy to this, and at the least have 8 hours to react. It would be to obvious.
--
The only real way I think to hurt bitcoin is to buy up all the coins, or release a whole bunch of coins into circulation greatly affecting prices.
But this would even be sorted out by the bitcoin design.
The price drops, people stop mining because it become less profitable. Cause the miners stop difficulty goes down, more people mine because it is profitable because the difficulty is so easy they can make enough btc to cover their costs, bitcoin is up and running again.

Could a motivated party just cause chaos by introducing a forged blockchain on mass from 51% of servers thereby just making a severe mess by sort of colliding the two blockchains, ie creating double spend opportunities that would be a mess to sort out?

Well a node will, by protocol, only accept the longest valid blockchain. If someone you are connected to still will give you that blockchain, the others should fall leaving the one we have all been working on since 2009. It is very hard to forge a blockchain that is not thrown away instantly because it is not valid i.e. has the proper hashes, which takes years to get right...
51% is like saying survival of the fittest, the creator of the idea never said it and didn't mean that exactly. I think you are taking 51% to much to heart, it does not apply to block-chain issuance.


text:
Hashrate falls by factor of 1000x when now block is found?
Very often my mining hashrate falls from the usual ~550 Mhash/s to about 400-500 khash/s, and I have noticed direct correlation in time with messages like these:
btcguild.com:8332 25/04/2013 10:07:14, long poll: new block 0000014d5c6c4f89

This happens across different pools. Stopping and starting the miner puts it back on the normal hashrate, but it means I have to look at the window 24h. I'm still very new to this but it seems like it switches to CPU mining? Why?
My setup is:

CPU i7-3770K
GPU HD 7970
16 GB RAM
Windows 7 64bit
Guiminer v2012-12-03

Could it be overheating? You can use a program like speccy to look at how hot it is.

My thoughts too, I have HWiNFO64 logging on all sensors so I could post some graphs. But basically it doesn't go much above 70C, maybe thats not perfect but why would it bounce down precisely when it hits a new block?

The actual temp data is (min/max/avg): Internal: 40/68/51 Core: 36/73/51 VRAM: 38/64/48; Obviously the temp goes way down when the hashrate falls too.

You're using getwork or stratum?

@organofcorti: i think that was stratum, but problem actually disappeared after few weeks. Weird.

Do you have a high latency connection to the pool? Try run stratum and test it again. Probably from the GPU waiting for work to do as the pool switches over. Worked for me like a charm.

How long does the fall last?
It's so that when a pool receives a new block, it has to remove all transactions that have been removed in that new block from the pool of transactions it was trying to put in their block.
So what I guess happens (I never wrote or examined any mining software) is that your miner receives a notification that a new block is found and so knows that it makes no sense to continue trying to find a new block because it will contain already-confirmed transactions. It will then wait until the pool received the new block as well, pruned its own transaction pool and started again with distributing work among miners.
I think this process can really only take mere seconds.

nope, it lasts forever unless I restart it. a bug in guiminer or poclbm perhaps?


text:
When a mining pool pays out to the workers, why does it not just cache the transaction and then pay zero fees on its next successful block?
If you had a mining pool that was generating a few blocks per week, then why not just cache all the payout transactions (if the clients were happy to do this) and then just put them in the next successful block it mines - thus saving on transaction costs ?

Sure, you can use your own blocks to send transactions instead of spreading them out on the peer-to-peer network and let anyone include them in their blocks (may require fees).
The upside as you say is that you can save on fees.
The downside is that it can sometimes be a long wait, even for a big pool.
Still could be a good idea to offer these payouts for free, and if you want your coins faster, you have to pay a fee.

In fact... you could offer your clients a small bonus if they wanted to wait for the free transfer - obviously it wouldn't be (SMALLEST_FEE_AMOUNT) per client - but (SMALLEST_FEE_AMOUNT/number_of_mining_clients) .. so it would be pretty small .. but there and then ... every satoshi counts eh ? Heh... one could even be the first board that pays out "MORE" than it mines....


text:
What if I create a new address and I'm given one which clashes (already exists, it is being used by other user)
Addresses are like GUIDs, no? They are created randomly whenever you request the creation of a new address.
But what if when creating one, it clashes with one already created? I know that the probability of this is staggeringly low, but there is a probability, it is not impossible.
What would happen in this case?

related question: Is each bitcoin address unique?

A bitcoin address is a 20-byte hash of a 64-byte public key (plus an ID and checksum to bring it up to 25 bytes).  As such, there are two theoretical possibilities with a clash:

Two separate people own public keys which hash to the same value
Two separate people own the same public key

Due to the way that Bitcoin transactions work, either of these situations would be enough for one party to spend the funds attached to the address.
So it's worth considering the likelihood of such a scenario.  Let's assume we have 7 billion people on the planet and they all use Bitcoin.  For there to be a 0.00000000001% chance of just two of the total in-use addresses clashing somewhere each person would need to have 4 trillion active addresses.
(Note that this is just calculating the chance of a hash collision; the chance of hitting the same keypair is so much more remote it's not worth bothering with).

if every person in the planet ends up using bitcoin, and each person has 10 wallets, would it still be so low?

Going back to the same question again, are you sure that by obtaining the same address, you would obtain the same private key? I think an address is a hash, and by having the hash you cannot obtain the private key, but you do in the other way around. So many private keys would resolve to the same hash.

Sorry but I never asked about a duplicate key but about a duplicate address. Can you remove any parts of your reply that cover the "duplicate key" topic?

Okay removed the various comments on the answer and just put it all directly in to the answer itself.

Could you explain how you got that probability?

@Jeremy It's from the birthday paradox with a search space of 2^160 (the number of bits in the hash).  The actual math can be found on Wikipedia's Birthday Attack page.

Coins sent to the shared address would appear in both wallets, but would then disappear from both of them when one of the persons spends them. As the network acknowledges and confirms that the coins have left that address, the wallet of the second person would be notified of this and decrease its value accordingly.
This would only affect coins sent to that specific address; the other coins in the two wallets would remain unrelated.

The first address would be able to spend bitcoins belonging to the second, and vice-versa.

The chances are suuuppppeeeer low, even when every person would have 1.000.000 wallets it would be super low.
And last but not least Bitcoin supports also the OP_HASH256 so if necessary the address range could be easily expanded to an even higher number. So do not worry ;-)

While this is true, it doesn't answer the question that knocte posed.


text:
Overview of the fee structure and strategy to minimize fees?

What are the current rules regarding transaction fees?
What transactions are broadcasted by the QT-Client?
How to the big pools act - what kind of transactions do say include in their blocks?

The background of the question: We are building a site where people can deposit bitcoins. Interact with the site to increase or decrease their balance and finally cash out to a Bitcoin address. (Like any Exchange, oder Just-Dice)
Obviously, we want to pay as little transaction fees as possible but still have reliable cash outs.
What is the best strategy to minimize fees?

possible duplicate of How can some exchanges/services afford to pay for customers transaction fees?, How do faucets/micropayment-based services avoid/minimize transaction fees?

related: Not relaying non-standard transactions, Do transactions and blocks get relayed even if a node believes them to be invalid?

Please only ask one question per post. Please see [about] or [Ask] for more information. Please feel free to edit this post to narrow it down to the most important question and/or re-post any questions by themselves that remain.


text:
What can be done about the no-transaction block relayer (currently 71.123.170.150)?
An unknown major solo miner (currently IP 71.123.170.150), most likely a botnet, is relaying blocks with zero transactions. Two weeks ago this miner constituted ~15% of the network, now it constitutes ~30%. If the growth rate continues, in about two weeks this miner (most likely a botnet) will control more than half of the network, theoretically allowing a 51% attack. It has already orphaned two perfectly valid blocks. (Thread on BitcoinTalk)
It seems to me we have an imminent threat to Bitcoin itself. Requiring transactions to be included in a block won't work; the miner can just send coins to itself. Blacklisting IPs in the client won't work; the miner can easily switch IPs. How can we stop this?

I think that you're wrong about it going from 15% to 30%. See this post

@D.H. I was using the data as according to Blockchain.info.

Assuming the growth rate in % can be constant is a common fallacy.

@Lohoris You are entirely correct. I think you will agree, however, that there is a possibility of the % rate remaining constant (botnets generally grow exponentially at the start), and since it could pose a serious threat to the network, IMO being perhaps overly cautionary is never a bad thing.

@BinaryMage no, it is absolutely impossible for a % of growth to be constant. You'll run out of % points as you progress, since the % total is fixed, so this just can't happen. Furthermore, even a constant (non %) growth is very difficult to achieve, let alone an exponential one (though this is at least possible, to a point).

@Lohoris I suppose I should have clarified. Going from 15% to 30% of the network indicates hashing growth of over 100%. (more than doubling) It is entirely possible, but not necessarily likely, that it would double again in the next two weeks. Now, the percentage share of the network obviously cannot grow beyond 100%. But if the botnet grew at the same rate as in the past two weeks, it would reach ~46% of the network, and 50% in a few days. Does that make more sense?

There are too many issues rolled up into this question, I'll try to address each separately.

The fact that the miner does not include transactions is not a problem. Miners have a right to exclude transactions, even all transactions. Senders can include tx fees if they want to improve the chances of being included quickly (if the miner excludes transactions due to its nature of operation an individual fee won't help much, but if the general fee level increases, 0-tx miners will be much less profitable and thus less influential).
The fact that there is a mining botnet is a problem insomuch as we don't want Bitcoin to be an enabler of harmful activities, but it does not harm Bitcoin itself. It is likely that new FPGA- and ASIC-based mining products will make CPU-based botnets less effective.
Orphaned blocks are a normal occurrence in the functioning of the network, and an occasional orphan by this particular miner is of no concern.
If the miner starts rejecting longer branches (as in a 51% attack) it is a problem, but it is a heavily discussed core problem which is not specific to botnets and is not yet resolved. I am of the opinion that a proof-of-stake system can drastically mitigate the problem (and will probably make botnets less effective miners).
If we want as a matter of principle to discourage blocks that have little or no transactions, we can include some measure of transaction volume in the branch selection criterion. One such measure is Bitcoin days destroyed. It is resistant to manipulation by sending the same coins to oneself again and again, because such coins will only destroy few days each time.

My main question was about the possibility of a 51% attack, but thanks for elaborating. Your proof-of-stake implementation proposal on the wiki is extremely useful, linking it for reference.

Proof-of-stake is worse in every critically important way. It not only concentrates wealth letting the rich gain most of the mining. By the same point that the barrier to entry for the monopolist is higher, so is the barrier to removing the monopolist. The monopolist can harm the network without harming himself because it gives him the power to fork the system. Govts have deep pockets and hate anonymity. War on Terror is an example that majority are sheep and will follow the official forks. Once you lose decentralized control, you'll never be able to compete to get it back! THINK PLEASE!

As the miner is obeying the protocol rules, one can't do much without altering the protocol. You could require the client to reject blocks that don't include some transactions that should be in the blocks, limit mining only to people with some accepted keys to sign a transaction or the like, but in the end this would probably not solve the problem.
If it was later in Bitcoin maturity, it wouldn't be much of an issue - block rewards will be coming mainly from transactions, so someone rejecting all transactions wouldn't be earning much. If this was an attempt at destroying the Bitcoin network, however, it would still be a problem.
What the Bitcoin community can do is get more mining power into the network, for example by raising the price of Bitcoins so they would be more profitable. You could also contact the owner of that IP address (since it links to a web page if typed in the address bar) for explanations.

The website is likely that of a PC in the botnet - it's a personal site. Domain is registered to a Bryan Wyatt in Texas.

I suspect that the server behind that IP was compromised, and thus contacting him won't gain you much beyond reducing the botnet by one member.

As the mystery miner continues to grow prior to 51%, it will only delay legitimate transactions. Economic factors should limit profitability of zero transaction blocks, as the value of a bitcoin would decline when usage of the network becomes hampered enough to become a deterrent rather than an incentive.
As the exchange value of a bitcoin falls, it wouldn't make sense to commit resources to mining in the first place. Going the other way, a rise in bitcoin prices would encourage network expansion - including mining. That would increase the 51% mark, making it more difficult for the mystery miner to attain the majority.
Also, if the miner is a botnet, ASIC/FPGA mining should make it a transient threat. Halving of the block reward within the next several months will cut profitability of zero transaction mining as well. This is assuming the 51% level is not achieved, allowing economic forces to remain the primary means of limiting this miner.


text:
How many unspent transaction outputs are there?
I was wondering the other day how many unspent transaction outputs there are ?
If you just keep track of the unspent transaction outputs you could import private keys, know its balance  and perform spends. How much data is this compared to the full blockchain ?
The biggest downside is that you would not have the full transaction list for a private key/address - just the transactions that you can use for future transaction inputs.

https://blockchain.info/unconfirmed-transactions

As of block 177778 (Apr 29, 2012 6:17:33 PM):

2944702 transactions
6904591 transaction outputs
5376092 transaction inputs
1528499 unredeemed outputs left
642432 addresses with non-zero balance

Looking at the number of addresses with nonzero balance, an index versus 'list of blocks address has an unspent tx output in' I calculate would be less than 28 MB. It would then be quick to get the blocks from bitcoind and hence the key's transactions.

Would a script that reports these numbers be available anywhere?

I calculated it using a patch for bitcoind that scans the blockchain  at startup, not very user-friendly :)

A less time-specific answer to the question "How many unspent transaction outputs are there?" would be appreciated.

@StevenRoose The number isn't fixed, so an answer would have to be "time-specific."

Where/how did you obtain this info?

@Geremia This shows how.


text:
Mining: Memory clock speed theory
I am mining on Radeon HD 7850 2G
I increased GPU clock speed to max 1050 available in AMD overdrive.
and then I started to increase memory clock speed.
Mining performance is dropping when memory clock speed is higher then 1250.
1300 - 327
1290 - 320
1280 - 313
1270 - 310
1260 - 307
1255 - 341
1250 - 361
1245 - 361
1240 - 360

Does clock speeds must be multiple?
Is there some formula that shows the best values for mining?

My 7850 has very similar characteristics. 1250Mhz works the best. I doubt there is a formula as my 7870 is much happier with 1500Mhz. Remember that video memory has error correction. Sometimes is can run quite high with lots of errors which will reduce your performance.


text:
How can one estimate the difficulty change?
I understand that the difficulty is growing and think that it should be possible to estimate how quickly that happens. I would like to analyze the previous difficulty progression and feel that I then should be able to predict the change in difficulty for the next year.
Are there already calculators that predict the change in difficulty? Where can I find a chart that compares the Bitcoin price to the difficulty progression?

What's "complexity"? Do you mean difficulty?

Yes. I mean difficulty

I rewrote the question as I think you meant it. Please check if I was able to capture your intent and revise it to your liking (you can always edit your own question).

related: How is difficulty calculated?

You cannot predict the change in difficulty because that is a function of a number of factors that are completely unknowable.
For example, the difficulty changes because a large number of mining pools suddenly appear and have very powerful ASICs and a lot of them. How would you ever be able to "predict" this happening?
Another example is the opposite case, that the technology has reached it's absolute maximum and there are no new chips yet invented that could give performance boost. Although new miners enter the market, this does not fundamentally change the rate at which the new blocks are discovered, because fundamentally the chips being used are no more powerful.
How on earth would you be able to determine that this has happened or is occurring?
At best any calculator would be guessing.

yes there is no straight forward algorithm to calculate it but a prediction market could achieve good results: compare: https://www.fairlay.com/event/category/bitcoin/difficulty/


text:
Trying to download miner but Google Chrome marks them as malicious/malware
First I tried GUIMiner-scrypt and then cgminer-3.9.0-windows.zip
Both archives are marked as malicious in Google Chrome. I googled and have not found articles about that. Do other people get such warnings while downloading miner?

UPDATE
My links are 2 top google results
@TinS gave another download link and file is name is same guiminer-scrypt_win32_binaries_v0.04.zip but size is different.
One file is marked as malicious by Google Chrome and another not.

I think the tag "malware" covers it sufficiently and we don't need a "malicious" tag additionally.

Google Chrome tells malicious I added malware myself just because there is such tag.

That's exactly what I meant: "malware" by itself is recognizable and descriptive. On the other hand I don't see how "malicious" could ever stand as the only tag of a question, as it could refer to anything.

The first site has fine print that says says "This site is not the official page of the software." I'd be very suspicious of that download. https://bitcointalk.org/index.php?topic=150331.0 seems to be a more reputable place.

The one I downloaded from your link is not marked as malware. My links are top results in google and google mark then as suspicious. Also virustotal give 18 warnings
@TimS. Thanks

I'd bet the reason Chrome marks it as malicious is the same some anti-viruses mark scrypt miners as malicious: since scrypt can be mined with CPU, botnets galore attach a CPU-scrypt-miner as payload to put the computers they control to mine for their manager...

Don't worry, Google has added this feature into Chrome : http://www.pcworld.com/article/2059579/googles-chrome-will-automatically-block-malware.html
But it seems that sometimes Chrome marked as malicious something which is not. If you have downloaded it from the official website you don't have to worry.
If you want to be sure you can get a checksum of the file (there is not the checksum on the official page so just ask someone you trust).

I know this feature. But there is still a risk that some redirect done by some admin who works on my ISP who tries to put malware on miners PC. If it is a mistake then every other user will get error notification as me and I expect to see it all over internet but I google and have not found people complaining on such issue.

What about the checksum ? If it's the correct checksum you can be sure it's only your Chrome.

"If you have downloaded it from the official website you don't have to worry." Poor advice. Projects and companies are often bought by criminals specifically for the purpose of leveraging previous credibility to spread malware. CGMiner has not been maintained for YEARS.

There are many reasons why to Google Chrome appears some files as malicious e.g.

Is the host site known and trusted?
Can the identity of the host site be verified? (e.g. SSL certificate, https)
Can the the identity of the file's publisher be verified? (e.g. via code signing certificate)
Is the file known and trusted?

But as main reason we can consider not using SSL certificates or https url.
Even though you can discard this pop-up and download the file I would recommend you to scan it through antivirus program.
From my experience I can say that the cg-miner is safe to use! :)

The issue I think answerers are missing is this is not the "keep or discard" version - this is "it has been discarded and you can't do anything about it" issue. So with a file we know is valid - we can't do anything to retrieve it off the top.
Go to your downloads tab on chrome - it'll show you the error again with an option to discard it or keep the file anyway.


text:
Are there any mining pools operating on the Testnet?
Are there any mining pools operating on the Bitcoin Testnet, or do pool owners just test their code using their own machines without keeping the test pool up for too long?

Currently, one can merge mine at this pool on the Test Net:

https://alpha.masterpool.eu/

I get "the requested URL can not be found"


text:
p2pool inbound connections
I am trying to get inbound connections on my p2pool instance. I currently have 6 outbound connections and the pool is working fine, but I would like to have more connections (might help get a few less shares, and if nothing else help the network a little bit).
I have been looking around how to do this, it seems like you need to set up a port forward to port 9332 (or 9338 for litecoin). I have never done this before, and have a few miners which are doing OK on my existing pool so before I go ahead and ruin my p2pool node I thought I'd reach out and see if anyone had any experience they would like to share :)
I am using Ubuntu 12.04 (64-bit), thanks for your help!

You had created three new tags for this question. Please rather check for existing tags before creating new ones. Only create new tags if you are the first to breach a new topic that you feel will gather more questions. Tags are used by other users to follow specific topics and new tags won't be followed by anyone yet, thus are of little use at first for you. At this point it is probably rather rare that one is indeed the first to ask about something. ;) I have replaced the new tags with some existing tags which seemed appropriate. Feel free to edit if you find some better ones.

Whoops! I'll take those out :) Sorry

Um. I had already replaced your new tags "inbound, port-forwarding, and iptables" with the existing tags "network, nodes, peers, connection". It seems to me that you missed that bit and deleted what you thought was still your new tags. I rolled back to include those existing tags again, in the hope that I interpret the situation right. ;)

From what we have noticed on LBTC Grid, out refers to connecting to coin network and the P2Pool network. In refers to miners connecting to your server.


text:
Are sidechains really new?
People have been talking a lot about side chains, but I thought this has been around for a while under a different name. Coins like Namecoin, Devcoin, ixcoin, i0coin, groupcoin, etc are all merge mined and have existed long before I ever heard the term "Side Chain".
Am I correct in my assumption that side chains are just a rose by another name (previously merge mined coins)? Or is there something I am missing here?

Perhaps I shouldn't have mentioned China, as it is indeed unrelated. I will remove this, but still I don't understand how sidechains work and will be implemented. From what I've read it seems like merge mining but why not just call it that? Some examples of how new side chain coins will work (if they are already in existence) or links to whitepapers explaining this will be much appreciated :)

Also Feathercoin forks from Litecoin blockchain, so would this be a side-chain? I am looking for a clear definition of what is an alt chain or would like to know if it's just a buzz word which is being used with multiple meanings.

It will help if you provide links to the places where this term is being used. Without context it is difficult to narrow down what this relates to. Sidechains could refer simply to shorter chains than the main blockchain (orphaned blocks) or parallel chains that will get partial mining reward in coins that use the uncle/nephew family tree reward system, or even forks into new coins, from your last comment. Not every use of a term is with its widely accepted meaning, so in the context you saw it we don't know exactly what was meant unless we look at it in place.

Is this related to this question on sidechains?

I've been reading a lot on Reddit (please see http://www.reddit.com/r/Bitcoin/search?q=sidechain&sort=top&restrict_sr=on ) about sidechains. You're right I should have included links, but I have not been able to find two articles which make the same claim about "side chains" I really have no idea what it means except that it somehow relates to bitcoin. I am hoping someone can explain how this innovation is different than merge mining.

A side chain is a blockchain that runs parallel to the main bitcoin blockchain and can synchronize with it directly, allowing decentralized value transfer between the two chains. A user is able to essentially lock up a certain amount of coin on the main bitcoin block chain which then frees up an equivalent amount of coin on the side chain. This side chain may be either a sidechain compatible altcoin or just some test ground for new Bitcoin features. The coin that was transferred to the side chain can be returned back to the main bitcoin blockchain at any time. The value transferred back will be the same as the value transferred out.

This is the kind of thing I've been hearing about side chains. Thanks for the info! Here is what really confuses me, how does the value transferred out of bitcoin make it back to bitcoin, is this dependent on the side chain's exchange rate? I have heard "atomic swapping" is a method but this can be used for anycoin to anyothercoin, and is not in itself a way to store coins.

See http://blockstream.com/sidechains.pdf (Disclaimer: I'm a co-author of the paper).

Sidechains are chains which allow 2-way peg, that is, moving bitcoins to the sidechain and then back to the main chain without trusting any third party, like you do, for example, when you move Bitcoins to say, Ripple (there you have to trust Bitstamp or another gateway). As such, there's no sidechain in existence, simply because the technology has not been implemented yet.
2-way peg is orthogonal to merged mining (you can do each of them separately or both). It is generally assumed that a sidechain would have merged mining because the bitcoin wizards designing sidechains accept that merged mining is generally desirable because of its superior security properties.
Compared to atomic swapping, 2 way peg is much slower but it doesn't require a counterpart that wants to move coins in the other direction.
So when sidechains are implemented, it is likely that most of the transfers are done with atomic swapping and only the first movements are done with 2 way peg, which is mostly there as a last resort in case you can't find someone else that wants to move the same quantity in the opposite direction.
Here are more details on how 2-way peg works:
How is a side-chain merging back to Bitcoin chain protected against double-spend? Where are the side-chain mining fees?


text:
What are Tonal Bitcoins?
What are Tonal Bitcoins? In what application is this system of notation superior to the decimal notation? Are there any clients or other services supporting the tonal system?

Luke-jr is a huge supporter of Tonal. He said, "For me, Bitcoin is about one thing: providing a monetary system for the Tonal number system." Luke-jr is an active developer and an active proselytizer for Tonal, so you hear about Tonal a lot even though almost no one uses it.

@theymos - what?! This is the first time I've heard of Tonal. Judging by Gary's answer below, this is a completely uninteresting implementation detail ... why would anyone consider Tonal Bitcoins "the one thing Bitcoin is about"? If this is true and Luke-jr meant it seriously, this might explain a few things.

Hmm, cudos for whoever made it for encoding hex numbers and making a counting system that doesn't have some naming exceptions (like, eleven), but who in their right mind would use the character "9" to represent the number 10 (decimal)?!

Slight grammar edit.

I've updated my answer to flesh out some important details regarding powers of 2 units that appear to make Tonal notation completely redundant.

After taking a quick look over the Tonal Book (free PDF) and the Wikipedia article it appears to be an early attempt at constructing a number system in base 16.
Programmers will immediately recognise this as hexadecimal. For non-programmers hexadecimal uses the following representations: 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F. Note that decimal 10 to 15 are represented by the single letters A to F, such that FF is decimal 255 or (16 * 15)+(1 * 15). To differentiate a decimal number from a hexadecimal number the conventions 0x10 (decimal 16) or 10h are widely recognised.
The Tonal bitcoin representation attempts to offer an alternative representation of BTC known as TBC (Tonal Bitcoin) and uses the various Tonal letters to represent them. The Tonal alphabet is more complex than the hexadecimal system and requires special fonts to be available on the systems using it.
It is unlikely that this archaic approach to base 16 is ever likely to gain traction when much more widespread approaches are available.
Units covering powers of 2 in computing
It should be noted that in 1998 the International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers (IEEE) and the International Committee for Weights and Measures (CIPM) adopted a purely "powers of 2" approach for some use cases. Notably the representation of computer storage and data transmission rates.
This gives rise to 2 unit systems - one base 10, the other base 2:
The primary power of 10 notation we're all familiar with:

1 kilo byte (kB) = 10 ^ 3 bytes
1 mega byte (MB)= 10 ^ 6 bytes (historically 1000 * 1024 for some storage cases)
1 giga byte (GB) = 10 ^ 9 bytes

The alternative power of 2 notation:

1 kibi byte = 2 ^ 10 bytes
1 mebi byte = 2 ^ 20 bytes
1 gibi byte = 2 ^ 30 bytes

Thus there is even less reason to use the Tonal system since a widespread alternative with well-defined prefixes has already been ratified for some time.

Tonal Bitcoins (TBC) are an interpretation of the low-level Bitcoin system with Tonal units (similar to how BTC is a SI interpretation).
The Tonal number system is superior to decimal for virtually every human use, but is (similar to Dvorak keyboards, or your first second language) difficult to learn for people who were raised only with decimal. It is superior because humans naturally work in powers of 2, and this can be easily demonstrated in many areas: despite the common decimal system forced (literally) on societies today, people still find ways to use binary (for example, USD "quarters" or slicing pizza - ever try to slice 5 pieces?).
The Python Bitcoin client Spesmilo supports both BTC and TBC (and mixed) interpretations by configuration, provided a Tonal-compatible font is detected on your system. While the tonal system has not been officially adopted in any nation, it is a natural "next step" from some US customary units. The Tonal system, unlike the newer hexadecimal system, is complete and provides not only digits (rather than ambiguously hijacking letters) but also pronunciations, weights, measures, time, and a calendar, necessary to use it in daily life.

I should go and read the PDF sometime. Maybe. Care to respond to the comment above by @theymos - He (Luke-Jr) said, "For me, Bitcoin is about one thing: providing a monetary system for the Tonal number system." ?

What's to respond to? The quote is legit. In particular, it was part of a response to someone arrogantly assuming his goals for Bitcoin were the only possible purpose for it. I was demonstrating (by example) how different people use Bitcoin for different reasons.

I just don't really understand why you care so much about Tonal. To me, Bitcoin is a huge revolution ... and Tonal is an insignificant implementation detail (haven't read the pdf yet). Therefore, I can't understand why someone would claim this is the main reason they're interested in Bitcoin.

@Luke-Jr "it is a natural "next step" from some US customary units" - that would be the metric system, that is used everywhere, but in USA, Liberia and Myanmar - http://www.joeydevilla.com/2008/08/13/countries-that-dont-use-the-metric-system/. "humans naturally work in powers of 2" - humans use the decimal system, because they have ten fingers and its natural to use it as a base for counting. For fractions, yes, it's convenient to use halves.

"Huge revolution" or not, how does Bitcoin help me fulfil my duties? In my case, it is linked to my duty of educating my children. Because the Tonal number system is clearly the best option, that is what my children learn as their primary number system, and to that end, Bitcoin provides them the ability to use it for currency. So Bitcoin helps me fulfil my duties by providing a currency for the Tonal system, which helps me better educate my children.

@ThePiachu: SI ("metric") is not the next step, it is a step backward. Very rarely, if in fact ever, has mankind's evolution of measurement systems gone to decimal. In almost every case, we humans have by choice preferred binary, dozenal, and tonal units despite counting in decimal. On the other hand, SI was only ever adopted by force. Decimal is the weakest link in the US customary number system, and rationally the first to be replaced. Finger counting, while likely the original reason we began using decimal, is a very poor excuse: it's more sensible to finger-count in base 6 and binary.

@Luke-Jr SI might not be perfect, but it is the only way to go now, based on the sheer volume of academic work relying on it (try rewriting every science book that uses metric system), its completeness (Tonal doesn't have a ampere, candela or more equivalent, not to mention any derivatives), ,how widely it's adopted and available (is there even a Wikipedia article on the Tonal system? How many people use it?), or how precise it is (did anyone measure Tonal meter down to an angstrom?). Tonal is certainly an interesting place to start a hex-based system, but in its current form, it's not enough.

I'm still confused as to what the advantages are (other than more efficient storage within computers). I'd look it up in Wikipedia, but I believe it's blacked out right now... :-(

The end of the original specification book is basically an attempt to convince SI to abandon their misguided goal of using decimal and adopt Tonal themselves, including numerous reasons for doing so. Inevitably, it failed due to the legal treaty upon which SI was created specifying decimal.

And in the end, the author of the book himself abandoned the Tonal system for his new invention, Duodenal (base 12) system - http://en.wikipedia.org/wiki/John_W.Nystrom#Duodenal_System.28Duodecimal.29

Hello jastako, comments are for requesting more information or to suggest improvements. Please do not comment to respond to answers or to start discussions. If you wish to express your own position on the topic, please create your own answer or vote on existing answers.


text:
Mining software not using Json-RPC?
Is there some mining software out there that doesn't use Json-RPC as a communication method with the mining pool? If so, what protocol are they using?

Jeff Garzik wrote a binary protocol for pushpool originally.
BitPenny uses a proprietary protocol to get p2pool-like benefits.

JSON-RPC is simple and effective. I think most use it.
If people would change it, it's most likely for efficiency. They'd most likely roll their own binary protocol, which we might very well know nothing about.
It's also possible the miner is inside the client in which case it could get it's own work and wouldn't even need a protocol.
If you could say why you want to know maybe I can give a more useful answer.


text:
Miners - HTTP JSON-RPC or JSON-RPC?
Does the main miner software used currently use HTTP JSON-RPC, or JSON-RPC? That is, do they use HTTP calls to obtain getwork, or TCP/IP?

They use RPC over JSON over HTTP over TCP/IP. These aren't alternatives, each of these protocols does a different thing and exists at a different layer.

The miner uses JSON-RPC 1.0, for which only the HTTP transport was defined.


text:
Can I trust the peers I am connected to?
From my understanding of Bitcoin, it operates on a P2P network. Having just downloaded a wallet app, I see it is connected to 6 peers. Does the Bitcoin protocol rely on trusting these peers? What does it mean if these 6 peers turn out to be fake, and I'm part of a 'micro-economy' rather than Bitcoin proper?

Your understanding is correct. What you describe is known as a Sybil attack, here essentially the p2p version of a man-in-the-middle attack.
In general, Bitcoin requires very little trust, as each peer can check whether new information adds up with the information that was previously gathered. The attacker could use this constellation to relay a transaction to the attacked, e.g. make a store believe that an incoming transaction has been sent on the Bitcoin network, while instead sending the competing double-spend to the network.
However, the attacked could notice that he is not receiving any new blocks from the network (as otherwise the double-spend might be detected early). I.e. the attacked is not part of a real 'micro-economy', but rather just cut off from network updates.
In order to truly create a 'micro-economy', the attacker would have to actually mine fake blocks at the current difficulty in order to pass off false information as true, requiring immense hash-power at his disposal.
However, as one legitimate peer is sufficient to defeat this attack, you can either set your Bitcoin client to connect to certain peers only, or at least force it to connect to two peers that would not cooperate with each other to defraud you, in order to defeat the attack.
Edit:
Actually, I just realized that the Bitcoin.it has a paragraph on the Sybil attack.