Bitcoin Wiki - User contributions [en]

Namecoin

2013-06-03T05:19:22Z

Dscotese: Edited for clarity in English.

Namecoin is an alternative distributed Domain Name System (DNS) on the basis of Bitcoin software. It expands the software to support transactions for registering, updating, and transferring domains to serve.

Like Bitcoin, Namecoin is a peer-to-peer system, which, assuming an honest majority of participants, can not be controlled by a single state or a company. Changes to the namespace of the rightful owner of a domain with a public key signature are distributed to all peer-to-peer users. The inclusion in the block chain, as the everlasting logfile is used, verifies that the transactions are authentic. The block chain grows whenever new transactions are added by any of the participants. Through a fairly intense proof-of-work process, a matching result of a cryptographic hash function is found that may be verified by all other participants. Due to the computational effort, it is impractical for a counterfeit blockchain to be created.

Currently, the top-level domain .bit used in the official domain name system is not awarded. To resolve domain name you need either the current block chain or use a public name server that participates in the Namecoin system. Namecoin uses a separate block of Bitcoin chain. The software is open source and is hosted on GitHub.

==See Also==

* [[Dot-bit]]
* [[NamecoinUs]]
* [[Cryptocoin]]

==External Links==

* [http://github.com/vinced/namecoin Namecoin Project] on GitHub
* [http://dot-bit.org dot-bit.org] project, focused on the domain registration aspect of Namecoin
* [http://whois.namecoin.us/ Namecoin (.bit) WHOIS Server]
* [http://liliontransfer.org/ Lilion Transfer] Exchange where you may exchange NameCoin to 20 currencies, 70 e-currencies, 20 e-wallets or 3 cryptocurrencies.
* [http://exchange.bitparking.com Bitparking BTC/NMC] Namecoin <=> Bitcoin exchange
* [https://vircurex.com Vircurex] Buy, sell and trade your Namecoins
*[http://www.crypto.st Crypto Street - Advanced Trading Exchange for Namecoins]

==References==
<references />

[[Category:Open Source]]
[[Category:Digital currencies]]
[[Category:Alternative cryptocurrencies]]

Development process

2012-10-28T19:30:15Z

Dscotese: /* Bitcoin Open Source Development Process */

== Bitcoin Open Source Development Process ==

The [[Original_Bitcoin_client|Bitcoin client]] project has transitioned from what was essentially a one-person software endeavor, with Satoshi functioning as the primary developer and gatekeeper for all changes, to a more distributed, free software model of development. The Linux Kernel development process is being used as the model for how changes flow into the original Bitcoin application:
# Developers work in their own source code trees, sharing and testing patches with each other. Git, using github, is the preferred source control system for development.
# When a developer thinks a patch is ready, they submit a pull request for the [https://github.com/bitcoin/bitcoin bitcoin github repository] and post a message on the [https://bitcointalk.org/index.php?board=6.0 Development and Technical Forum].
# Pull requests are discussed on the forums and if there is consensus they're safe, tested, useful, well written, match coding style, etc. then they're merged into the 'master' branch.
# The master github branch is regularly built and tested, and periodically pushed to the [http://sourceforge.net/projects/bitcoin/develop subversion repository] to become a "release candidate" and then the official, stable, released bitcoin.
# After being accepted into the mainline master branch, bugfixes are merged or backported into the current stable branch, which periodically releases stable older versions.

Please read and follow [https://raw.github.com/gavinandresen/bitcoin-git/master/doc/coding.txt coding.txt] for a description of the bitcoin coding style.

==See Also==

* [[Release process]]
* [[Original Bitcoin client]]
* [[:Category:Open_Source|Open source]]

[[es:Proceso de desarrollo]]

[[Category:Developer]]

Transaction

2012-06-04T02:01:23Z

Dscotese: Grammar number match for "transaction" explanation.

[[File:TxBinaryMap.png|thumb|right|Byte-map of Transaction with each type of TxIn and TxOut]]
A transaction is a signed section of data that is broadcast to the [[network]] and collected into [[block|blocks]]. It references a previous transaction and dedicates a certain number of bitcoins from it to a new public key (Bitcoin address). It is not encrypted (nothing in Bitcoin is encrypted).

A [[block chain browser]] is a site where every transaction included within the block chain can be viewed. This is useful for seeing the technical details of transaction in action, and for payment verification purposes.

=== Example Bitcoin Transaction ===

==== Data ====

<pre>Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG</pre>

==== Explanation ====

The input in this transaction imports 50 BTC from output #0 in transaction f5d8... Then the output sends 50 BTC to a Bitcoin address (expressed here in hexadecimal 4043... instead of the normal base58). When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction.

===== Input =====

An '''input''' is a reference to an output in a different transaction. Multiple inputs are often listed in a transaction. The values of the referenced outputs are added up, and the total is usable in the outputs of this transaction. '''Previous tx''' is a [[hash]] of a previous transaction. '''Index''' is the specific output in the referenced transaction. '''ScriptSig''' is the first half of a [[script]] (discussed in more detail later).

The script contains two components, a signature and a public key. The public key belongs to the redeemer of the output transaction and proves the creator is allowed to redeem the outputs value. The other component is an ECDSA signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by the real owner of the address in question. Various flags define how the transaction is simplified and can be used to create different types of payment.

===== Output =====

An '''output''' contains instructions for sending bitcoins. '''Value''' is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. '''ScriptPubKey''' is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because an output can only ever be referenced by a single input, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction fee]]; whoever generates the block will get it.
[[File:transaction.png|thumb|A sends 100 BTC to C and C generates 50 BTC. C sends 101 BTC to D, and he needs to send himself some change. D sends the 101 BTC to someone else, but they haven't redeemed it yet. Only D's output and C's change are capable of being spent in the current state.]]

===== Verification =====

To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a custom Forth-like [[script|scripting]] system. The input's scriptSig and the ''referenced'' output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that people have to meet in order to claim the output's value. For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys, or be redeemable with a password instead of a key.

=== Types of Transaction ===
Bitcoin currently only creates three different scriptSig/scriptPubKey pairs. These are described below.

It is possible to design more complex types of transactions, and link them together into cryptographically enforced agreements. These are known as [[Contracts]].

==== Transfer to IP address ====

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>
The sender gets the public key when talking to the recipient over IP. When redeeming coins that have been sent to an IP address, the recipient provides only a signature. The signature is checked against the public key in scriptPubKey.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <pubKey> OP_CHECKSIG
|scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_CHECKSIG
|Constants are added to the stack.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

==== Transfer to Bitcoin address ====

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
A Bitcoin [[address]] is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

==== Generation ====

Generations have a single input, and this input has a "coinbase" parameter instead of a scriptSig. The data in "coinbase" can be anything; it isn't used. Bitcoin puts the current compact-format [[target]] and the arbitrary-precision "extraNonce" number there, which increments every time the Nonce field in the [[block_hashing_algorithm|block header]] overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction.

==See Also==

* [[Script]]
* [[BTC Sender]] Transmit raw, hand-crafted transactions

[[Category:Technical]]
[[Category:Vocabulary]]
[[de:Transaktion]]
[[pl:Transakcje]]

Browser-based wallet

2012-05-30T21:11:26Z

Dscotese: /* Hybrid e-wallets */ typo

A '''browser-based wallet''' or '''wallet service''' is an online account with an external provider where bitcoins can be stored. Examples include accounts on currency exchange [[:Category:Markets|Markets]], online [[:Category:Services|Services]] and with ecommerce transaction processors. This definition also includes [[Browser-based_wallet#Hybrid_e-wallets|Hybrid e-wallets]].

<span style="color:red">Warning: When storing your bitcoins with a browser-based wallet on a third-party website, you are trusting that the operator will not abscond with your bitcoins, and that operator maintains secure systems that protect against theft, internal or external. It is recommended that you obtain the real-world identity of the website operator, ensure that sufficient recourse is available and avoid services that do not use an offline wallet ([[cold storage]]) for bitcoins that are not needed for daily transactions. Storing significant quantities of bitcoins on third party websites is not recommended.</span>

==Benefits==
* Use of a browser-based wallet provider may help improve [[anonymity]] against third-parties who watch your IP address use.
* An account with a wallet service can generally be established in just minutes.
* Some bitcoin users store some or all of their bitcoins in a browser-based wallet to avoid having to worry about keeping a local wallet [[Securing_your_wallet|secure]].
* Since withdrawals can be made to any Bitcoin address, simply using the withdrawal feature to withdraw to an address that is not yours is functionally equivalent to sending a Bitcoin payment when running the Bitcoin client locally.
* Some services offer instant, internal transfers. This allows transactions to complete without having to wait for block confirmations.

==Things to be aware of==

When bitcoins are stored online, the provider retains full control of those amounts. You are trusting a third party to maintain your Bitcoin balance on your behalf. In comparison, if you run the Bitcoin software yourself, you are in full control of your coins so long as the wallet file stored on your computer is kept secret and secure.

Other relevant things:

* You typically have less anonymity with respect to those who run the online wallet site.
* If a payment is made from an online wallet, the transaction's "from" [[address]] is an address for the wallet provider and not an address reserved specifically for the sender. This is because the wallet service provider may service the payment from any coins in its possession - your balance is not associated with any particular coins, any more than your balance at your local bank is associated with any specific bills. Thus if the recipient were to "return" any bitcoins to the same address they were sent from, the sender would not receive those bitcoins.

* Not all wallet providers reserve a bitcoin address for the account holder indefinitely. Bitcoin addresses generally work best when one is assigned for each use. There is the risk of showing an address from a wallet provider in a directory or on a web page (for donations, as an example) as there is the possibility that at the future date when those bitcoins are sent that the intended recipient still has the wallet account. The same concern applies should the wallet provider cease operations.

* There is no trivial way to guarantee that the amount of bitcoins showing for the account holder's balance are truly being held in reserve by the wallet provider.

* Transactions to a Bitcoin address from the same wallet provider are usually completed internally and, if so, will not be processed on the Bitcoin P2P network. Auditing tools such as the [[Block Explorer]] will not show any activity for this transaction.
** Some wallet providers allow amounts below 0.01 BTC to be sent if the transaction is to another account holder on the same service. This allows an inexpensive and immediate method to detect if the recipient is using the same wallet provider.

* The wallet service provider's wallet may be vulnerable to security breaches, loss, or theft. Because Bitcoin transactions are irreversible, there may be limited or no recovery if a provider's master wallet is compromised. Wallet providers who implement preventative controls - such as keeping their reserves in an [[offline wallet]] - are likely to be safer.

==Hybrid e-wallets==

After several online bitcoin wallets were hacked, a second wave of online Bitcoin wallets entered the market. Hybrid wallets generally use Javascript on the users browser to manage private keys and create payments.

These wallets differed from traditional online wallet services because the user actually owns the private keys inside their wallet. This approach has several advantages:

* The "from" address of a transaction originates from the actual bitcoin address of the user.
* The user can lookup their account balance in the blockchain and which guarantees their account balance is correct.
* Users can easily export their private keys out of a wallet to use with another bitcoin client or wallet provider.
* The users keys are stored encrypted on the server offering some protection for security breaches.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]
* [[Bitcoin faucet]]
* List of [[:Category:HybridEWallets|HybridEWallets]]
* List of [[:Category:eWallets|eWallets]]

Talk:Block

2012-05-29T19:04:29Z

Dscotese:

== Proposed FAQ question and answer ==
==== Won't the reward be too small? ====
As the reward shrinks, it may become unprofitable for anyone to create a new block, but as indicated above, the difficulty of the math problem is adjusted every two weeks in order to maintain the rate at which blocks are created. Since it takes about four years to generate the 210,000 blocks and their corresponding bitcoin rewards, it is virtually impossible to ever get to 21 million. At any point in time, it will take about four years to get '''halfway''' from the number of bitcoin currently in existence to the 21 million count. It's an unreachable goal, barring a kind of catastrophically destructive cooperation between all bitcoin miners that is untenable.

Only, I don't know if my understanding is correct. [[User:Dscotese|Dscotese]] 19:04, 29 May 2012 (GMT)

== Each block contains all recent transactions, a nonce (random number), and the hash of the previous block. ==
The nonce is a seed that starts at zero and is incremented until the block hashes below the target.
Hence, it should not be called "random".

== What if I'm 1% towards calculating a block and...? ==

"There's no such thing as being 1% towards solving a block. You don't make progress towards solving it."

Is this true? I don't know if there's a nonce which will solve any given block, but for a block that is solvable, it's possible to be 1% of the way towards finding it. Supposing it takes 10 million attempts to 'solve' a block, then after 100,000 attempts you could say you were 1% towards solving it. You're certainly closer to solving it than you were before those 100,000 failed attempts, aren't you? [[User:Dooglus|Dooglus]] 05:05, 15 January 2011 (GMT)
:No one can know how many tries it will take to solve the block. After the fact you might say that at some point you had finished 1% of the necessary calculation for that block, but this was not really "progress".

:If you go back in time after completing a block and don't generate for one of the days that you did originally, then you could actually end up getting the block ''sooner'', as the work required is random. [[User:Theymos|theymos]] 11:06, 15 January 2011 (GMT)

Probabilistically speaking, one can make a "best guess" for how long it will take to solve a block. A problem with probabilistic estimation, for example, is that it may say it will take 10 hours to solve the block, with a standard deviation of 15 hours. How much more work do you have when you've worked on it for 10 hours? The answer is that you have ~10 hours more work :).

But assuming all incorrect hashes are exhausted first, the maximal number of tries needed to solve the block is ~2<sup>256</sup>. So, there exists an upper limit (albeit, it is an obscenely large one!) on the amount of work you can do. Progress is made, just very slowly. --[[User:Dlo|Dlo]] 20:28, 11 April 2011 (GMT)
:That's not the maximum. You can't predict the hash outcome, so you could try forever and still get values above the target. You'd get repeat hash values from the same input. [[User:Theymos|theymos]] 03:47, 18 April 2011 (GMT)
::I can predict the hash outcome by calculating SHA-256 with my mighty x86 processor. :) IMO "predicting" is irrelevant here. Dlo is assuming that the hash function is injective, therefore the number of incomes (giving outcome above the target) <= 2^256. But the hash function is not injective (by the cardinality argument: the set of incomes is infinite and the set of outcomes is finite). --[[User:Shrewdwatson|Shrewdwatson]] 13:49, 23 April 2011 (GMT)