https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Ptd&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T21:34:28ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Template:MainPage_Topics&diff=7719Template:MainPage Topics2011-04-26T12:53:50Z<p>Ptd: Added link to my meetups page</p>
<hr />
<div><!--<br />
First table is for tutorials. Left column = pages written for end users. Right column = pages for developers.<br />
Second table is for categories.<br />
--><br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
| scope="col" style="width: 200px;" |<br />
* [[Introduction]]<br />
* [[Getting started]]<br />
* [[Securing your wallet]]<br />
* [[Secure Trading|Trading Best Practices]]<br />
* [[Myths]]<br />
| scope="col" style="width: 200px;" |<br />
* [[PHP developer intro]]<br />
* [[API reference (JSON-RPC)]]<br />
* [[Protocol specification]]<br />
|}<br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
! scope="col" style="width: 200px;" |<br />
! scope="col" style="width: 200px;" |<br />
|-<br />
|<br />
* [[:Category:Clients|Clients]]<br />
* [[:Category:Mining|Mining]]<br />
* [[:Category:Exchanges|Exchanges]]<br />
* [[Press]]<br />
|<br />
* [[:Category:Economics|Economics]]<br />
* [[Trade|Bitcoin-accepting sites]]<br />
* [[Active Bounties|Outstanding Bitcoin Bounties]]<br />
* [[Meetups]]<br />
|}<br />
<br />
<div style="text-align: right;" class="noprint"><span class="plainlinks">[{{fullurl:Template:MainPage_Topics|action=edit}} '''Edit''']</span> &ndash; '''[[Special:Categories|See More]]'''</div></div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Meetups&diff=7718Meetups2011-04-26T12:51:27Z<p>Ptd: Created page with "Don't add everyone who's going the the "Who?" column, just prominent bitcoin members and organizers. {| class="wikitable" |- ! Group ! When? ! Where? ! Who? ! Other Notes |- | N..."</p>
<hr />
<div>Don't add everyone who's going the the "Who?" column, just prominent bitcoin members and organizers.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Group<br />
! When?<br />
! Where?<br />
! Who?<br />
! Other Notes<br />
|-<br />
| New York Bitcoin Users <br />
| 7:00 PM, 2nd Saturday of every month<br />
| ??? - Can someone who knows please add?<br />
| Bruce Wagner (Organizer) and others<br />
| Is this some sort of secret society, because the thing on meetup.com says "This location is shown only to members".<br />
|-<br />
| Washington, DC Bitcoin Users<br />
| 7:00 PM, 1st Monday of every month<br />
| Northside Social, 3211 Wilson Blvd Arlington, VA<br />
| Darrell Duane (Organizer) and others<br />
|<br />
|-<br />
| Silicon Valley Bitcoin Users<br />
| 7:00 PM, Tuesday, May 10, 2011<br />
| Sunnyvale Art Gallery Cafe, 251 W El Camino Real Sunnyvale, CA<br />
| Brian Mcqueen and others<br />
|<br />
|}</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Myths&diff=6163Myths2011-03-26T19:57:52Z<p>Ptd: /* Bitcoins value is based on how much electricity it takes to mine them */</p>
<hr />
<div>Lets clear up common Bitcoin misconceptions.<br />
<br />
<br />
<br />
== Bitcoins don't solve any problems that fiat and/or gold doesn't solve ==<br />
<br />
Unlike gold, bitcoins are:<br />
* easy to transfer and store<br />
* easy to verify authenticity<br />
<br />
Unlike fiat currencies, bitcoins are:<br />
* predictable, and decreasing, as far as the rate of monetary inflation<br />
* not controlled by a central authority<br />
<br />
Unlike electronic fiat currency systems, bitcoins are:<br />
* potentially anonymous<br />
* assets cannot be frozen<br />
<br />
== Bitcoin is backed by CPU cycles ==<br />
<br />
It is not correct to say that Bitcoin is backed by CPU power. A currency being "backed" by something means that it is pegged to something else via a central party at a certain exchange rate. You cannot exchange bitcoins for the computing power that was used to create them. Bitcoin is in this sense not backed by anything. It is a commodity in its own right. Similar to gold - is gold backed by anything? No! It's just gold. Same thing with bitcoin. <br />
<br />
The Bitcoin currency is ''created'' via processing power, and the integrity of the block chain is ''protected'' by the existence of a large network of computing nodes from certain possible [[Weaknesses#Attacker_has_a_lot_of_computing_power|attacks]] exists. And that is all.<br />
<br />
== Bitcoins are worthless because they aren't backed by anything ==<br />
<br />
Gold isn't backed by anything either. See myth https://en.bitcoin.it/wiki/Myths#Bitcoin_is_backed_by_CPU_cycles<br />
<br />
== Bitcoins value is based on how much electricity and computing power it takes to mine them ==<br />
<br />
This statement is an attempt to apply to bitcoin the [http://en.wikipedia.org/wiki/Labor_theory_of_value labor theory of value], which is generally accepted as false. Just because something takes X resources to create does not mean that the resulting product will be worth X. It can be worth more, or less, depending on the utility thereof to its users. <br />
<br />
In fact the causality is the reverse of that (this applies to the labor theory of value in general). The cost to mine bitcoins is based on how much they are worth. If bitcoins go up in value, more people will mine (because mining is profitable), thus [difficulty] will go up, thus the cost of mining will go up. The inverse happens if bitcoins go down in value. These effects balance out to cause mining to always cost the amount of bitcoins it produces.<br />
<br />
== Bitcoins have no intrinsic value (unlike some other things) ==<br />
<br />
It is true that bitcoins have no intrinsic value, in other words, value in any realm outside of being used as a medium of exchange.<br />
<br />
However, while some tangible commodities do have intrinsic value, that value is generally much less than its trading price. Consider for example that gold, if it were not used as an inflation-proof store of value, but rather only for its industrial uses, would certainly not be worth what it is today, since the industrial requirements for gold are far smaller than the available supply thereof.<br />
<br />
While historically intrinsic value, as well as other attributes like divisibility, fungibility, scarcity, durability, helped establish certain commodities as mediums of exchange, it is certainly not a prerequisite. While bitcoins lack 'intrinsic value', they make up for it in spades by possessing the other qualities necessary to make it a good medium of exchange.<br />
<br />
Value is ultimately determined by what people are willing to trade for - by supply and demand.<br />
<br />
== Bitcoins are illegal because it's not legal tender ==<br />
<br />
Short answer: chickens aren't legal tender either, but bartering with chickens is not illegal.<br />
<br />
There are a [http://en.wikipedia.org/wiki/Local_currency number of currencies] in existence that are not official government-backed currencies. A currency is, after all, nothing more than a convenient unit of account. While national laws may vary from country to country, and you should certainly check the laws of your jurisdiction, in general trading in any commodity, including digital commodities like bitcoin, game currencies like WoW gold or Linden dollars, is not illegal.<br />
<br />
== Bitcoin is a form of domestic terrorism because it only harms the economic stability of the USA and its currency ==<br />
<br />
http://en.wikipedia.org/wiki/Definitions_of_terrorism#United_States according to this, you need to do violent activities to be considered a terrorist for legal purposes. This has no bearing on politicians and idiotic US attorney's public remarks.<br />
<br />
Also bitcoin isn't domestic. It's a worldwide community. See this map of bitcoin nodes <br />
http://www.bitcoin.org/smf/index.php?topic=2346.0<br />
<br />
== Bitcoin will only enable tax evaders which will lead to the eventual downfall of civilization ==<br />
<br />
It's up to you to follow the applicable state laws in your home country, or face the consequences.<br />
<br />
== Bitcoins can be printed/minted by anyone and are therefore worthless ==<br />
<br />
It requires substantial computing power to generate new coins, and eventually all the coins will be generated.<br />
<br />
== Bitcoins are worthless because it's based on unproven cryptography ==<br />
<br />
SHA256 and ECDSA which are used in Bitcoin are well-known industry standard algorithms.<br />
<br />
== Early adopters are unfairly rewarded ==<br />
<br />
Early adopters are rewarded for taking the higher risk with their time and money. <br />
<br />
In more pragmatic terms, "fairness" is an arbitrary concept that is improbable to be agreed upon by a large population. Establishing "fairness" is no goal of Bitcoin, as this would be impossible.<br />
<br />
The vast majority of the 21 million Bitcoins still have not been distributed. By starting to mine or acquire Bitcoins today, you too can become an early adopter.<br />
<br />
== 21 million coins isn't enough, doesn't scale ==<br />
<br />
There are really 2,099,999,997,690,000 (just over 2 quadrillion) maximum possible atomic units in the bitcoin design.<br />
<br />
The value of "1 BTC" represents 100,000,000 of these. In other words, each is divisible by up to 10^8. <br />
<br />
As the value of the unit of 1 BTC grows too large to be useful for day to day transactions, people can start dealing in smaller [[Units|units]], such as milli-bitcoins (mBTC) or micro-bitcoins (μBTC).<br />
<br />
== Bitcoins are stored in wallet files, just copy the wallet file to get more coins! ==<br />
<br />
No, your wallet contains your secret keys. Your rights to spend your bitcoins. Think of it like having lots of bank details stored in a file. If you give you bank details (or bitcoin wallet), that doesn't double the ammount of money in your account. You can spend your money or they can spend your money but not both.<br />
<br />
== Lost coins can't be replaced and this is bad ==<br />
<br />
Bitcoins are divisible to 0.00000001, so this is not a problem. If you lose your coins, all other coins will go up in value a little. Consider it a donation to all other bitcoin users.<br />
<br />
A related question is: Why don't we have a mechanism to replace lost coins? The answer is that it is impossible to distinguish between a 'lost' coin and one that is simply sitting unused in someone's safe.<br />
<br />
== It's a giant ponzi scheme ==<br />
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.<br />
<br />
Not to be confused with the [[Bitcoin randomizer|Bitcoin Randomizer]] which is a game that really is self-described as a Ponzi scheme.<br />
<br />
== Deflationary spiral ==<br />
As deflationary forces may apply, economic factors such as hoarding are offset by human factors that may lessen the chances that a [[Deflationary spiral]] will occur.<br />
<br />
== Bitcoin can't work because there is no way to control inflation ==<br />
<br />
Inflation is simply a rise of prices over time, which is generally the result of the devaluing of a currency. This is a function of supply and demand. Given the fact that the supply of Bitcoins is fixed at a certain amount, unlike fiat money, the only way for inflation to get out of control is for demand to disappear.<br />
<br />
Given the fact that Bitcoin is a distributed system of currency, if demand were to decrease to almost nothing, the currency would be doomed anyway.<br />
<br />
The key point here is that Bitcoin as a currency can't be inflated by any single person or entity, like a government, as there's no way to increase supply past a certain amount.<br />
<br />
Indeed, the most likely scenario, as Bitcoin becomes more popular and demand increases, is for the currency to increase in value, or deflate, until demand stabilizes.<br />
<br />
== Bitcoin community are anarchist/conspiracy theorist/gold standard weenies ==<br />
<br />
CONFIRMED<br />
<br />
== Anyone with enough computing power can take over the network ==<br />
<br />
CONFIRMED, see [[Weaknesses]].<br />
<br />
That said, as the network grows, it becomes harder and harder for a single entity to do so. Already the bitcoin network's computing power is on par with some of the world's fastest supercomputers.<br />
<br />
What an attacker can do once the network is taken over is quite limited. Under no circumstances could an attacker take anybody else's money. An attacker's capabilities are limited to taking back their own money that they very recently spent, and preventing other people's transactions from receiving confirmations. Such an attack would be very costly in resources, and for such meager benefits there is little rational economic incentive to do such a thing.<br />
<br />
== Bitcoin violates some sort of government regulations ==<br />
<br />
Name them if you can.<br />
<br />
See also the [[Myths#Bitcoins_are_illegal_because_it_s_not_legal_tender|legal tender]] question.<br />
<br />
== Fractional reserve banking is not possible ==<br />
<br />
Yes, it is. <br />
<br />
1. Start Bitcoin Bank.<br />
<br />
2. Accept deposits from customers<br />
<br />
3. Make loans, using part of the funds deposited by customers, keeping a '''fraction''' thereof in '''reserve'''.<br />
<br />
4. ????<br />
<br />
5. PROFIT! <br />
<br />
See [http://en.wikipedia.org/wiki/Fractional-reserve_banking Fractional reserve banking].<br />
<br />
Peanut Gallery: But how does the bank guarantee that account holders can withdraw 100% of their bitcoins?<br />
<br />
Same way non-bitcoin banks do it - they don't. They rely on the government's [http://en.wikipedia.org/wiki/Federal_Deposit_Insurance_Corporation FDIC] program to insure depositors up to a certain amount (currently $250K USD per depositor). The FDIC is widely known to have reserves sufficient to cover only a very small fraction of the total deposits it insures.<br />
<br />
== Point of sale with bitcoins isn't possible because of the 10 minute wait for confirmation ==<br />
<br />
Tansactions '''can''' take tens of minutes to become confirmed, and this won't change for the forseeable future. Even after the computing power of the network is orders of magnitude larger than today, the difficulty of generating a block will self-adjust to maintain a target of 6 blocks per hour. Two potential solutions to allow POS transactions are:<br />
<br />
1) For small transactions, simply assume the customer isn't ripping you off. Give the customer his latte immediately after the transaction posts to the network. The transaction should propagate through the network almost instantly, allowing the seller to see the transaction within seconds (albeit with zero confirmations.) The cost of a double-spend attack should make small-scale fraud not worthwhile.<br />
<br />
2) Create a network of transaction hubs. These entities would communicate using a common API. They would float short-term loans between each other to facilitate instant transactions. <br />
<br />
Imagine that Alice uses Carol's Clearinghouse as her hub, and Bob uses Dave's Anonymous Exchange. Both Alice and Bob have accounts with their respective hubs, and have already deposited some Bitcoins in their accounts. When Alice wants to buy a latte from Bob at a point of sale, Alice tells Carol "I want to send Bob ''x'' Bitcoins. He uses Dave's Anonymous Exchange." After checking that Alice's account does contain at least ''x'' Bitcoins, Carol sends a message to Dave, saying "Credit Bob's account with ''x'' bitcoins immediately; I'll send you the real Bitcoins in the next block." Bob instantly sees his balance increase, and gives Alice her latte.<br />
<br />
As always, trust is required - Alice has to trust Carol, and the hubs have to trust each other. Due to competition, various hubs could develop with vastly different fee structures, membership requirements, trustability, etc.<br />
<br />
(But the point of bitcoin is you don't need trust to execute the transaction, in the above you replaced the bitcoins with a trust-based centralized authority.)<br />
<br />
== After 21 million coins are mined, no one will generate new blocks ==<br />
<br />
When operating costs can't be covered by the block creation bounty, which will happen some time before the total amount of BTC is reached, miners are expected to earn profit from [[transaction fees]].<br />
<br />
== Bitcoin has no built-in chargeback mechanism, and this is bad ==<br />
<br />
'''Why some people think this is bad''': Chargebacks are useful for limiting fraud. The person handling your money has a responsibility to prevent fraud. If you buy something on Ebay and the seller never ships it, PayPal takes funds from the seller's account and gives you back the money. This strengthens the Ebay economy, because people recognize that their risk is limited and are more willing to purchase items from risky sellers.<br />
<br />
'''Why it's actually a good thing''': Bitcoin is designed such that your money is yours and yours alone. Allowing chargebacks implies that it is possible for another entity to take your money from you. You can have either total ownership rights of your money, or fraud protection, but not both. <br />
<br />
The statement "The person handling your money has a responsibility to prevent fraud" is still true; the power has been shifted into your own hands. Fraud will always exist. It's up to you to only send bitcoins to trusted entities. It is possible to trust an online identity without ever knowing their physical identity; see the [http://wiki.bitcoin-otc.com/wiki/OTC_Rating_System OTC Web of Trust].<br />
<br />
== Bitcoin is just like all the other virtual currencies, nothing new ==<br />
<br />
All other virtual currencies are centrally controlled. This means that:<br />
* they can be printed at the subjective whims of the controllers<br />
* they can be destroyed by attacking the central point of control<br />
* arbitrary rules can be imposed upon their users by the controllers<br />
<br />
Being decentralized, bitcoin solves all of these problems.<br />
<br />
== Quantum computers would break bitcoin's security ==<br />
<br />
Yes, but quantum computers don't yet exist and probably won't for a while. Bitcoin's security can be [http://en.wikipedia.org/wiki/Post-quantum_cryptography upgraded] if this were considered an imminent threat.<br />
<br />
See the implications of quantum computers on public key cryptography here http://en.wikipedia.org/wiki/Quantum_computer#Potential<br />
<br />
The ''risk'' of quantum computers is also there for financial institutions, like banks, because they heavily rely on cryptography when doing transactions.<br />
<br />
== Bitcoin mining is a waste of energy and harmful for ecology ==<br />
<br />
No more so than the the wastefulness of mining gold out of the ground, melting it down and shaping it into bars, and then putting it back underground again. Not to mention the building of big fancy buildings, the waste of energy printing and minting all the various fiat currencies, the transportation thereof in armored cars by no less than two security guards for each who could probably be doing something more productive, etc. <br />
<br />
As far as mediums of exchange go, bitcoin is actually quite economical of resources, compared to others.<br />
<br />
== Shopkeepers can't seriously set prices in bitcoins because of the volatile exchange rate ==<br />
<br />
The assumption is that bitcoins must be sold immediately to cover operating expenses. This might not be the case for various reasons, make sure you need to do that.<br />
<br />
It's true that due to the small size of the bitcoin market, there's relatively high volatility. In the future volatility is expected to decrease, as the size and depth of the market grows. <br />
<br />
In the meantime, many merchants simply regularly pull the latest market rates from the exchanges and automatically update the prices on their websites. Also you might be able to buy a put option in order to sell at a fixed rate for a given amount of time. This would protect you from drops in price and simplify your operations for that time period.<br />
<br />
== Like Flooz and e-gold, bitcoins are great for criminals and so will be shut down ==<br />
<br />
Gun control is arguably pretty great for criminals too.</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Myths&diff=6162Myths2011-03-26T19:45:08Z<p>Ptd: /* Bitcoins are stored in wallet files, just copy the wallet file to get more coins! */ Rewrite for clarity</p>
<hr />
<div>Lets clear up common Bitcoin misconceptions.<br />
<br />
<br />
<br />
== Bitcoins don't solve any problems that fiat and/or gold doesn't solve ==<br />
<br />
Unlike gold, bitcoins are:<br />
* easy to transfer and store<br />
* easy to verify authenticity<br />
<br />
Unlike fiat currencies, bitcoins are:<br />
* predictable, and decreasing, as far as the rate of monetary inflation<br />
* not controlled by a central authority<br />
<br />
Unlike electronic fiat currency systems, bitcoins are:<br />
* potentially anonymous<br />
* assets cannot be frozen<br />
<br />
== Bitcoin is backed by CPU cycles ==<br />
<br />
It is not correct to say that Bitcoin is backed by CPU power. A currency being "backed" by something means that it is pegged to something else via a central party at a certain exchange rate. You cannot exchange bitcoins for the computing power that was used to create them. Bitcoin is in this sense not backed by anything. It is a commodity in its own right. Similar to gold - is gold backed by anything? No! It's just gold. Same thing with bitcoin. <br />
<br />
The Bitcoin currency is ''created'' via processing power, and the integrity of the block chain is ''protected'' by the existence of a large network of computing nodes from certain possible [[Weaknesses#Attacker_has_a_lot_of_computing_power|attacks]] exists. And that is all.<br />
<br />
== Bitcoins are worthless because they aren't backed by anything ==<br />
<br />
Gold isn't backed by anything either. See myth https://en.bitcoin.it/wiki/Myths#Bitcoin_is_backed_by_CPU_cycles<br />
<br />
== Bitcoins value is based on how much electricity it takes to mine them ==<br />
<br />
This statement is an attempt to apply to bitcoin the [http://en.wikipedia.org/wiki/Labor_theory_of_value labor theory of value], which is generally accepted as false. Just because something takes X resources to create does not mean that the resulting product will be worth X. It can be worth more, or less, depending on the utility thereof to its users. <br />
<br />
Some trivial counterexamples: <br />
* It may take you an hour to build a sandcastle on the beach, but you will not be able to sell it in exchange for your usual hourly wage. <br />
* A 100 dollar bill does not cost anywhere near $100 in terms of labor and materials, but is worth $100.<br />
<br />
== Bitcoins have no intrinsic value (unlike some other things) ==<br />
<br />
It is true that bitcoins have no intrinsic value, in other words, value in any realm outside of being used as a medium of exchange.<br />
<br />
However, while some tangible commodities do have intrinsic value, that value is generally much less than its trading price. Consider for example that gold, if it were not used as an inflation-proof store of value, but rather only for its industrial uses, would certainly not be worth what it is today, since the industrial requirements for gold are far smaller than the available supply thereof.<br />
<br />
While historically intrinsic value, as well as other attributes like divisibility, fungibility, scarcity, durability, helped establish certain commodities as mediums of exchange, it is certainly not a prerequisite. While bitcoins lack 'intrinsic value', they make up for it in spades by possessing the other qualities necessary to make it a good medium of exchange.<br />
<br />
Value is ultimately determined by what people are willing to trade for - by supply and demand.<br />
<br />
== Bitcoins are illegal because it's not legal tender ==<br />
<br />
Short answer: chickens aren't legal tender either, but bartering with chickens is not illegal.<br />
<br />
There are a [http://en.wikipedia.org/wiki/Local_currency number of currencies] in existence that are not official government-backed currencies. A currency is, after all, nothing more than a convenient unit of account. While national laws may vary from country to country, and you should certainly check the laws of your jurisdiction, in general trading in any commodity, including digital commodities like bitcoin, game currencies like WoW gold or Linden dollars, is not illegal.<br />
<br />
== Bitcoin is a form of domestic terrorism because it only harms the economic stability of the USA and its currency ==<br />
<br />
http://en.wikipedia.org/wiki/Definitions_of_terrorism#United_States according to this, you need to do violent activities to be considered a terrorist for legal purposes. This has no bearing on politicians and idiotic US attorney's public remarks.<br />
<br />
Also bitcoin isn't domestic. It's a worldwide community. See this map of bitcoin nodes <br />
http://www.bitcoin.org/smf/index.php?topic=2346.0<br />
<br />
== Bitcoin will only enable tax evaders which will lead to the eventual downfall of civilization ==<br />
<br />
It's up to you to follow the applicable state laws in your home country, or face the consequences.<br />
<br />
== Bitcoins can be printed/minted by anyone and are therefore worthless ==<br />
<br />
It requires substantial computing power to generate new coins, and eventually all the coins will be generated.<br />
<br />
== Bitcoins are worthless because it's based on unproven cryptography ==<br />
<br />
SHA256 and ECDSA which are used in Bitcoin are well-known industry standard algorithms.<br />
<br />
== Early adopters are unfairly rewarded ==<br />
<br />
Early adopters are rewarded for taking the higher risk with their time and money. <br />
<br />
In more pragmatic terms, "fairness" is an arbitrary concept that is improbable to be agreed upon by a large population. Establishing "fairness" is no goal of Bitcoin, as this would be impossible.<br />
<br />
The vast majority of the 21 million Bitcoins still have not been distributed. By starting to mine or acquire Bitcoins today, you too can become an early adopter.<br />
<br />
== 21 million coins isn't enough, doesn't scale ==<br />
<br />
There are really 2,099,999,997,690,000 (just over 2 quadrillion) maximum possible atomic units in the bitcoin design.<br />
<br />
The value of "1 BTC" represents 100,000,000 of these. In other words, each is divisible by up to 10^8. <br />
<br />
As the value of the unit of 1 BTC grows too large to be useful for day to day transactions, people can start dealing in smaller [[Units|units]], such as milli-bitcoins (mBTC) or micro-bitcoins (μBTC).<br />
<br />
== Bitcoins are stored in wallet files, just copy the wallet file to get more coins! ==<br />
<br />
No, your wallet contains your secret keys. Your rights to spend your bitcoins. Think of it like having lots of bank details stored in a file. If you give you bank details (or bitcoin wallet), that doesn't double the ammount of money in your account. You can spend your money or they can spend your money but not both.<br />
<br />
== Lost coins can't be replaced and this is bad ==<br />
<br />
Bitcoins are divisible to 0.00000001, so this is not a problem. If you lose your coins, all other coins will go up in value a little. Consider it a donation to all other bitcoin users.<br />
<br />
A related question is: Why don't we have a mechanism to replace lost coins? The answer is that it is impossible to distinguish between a 'lost' coin and one that is simply sitting unused in someone's safe.<br />
<br />
== It's a giant ponzi scheme ==<br />
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.<br />
<br />
Not to be confused with the [[Bitcoin randomizer|Bitcoin Randomizer]] which is a game that really is self-described as a Ponzi scheme.<br />
<br />
== Deflationary spiral ==<br />
As deflationary forces may apply, economic factors such as hoarding are offset by human factors that may lessen the chances that a [[Deflationary spiral]] will occur.<br />
<br />
== Bitcoin can't work because there is no way to control inflation ==<br />
<br />
Inflation is simply a rise of prices over time, which is generally the result of the devaluing of a currency. This is a function of supply and demand. Given the fact that the supply of Bitcoins is fixed at a certain amount, unlike fiat money, the only way for inflation to get out of control is for demand to disappear.<br />
<br />
Given the fact that Bitcoin is a distributed system of currency, if demand were to decrease to almost nothing, the currency would be doomed anyway.<br />
<br />
The key point here is that Bitcoin as a currency can't be inflated by any single person or entity, like a government, as there's no way to increase supply past a certain amount.<br />
<br />
Indeed, the most likely scenario, as Bitcoin becomes more popular and demand increases, is for the currency to increase in value, or deflate, until demand stabilizes.<br />
<br />
== Bitcoin community are anarchist/conspiracy theorist/gold standard weenies ==<br />
<br />
CONFIRMED<br />
<br />
== Anyone with enough computing power can take over the network ==<br />
<br />
CONFIRMED, see [[Weaknesses]].<br />
<br />
That said, as the network grows, it becomes harder and harder for a single entity to do so. Already the bitcoin network's computing power is on par with some of the world's fastest supercomputers.<br />
<br />
What an attacker can do once the network is taken over is quite limited. Under no circumstances could an attacker take anybody else's money. An attacker's capabilities are limited to taking back their own money that they very recently spent, and preventing other people's transactions from receiving confirmations. Such an attack would be very costly in resources, and for such meager benefits there is little rational economic incentive to do such a thing.<br />
<br />
== Bitcoin violates some sort of government regulations ==<br />
<br />
Name them if you can.<br />
<br />
See also the [[Myths#Bitcoins_are_illegal_because_it_s_not_legal_tender|legal tender]] question.<br />
<br />
== Fractional reserve banking is not possible ==<br />
<br />
Yes, it is. <br />
<br />
1. Start Bitcoin Bank.<br />
<br />
2. Accept deposits from customers<br />
<br />
3. Make loans, using part of the funds deposited by customers, keeping a '''fraction''' thereof in '''reserve'''.<br />
<br />
4. ????<br />
<br />
5. PROFIT! <br />
<br />
See [http://en.wikipedia.org/wiki/Fractional-reserve_banking Fractional reserve banking].<br />
<br />
Peanut Gallery: But how does the bank guarantee that account holders can withdraw 100% of their bitcoins?<br />
<br />
Same way non-bitcoin banks do it - they don't. They rely on the government's [http://en.wikipedia.org/wiki/Federal_Deposit_Insurance_Corporation FDIC] program to insure depositors up to a certain amount (currently $250K USD per depositor). The FDIC is widely known to have reserves sufficient to cover only a very small fraction of the total deposits it insures.<br />
<br />
== Point of sale with bitcoins isn't possible because of the 10 minute wait for confirmation ==<br />
<br />
Tansactions '''can''' take tens of minutes to become confirmed, and this won't change for the forseeable future. Even after the computing power of the network is orders of magnitude larger than today, the difficulty of generating a block will self-adjust to maintain a target of 6 blocks per hour. Two potential solutions to allow POS transactions are:<br />
<br />
1) For small transactions, simply assume the customer isn't ripping you off. Give the customer his latte immediately after the transaction posts to the network. The transaction should propagate through the network almost instantly, allowing the seller to see the transaction within seconds (albeit with zero confirmations.) The cost of a double-spend attack should make small-scale fraud not worthwhile.<br />
<br />
2) Create a network of transaction hubs. These entities would communicate using a common API. They would float short-term loans between each other to facilitate instant transactions. <br />
<br />
Imagine that Alice uses Carol's Clearinghouse as her hub, and Bob uses Dave's Anonymous Exchange. Both Alice and Bob have accounts with their respective hubs, and have already deposited some Bitcoins in their accounts. When Alice wants to buy a latte from Bob at a point of sale, Alice tells Carol "I want to send Bob ''x'' Bitcoins. He uses Dave's Anonymous Exchange." After checking that Alice's account does contain at least ''x'' Bitcoins, Carol sends a message to Dave, saying "Credit Bob's account with ''x'' bitcoins immediately; I'll send you the real Bitcoins in the next block." Bob instantly sees his balance increase, and gives Alice her latte.<br />
<br />
As always, trust is required - Alice has to trust Carol, and the hubs have to trust each other. Due to competition, various hubs could develop with vastly different fee structures, membership requirements, trustability, etc.<br />
<br />
(But the point of bitcoin is you don't need trust to execute the transaction, in the above you replaced the bitcoins with a trust-based centralized authority.)<br />
<br />
== After 21 million coins are mined, no one will generate new blocks ==<br />
<br />
When operating costs can't be covered by the block creation bounty, which will happen some time before the total amount of BTC is reached, miners are expected to earn profit from [[transaction fees]].<br />
<br />
== Bitcoin has no built-in chargeback mechanism, and this is bad ==<br />
<br />
'''Why some people think this is bad''': Chargebacks are useful for limiting fraud. The person handling your money has a responsibility to prevent fraud. If you buy something on Ebay and the seller never ships it, PayPal takes funds from the seller's account and gives you back the money. This strengthens the Ebay economy, because people recognize that their risk is limited and are more willing to purchase items from risky sellers.<br />
<br />
'''Why it's actually a good thing''': Bitcoin is designed such that your money is yours and yours alone. Allowing chargebacks implies that it is possible for another entity to take your money from you. You can have either total ownership rights of your money, or fraud protection, but not both. <br />
<br />
The statement "The person handling your money has a responsibility to prevent fraud" is still true; the power has been shifted into your own hands. Fraud will always exist. It's up to you to only send bitcoins to trusted entities. It is possible to trust an online identity without ever knowing their physical identity; see the [http://wiki.bitcoin-otc.com/wiki/OTC_Rating_System OTC Web of Trust].<br />
<br />
== Bitcoin is just like all the other virtual currencies, nothing new ==<br />
<br />
All other virtual currencies are centrally controlled. This means that:<br />
* they can be printed at the subjective whims of the controllers<br />
* they can be destroyed by attacking the central point of control<br />
* arbitrary rules can be imposed upon their users by the controllers<br />
<br />
Being decentralized, bitcoin solves all of these problems.<br />
<br />
== Quantum computers would break bitcoin's security ==<br />
<br />
Yes, but quantum computers don't yet exist and probably won't for a while. Bitcoin's security can be [http://en.wikipedia.org/wiki/Post-quantum_cryptography upgraded] if this were considered an imminent threat.<br />
<br />
See the implications of quantum computers on public key cryptography here http://en.wikipedia.org/wiki/Quantum_computer#Potential<br />
<br />
The ''risk'' of quantum computers is also there for financial institutions, like banks, because they heavily rely on cryptography when doing transactions.<br />
<br />
== Bitcoin mining is a waste of energy and harmful for ecology ==<br />
<br />
No more so than the the wastefulness of mining gold out of the ground, melting it down and shaping it into bars, and then putting it back underground again. Not to mention the building of big fancy buildings, the waste of energy printing and minting all the various fiat currencies, the transportation thereof in armored cars by no less than two security guards for each who could probably be doing something more productive, etc. <br />
<br />
As far as mediums of exchange go, bitcoin is actually quite economical of resources, compared to others.<br />
<br />
== Shopkeepers can't seriously set prices in bitcoins because of the volatile exchange rate ==<br />
<br />
The assumption is that bitcoins must be sold immediately to cover operating expenses. This might not be the case for various reasons, make sure you need to do that.<br />
<br />
It's true that due to the small size of the bitcoin market, there's relatively high volatility. In the future volatility is expected to decrease, as the size and depth of the market grows. <br />
<br />
In the meantime, many merchants simply regularly pull the latest market rates from the exchanges and automatically update the prices on their websites. Also you might be able to buy a put option in order to sell at a fixed rate for a given amount of time. This would protect you from drops in price and simplify your operations for that time period.<br />
<br />
== Like Flooz and e-gold, bitcoins are great for criminals and so will be shut down ==<br />
<br />
Gun control is arguably pretty great for criminals too.</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Local_Currencies&diff=5259Local Currencies2011-03-11T09:00:50Z<p>Ptd: Page was copy of Wikipedia article "Local Currencies", I have blanked it. It should be deleted.</p>
<hr />
<div></div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Template:MainPage_Intro&diff=4645Template:MainPage Intro2011-03-01T12:29:28Z<p>Ptd: Clarified</p>
<hr />
<div>[[Image:Bitcoin world map.png|left|200px|Bitcoin usage worldwide.]]<br />
<br />
:''Sourced from [http://en.wikipedia.org/wiki/Bitcoin Wikipedia].''<br />
<br />
'''Bitcoin''' is a [[digital currency]] created in 2009 by [[Satoshi Nakamoto]]. It is also the name of the open source software designed in order to use this currency.<br />
<br />
Bitcoin is one of the first implementations of a concept called ''cryptocurrency'', which was first described in 1998 by Wei Dai on the cypherpunks mailing list. Building upon the notion that money is any object, or any sort of record, accepted as payment for goods and services and repayment of debts in a given country or socio-economic context, Bitcoin is designed around the idea of using cryptography to control the creation and transfer of money, rather than relying on central authorities.<br />
<br />
{|style="background-color: inherit;"<br />
|<br />
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.20/bitcoin-0.3.20.01-win32-setup.exe/download '''Windows (exe)'''] 5.2 MB<br />
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.20/bitcoin-0.3.20.01-win32.zip/download '''Windows (zip)'''] 5.2 MB<br />
| style="padding-left: 50px;" &nbsp; |<br />
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.20/bitcoin-0.3.20.01-linux.tar.gz/download '''Linux'''] 9.6 MB<br />
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.20/bitcoin-0.3.20.01-macosx.zip/download '''Mac OS X'''] 7.6 MB<br />
|}</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=BitcoinTalk&diff=4599BitcoinTalk2011-02-28T11:28:10Z<p>Ptd: Style</p>
<hr />
<div>The Bitcoin Forum is a message board where people interested in the technical details and the development of Bitcoin software can talk to each other. The forum also has places for people who are interested in bitcoin [[:Category:Mining|mining]], in trading with bitcoin, and in the economics of Bitcoin.<br />
<br />
==History==<br />
<br />
Before the creation of the current Bitcoin Forum, a SourceForge forum was used.<br />
<br />
==External links==<br />
<br />
* [http://www.bitcoin.org/smf/ Bitcoin Forum]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Talk:Trade&diff=3605Talk:Trade2011-02-13T12:59:36Z<p>Ptd: </p>
<hr />
<div>==Proposed Listing Standards==<br />
I propose the following standards be required for listing on the [Trade]. The listed site must<br />
# Be currently functional (downtime of less than 48 hours is acceptable)<br />
# Be currently accepting bitcoins<br />
# Have clear instructions for paying with bitcoins from the link given<br />
# Prices must be sane within an order of magnitude (non-sane prices indicate that the website has not been updated to match bitcoin deflation)<br />
The standards will help keep the list manageable and easy to use.<br />
<br />
<br />
This is a talk page, so please sign your contributions. I mostly agree, but the "sane prices" criterion seems a bit subjective ; there is a risk that we exclude goodwilling merchants, who would otherwise be willing to update their prices when contacted. [[User:ThomasV|ThomasV]] 10:43, 12 February 2011 (GMT)<br />
<br />
:Here is an example [http://bitcoin2cash.com/]. When I say "sane", I mean reasonable within an order of magnitude. I moved your other comment to a separate section for clarity [[User:Ptd|Ptd]] 12:59, 13 February 2011 (GMT)<br />
<br />
==Should we put addresses on the wiki?==<br />
We just had some bitcoin address spam. perhaps it would not have happened if we did not put bitcoin addresses on the wiki ? [[User:ThomasV|ThomasV]] 23:50, 12 February 2011 (GMT)</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Weaknesses&diff=3574Weaknesses2011-02-12T21:25:17Z<p>Ptd: /* Cancer nodes */ Added an idea</p>
<hr />
<div>== Might be a problem ==<br />
<br />
=== Tracing a coin's history ===<br />
Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br />
<br />
=== Cancer nodes ===<br />
It's trivial for an attacker to fill the network with clients controlled by him. This might be helpful in the execution of other attacks.<br />
<br />
For example, an attacker might connect 100,000 IP addresses to the IRC bootstrap channel. You would then be very likely to connect only to attacker nodes. This state can be exploited in (at least) the following ways:<br />
* The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br />
* The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.<br />
* If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br />
* Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.<br />
<br />
Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.<br />
<br />
Looking for suspiciously low network hash-rates may help prevent the second one.<br />
<br />
=== No authentication for IP transfers ===<br />
Since there's no authentication when sending to an [[IP address]], executing a man-in-the-middle attack and stealing the sent BitCoins is trivial. This attack is downright ''likely'' if you're using Tor.<br />
<br />
=== Packet sniffing ===<br />
Someone who can see all of your Internet traffic can easily see when you send a transaction that you didn't receive (which means that it's yours). This would be made more difficult (but not impossible) if node-to-node encryption was used.<br />
<br />
== Probably not a problem ==<br />
<br />
===Breaking the cryptography===<br />
SHA-256 and ECDSA are considered very strong currently, but they might be broken in the far future. If that happens, BitCoin can shift to a stronger algorithm. [http://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585 More info].<br />
<br />
===Scalability===<br />
BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br />
<br />
===Segmentation===<br />
If there is even a "trickle" of a connection between two sides of a segmented network, things should still work perfectly. When block chains are combined, all of the non-generation transactions in the shorter chain are re-added to the transaction pool -- they'll start over at 0/unconfirmed, but they'll still be valid. No mature transactions will be lost unless the segmentation persists for longer than ~120 blocks. Then generations will start to mature, and any transactions based on those generations will become invalid when recombined with the longer chain. [http://www.bitcoin.org/smf/index.php?topic=241.msg2071#msg2071 More info].<br />
<br />
=== Attacking all users ===<br />
The IP addresses of most users are totally public. You can use Tor to hide this, but the network won't work if everyone does this. BitCoin requires that ''some'' country is still free.<br />
<br />
=== Dropping transactions ===<br />
Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains "active" and can be included in a later block. Two things discourage this:<br />
* Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br />
* [[Satoshi]] has [http://www.bitcoin.org/smf/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br />
<br />
=== Attacker has a lot of computing power ===<br />
An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:<br />
* Reverse transactions that he sends while he's in control<br />
* Prevent some or all transactions from gaining any confirmations<br />
* Prevent some or all other generators from getting any generations<br />
The attacker ''can't'':<br />
* Reverse other people's transactions<br />
* Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br />
* Change the number of coins generated per block<br />
* Create coins out of thin air<br />
* Send coins that never belonged to him<br />
<br />
It's much more difficult to change historical blocks, and it becomes exponentially more difficult the further back you go. As above, changing historical blocks only allows you to exclude and change the ordering of transactions. It's impossible to change blocks created before the last checkpoint.<br />
<br />
Since this attack doesn't permit all that much power over the network, it is expected that no one will attempt it. A profit-seeking person will always gain more by just following the rules, and even someone trying to destroy the system will probably find other attacks more attractive. However, if this attack is successfully executed, it will be difficult or impossible to "untangle" the mess created -- any changes the attacker makes might become permanent.<br />
<br />
=== Spamming transactions ===<br />
<br />
It is easy to send transactions to yourself repeatedly. If these transactions fill blocks to the maximum size (1MB), other transactions would be delayed until the next block.<br />
<br />
This is made expensive by the [[transaction fee|fees]] that would be required after the 50KB of free transactions per block are exhausted. An attacker will eventually eliminate free transactions, but Bitcoin fees will always be low because raising fees above 0.01 BTC per KB would require spending transaction fees. An attacker will eventually run out of money. Even if an attacker wants to waste money, transactions are further prioritized by the time since the coins were last spent, so attacks spending the same coins repeatedly are less effective.<br />
<br />
== Definitely not a problem ==<br />
<br />
===Coin destruction===<br />
BitCoin has 8 decimals of precision, so the entire network could operate on just a handful of BitCoins. An attacker could never destroy them all. If deflation gets to the point where transactions of more than 10BC are unheard of, the client can just shift the decimal point over so that, for example, people with 0.001 BitCoins have 1.000 BitCents.<br />
<br />
===Generating tons of addresses===<br />
Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br />
<br />
===Rival/malicious client code===<br />
Any rival client must follow BitCoin's rules or else all current BitCoin clients will ignore it. You'd have to actually get people to ''use'' your client.<br />
<br />
===Everyone calculates at the same rate===<br />
If everyone began with identical blocks and started their nonce at 1 and incremented, the fastest machine would always win. However, each block contains a new, random public key known only to you in the list of transactions. The 256-bit "Merkle tree" hash of this is part of the block header.<br />
<br />
So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br />
<br />
===Generate "valid" blocks with a lower difficulty than normal===<br />
Using unmodified Bitcoin code, an attacker could segment himself from the main network and generate a long block chain with a lower difficulty than the real network. These blocks would be totally valid for his network. However, it would be impossible to combine the two networks (and the "false" chain would be destroyed in the process).<br />
<br />
* Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br />
* Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br />
* "Block chain length" is calculated from the combined difficulty of all the blocks, not just the number of blocks in the chain. The one that represents the most CPU usage will win.<br />
<br />
{{fromold|weaknesses}}<br />
<br />
[[Category:Technical]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Satoshi_Nakamoto&diff=3573Satoshi Nakamoto2011-02-12T21:21:30Z<p>Ptd: Edited for style</p>
<hr />
<div>[[File:Satoshi-nakamoto.gif|thumb|200px|right|Picture of Satoshi Nakamoto.]]<br />
<br />
'''Satoshi Nakamoto''' is the founder of [[Bitcoin]] and initial author of the [[Original Bitcoin client]]. He has said in a p2p foundation profile<ref name="p2p_f_profile">[http://p2pfoundation.ning.com/profile/SatoshiNakamoto Satoshi Nakamoto profile on P2P Foundation]</ref> that he is from Japan. Beyond that, not much is known about him. He has been working on Bitcoin for more than two years.<ref>[http://www.bitcoin.org/smf/index.php?topic=453.msg4068#msg4068 MSVC build & SHA-256]</ref><br />
<br />
==Possible Motives==<br />
<br />
He left some clues about why he is doing this project with the inclusion of the following text in the [[Genesis block]], "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks".<br />
<br />
Some interesting quotes:<br />
<blockquote><p>Yes, [we will not find a solution to political problems in cryptography,] but we can win a major battle in the arms race and gain a new territory of <br />
freedom for several years.</p><br />
<br />
<p>Governments are good at cutting off the heads of a centrally controlled <br />
networks like Napster, but pure P2P networks like Gnutella and Tor seem to be <br />
holding their own.<ref>[http://www.mail-archive.com/cryptography@metzdowd.com/msg09971.html Re: Bitcoin P2P e-cash paper Fri, 07 Nov 2008 09:30:36 -0800]</ref></p></blockquote><br />
<br />
<blockquote>It's very attractive to the libertarian viewpoint if we can explain it <br />
properly. I'm better with code than with words though. <ref>[http://www.mail-archive.com/cryptography@metzdowd.com/msg10001.html Re: Bitcoin P2P e-cash paper Fri, 14 Nov 2008 14:29:22]</ref></blockquote><br />
<br />
==Possible identity==<br />
<br />
His identity and nationality are unknown. The few bits of information available<ref name="p2p_f_profile"/> about him point to Japan, he never wrote a single line of Japanese, the Bitcoin client has no Japanese version and there is no Japanese page on [http://bitcoin.org bitcoin.org].<br />
<br />
He is entirely unknown outside of Bitcoin as far as anyone can tell, and his PGP key was created just months prior to the date of the genesis block. He seems to be very familiar with the cryptography mailing list, but there are no non-Bitcoin posts from him on it. He has used an email address from an anonymous mail hosting service (vistomail) as well as one from a free webmail account (gmx.com) and sends mail when connected via Tor. Some have speculated that his entire identity was created in advance in order to protect himself or the network. Perhaps he chose the name Satoshi because it can mean "wisdom" or "reason".<br />
<br />
==External links==<br />
* [http://www.bitcoin.org/Satoshi_Nakamoto.asc Satoshi's PGP public key]<br />
* [http://www.bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System] Paper<br />
* [http://sourceforge.net/users/s_nakamoto SourceForge page]<br />
<br />
==Notes==<br />
<references/><br />
[[Category:Bitcoiners]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Talk:Trade&diff=3470Talk:Trade2011-02-11T18:42:36Z<p>Ptd: Convert list to numbered and add a 4th condition</p>
<hr />
<div>==Proposed Listing Standards==<br />
I propose the following standards be required for listing on the [Trade]. The listed site must<br />
# Be currently functional (downtime of less than 48 hours is acceptable)<br />
# Be currently accepting bitcoins<br />
# Have clear instructions for paying with bitcoins from the link given<br />
# Prices must be sane (non-sane prices indicate that the website has not been updated to match bitcoin deflation)<br />
The standards will help keep the list manageable and easy to use.</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Talk:Trade&diff=3467Talk:Trade2011-02-11T17:38:04Z<p>Ptd: Added "Proposed Listing Standards"</p>
<hr />
<div>==Proposed Listing Standards==<br />
I propose the following standards be required for listing on the [Trade]. The listed site must<br />
* Be currently functional (downtime of less than 48 hours is acceptable)<br />
* Be currently accepting bitcoins<br />
* Have clear instructions for paying with bitcoins from the link given<br />
The standards will help keep the list manageable and easy to use.<br />
<br />
Opinions:<br />
* I think this is a great idea, just how I would have written them (well I did :) [[User:Ptd|Ptd]] 17:38, 11 February 2011 (GMT)</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Template:MainPage_Topics&diff=3453Template:MainPage Topics2011-02-11T11:40:10Z<p>Ptd: </p>
<hr />
<div><!--<br />
First table is for tutorials. Left column = pages written for end users. Right column = pages for developers.<br />
Second table is for categories.<br />
--><br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
| scope="col" style="width: 200px;" |<br />
* [[Getting started]]<br />
* [[Securing your wallet]]<br />
* [http://www.bitcoinmap.com/ Map of exchangers]<br />
| scope="col" style="width: 200px;" |<br />
* [[:Category:Developer|Developer pages]]<br />
* [[API tutorial (JSON-RPC)]]<br />
* [[Protocol specification]]<br />
|}<br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
! scope="col" style="width: 200px;" |<br />
! scope="col" style="width: 200px;" |<br />
|-<br />
|<br />
* [[:Category:Clients|Clients]]<br />
* [[:Category:Mining|Mining]]<br />
* [[:Category:Exchanges|Exchanges]]<br />
|<br />
* [[:Category:Economics|Economics]]<br />
* [[Trade|Bitcoin-accepting sites]]<br />
|}<br />
<br />
<div style="text-align: right;" class="noprint"><span class="plainlinks">[{{fullurl:Template:MainPage_Topics|action=edit}} '''Edit''']</span> &ndash; '''[[Special:Categories|See More]]'''</div></div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Template:MainPage_Topics&diff=3285Template:MainPage Topics2011-02-08T14:49:20Z<p>Ptd: Removed the "that accept bitcoin" from my previous edit (messes up formatting)</p>
<hr />
<div><!--<br />
First table is for tutorials. Left column = pages written for end users. Right column = pages for developers.<br />
Second table is for categories.<br />
--><br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
| scope="col" style="width: 200px;" |<br />
* [[Getting started]]<br />
* [[Securing your wallet]]<br />
* [http://www.bitcoinmap.com/ Map of exchangers]<br />
| scope="col" style="width: 200px;" |<br />
* [[:Category:Developer|Developer pages]]<br />
* [[API tutorial (JSON-RPC)]]<br />
* [[Protocol specification]]<br />
|}<br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
! scope="col" style="width: 200px;" |<br />
! scope="col" style="width: 200px;" |<br />
|-<br />
|<br />
* [[:Category:Clients|Clients]]<br />
* [[:Category:Mining|Mining]]<br />
* [[:Category:Exchanges|Exchanges]]<br />
|<br />
* [[:Category:Economics|Economics]]<br />
* [[:Category:Services|Services]]<br />
* [[Charities]]<br />
|}<br />
<br />
<div style="text-align: right;" class="noprint"><span class="plainlinks">[{{fullurl:Template:MainPage_Topics|action=edit}} '''Edit''']</span> &ndash; '''[[Special:Categories|See More]]'''</div></div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Template:MainPage_Topics&diff=3284Template:MainPage Topics2011-02-08T14:48:22Z<p>Ptd: Replaced "Original Wiki" link (It's all here now) with a link to the list of charities that accept bitcoin</p>
<hr />
<div><!--<br />
First table is for tutorials. Left column = pages written for end users. Right column = pages for developers.<br />
Second table is for categories.<br />
--><br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
| scope="col" style="width: 200px;" |<br />
* [[Getting started]]<br />
* [[Securing your wallet]]<br />
* [http://www.bitcoinmap.com/ Map of exchangers]<br />
| scope="col" style="width: 200px;" |<br />
* [[:Category:Developer|Developer pages]]<br />
* [[API tutorial (JSON-RPC)]]<br />
* [[Protocol specification]]<br />
|}<br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
! scope="col" style="width: 200px;" |<br />
! scope="col" style="width: 200px;" |<br />
|-<br />
|<br />
* [[:Category:Clients|Clients]]<br />
* [[:Category:Mining|Mining]]<br />
* [[:Category:Exchanges|Exchanges]]<br />
|<br />
* [[:Category:Economics|Economics]]<br />
* [[:Category:Services|Services]]<br />
* [[Charities]] that accept bitcoins<br />
|}<br />
<br />
<div style="text-align: right;" class="noprint"><span class="plainlinks">[{{fullurl:Template:MainPage_Topics|action=edit}} '''Edit''']</span> &ndash; '''[[Special:Categories|See More]]'''</div></div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Talk:Bitcoin.it_Wiki_Contributors%27_Award&diff=3038Talk:Bitcoin.it Wiki Contributors' Award2011-02-01T20:00:01Z<p>Ptd: /* Am I too late? */ new section</p>
<hr />
<div>Great idea! [[User:Gavinandresen|Gavinandresen]] (13:28, 19 December 2010 JST)<br />
<br />
== typo correction ==<br />
<br />
responsability -> responsibility.<br />
i'd have done it myself but page is locked. :) [[User:Nanotube|Nanotube]] (02:24, 25 December 2010 JST)<br />
:Fixed. [[User:MagicalTux|MagicalTux]] 18:18, 24 December 2010 (GMT)<br />
<br />
based on the feedback their receive from users -> based on the feedback they receive from users<br />
I'd also have fixed it if the page wasn't locked. [[User:Dooglus|Dooglus]] 21:45, 14 January 2011 (GMT)<br />
<br />
== Am I too late? ==<br />
<br />
I added my "contributers award participant" today (1st of February), will I be eligible? [[User:Ptd|Ptd]] 20:00, 1 February 2011 (GMT)</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=User:Ptd&diff=3037User:Ptd2011-02-01T19:56:23Z<p>Ptd: Added contributers award application (am I too late)</p>
<hr />
<div>Contributors Award participant: 1J1589a3MFGwFmFe9vG5WgHY4RkoKBaU4Z</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Merchant_Howto&diff=2740Merchant Howto2011-01-25T14:14:31Z<p>Ptd: This contains a guide for merchants and outlines how merchant tools should work</p>
<hr />
<div>This page is intended as guide to merchants who want accept bitcoin.<br />
<br />
==Manual==<br />
# Download a bitcoin client<br />
# When a customer wants to buy something issue them with a bitcoin address<br />
#* You can do this by clicking "New.." next to your address in the bitcoin client and sending that address to the customer<br />
# When payment comes in from that address send the goods to your customer<br />
# If you ever need to refund a customer send the bitcoins they sent back to the from address you recieved the bitcoins from.<br />
<br />
==Automated==<br />
Setup a system (pointers to easy-to-use packaged systems should be added) that:<br />
# When a customers orders something on your website it records<br />
#* Bitcoin address that payment should be sent to<br />
#* Order details (delivery address etc.)<br />
#* Payment amount<br />
# When payment arrives, checks that they have paid the correct amount (and refunds the from address otherwise) and informs you<br />
#* You dispach the goods to the customer and mark the order as fulfilled<br />
#* If you cannot dispach the goods you mark the order as denied and the system sends the customer a refund<br />
# Pays money made to your bitcoin address</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=DiabloMiner&diff=2697DiabloMiner2011-01-24T11:57:05Z<p>Ptd: Cleanup</p>
<hr />
<div>DiabloMiner is a Java GPU bitcoin miner that uses the OpenCL framework to quickly perform the hashing computations. Works on current Nvidia drivers and ATI Stream SDK 2.1.<br />
==Donation==<br />
Bitcoin address in the signature in the [http://www.bitcoin.org/smf/index.php?action=profile;u=1796 founder's page].<br />
==Download==<br />
[http://adterrasperaspera.com/images/DiabloMiner.zip Newest binary]<br />
<br />
[https://github.com/Diablo-D3/DiabloMiner/archives/master Source]<br />
==Examples==<br />
From the introductory [http://www.bitcoin.org/smf/index.php?topic=1721.msg21054#msg21054 post], to run type:<br />
./DiabloMiner-YourOS.sh -u youruser -p yourpass<br />
Where user and pass are what you set in your bitcoin.conf.<br />
<br />
<br />
To run on Windows you have to do something like:<br />
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<br />
==Founder==<br />
[http://www.bitcoin.org/smf/index.php?action=profile;u=1796 DiabloD3]<br />
==HomePage==<br />
[https://github.com/Diablo-D3/DiabloMiner Project Page]<br />
<br />
[http://www.bitcoin.org/smf/index.php?topic=1721.0 Project Thread]<br />
==License==<br />
[http://www.gnu.org/copyleft/gpl.html GPL]<br />
<br />
[[Category:Mining]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Protocol_documentation&diff=2448Protocol documentation2011-01-19T22:40:51Z<p>Ptd: /* addr */ Fixed table (previous info was confusing)</p>
<hr />
<div>Sources:<br />
* [[Original Bitcoin client]] source<br />
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
== Common standards ==<br />
<br />
=== Hashes ===<br />
<br />
Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desireable (for example when creating a bitcoin address).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] (ECDSA) to sign transactions. <br />
<br />
For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
Public keys (in scripts) are given as 04 <x> <y> where x and y are 32 byte strings representing the coordinates of a point on the curve.<br />
<br />
=== Transaction Verification ===<br />
<br />
The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.<br />
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.<br />
<br />
If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.<br />
The script from the in part of this transaction is executed.<br />
Then the script from the out part of the referenced transaction is executed.<br />
It is considered valid if the top element of the stack is true.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload)) (not included in version or verack)<br />
|-<br />
| ? || payload || char[] || The actual data<br />
|}<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value<br />
|-<br />
| main || F9BEB4D9<br />
|-<br />
| testnet || FABFB5DA<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd + uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe + uint32_t<br />
|-<br />
| - || 9 || 0xff + uint64_t<br />
|}<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || var_int || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the official client currently only supports IPv4 networking'''.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]?<br />
|-<br />
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The official client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the official client writes the IPv4 address into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node receives an incoming connection, it will immediatly advertise its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || uint64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_me || net_addr || The network address of the node emitting this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_you || net_addr || The network address seen by the node emitting this message (ie, the address of the receiving node)<br />
|-<br />
| 8 || nonce || uint64_t || Node random unique id. This id is used to detect connections to self<br />
|-<br />
| ? || sub_version_num || var_str || Secondary Version information (null terminated?)<br />
|-<br />
|colspan="4"| version >= 209<br />
|-<br />
| 4 || start_height || uint32_t || The last block received by the emitting node<br />
|}<br />
<br />
If the emitter of the packet has version >= 209, a "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (note the message header for this version message does not have a checksum):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - Sender address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Recipient address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version'' for clients >= 209. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 ....<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload (maximum payload length: 1000 bytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || var_int || Number of address entries<br />
|-<br />
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one<br />
|}<br />
<br />
'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D .D(.. .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
7F 85 39 C2 - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 50000 bytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || var_int || Number of inventory entries<br />
|-<br />
| 36x? || inventory || inv_vect[] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.<br />
<br />
Payload (maximum payload length: 50000 bytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || var_int || Number of inventory entries<br />
|-<br />
| 36x? || inventory || inv_vect[] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || only present if nType has SER_GETHASH set (purpose unknown)<br />
|-<br />
| 1+ || start count || var_int || number of hash_start entries<br />
|-<br />
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || var_int || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || var_int || Number of Transaction outputs<br />
|-<br />
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || var_int || The length of the signature script<br />
|-<br />
| ? || signature script || char[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || uint64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || var_int || Length of the pk_script<br />
|-<br />
| ? || pk_script || char[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2038!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || var_int || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
=== getaddr ===<br />
<br />
The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== checkorder ===<br />
<br />
This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.<br />
<br />
=== alert ===<br />
<br />
An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network<br />
|-<br />
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message<br />
|}<br />
<br />
The signature is to be compared to this ECDSA public key:<br />
<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]<br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Category:Clients&diff=2430Category:Clients2011-01-19T17:44:25Z<p>Ptd: grammer</p>
<hr />
<div>'''Bitcoin clients''' are software that can connect to the network, download the [[blockchain]], manages wallets, and send or receive bitcoins.<br />
<br />
[[fr:Catégorie:Clients Bitcoin]]<br />
[[Category:Main category]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Protocol_documentation&diff=2376Protocol documentation2011-01-18T22:53:20Z<p>Ptd: Cleared up details on presence of checksums</p>
<hr />
<div>Sources:<br />
* [[Original Bitcoin client]] source<br />
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
== Common standards ==<br />
<br />
=== Hashes ===<br />
<br />
Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desireable (for example when creating a bitcoin address).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] (ECDSA) to sign transactions. <br />
<br />
For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
Public keys (in scripts) are given as 04 <x> <y> where x and y are 32 byte strings representing the coordinates of a point on the curve.<br />
<br />
=== Transaction Verification ===<br />
<br />
The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.<br />
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.<br />
<br />
If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.<br />
The script from the in part of this transaction is executed.<br />
Then the script from the out part of the referenced transaction is executed.<br />
It is considered valid if the top element of the stack is true.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload)) (not included in version or verack)<br />
|-<br />
| ? || payload || char[] || The actual data<br />
|}<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value<br />
|-<br />
| main || F9BEB4D9<br />
|-<br />
| testnet || FABFB5DA<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd + uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe + uint32_t<br />
|-<br />
| - || 9 || 0xff + uint64_t<br />
|}<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || var_int || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the official client currently only supports IPv4 networking'''.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]?<br />
|-<br />
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The official client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the official client writes the IPv4 address into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node receives an incoming connection, it will immediatly advertise its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || uint64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_me || net_addr || The network address of the node emitting this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_you || net_addr || The network address seen by the node emitting this message (ie, the address of the receiving node)<br />
|-<br />
| 8 || nonce || uint64_t || Node random unique id. This id is used to detect connections to self<br />
|-<br />
| ? || sub_version_num || var_str || Secondary Version information (null terminated?)<br />
|-<br />
|colspan="4"| version >= 209<br />
|-<br />
| 4 || start_height || uint32_t || The last block received by the emitting node<br />
|}<br />
<br />
If the emitter of the packet has version >= 209, a "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (note the message header for this version message does not have a checksum):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - Sender address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Recipient address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version'' for clients >= 209. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 ....<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload (maximum payload length: 1000 bytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || var_int || Number of address entries<br />
|-<br />
| 26x? || addr_list || net_addr[] || Address of other nodes on the network. version < 209 will only read the first one<br />
|}<br />
<br />
'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D .D(.. .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
7F 85 39 C2 - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 50000 bytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || var_int || Number of inventory entries<br />
|-<br />
| 36x? || inventory || inv_vect[] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.<br />
<br />
Payload (maximum payload length: 50000 bytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || var_int || Number of inventory entries<br />
|-<br />
| 36x? || inventory || inv_vect[] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || only present if nType has SER_GETHASH set (purpose unknown)<br />
|-<br />
| 1+ || start count || var_int || number of hash_start entries<br />
|-<br />
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || var_int || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || var_int || Number of Transaction outputs<br />
|-<br />
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || var_int || The length of the signature script<br />
|-<br />
| ? || signature script || char[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || uint64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || var_int || Length of the pk_script<br />
|-<br />
| ? || pk_script || char[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2038!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || var_int || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
=== getaddr ===<br />
<br />
The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== checkorder ===<br />
<br />
This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.<br />
<br />
=== alert ===<br />
<br />
An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network<br />
|-<br />
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message<br />
|}<br />
<br />
The signature is to be compared to this ECDSA public key:<br />
<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]<br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Block_chain&diff=2368Block chain2011-01-18T22:05:02Z<p>Ptd: Rewrote another paragraph</p>
<hr />
<div>[[File:blockchain.png|thumb|Blocks in the main chain (black) are the longest series of blocks that go from the genesis block (green) to the current block. Orphan blocks (purple) are blocks that are not in the longest chain.]]<br />
<br />
Every [[block]] contains a [[hash]] of the previous block. This has the effect of creating a chain of blocks from the [[genesis block]] to the current block. Each block is guaranteed to come after the previous block chronologically because the previous block's hash would otherwise not be known. The blocks thus form a history of the bitcoin state, with which address each bitcoin was assigned at a given time, it is not possible to change the contents of any block without invalidating the successive blocks (because its hash would change).<br />
<br />
Each block contains a [[Proof-of-work]] that protects the block chain. Generators will build on the valid chain that contains the most work (blocks don't neccesarily contain the same amount of work).<br />
<br />
When two blocks are generated referencing the same previous block the block chain forks. This can happen for a number of reasons. If two blocks are generated simultaneously, the one that is built on by the next block will form the future chain. More serious forks can occur in a bug is found in the client which allows an invalid block chain to form, the chain will be recognised as invalid by future versions. As long as such invalid chains are recognized as such by at least 50% of computation power, the old block chain will be abandoned when more work has been put into the new one. Malicious clients attempting to fork the block chain (and thus alter transaction history) will not succeed unless they can perform work faster than normal clients (this is very unlikely).<br />
<br />
Blocks in shorter chains (or invalid chains) are called "orphan blocks", and while they are stored, they are not used for anything. When a block becomes an orphan block, all of its valid transactions are re-added to the pool of queued transactions and will be included in another block. The 50 BTC reward for the orphan block will be lost, which is why a network-enforced 100-block maturation time for generations exists.<br />
<br />
Because a block can only reference one previous block, it is impossible for two forked chains to merge.<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Block_chain&diff=2361Block chain2011-01-18T17:22:18Z<p>Ptd: Rewrote first two paragraphs</p>
<hr />
<div>[[File:blockchain.png|thumb|Blocks in the main chain (black) are the longest series of blocks that go from the genesis block (green) to the current block. Orphan blocks (purple) are blocks that are not in the longest chain.]]<br />
<br />
Every [[block]] contains a [[hash]] of the previous block. This has the effect of creating a chain of blocks from the [[genesis block]] to the current block. Each block is guaranteed to come after the previous block chronologically because the previous block's hash would otherwise not be known. The blocks thus form a history of the bitcoin state, with which address each bitcoin was assigned at a given time, it is not possible to change the contents of any block without invalidating the successive blocks (because its hash would change).<br />
<br />
Each block contains a [[Proof-of-work]] that protects the block chain. Generators will build on the valid chain that contains the most work (blocks don't neccesarily contain the same amount of work).<br />
<br />
For any block on the chain, there is only one path to the genesis block. Coming from the genesis block, however, there can be forks. One-block forks are created from time to time when two blocks are created just a few seconds apart. When that happens, generating nodes build onto whichever one of the blocks they received first. Whichever block ends up being included in the next block becomes part of the main chain because that chain is longer. More serious forks have occurred after fixing bugs that required backward-incompatible changes.<br />
<br />
Blocks in shorter chains (or invalid chains) are called "orphan blocks", and while they are stored, they are not used for anything. When a block becomes an orphan block, all of its valid transactions are re-added to the pool of queued transactions and will be included in another block. The 50 BTC reward for the orphan block will be lost, which is why a network-enforced 100-block maturation time for generations exists.<br />
<br />
Because a block can only reference one previous block, it is impossible for two forked chains to merge.<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Proof_of_work&diff=2217Proof of work2011-01-15T20:44:06Z<p>Ptd: Fixed markup mistake</p>
<hr />
<div>{{stub}}<br />
<br />
A '''proof of work''' is the 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.<br />
<br />
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).<br />
<br />
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 a predecessor 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.<br />
<br />
== Example ==<br />
<br />
Lets 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 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 98 tries:<br />
<br />
Hello world ! 0 : 3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106a<br />
Hello world ! 1 : b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27<br />
Hello world ! 2 : 5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320<br />
....<br />
Hello world ! 95 : b74f3b2cf1061895f880a99d1d0249a8cedf223d3ed061150548aa6212c88d43<br />
Hello world ! 96 : 447ca2fa886965af084808d22116edde4383cbaa16fd1fbcf3db61421b9990b9<br />
Hello world ! 97 : 000ba61ca46d1d317684925a0ef070e30193ff5fa6124aff76f513d96f49349d<br />
<br />
98 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 target (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].<br />
<br />
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.<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Script&diff=1743Script2011-01-11T14:24:30Z<p>Ptd: /* Standard Transaction to Bitcoin address */ Added missing characters</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops or nesting ''if'' statements.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (1).<br />
<br />
Scripts are big-endian. (Is all data, also?)<br />
<br />
== Words ==<br />
This is a list of all Script words (commands/functions). Some are currently disabled for security reasons.<br />
<br />
True=1 and False=0.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|Nothing.<br />
|0<br />
|The number 0 is pushed onto the stack.<br />
|-<br />
|N/A<br />
|1-75<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
| colspan="2"|<expression> if [statements] [else [statements]] endif<br />
|If the top stack value is 1, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
| colspan="2"|<expression> if [statements] [else [statements]] endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
| colspan="2"|<expression> if [statements] [else [statements]] endif<br />
|If the preceding OP_IF was not executed, these statements are.<br />
|-<br />
|OP_ENDIF<br />
|104<br />
| colspan="2"|<expression> if [statements] [else [statements]] endif<br />
|Ends an if/else block.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|x<br />
|x / x x<br />
|If the input is true or false, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|x1 x2<br />
|out<br />
|Concatenates two strings. ''Currently disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|in begin size<br />
|out<br />
|Returns a section of a string. ''Currently disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|in size<br />
|out<br />
|Keeps only characters left of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|in size<br />
|out<br />
|Keeps only characters right of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|in<br />
|out<br />
|Flips all of the bits in the input. ''Currently disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|x1 x2<br />
|out<br />
|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|x1 x2<br />
|out<br />
|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|x1 x2<br />
|out<br />
|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|x1 x2<br />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|in<br />
|out<br />
|The input is multiplied by 2. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|in<br />
|out<br />
|The input is divided by 2. ''Currently disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|in<br />
|out<br />
|Returns 1 if the input is 0. 0 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|a b<br />
|out<br />
|a is multiplied by b. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|a b<br />
|out<br />
|a is divided by b. ''Currently disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|a b<br />
|out<br />
|Returns the remainder after dividing a by b. ''Currently disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|a b<br />
|out<br />
|Shifts a left b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|a b<br />
|out<br />
|Shifts a right b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|a b<br />
|out<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|OP_CHECKSIG<br />
|172<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|sig pubkey<br />
|True / false<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|Transaction is invalid<br />
|-<br />
|OP_VER<br />
|98<br />
|Transaction is invalid<br />
|-<br />
|OP_VERIF<br />
|101<br />
|Transaction is invalid<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|Transaction is invalid<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|Transaction is invalid<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|Transaction is invalid<br />
|-<br />
|OP_NOP1-OP_NOP10<br />
|176-185<br />
|The word is ignored.<br />
|}<br />
<br />
== Scripts ==<br />
Keep in mind that all constants actually use the data-pushing commands above.<br />
<br />
=== Standard Transaction to Bitcoin address ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Standard Generation / transaction to IP address ===<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Transaction with a message ===<br />
<br />
It's possible to add arbitrary data to any transaction by just adding some data along with OP_DROP (or ommitting OP_DROP and allowing the value to sit on the stack unused). Scripts are limited to 10,000 bytes and 201 instructions/values, and each individual instruction/value is limited to 520 bytes.<br />
<br />
scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey> <message><br />
|OP_DROP OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
|Top item in the stack is removed.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Block_Chain&diff=1372Block Chain2011-01-08T10:54:36Z<p>Ptd: Made it redirect to Block chain (different capitalization)</p>
<hr />
<div>#REDIRECT [[Block chain]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Vocabulary&diff=1371Vocabulary2011-01-08T10:51:30Z<p>Ptd: Added a link and explained that Bitcoins are abbreviated BTC</p>
<hr />
<div>;'''Bitcoin'''<br />
: The name of a decentralized p2p crypto-currency application.<br />
;'''[[Bitcoins]]''' ''(abbreviated BTC)''<br />
: The currency used and generated within the Bitcoin system.<br />
;'''[[Block]]'''<br />
: Blocks are links in a chain of transaction verifications. Outstanding transactions get bundled into a block and are verified roughly every ten minutes on average. Each subsequent block strengthens the verification of previous blocks. Each block contains one or more transactions.<br />
;'''[[Block Chain]]'''<br />
: Each block includes the difficult-to-produce verification hash of the previous block. This allows each subsequent block to be linked to all previous blocks. These blocks which are linked together for the purpose of verifying transactions within blocks is called the block chain.<br />
;'''Branching Point'''<br />
: The block at which the block chain diverges into multiple chain branches<br />
;'''Chain Branching'''<br />
;'''Checkpoint lockin'''<br />
: Every once in a while, a recent block hash is hardcoded into Bitcoin. This prevents pretty much any possible attack from affecting transactions made up to this point. No matter what happens (except perhaps if SHA-256 is broken), these transactions will survive.<br />
;'''Coinbase'''<br />
: "Coinbase" is another name for a generation transaction. The input of such a transaction contains some arbitrary data where the scriptSig would go in normal transactions -- this data is sometimes called the "coinbase", as well.<br />
;'''[[Difficulty]]'''<br />
: Every 2016 blocks, Bitcoin adjusts the difficulty of verifying blocks based on the time it took to verify the previous 2016 blocks. The difficulty is adjusted so that given the average estimated computing power of the whole bitcoin network, only one block will verified on average every ten minutes for the next 2016 blocks. The difficulty is usually expressed as a number, optionally accurate to to many decimal places. Sometimes it is expressed as a very very long number preceded by many zeros which is the number under which a block's generated hash must be to qualify as an officially verified block. Difficulty is also often called block difficulty, hash difficulty, hash target, verification difficulty or the difficulty of generating bitcoins.<br />
;'''Discouraged block'''<br />
: A discouraged [[block]] is considered to be a valid part of the chain, but blocks you generate will build onto the block before it instead of that block. If most of the network is discouraging a block, then it will almost always be replaced by another block and not end up making it into the final [[block chain]]. Unlike rejecting a block, discouraging a block has no risk of splitting the network. Bitcoin currently doesn't discourage any blocks, but the mechanism may be used in the future to handle certain issues such as unreasonably high or low fees.<br />
;'''Double Spending'''<br />
: Attempting to spend coins that have already been spent in another transaction<br />
;'''Generate Bitcoins'''<br />
: The phrase generating bitcoins comes from the file menu option 'Generate Coins' in the Bitcoin which enables or disables the CPU intensive process of verifying blocks. When Bitcoin verifies a block before any other Bitcoin client, it receives newly minted bitcoins and the transaction fees which may or may not be included in the verified block. The amount of bitcoins awarded for verifying a block is ?50.00 for the first 210,000 blocks and half the previous amount of bitcoins for each subsequent 210,000 blocks. On average, 210,000 blocks take about 4 years to verify. The total amount of bitcoins that will ever be minted is roughly 21,000,000.00000000. Currently the decimal places more than two to the right of the decimal point are not displayed in the official Bitcoin client.<br />
;'''[[Hash]]'''<br />
: A computer algorithm which produces an identification key that can be used to easily verify that data has not been altered. If you change any single bit of the original data and run the hash algorithm, the hash will completely change. Because the hash is seemingly random, it is prohibitively difficult to try to produce a specific hash by changing the data which is being hashed.<br />
;'''Memory pool'''<br />
: Generators store [[transactions]] waiting to get into a block in their memory pool after receiving them. Received transactions are stored even if they are invalid to prevent nodes from constantly requesting transactions that they've already seen. The memory pool is cleared when Bitcoin is shut down, causing the [[network]] to gradually forget about transactions that haven't been included in a [[block]].<br />
;'''Merkle root'''<br />
: Every [[transactions|transaction]] has a [[hash]] associated with it. In a [[block]], all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the [[block hashing algorithm|block header]]. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and [[Wikipedia:Merkle tree|Merkle tree]] -- downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.<br />
;''' Miner'''<br />
: Computer software which is designed to create hashes with the intention to create a successful block and earn coins from transaction fees and new coins created with the block itself. The term references an analogy of gold miners who dig gold out of the ground and thus "discover" new gold that can be used to create new coins with a similar kind of discovery occurring with a successful hash to create new Bitcoins.<br />
;'''Node'''<br />
: Each Bitcoin client currently running within the network is referred to as a Node of the system.<br />
;'''Nonce'''<br />
: A nonce is an otherwise meaningless number which is used to alter the outcome of a hash. Each time Bitcoin hashes a block, it increments a nonce within the block which it is trying verify. If the numeric value of the effectively random hash is below a certain amount determined by the block generation difficulty, then the block is accepted by other clients and gets added to the chain.<br />
;'''[[Proof of work]]'''<br />
: A result that can only be obtained through the use of computational resources. Changing the data in the proof of work requires redoing the work.<br />
;'''Subsidy'''<br />
: The block subsidy is the BTC created for generating a block. The subsidy is halved every four years.<br />
;'''Super Nodes'''<br />
: A participant in a p2p network which connects to as many other nodes as possible.<br />
;'''[[Tonal BitCoin]]'''<br />
: Adaptation of BitCoin to the Tonal System. 1 TBC is defined as 1,0000 (65,536 decimal) uBTC.<br />
;'''[[Transaction Fee]]'''<br />
: A voluntary fee which can be added to a transaction which is use as an incentive to add the bitcoin transaction to a block. The fee determines the likelihood of inclusion in any given block, where a high fee included with a transaction has a priority over transactions with a lower fee included or no fee at all.<br />
<br />
{{fromold|bitcoin_vocabulary}}<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary| ]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Vocabulary&diff=1370Vocabulary2011-01-08T10:45:37Z<p>Ptd: Added "Proof of Work"</p>
<hr />
<div>;'''Bitcoin'''<br />
: The name of a decentralized p2p crypto-currency application.<br />
;'''[[Bitcoins]]'''<br />
: The currency used and generated within the Bitcoin system.<br />
;'''[[Block]]'''<br />
: Blocks are links in a chain of transaction verifications. Outstanding transactions get bundled into a block and are verified roughly every ten minutes on average. Each subsequent block strengthens the verification of previous blocks. Each block contains one or more transactions.<br />
;'''Block Chain'''<br />
: Each block includes the difficult-to-produce verification hash of the previous block. This allows each subsequent block to be linked to all previous blocks. These blocks which are linked together for the purpose of verifying transactions within blocks is called the block chain.<br />
;'''Branching Point'''<br />
: The block at which the block chain diverges into multiple chain branches<br />
;'''Chain Branching'''<br />
;'''Checkpoint lockin'''<br />
: Every once in a while, a recent block hash is hardcoded into Bitcoin. This prevents pretty much any possible attack from affecting transactions made up to this point. No matter what happens (except perhaps if SHA-256 is broken), these transactions will survive.<br />
;'''Coinbase'''<br />
: "Coinbase" is another name for a generation transaction. The input of such a transaction contains some arbitrary data where the scriptSig would go in normal transactions -- this data is sometimes called the "coinbase", as well.<br />
;'''[[Difficulty]]'''<br />
: Every 2016 blocks, Bitcoin adjusts the difficulty of verifying blocks based on the time it took to verify the previous 2016 blocks. The difficulty is adjusted so that given the average estimated computing power of the whole bitcoin network, only one block will verified on average every ten minutes for the next 2016 blocks. The difficulty is usually expressed as a number, optionally accurate to to many decimal places. Sometimes it is expressed as a very very long number preceded by many zeros which is the number under which a block's generated hash must be to qualify as an officially verified block. Difficulty is also often called block difficulty, hash difficulty, hash target, verification difficulty or the difficulty of generating bitcoins.<br />
;'''Discouraged block'''<br />
: A discouraged [[block]] is considered to be a valid part of the chain, but blocks you generate will build onto the block before it instead of that block. If most of the network is discouraging a block, then it will almost always be replaced by another block and not end up making it into the final [[block chain]]. Unlike rejecting a block, discouraging a block has no risk of splitting the network. Bitcoin currently doesn't discourage any blocks, but the mechanism may be used in the future to handle certain issues such as unreasonably high or low fees.<br />
;'''Double Spending'''<br />
: Attempting to spend coins that have already been spent in another transaction<br />
;'''Generate Bitcoins'''<br />
: The phrase generating bitcoins comes from the file menu option 'Generate Coins' in the Bitcoin which enables or disables the CPU intensive process of verifying blocks. When Bitcoin verifies a block before any other Bitcoin client, it receives newly minted bitcoins and the transaction fees which may or may not be included in the verified block. The amount of bitcoins awarded for verifying a block is ?50.00 for the first 210,000 blocks and half the previous amount of bitcoins for each subsequent 210,000 blocks. On average, 210,000 blocks take about 4 years to verify. The total amount of bitcoins that will ever be minted is roughly 21,000,000.00000000. Currently the decimal places more than two to the right of the decimal point are not displayed in the official Bitcoin client.<br />
;'''[[Hash]]'''<br />
: A computer algorithm which produces an identification key that can be used to easily verify that data has not been altered. If you change any single bit of the original data and run the hash algorithm, the hash will completely change. Because the hash is seemingly random, it is prohibitively difficult to try to produce a specific hash by changing the data which is being hashed.<br />
;'''Memory pool'''<br />
: Generators store [[transactions]] waiting to get into a block in their memory pool after receiving them. Received transactions are stored even if they are invalid to prevent nodes from constantly requesting transactions that they've already seen. The memory pool is cleared when Bitcoin is shut down, causing the [[network]] to gradually forget about transactions that haven't been included in a [[block]].<br />
;'''Merkle root'''<br />
: Every [[transactions|transaction]] has a [[hash]] associated with it. In a [[block]], all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the [[block hashing algorithm|block header]]. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and [[Wikipedia:Merkle tree|Merkle tree]] -- downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.<br />
;''' Miner'''<br />
: Computer software which is designed to create hashes with the intention to create a successful block and earn coins from transaction fees and new coins created with the block itself. The term references an analogy of gold miners who dig gold out of the ground and thus "discover" new gold that can be used to create new coins with a similar kind of discovery occurring with a successful hash to create new Bitcoins.<br />
;'''Node'''<br />
: Each Bitcoin client currently running within the network is referred to as a Node of the system.<br />
;'''Nonce'''<br />
: A nonce is an otherwise meaningless number which is used to alter the outcome of a hash. Each time Bitcoin hashes a block, it increments a nonce within the block which it is trying verify. If the numeric value of the effectively random hash is below a certain amount determined by the block generation difficulty, then the block is accepted by other clients and gets added to the chain.<br />
;'''[[Proof of work]]'''<br />
: A result that can only be obtained through the use of computational resources. Changing the data in the proof of work requires redoing the work.<br />
;'''Subsidy'''<br />
: The block subsidy is the BTC created for generating a block. The subsidy is halved every four years.<br />
;'''Super Nodes'''<br />
: A participant in a p2p network which connects to as many other nodes as possible.<br />
;'''[[Tonal BitCoin]]'''<br />
: Adaptation of BitCoin to the Tonal System. 1 TBC is defined as 1,0000 (65,536 decimal) uBTC.<br />
;'''[[Transaction Fee]]'''<br />
: A voluntary fee which can be added to a transaction which is use as an incentive to add the bitcoin transaction to a block. The fee determines the likelihood of inclusion in any given block, where a high fee included with a transaction has a priority over transactions with a lower fee included or no fee at all.<br />
<br />
{{fromold|bitcoin_vocabulary}}<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary| ]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Vocabulary&diff=1369Vocabulary2011-01-08T10:37:34Z<p>Ptd: Simplified "Double Spending"</p>
<hr />
<div>;'''Bitcoin'''<br />
: The name of a decentralized p2p crypto-currency application.<br />
;'''[[Bitcoins]]'''<br />
: The currency used and generated within the Bitcoin system.<br />
;'''[[Block]]'''<br />
: Blocks are links in a chain of transaction verifications. Outstanding transactions get bundled into a block and are verified roughly every ten minutes on average. Each subsequent block strengthens the verification of previous blocks. Each block contains one or more transactions.<br />
;'''Block Chain'''<br />
: Each block includes the difficult-to-produce verification hash of the previous block. This allows each subsequent block to be linked to all previous blocks. These blocks which are linked together for the purpose of verifying transactions within blocks is called the block chain.<br />
;'''Branching Point'''<br />
: The block at which the block chain diverges into multiple chain branches<br />
;'''Chain Branching'''<br />
;'''Checkpoint lockin'''<br />
: Every once in a while, a recent block hash is hardcoded into Bitcoin. This prevents pretty much any possible attack from affecting transactions made up to this point. No matter what happens (except perhaps if SHA-256 is broken), these transactions will survive.<br />
;'''Coinbase'''<br />
: "Coinbase" is another name for a generation transaction. The input of such a transaction contains some arbitrary data where the scriptSig would go in normal transactions -- this data is sometimes called the "coinbase", as well.<br />
;'''[[Difficulty]]'''<br />
: Every 2016 blocks, Bitcoin adjusts the difficulty of verifying blocks based on the time it took to verify the previous 2016 blocks. The difficulty is adjusted so that given the average estimated computing power of the whole bitcoin network, only one block will verified on average every ten minutes for the next 2016 blocks. The difficulty is usually expressed as a number, optionally accurate to to many decimal places. Sometimes it is expressed as a very very long number preceded by many zeros which is the number under which a block's generated hash must be to qualify as an officially verified block. Difficulty is also often called block difficulty, hash difficulty, hash target, verification difficulty or the difficulty of generating bitcoins.<br />
;'''Discouraged block'''<br />
: A discouraged [[block]] is considered to be a valid part of the chain, but blocks you generate will build onto the block before it instead of that block. If most of the network is discouraging a block, then it will almost always be replaced by another block and not end up making it into the final [[block chain]]. Unlike rejecting a block, discouraging a block has no risk of splitting the network. Bitcoin currently doesn't discourage any blocks, but the mechanism may be used in the future to handle certain issues such as unreasonably high or low fees.<br />
;'''Double Spending'''<br />
: Attempting to spend coins that have already been spent in another transaction<br />
;'''Generate Bitcoins'''<br />
: The phrase generating bitcoins comes from the file menu option 'Generate Coins' in the Bitcoin which enables or disables the CPU intensive process of verifying blocks. When Bitcoin verifies a block before any other Bitcoin client, it receives newly minted bitcoins and the transaction fees which may or may not be included in the verified block. The amount of bitcoins awarded for verifying a block is ?50.00 for the first 210,000 blocks and half the previous amount of bitcoins for each subsequent 210,000 blocks. On average, 210,000 blocks take about 4 years to verify. The total amount of bitcoins that will ever be minted is roughly 21,000,000.00000000. Currently the decimal places more than two to the right of the decimal point are not displayed in the official Bitcoin client.<br />
;'''[[Hash]]'''<br />
: A computer algorithm which produces an identification key that can be used to easily verify that data has not been altered. If you change any single bit of the original data and run the hash algorithm, the hash will completely change. Because the hash is seemingly random, it is prohibitively difficult to try to produce a specific hash by changing the data which is being hashed.<br />
;'''Memory pool'''<br />
: Generators store [[transactions]] waiting to get into a block in their memory pool after receiving them. Received transactions are stored even if they are invalid to prevent nodes from constantly requesting transactions that they've already seen. The memory pool is cleared when Bitcoin is shut down, causing the [[network]] to gradually forget about transactions that haven't been included in a [[block]].<br />
;'''Merkle root'''<br />
: Every [[transactions|transaction]] has a [[hash]] associated with it. In a [[block]], all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the [[block hashing algorithm|block header]]. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and [[Wikipedia:Merkle tree|Merkle tree]] -- downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.<br />
;''' Miner'''<br />
: Computer software which is designed to create hashes with the intention to create a successful block and earn coins from transaction fees and new coins created with the block itself. The term references an analogy of gold miners who dig gold out of the ground and thus "discover" new gold that can be used to create new coins with a similar kind of discovery occurring with a successful hash to create new Bitcoins.<br />
;'''Node'''<br />
: Each Bitcoin client currently running within the network is referred to as a Node of the system.<br />
;'''Nonce'''<br />
: A nonce is an otherwise meaningless number which is used to alter the outcome of a hash. Each time Bitcoin hashes a block, it increments a nonce within the block which it is trying verify. If the numeric value of the effectively random hash is below a certain amount determined by the block generation difficulty, then the block is accepted by other clients and gets added to the chain.<br />
;'''Subsidy'''<br />
: The block subsidy is the BTC created for generating a block. The subsidy is halved every four years.<br />
;'''Super Nodes'''<br />
: A participant in a p2p network which connects to as many other nodes as possible.<br />
;'''[[Tonal BitCoin]]'''<br />
: Adaptation of BitCoin to the Tonal System. 1 TBC is defined as 1,0000 (65,536 decimal) uBTC.<br />
;'''[[Transaction Fee]]'''<br />
: A voluntary fee which can be added to a transaction which is use as an incentive to add the bitcoin transaction to a block. The fee determines the likelihood of inclusion in any given block, where a high fee included with a transaction has a priority over transactions with a lower fee included or no fee at all.<br />
<br />
{{fromold|bitcoin_vocabulary}}<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary| ]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Proof_of_work&diff=1356Proof of work2011-01-07T22:35:49Z<p>Ptd: Fleshed out the description of example</p>
<hr />
<div>{{stub}}<br />
<br />
A '''proof of work''' is the 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.<br />
<br />
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).<br />
<br />
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 a predecessor 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.<br />
<br />
== Example ==<br />
<br />
Lets 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 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 98 tries:<br />
<br />
Hello world ! 0 : 3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106a<br />
Hello world ! 1 : b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27<br />
Hello world ! 2 : 5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320<br />
....<br />
Hello world ! 95 : b74f3b2cf1061895f880a99d1d0249a8cedf223d3ed061150548aa6212c88d43<br />
Hello world ! 96 : 447ca2fa886965af084808d22116edde4383cbaa16fd1fbcf3db61421b9990b9<br />
Hello world ! 97 : 000ba61ca46d1d317684925a0ef070e30193ff5fa6124aff76f513d96f49349d<br />
<br />
98 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 target (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].<br />
<br />
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.<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Proof_of_work&diff=1348Proof of work2011-01-07T19:37:47Z<p>Ptd: Added a sentence to my previous edit</p>
<hr />
<div>{{stub}}<br />
<br />
A '''proof of work''' is the 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.<br />
<br />
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).<br />
<br />
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 a predecessor block, thus each block has a [chain|block 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.<br />
<br />
== Example ==<br />
<br />
Let's say our base work is "Hello world" and our work is to find a hash starting with "000". We are going to increase an integer value (nonce) hashed alongside "Hello world", until we reach our goal.<br />
<br />
Hello world ! 0 : 3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106a<br />
Hello world ! 1 : b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27<br />
Hello world ! 2 : 5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320<br />
Hello world ! 3 : 9c5d769416aa0ca894abf22bd17bd30fbb6959291423ae1903a9f86a1fe7ce78<br />
Hello world ! 4 : 4efc65df7933e4f5cc21947c61d5cc6bd11d644794bfa210603b0547c4b1cc3e<br />
Hello world ! 5 : 441b15b67d791620cd50ea537144e3115422e33bdb1b1b9b110d3265f7a9199b<br />
Hello world ! 6 : d368331386f0cf773ad53910fefcef4bdceeb526e408d3fbc9408d6f6e481ca4<br />
Hello world ! 7 : 013cc9722f38d2eb6186b75e2e7cbe6e7818e0612a2774d4400416b17ae03b87<br />
Hello world ! 8 : 3a92631799b478c3bcc554df8401b09900fbdb58cc0e58efe711cc475ee097b3<br />
Hello world ! 9 : 66658881696164fcb04f32ec505bb5e515000a85baf691beb63fc9d3f4d0fee2<br />
....<br />
Hello world ! 88 : 80d009db72c6ad35241bb3dbac77cbe177c6a803fe67527c159dbfaf2cbf9f5c<br />
Hello world ! 89 : a5b1e789f691f9793f8a84f8ebae3d8e28d49cbe0eeea2da621cd409e3bdee2b<br />
Hello world ! 90 : 4eba5b2459caac3d9ff3b787aaa5cac481aaa4a0232fbbe02a8ee4d1101c2ca2<br />
Hello world ! 91 : c811722c68b53614d58d37dcad9d540c2bce9f85b5ccae94424ff4716eea1765<br />
Hello world ! 92 : e30c716fccda22f394a8e80a2670b97968b5416b8b39e2061a7b7d1a9f41e0a9<br />
Hello world ! 93 : 965425c39d4e24c532721d7f7b77a00b31b0c0d0e316d46240c4e6bec9c09f65<br />
Hello world ! 94 : 7090a0e5d88cff635e42ea33fcd6091a058e9cdd58ab8cd5c21c1c70421e35c6<br />
Hello world ! 95 : b74f3b2cf1061895f880a99d1d0249a8cedf223d3ed061150548aa6212c88d43<br />
Hello world ! 96 : 447ca2fa886965af084808d22116edde4383cbaa16fd1fbcf3db61421b9990b9<br />
Hello world ! 97 : 000ba61ca46d1d317684925a0ef070e30193ff5fa6124aff76f513d96f49349d<br />
<br />
And here we are. Now we just have to let the network know our block, made of "Hello world" and 97, won. <br />
<br />
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.<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Proof_of_work&diff=1347Proof of work2011-01-07T19:37:04Z<p>Ptd: Explained how proof of work is applied to bitcoins</p>
<hr />
<div>{{stub}}<br />
<br />
A '''proof of work''' is the 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.<br />
<br />
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).<br />
<br />
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 a predecessor block, thus each block has a [chain|block 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.<br />
<br />
== Example ==<br />
<br />
Let's say our base work is "Hello world" and our work is to find a hash starting with "000". We are going to increase an integer value (nonce) hashed alongside "Hello world", until we reach our goal.<br />
<br />
Hello world ! 0 : 3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106a<br />
Hello world ! 1 : b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27<br />
Hello world ! 2 : 5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320<br />
Hello world ! 3 : 9c5d769416aa0ca894abf22bd17bd30fbb6959291423ae1903a9f86a1fe7ce78<br />
Hello world ! 4 : 4efc65df7933e4f5cc21947c61d5cc6bd11d644794bfa210603b0547c4b1cc3e<br />
Hello world ! 5 : 441b15b67d791620cd50ea537144e3115422e33bdb1b1b9b110d3265f7a9199b<br />
Hello world ! 6 : d368331386f0cf773ad53910fefcef4bdceeb526e408d3fbc9408d6f6e481ca4<br />
Hello world ! 7 : 013cc9722f38d2eb6186b75e2e7cbe6e7818e0612a2774d4400416b17ae03b87<br />
Hello world ! 8 : 3a92631799b478c3bcc554df8401b09900fbdb58cc0e58efe711cc475ee097b3<br />
Hello world ! 9 : 66658881696164fcb04f32ec505bb5e515000a85baf691beb63fc9d3f4d0fee2<br />
....<br />
Hello world ! 88 : 80d009db72c6ad35241bb3dbac77cbe177c6a803fe67527c159dbfaf2cbf9f5c<br />
Hello world ! 89 : a5b1e789f691f9793f8a84f8ebae3d8e28d49cbe0eeea2da621cd409e3bdee2b<br />
Hello world ! 90 : 4eba5b2459caac3d9ff3b787aaa5cac481aaa4a0232fbbe02a8ee4d1101c2ca2<br />
Hello world ! 91 : c811722c68b53614d58d37dcad9d540c2bce9f85b5ccae94424ff4716eea1765<br />
Hello world ! 92 : e30c716fccda22f394a8e80a2670b97968b5416b8b39e2061a7b7d1a9f41e0a9<br />
Hello world ! 93 : 965425c39d4e24c532721d7f7b77a00b31b0c0d0e316d46240c4e6bec9c09f65<br />
Hello world ! 94 : 7090a0e5d88cff635e42ea33fcd6091a058e9cdd58ab8cd5c21c1c70421e35c6<br />
Hello world ! 95 : b74f3b2cf1061895f880a99d1d0249a8cedf223d3ed061150548aa6212c88d43<br />
Hello world ! 96 : 447ca2fa886965af084808d22116edde4383cbaa16fd1fbcf3db61421b9990b9<br />
Hello world ! 97 : 000ba61ca46d1d317684925a0ef070e30193ff5fa6124aff76f513d96f49349d<br />
<br />
And here we are. Now we just have to let the network know our block, made of "Hello world" and 97, won. <br />
<br />
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.<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Proof_of_work&diff=1310Proof of work2011-01-06T12:57:32Z<p>Ptd: Add a newline to create a separate paragraph</p>
<hr />
<div>{{stub}}<br />
<br />
A '''proof of work''' is the 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.<br />
<br />
An application is this is a proposed method for preventing email spam, require 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 will require huge computational resources).<br />
<br />
This is used in bitcoin for block generation. The block hash itself is a proof of work, proving that whoever generated that block deserves the associated transaction fees and reward.<br />
<br />
== Example ==<br />
<br />
Let's say our base work is "Hello world" and our work is to find a hash starting with "000". We are going to increase an integer value (nonce) hashed alongside "Hello world", until we reach our goal.<br />
<br />
Hello world ! 0 : 3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106a<br />
Hello world ! 1 : b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27<br />
Hello world ! 2 : 5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320<br />
Hello world ! 3 : 9c5d769416aa0ca894abf22bd17bd30fbb6959291423ae1903a9f86a1fe7ce78<br />
Hello world ! 4 : 4efc65df7933e4f5cc21947c61d5cc6bd11d644794bfa210603b0547c4b1cc3e<br />
Hello world ! 5 : 441b15b67d791620cd50ea537144e3115422e33bdb1b1b9b110d3265f7a9199b<br />
Hello world ! 6 : d368331386f0cf773ad53910fefcef4bdceeb526e408d3fbc9408d6f6e481ca4<br />
Hello world ! 7 : 013cc9722f38d2eb6186b75e2e7cbe6e7818e0612a2774d4400416b17ae03b87<br />
Hello world ! 8 : 3a92631799b478c3bcc554df8401b09900fbdb58cc0e58efe711cc475ee097b3<br />
Hello world ! 9 : 66658881696164fcb04f32ec505bb5e515000a85baf691beb63fc9d3f4d0fee2<br />
....<br />
Hello world ! 88 : 80d009db72c6ad35241bb3dbac77cbe177c6a803fe67527c159dbfaf2cbf9f5c<br />
Hello world ! 89 : a5b1e789f691f9793f8a84f8ebae3d8e28d49cbe0eeea2da621cd409e3bdee2b<br />
Hello world ! 90 : 4eba5b2459caac3d9ff3b787aaa5cac481aaa4a0232fbbe02a8ee4d1101c2ca2<br />
Hello world ! 91 : c811722c68b53614d58d37dcad9d540c2bce9f85b5ccae94424ff4716eea1765<br />
Hello world ! 92 : e30c716fccda22f394a8e80a2670b97968b5416b8b39e2061a7b7d1a9f41e0a9<br />
Hello world ! 93 : 965425c39d4e24c532721d7f7b77a00b31b0c0d0e316d46240c4e6bec9c09f65<br />
Hello world ! 94 : 7090a0e5d88cff635e42ea33fcd6091a058e9cdd58ab8cd5c21c1c70421e35c6<br />
Hello world ! 95 : b74f3b2cf1061895f880a99d1d0249a8cedf223d3ed061150548aa6212c88d43<br />
Hello world ! 96 : 447ca2fa886965af084808d22116edde4383cbaa16fd1fbcf3db61421b9990b9<br />
Hello world ! 97 : 000ba61ca46d1d317684925a0ef070e30193ff5fa6124aff76f513d96f49349d<br />
<br />
And here we are. Now we just have to let the network know our block, made of "Hello world" and 97, won. <br />
<br />
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.<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Ptdhttps://tests.bitcoin.it/w/index.php?title=Proof_of_work&diff=1309Proof of work2011-01-06T12:56:55Z<p>Ptd: Rewrote top paragraph</p>
<hr />
<div>{{stub}}<br />
<br />
A '''proof of work''' is the 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.<br />
An application is this is a proposed method for preventing email spam, require 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 will require huge computational resources).<br />
<br />
This is used in bitcoin for block generation. The block hash itself is a proof of work, proving that whoever generated that block deserves the associated transaction fees and reward.<br />
<br />
== Example ==<br />
<br />
Let's say our base work is "Hello world" and our work is to find a hash starting with "000". We are going to increase an integer value (nonce) hashed alongside "Hello world", until we reach our goal.<br />
<br />
Hello world ! 0 : 3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106a<br />
Hello world ! 1 : b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27<br />
Hello world ! 2 : 5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320<br />
Hello world ! 3 : 9c5d769416aa0ca894abf22bd17bd30fbb6959291423ae1903a9f86a1fe7ce78<br />
Hello world ! 4 : 4efc65df7933e4f5cc21947c61d5cc6bd11d644794bfa210603b0547c4b1cc3e<br />
Hello world ! 5 : 441b15b67d791620cd50ea537144e3115422e33bdb1b1b9b110d3265f7a9199b<br />
Hello world ! 6 : d368331386f0cf773ad53910fefcef4bdceeb526e408d3fbc9408d6f6e481ca4<br />
Hello world ! 7 : 013cc9722f38d2eb6186b75e2e7cbe6e7818e0612a2774d4400416b17ae03b87<br />
Hello world ! 8 : 3a92631799b478c3bcc554df8401b09900fbdb58cc0e58efe711cc475ee097b3<br />
Hello world ! 9 : 66658881696164fcb04f32ec505bb5e515000a85baf691beb63fc9d3f4d0fee2<br />
....<br />
Hello world ! 88 : 80d009db72c6ad35241bb3dbac77cbe177c6a803fe67527c159dbfaf2cbf9f5c<br />
Hello world ! 89 : a5b1e789f691f9793f8a84f8ebae3d8e28d49cbe0eeea2da621cd409e3bdee2b<br />
Hello world ! 90 : 4eba5b2459caac3d9ff3b787aaa5cac481aaa4a0232fbbe02a8ee4d1101c2ca2<br />
Hello world ! 91 : c811722c68b53614d58d37dcad9d540c2bce9f85b5ccae94424ff4716eea1765<br />
Hello world ! 92 : e30c716fccda22f394a8e80a2670b97968b5416b8b39e2061a7b7d1a9f41e0a9<br />
Hello world ! 93 : 965425c39d4e24c532721d7f7b77a00b31b0c0d0e316d46240c4e6bec9c09f65<br />
Hello world ! 94 : 7090a0e5d88cff635e42ea33fcd6091a058e9cdd58ab8cd5c21c1c70421e35c6<br />
Hello world ! 95 : b74f3b2cf1061895f880a99d1d0249a8cedf223d3ed061150548aa6212c88d43<br />
Hello world ! 96 : 447ca2fa886965af084808d22116edde4383cbaa16fd1fbcf3db61421b9990b9<br />
Hello world ! 97 : 000ba61ca46d1d317684925a0ef070e30193ff5fa6124aff76f513d96f49349d<br />
<br />
And here we are. Now we just have to let the network know our block, made of "Hello world" and 97, won. <br />
<br />
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.<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Ptd