Still, there has really been a sudden increase:



(this graph is generated from the precise timings blocks were found, and not just the number of blocks since difficulty increase)

I believe fellowtraveler means here 'fiat' in the sense that bitcoin's only value is its use as payment, and not 'fiat' in the meaning that its value is forced by government decree. Compare this to gold which has a use as component for jewelry, even when not used as monetary system.

I admit this is something i did not think about. Maybe part of the bandwidth can be prevented by only sending the list of tx ids + the block header over the pool-network as proof-of-work, instead of the full blocks. However, this will still be a significant amount of bandwidth (at 80 tx/s), and increase the difficulty of verifying the proof-of-works.

Each time a low-difficulty block is found by someone, everyone's distribution tables should be updated, yes. However, this does not mean an immediate getwork is necessary. People can keep mining using slightly outdated tables.

This is an idea that originally grew on #bitcoin-dev and in PM's between me and marioxcc some time ago. After mentioning it the past few days again on IRC, I thought about writing it out.

The idea is to make a server-less pool that is not controlled by a single individual (or group) like traditional pools are. Everything is done by the mining nodes themselves.

1. The concept

We combine some ideas from slush's pool and from puddinpop's earlier pool:

• Everyone mines real bitcoin blocks.
• The generation transaction has multiple outputs, one for each participant in the pool.
• Miners do not only report blocks that beat the "real" difficulty, but also those beating only a lower difficulty.

Contrary to centralized pools however, the miners are only connected to eachother. This is done through a secondary p2p network (disconnected from the real bitcoin network). Through this network, they show their low-difficulty blocks to eachother.

Each node maintains a table with how the reward from his blocks should be distributed to other pool members. When miner X sees a (low difficulty) block by miner Y that contains address X as generation transaction output, X updates his own table to increase Y's share. The intent is that this reaches an equilibrium proportional to the hashing speed of all players.

Since one has to decide what the generation transaction outputs are before actually starting to mine, a low-difficulty block is an unfakeable proof that one did intend to distribute gains according the way encoded in the transaction. If Y would stop including X as output, X would notice and can retaliate by removing Y from his own outputs.

2. Issues

There are some possible issues with this:

• Everyone needs to see all low-difficulty blocks by everyone. This quickly leads to rather high bandwidth usage. One solution is to let miners decide their own (low) target difficulty, and encode that in their blocks as well (it can be stored in the coinbase of the generating transaction, for example). A block with target difficulty D (and hash which matches that difficulty, of course) then counts as D diffculty-1 blocks for the speed estimation.
• Attacks: like all pools, this system is vulnerable to a vandalism attack: a miner is able to just not report a block he found that beats the real difficulty, decreasing the joint income of the whole pool. If people were free to join and leave a P2P pool like described here, this would be very hard to detect. A second possible attack is waiting for a opportune time (where you have earned more than you deserve, which will always happen through statistical variation), leave the pool, and return under a different name.
• Bootstrapping: someone new who joins the pool should be able to bootstrap - get an initial distribution table for his blocks, before anyone in the network is including him in their blocks. One possibility is using measured block frequencies (in general, not just the part mentioning him) of other nodes for this.
  

3. Implementation

One possible way of implementing this, is as a patch for bitcoind, with RPC calls:

• updatedist(), which sets a new distribution table and difficulty to be used in the generation transactions used by getwork()
• getwork(), modified to incorporate the distribution table set by updatedist()
• getshares(), returning information about recent blocks found by miners (including low-difficulty ones)

The rest of the implementation is then done in a separate pool client, which connects to bitcoind and uses these calls, as well as connecting to other pool clients and forwarding low-difficulty blocks.

An alternative is to incorporate everything into bitcoind, and possibly even use the bitcoin p2p network itself to communicate with other pool nodes. Initially however, it is probably better to let the communication between pool nodes happen through a simple multiplexing server, which forwards blocks between different nodes, adding some authentication as well.

There are further details that are already worked out as well. I'll write those out later, if there is interest.

