Bitcoin Wiki - User contributions [en]

Proof of work

2011-03-05T01:54:38Z

Rgm: /* Example */

{{stub}}

A '''proof of work''' is a verifiable result that can only be obtained through a given work. Proofs of work are hard to obtain (i.e. require work), but trivial to check. Proofs of work can be applied to information; you can prove that you did work on a particular number.

One application of this idea is a proposed [http://en.wikipedia.org/wiki/Hashcash method for preventing email spam], requiring a proof of work on the email's contents (including the To address), on every email. Legitimate emails will be able to do the work to generate the proof easily (not much work is required for a single email), but mass spam emailers will have difficulty generating the required proofs (which would require huge computational resources).

This concept is used in Bitcoin for block generation. For a block to be valid it must hash to a value less than the current [[target]]; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceeding block, thus each block has a [[block chain|chain]] of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.

== Example ==

Let's say the base string that we are going to do work on is "Hello, world!". Our target is to find a variation of it that SHA-256 hashes to a value beginning with '000'. We vary the string by adding a integer value to the end called a [[nonce]] and incrementing it each time. Finding a match for "Hello, world!" takes us 4251 tries (but happens to have zeroes in the first four digits):

"Hello, world!0" => 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64
"Hello, world!1" => e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8
"Hello, world!2" => ae37343a357a8297591625e7134cbea22f5928be8ca2a32aa475cf05fd4266b7
...
"Hello, world!4248" => 6e110d98b388e77e9c6f042ac6b497cec46660deef75a55ebc7cfdf65cc0b965
"Hello, world!4249" => c004190b822f1669cac8dc37e761cb73652e7832fb814565702245cf26ebb9e6
"Hello, world!4250" => 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9

4251 hashes on a modern computer is not very much work (most computers can achieve at least 4 million hashes per second). Bitcoin automatically varies the [[difficulty]] (and thus the amount of work required to generate a block) to keep a roughly constant rate of block generation. The probability of a single hash succeeding can be found [http://blockexplorer.com/q/probability here].

In Bitcoin things are a bit more complex, especially since the header contains the [http://en.wikipedia.org/wiki/Merkle_tree Merkle tree] which depends on the included [[transactions]]. This includes the generation transaction, a transaction "out of nowhere" to our own address, which in addition to providing the miner with incentive to do the work, also ensures that every miner hashes a unique data set.

[[Category:Vocabulary]]

[[fr:Preuve de travail]]

Proof of work

2011-03-05T01:52:52Z

Rgm: Clarify & add missing word.

{{stub}}

A '''proof of work''' is a verifiable result that can only be obtained through a given work. Proofs of work are hard to obtain (i.e. require work), but trivial to check. Proofs of work can be applied to information; you can prove that you did work on a particular number.

One application of this idea is a proposed [http://en.wikipedia.org/wiki/Hashcash method for preventing email spam], requiring a proof of work on the email's contents (including the To address), on every email. Legitimate emails will be able to do the work to generate the proof easily (not much work is required for a single email), but mass spam emailers will have difficulty generating the required proofs (which would require huge computational resources).

This concept is used in Bitcoin for block generation. For a block to be valid it must hash to a value less than the current [[target]]; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceeding block, thus each block has a [[block chain|chain]] of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.

== Example ==

Let's say the base string that we are going to do work on is "Hello, world!". Our target is to find a variation of it that SHA-256 hashes to a value beginning with '000'. We vary the string by adding a integer value to the end called a [[nonce]] and incrementing it each time. Finding a match for "Hello, world!" takes us 4251 tries (but happens to have zeroes in the first four digits):

"Hello, world!0" => 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64
"Hello, world!1" => e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8
"Hello, world!2" => ae37343a357a8297591625e7134cbea22f5928be8ca2a32aa475cf05fd4266b7
...
"Hello, world!4248" => 6e110d98b388e77e9c6f042ac6b497cec46660deef75a55ebc7cfdf65cc0b965
"Hello, world!4249" => c004190b822f1669cac8dc37e761cb73652e7832fb814565702245cf26ebb9e6
"Hello, world!4250" => 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9

4251 hashes on a modern computer is not very much work (most computers can achieve at least 4 million hashes per second). Bitcoin automatically varies the [[difficulty]] (and thus the amount of work required to generate a block) to keep a roughly constant rate of block generation. The probability of a single hash succeeding can be found [http://blockexplorer.com/q/probability here].

In Bitcoin things are a bit more complex, especially since the header contains the [http://en.wikipedia.org/wiki/Merkle_tree Merkle tree] which depends on the included transactions. This includes the generation transaction, a transaction "out of nowhere" to our own address, which in addition to providing the miner with incentive to do the work, also ensures that every miner hashes a unique data set.

[[Category:Vocabulary]]

[[fr:Preuve de travail]]

DiabloMiner

2011-03-03T00:13:24Z

Rgm: OSX.sh -> YourOS.sh

DiabloMiner is a Java GPU bitcoin miner that uses the [[OpenCL_miner|OpenCL]] framework to quickly perform the hashing computations. Works on current Nvidia drivers and ATI Stream SDK 2.1.
==Donation==
Bitcoin address in the signature in the [http://www.bitcoin.org/smf/index.php?action=profile;u=1796 founder's page].
==Download==
[http://adterrasperaspera.com/images/DiabloMiner.zip Newest binary]

[https://github.com/Diablo-D3/DiabloMiner/archives/master Source]
==Examples==
From the introductory [http://www.bitcoin.org/smf/index.php?topic=1721.msg21054#msg21054 post], to run type:
./DiabloMiner-YourOS.sh -u youruser -p yourpass
Where user and pass are the values for the rpcuser and rpcpassword configuration settings from the bitcoin.conf file located your [[Data directory#Files|data directory]].
Newer versions of DiabloMiner support a <code>--url</code> argument, for example:
/DiabloMiner-YourOS.sh --url <nowiki>http://youruser:yourpass@localhost:8332/</nowiki>

To run on Windows you have to do something like:
java -cp target\libs\*;target\DiabloMiner-0.0.1-SNAPSHOT.jar -Djava.library.path=target\libs\natives\windows com.diablominer.DiabloMiner.DiabloMiner -u youruser -p yourpassword

==Founder==
[http://www.bitcoin.org/smf/index.php?action=profile;u=1796 DiabloD3]
==HomePage==
[https://github.com/Diablo-D3/DiabloMiner Project Page]

[http://www.bitcoin.org/smf/index.php?topic=1721.0 Project Thread]
==License==
[http://www.gnu.org/copyleft/gpl.html GPL]

[[Category:Mining]]

DiabloMiner

2011-03-03T00:12:51Z

Rgm: Add note about --url argument

DiabloMiner is a Java GPU bitcoin miner that uses the [[OpenCL_miner|OpenCL]] framework to quickly perform the hashing computations. Works on current Nvidia drivers and ATI Stream SDK 2.1.
==Donation==
Bitcoin address in the signature in the [http://www.bitcoin.org/smf/index.php?action=profile;u=1796 founder's page].
==Download==
[http://adterrasperaspera.com/images/DiabloMiner.zip Newest binary]

[https://github.com/Diablo-D3/DiabloMiner/archives/master Source]
==Examples==
From the introductory [http://www.bitcoin.org/smf/index.php?topic=1721.msg21054#msg21054 post], to run type:
./DiabloMiner-YourOS.sh -u youruser -p yourpass
Where user and pass are the values for the rpcuser and rpcpassword configuration settings from the bitcoin.conf file located your [[Data directory#Files|data directory]].
Newer versions of DiabloMiner support a <code>--url</code> argument, for example:
/DiabloMiner-OSX.sh --url <nowiki>http://youruser:yourpass@localhost:8332/</nowiki>

To run on Windows you have to do something like:
java -cp target\libs\*;target\DiabloMiner-0.0.1-SNAPSHOT.jar -Djava.library.path=target\libs\natives\windows com.diablominer.DiabloMiner.DiabloMiner -u youruser -p yourpassword

==Founder==
[http://www.bitcoin.org/smf/index.php?action=profile;u=1796 DiabloD3]
==HomePage==
[https://github.com/Diablo-D3/DiabloMiner Project Page]

[http://www.bitcoin.org/smf/index.php?topic=1721.0 Project Thread]
==License==
[http://www.gnu.org/copyleft/gpl.html GPL]

[[Category:Mining]]

OpenCL miner

2011-03-02T23:40:43Z

Rgm: link to hash page

{{stub}}
An '''OpenCL miner''' is a bitcoin miner that uses the [http://en.wikipedia.org/wiki/OpenCL OpenCL framework] to perform the [[hash|hashing]] computations. When used with a modern GPU, this can produce hash rates orders of magnitude higher than what can be achieved with a CPU. Hashing on a GPU requires an OpenCL or CUDA compatible graphics card ([http://www.nvidia.com/object/cuda_gpus.html NVIDIA], [http://developer.amd.com/gpu/AMDAPPSDK/pages/DriverCompatibility.aspx ATI/AMD]).

The python [[Poclbm]] open source OpenCL bitcoin miner was created by m0mchil<ref>[http://www.bitcoin.org/smf/index.php?topic=1334.0 m0mchil's announcement on the forum]</ref> based on the open source CUDA client originally released by puddinpop<ref>[http://www.bitcoin.org/smf/index.php?topic=133.msg13135#msg13135 puddinpop's open source CUDA miner]</ref>. Subsequently the java [[DiabloMiner]] based on m0mchil's was created by Diablo-D3<ref>[http://www.bitcoin.org/smf/index.php?topic=1721.0 Diablo's announcement on the forum]</ref>. Puddinpop has also released a C++ OpenCL client capable of being compiled into the GUI client or daemon, or as a stand alone RPC miner<ref>[http://www.bitcoin.org/smf/index.php?topic=2444.0 puddinpop's RPC miners]</ref>.

See the [[Mining Hardware Comparison]] page for detailed statistics on the hash rates that can be achieved with various hardware.

==See Also==

* [[Poclbm|momchil's OpenCL miner]]
* [[DiabloMiner|Diablo's miner]]
* [[RPC Miner|puddinpop's RPC miner]]

==References==
<references/>

[[Category:Mining]]

Block

2011-03-02T23:37:49Z

Rgm: link to nonce

Data is permanently recorded in the Bitcoin network through '''blocks'''. Each block contains all recent [[transactions]], a [[nonce]] (random number), and the [[hash]] of the previous block. A block is "solved" (published and considered valid by peers) when the SHA-256 hash of the entire block is below the current [[target]]. This is very unlikely to occur after being hashed only once, so the nonce must be incremented and the block re-hashed millions of times until it does.

Bitcoin transactions are broadcast to the [[network]] by the sender, and all peers generating coins collect them and add them to the block they're working on. If the transaction is much larger than the average transaction size, a small [[transaction fee]] may be charged.

The first transaction in the block is special: it creates new [[Bitcoins]] for the person who generated it. Other peers will only accept the block if this transaction is of the correct amount. The number of [[Bitcoins]] generated per block starts at 50 and is halved every 210,000 blocks (about four years).

The network tries to create 6 blocks per hour. Every 2016 blocks (about two weeks), all Bitcoin clients compare the actual number created with this goal and modify the target by the percentage that it varied. This increases (or decreases) the difficulty of generating blocks.

The client accepts the 'longest' chain of blocks as valid. The 'length' of the entire [[block chain]] refers to the chain with the most combined difficulty, not the one with the most blocks. This prevents someone from forking the chain and creating a large number of low-difficulty blocks, and having it accepted by the network as 'longest'.

== Common Questions about Blocks ==

=== How many blocks are there? ===
[http://blockexplorer.com/q/getblockcount Current block count]

=== What is the maximum number of blocks? ===
There is no maximum number, blocks just keep getting added to the end of the chain at an average rate of one every 10 minutes.

==== Even when all 21 million coins have been generated? ====
Yes. The blocks are for proving that transactions existed at a particular time. Transactions will still occur once all the coins have been generated, so blocks will still be created as long as people are trading Bitcoins.

=== How long will it take me to generate a block? ===
No-one can say exactly. There is a [[Generation Calculator|generation calculator]] that will tell you how long it '''might''' take.

=== What if I'm 1% towards calculating a block and...? ===
There's no such thing as being 1% towards solving a block. You don't make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.

It's like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.

=== Where can I find more technical detail? ===
There is more technical detail on the [[block hashing algorithm]] page.

==See Also==

* [http://en.bitcoin.it/wiki/File:Total_bitcoins_over_time_graph.png Total Bitcoins Over Time]

{{fromold|block}}

[[Category:Technical]]
[[Category:Vocabulary]]

[[fr:Blocs]]

BlockExplorer.com

2011-03-02T23:36:51Z

Rgm: link to block and theymos pages

{{stub}}

'''Bitcoin Block Explorer''' (also known as '''Block Explorer''' or '''BBE''') is a service scanning bitcoin [[blocks]] and allowing visitors to see their content. It is operated by [[User:theymos|theymos]].

It is mainly aimed at advanced users who already know what blocks are and what kind of information they contain.

==Interfacing with BBE==

Use the [http://blockexplorer.com/q query pages] such as ''getreceivedbyaddress'' wherever possible. Note that these pages do not send a trailing newline, which may cause problems with your HTTP-fetching tool. When an error occurs, the result will begin with "ERROR:", followed by the error text. Your detection of "ERROR" must be case-insensitive. An empty result is also an error. Non-fatal errors will print query results on the next line after the error, though using this data is inadvisable.

To get block or transaction info, first find the hash of the item. This is done by using the search tool, which is accessible through a GET/HEAD request. For example, to get the hash of block number 444:
$ telnet blockexplorer.com 80
HEAD /search/444 HTTP/1.1
Host: blockexplorer.com

HTTP/1.1 302 Found
...
Location: http://blockexplorer.com/block/00000000cff43a64ec00bea1...
The hash is in the URL listed in the "location" header. Use it to get the JSON raw block:
http://blockexplorer.com/rawblock/00000000cff43a64ec00bea1...
Transactions use a URL like this:
http://blockexplorer.com/rawtx/cd5a933b2aec79c02f7ce36222930d4c85...

If the search returns any status code other than 302, then the search is bad. A status code of 200 indicates that the search was ambiguous, and the page body will contain links to the choices. [http://blockexplorer.com/search/111111 Example of search ambiguity]. A search with no search terms will 302-redirect to the home page.

Unfortunately, the JSON raw block/tx pages omit a lot of important information, and there is no similar page for addresses. A full XML interface is planned. Scraping the HTML pages is not recommended, as the layout can change at any time.

== External Links ==

* [http://blockexplorer.com/ Bitcoin Block Explorer main website]
* [http://blockexplorer.com/testnet Version for testnet]
* [http://blockexplorer.com/q Realtime stats and other queries] (RESTful)

[[Category:Services]]

Template:MainPage FAQ

2011-03-02T23:28:48Z

Rgm: link to Network article

'''Q. What is Bitcoin?'''

A. Bitcoin is a peer-to-peer currency. Peer-to-peer means that no central authority issues new money or tracks transactions. These tasks are managed collectively by the [[network]].

'''Q. How does Bitcoin work?'''

A. Bitcoin utilises [http://en.wikipedia.org/wiki/Public-key_cryptography public-key cryptography]. A coin contains the owner's public key. When a coin is transferred from user A to user B, A adds B’s public key to the coin, and the coin is signed using A's private key. B now owns the coin and can transfer it further. A is prevented from transferring the already spent coin to other users because a public list of all previous transactions is collectively maintained by the network. Before each transaction the coin’s validity will be checked.

<div style="text-align: right;" class="noprint">'''[[FAQ|See More]]'''</div>

Talk:Bitcoin

2011-03-02T23:25:46Z

Rgm: Is this page supposed to be a "what is it" page for the layman?

Why not make this page a copy of [http://en.wikipedia.org/wiki/Bitcoin the wikipedia article]?
--[[User:Rgm|Rgm]] 23:25, 2 March 2011 (GMT)

OpenCL miner

2011-03-02T18:33:51Z

Rgm: Link to list of NVIDIA and ATI cards that support CUDA/OpenCL

{{stub}}
An '''OpenCL miner''' is a bitcoin miner that uses the [http://en.wikipedia.org/wiki/OpenCL OpenCL framework] to perform the hashing computations. When used with a modern GPU, this can produce hash rates orders of magnitude higher than what can be achieved with a CPU. Hashing on a GPU requires an OpenCL or CUDA compatible graphics card ([http://www.nvidia.com/object/cuda_gpus.html NVIDIA], [http://developer.amd.com/gpu/AMDAPPSDK/pages/DriverCompatibility.aspx ATI/AMD]).

The python [[Poclbm]] open source OpenCL bitcoin miner was created by m0mchil<ref>[http://www.bitcoin.org/smf/index.php?topic=1334.0 m0mchil's announcement on the forum]</ref> based on the open source CUDA client originally released by puddinpop<ref>[http://www.bitcoin.org/smf/index.php?topic=133.msg13135#msg13135 puddinpop's open source CUDA miner]</ref>. Subsequently the java [[DiabloMiner]] based on m0mchil's was created by Diablo-D3<ref>[http://www.bitcoin.org/smf/index.php?topic=1721.0 Diablo's announcement on the forum]</ref>. Puddinpop has also released a C++ OpenCL client capable of being compiled into the GUI client or daemon, or as a stand alone RPC miner<ref>[http://www.bitcoin.org/smf/index.php?topic=2444.0 puddinpop's RPC miners]</ref>.

See the [[Mining Hardware Comparison]] page for detailed statistics on the hash rates that can be achieved with various hardware.

==See Also==

* [[Poclbm|momchil's OpenCL miner]]
* [[DiabloMiner|Diablo's miner]]
* [[RPC Miner|puddinpop's RPC miner]]

==References==
<references/>

[[Category:Mining]]

Scalability

2011-03-02T18:24:18Z

Rgm: More cross link (in opening paragraphs) = more better

The core BitCoin network can scale to very high [[transactions|transaction]] rates assuming a distributed version of the node software is built. This would not be very complicated.

==Scalability targets==

VISA handles on average around 2,000 transactions/sec, so call it a daily peak rate of 4,000/sec. They have burst capacity up to 10,000 transactions per second which they need to handle the busiest points of the holiday period (~8,500tps). [http://investor.visa.com/phoenix.zhtml?c=215693&p=irol-newsArticle_print&ID=1355716]

Let's take 4,000 tps as starting goal. Obviously if we want BitCoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand transactions/sec. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let's us do some basic calculations even if it's a little arbitrary.

==CPU and block chain storage==

The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.

The big cost is the crypto and block chain lookups involved with verifying the transaction. An ECDSA verification of a transaction input takes around 3msec on a modern Intel core. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds, ie it's dwarfed by the cost of the ECDSA.

The bulk of the rest of the time in verifying a transaction today probably goes on disk IO, but in our hypothetical future the entire block chain would surely be stored in RAM (or flash). Reading from RAM or even flash is cheap. Even if you assume a gigantic block chain, it's quite feasible to hold the whole thing in RAM. Consider that Google holds large parts of the web in RAM today if you don't believe me.

So the slowest part of verifying a transaction is verifying its inputs, which is ~3 msec per input on todays hardware. It seems like in the current blockchain most transactions have only one input, and a few have more like 5/6 inputs. Let's call it an average of 2 inputs overall. However each transaction input is verified twice: once when first received, and a second time when a block containing that transaction is received, so call it 12msec in total per transaction.

So this means a single core today can probably, with tuning and the block chain held in RAM but no special hardware beyond that, verify and accept about 80 transactions/sec. Writing data out over the network to peers is cheap and can be done largely by the NIC itself so that's not a concern. This means a network node capable of keeping up with VISA would need roughly 50 cores + whatever is used for mining (done by separate machines/GPUs). Whilst building a single machine with 50 cores would be kind of a pain load balancing inbound "tx" messages over multiple machines would be very easy. Certainly a single machine could easily load balance all of VISAs transactions to a small group of verification machines which would then send the verified tx hash to the miners for incorporation into the merkle tree.

For receiving and handling all the "tx" messages, you could build a rack of 12 4-core machines that would keep up easily. And there are cryptographic techniques that can speed up the type of ECDSA verification BitCoin needs considerably.

That leaves the inbound inv messages. The cost of handling an inv is basically reading a small message from the network and then doing a RAM lookup to see if we already have the transaction. This is really, really fast. A single core could easily handle several thousand inv messages per second before breaking a sweat, even assuming it needs to read from a sharded in-memory block chain index.

So with some adapted software, you could build a distributed BitCoin network node that could keep up with VISA with probably 2 or 3 racks of machines assuming the block chain and associated indexes are either kept in regular RAM or (more likely) flash storage. So something a rich hobbyist could do, but more likely for small company or organization today - not even taking into account the falling cost of computing over time. If BitCoin is ever as large as VISA there'll be plenty of people willing to run such rigs.

==Network==

Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but from looking at the block explorer it's probably averaging half a kilobyte today. So let's assume the way people use BitCoin gets more complicated and call it 1kb per transaction.

A solved block will then be around (1kb * 2000tps * 60 * 10) / 1024 / 1024 = 1.14 gigabytes per block.

But you only have to transmit a solved block to your connected peers. If we assume these big futuristic supernodes have something like 40 or 50 peered connections, that means in the worst case scenario where you solve a block OR you receive a block but none of your peers have it yet (unlikely), you have to send ~57 gigabytes of data (call it 60).

Shifting 60 gigabytes of data in, say, 60 seconds means an average rate of 1 gigabyte per second, or 8 gigabits per second.

The real question you want to know is how much does that sort of bandwidth cost? Well, bandwidth prices are a very tricky thing as some of the largest consumers pay the least due to how peering agreements work. The Googles and Akamais of this world will pay way less for a 10G wave than a small operator would. And, you wouldn't be hitting the 8Gbps very frequently .... only when you solve a block, really, as when relaying a block the peers you connect to will likely have already received it from some other peer anyway so only a subset would need to receive it from you. But you can take a look at [http://icecolo.com/colocation-packages] to get a feel for it.

If you wanted to run a distributed supernode that held the block chain in flash/ram etc, you'd probably buy an 11u quarter rack from them at 250 pound sterling a month, which also gets you 3T of data transfer per month beyond just power and cooling. So you could potentially do a full block broadcast 50 times per month. Certainly you could negotiate that up if you needed to.

It's very unlikely that a hypothetical VISA scale BitCoin network would have nodes which win a block every single day, at least, a healthy network would hopefully not have hash power concentrated so tightly into single miner nodes.

It's also possible to optimize the protocol somewhat. A solved block could be broadcast as only its header and merkle tree. Nodes would then check the transaction hashes against their own in-memory lists. If a block contains a transaction the node did not see for some reason, it'd then request only those transactions. For the common case of a node with good, 24/7 network connectivity, this would reduce the size of block broadcasts dramatically.

[[Category:Technical]]

User:Rgm

2011-03-02T18:00:26Z

Rgm: User page for contributor's participant

I started on Bitcoin Friday February 26th, 2011. I am interested in issues of digital identity and webs of trust.

Contributors Award participant: 1A5vZAwEUt99ntknPAC8LptG9mAXn8NGXG

Template:MainPage Reasons

2011-03-02T17:39:59Z

Rgm: more links to content

* Bitcoins are sent easily through the Internet, without trusting middlemen.
* [[Transactions]] are irreversible by design.
* Be safe from instability caused by fractional reserve banking and central banks. The limited inflation of the Bitcoin system's money supply is distributed evenly (by CPU power) throughout the network, not monopolized by banks.

Miner fees

2011-03-02T17:38:52Z

Rgm: Add cross-link back to Transactions

[[File:fee.png|thumb|Receiving a transaction fee of 0.44 BC]]
Transaction fees may be included with any transfer of bitcoins from one address to another. At the moment, many [[transactions]] are typically processed in a way where no fee is expected at all, but for transactions which draw coins from many bitcoin addresses and therefore have a large data size, a small transaction fee is usually expected.

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

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

It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be "mined" from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the "mining" activity is zero.

It works like this:
* Whoever sends the transaction is often able to guess what the appropriate fee will be based on their own fee rules. The official client will always assess the transaction, and if a fee will typically be expected, it will not allow you to send the transaction without the calculated fee.
* The user is prompted to confirm the fee before the transaction is sent.
* The sender makes a transaction with more coins in the "In" portion than the "Out" portion so that there are "leftovers" not assigned to any address.
* Whoever ends up publishing the [[block]] which contains this transaction will take these (and any) "leftover" coins. They are included with their normal generated coins and is an extra "bonus" for creating the block.
* If a generating node receives a transaction that should include a transaction fee but doesn't, they refuse to include it in their blocks. It might be included in a later block if someone is willing to accept it. Generators can't force a certain fee on transactions -- they can only accept or reject the transaction's "fee offer".
[[File:lfm_fee.png|thumb|This balance is made entirely of 0.01 BTC "cents". Since sending them requires a lot of data, a very large fee is required.]]

Different versions of Bitcoin have different rules for determining which transactions to accept and how large of a fee to send.

Current "Default" Rules for the regular Bitcoin client (Bitcoin 0.3.17)
* 0.01 BTC fee if sending any transaction less than 0.01 BTC. This is to help prevent DoS attacks against the network. Remember: fees are not network-enforced, so it's still ''possible'' to send these small transactions without the fee -- you just have to generate the blocks that contain them yourself (after modifying Bitcoin).
* 0.01 BTC fee per kilobyte of transaction, but:
** If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free.
** If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.
* Transactions within each fee tier are prioritized based on several factors. Most importantly, a transaction has more priority if the coins it is using have a lot of confirmations. Someone spamming the network will almost certainly be re-using the same coins, which will lower the priority of their transactions. Priority is also increased for transactions with more BTC, and reduced for transactions with more data.
* If the blocksize is over 4kB, free transactions in the above rules are only allowed if the transaction's priority is above a certain level.

An advantage for bitcoin users to include a transaction fee is that the likelihood of getting a transaction included into the next block is going to be higher than if a transaction fee is not included. This is a trade off of time vs. money put forward on the transaction fees, as you can be patient with a low or non-existent fee included in a transaction, or you can make sure that the transaction is processed immediately by including a higher fee than is typical.

The rules are far from set in stone, and the network can support many different rules simultaneously. If there are 10 generating nodes that never require a transaction fee and your client is modified to never send any transaction fee, then your transactions will eventually be picked up by one of those free nodes when they generate a block, though it will probably take a very long time. In the far future, different rules about transaction fees among generating nodes will probably create a clear choice between fees and transaction speed. For example, you might choose to spend 2% for a guaranteed spot in the next block or 0.01% for the transaction to be sent in a few hours.

As an example, clients that have block generation turned off don't know what the current blocksize is, and will therefore never pay a fee on transactions under 10 kilobytes. If you notice that your sent transactions take a very long time to accrue confirmations, this is possibly the cause. If this happens a lot (probably because the network is under attack), run Bitcoin with the -paytxfee switch: -paytxfee=0.01 will force a minimum fee of 0.01 per kilobyte for all sent transactions, which will prioritize your transactions over all free transactions.
[[File:feesend.png|thumb|Sending a transaction when the sender doesn't have enough money to actually pay the fee]]

ArtForz, who makes up a large percentage of the network's CPU power, never charged transaction fees (even for micro-transactions) for a period of several months.

{{fromold|transaction_fee}}

[[Category:Technical]]
[[Category:Vocabulary]]