PS: thanks to molecular for starting this text.

Furthermore, the difference between an acceptable optimization strategy (whether or not it gains you anything at all) and cheating, is IMHO the fact that if everyone used this 43%-strategy on the current system, it would break down (rounds wouldn't ever get finished), while in a only-shares-for-a-block system, the resulting gains would still be perfectly proportional to invested computation power (as share count would be reset after a block is found, even if everybody stopped pool mining, and people would join again).

Ok, agree. I think conventions for what and where fees are expected are a separate issue. But as long as no different set of rules is designed, and the client enforces those rules in the transactions it creates, no transactions that include a fee should be created beyond the user's (or JSON-RPC client's) control. Gavin's proposal does that nicely.


Ok, agree as well. But again, maybe introducing a new version of the protocol may or may not be worth the effort.


That comes close to my "Idea 1", and brings us back to the issue of whether it is the responsibility of the JSON server to provide encoding/formatting of numeric amounts for human readability (and humans with varying tastes).

My original post - though split off from its original thread by gavin - was mainly about the internal representation used by JSON-RPC, and it seems that's also what most discussion here was about. This is a detail, and although my personal opinion is that integer units are preferable, it may or may not be worth sacrificing backward compatibility for.

Concerning sub-cent precision itself, i think gavin's suggestion is very good. The JSON-RPC interface should support all transactions and accounting at full precision, the client should actively avoid creating fee-requiring transactions, and creation of fee-requiring transactions shouldn't occur without the user's knowledge. I would suggest adding an optional maxtxfee argument (overriding the default) to the RPC calls which cause transactions to be sent though - i don't like a global setting shared by possibly more than one JSON-RPC client.

Part of the problem is that the JSON-RPC interface is used for both communication with humans (most of whom prefer a decimal representation in bitcoin), and other software which may benefit from having an easier/safer representation as integers (because it does its own formatting/parsing when communicating with humans).

Idea 1:

• by default, all communication uses JSON numbers representing the interger count of bitcoin units (1E-8 BTC)
• The JSON-RPC server (being bitcoin, bitcoind, some proxy, some other implementation) may optionally support input using other encodings for numbers, which must be represented as a JSON string, ending in a suffix denoting the encoding (eg. ending the string with " BTC" means decimal bitcoin representation - which can by the way be parsed perfectly to units without any floating-point code). Using a non-supported encoding should cause a clear error message.
• The JSON-RPC client can ask the server for a particular encoding as an argument to the RPC function called, causing an error if that encoding isn't supported.
• The CLI bitcoin interface could use the " BTC" encoding by default.
• Additional encodings can easily be added, or provided by a wrapper script, ..., by only requiring that all servers and clients must support number-encoded integers.
• Some names of functions or arguments would need to be changed, to ensure that no program using the old API accidentaly sends 0.00000050 BTC instead of 50 BTC.

Idea 2
On the other hand, maybe it is not the responsibility of the server to support different encodings of amounts. Since the primary purpose of the JSON RPC interface is imho a standard way of communication with software (not people) interacting with bitcoin, it should be as simple/safe as possible, and use integers (since this has the least chance of causing rounding errors in client software, as explained by others in this thread), and give the responsibility of formatting numbers to client software (which should use integers to represent amounts internally anyway, if it does any form of processing on them). The CLI interface could then take care of providing the optional-encodings scheme outlined above.

Personally, I prefer the second idea.

The difficulty is 22012 since Januari 27th. At that difficulty and hash speed, the chance of not finding a block in 5 days, is almost 8.9%. So you've had bad luck, but it's far from impossible.

Not sure what you mean. A straight line on the graph would correspond to exponential growth. The only thing I notice is that the growth seems to be slowing down. My current estimate is indeed also around 170GHash/s.

Hello everyone,

i've created some graphs showing the total hashing speed of the bitcoin network, and its growth:





Larger versions can be found on http://bitcoin.sipa.be/speed.png and http://bitcoin.sipa.be/growth.png.